4 posts tagged with "datastore"

For services that require real-time responses, an in-memory data store is a key component. As fast read and write workloads such as user sessions, caches, and queues grow, database response performance becomes directly tied to service experience. In operations, stable failover, security patches, and version lifecycle management are just as important as performance.

KakaoCloud MemStore now supports Valkey 8.1 as a new engine, in addition to the existing Redis OSS family. In this post, we introduce the Valkey engine and the key operational points to check when configuring a Valkey-based cluster in MemStore.

Understanding the Valkey engine​

MemStore is a fully managed in-memory data store service. It runs in a VPC environment and helps reduce database operation overhead by automating tasks such as node provisioning, network configuration, and node status management. Instead of building and managing a cache database directly, users can use managed features such as cluster creation, backup, monitoring, and access control.

Valkey is an open-source in-memory data store engine based on Redis OSS 7.2 and earlier open-source Redis versions. In MemStore, Valkey is provided as a managed in-memory data store engine alongside the Redis OSS family.

The Valkey engine may be a good option in the following cases.

• You want to configure a newly created cache or session store based on Valkey.
• You want to review the Valkey engine while keeping a familiar Redis OSS-based usage experience.
• You want to operate cluster mode, high availability, backup, and monitoring as managed service features.

Valkey 8.1 in MemStore​

MemStore currently provides Valkey 8.1 and Redis OSS versions up to 7.2. When creating a cluster, you select an engine version and configure the parameter group and cluster settings that match the selected engine version.

Valkey also supports the key managed features of MemStore. Clusters are deployed in the user's VPC and subnets, and security groups control accessible IP ranges and ports. With cluster mode, data can be distributed across multiple shards, and Primary/Replica configuration helps prepare for node failures.

Operational features are also available. Automatic and manual backups help secure data for recovery, and clusters can be restored from backup files stored in Object Storage. TLS 1.2 transport encryption and user authentication can strengthen access security, while key metrics such as Valkey, CPU, memory, and network metrics help monitor cluster status.

Even when you choose Valkey, existing MemStore operational features such as cluster creation, backup, and monitoring are still available.

Operational Differences Between Valkey and Redis OSS​

Valkey and Redis OSS are provided as in-memory data store engines within MemStore. The basic flow for creating and operating clusters is similar, but some differences, such as shard configuration and failover behavior, affect operational policy.

Both engines commonly support the following MemStore operational features.

• Shard-based distributed structure or single-shard structure depending on whether cluster mode is enabled
• High availability configuration based on Primary/Replica structure
• Network access control through VPCs, subnets, and security groups
• Automatic backup, manual backup, and backup-based restore
• TLS 1.2 transport encryption, user authentication, and key metrics monitoring

The following items differ depending on the selected engine.

Cluster mode configuration​

Both engines can distribute data across multiple shards when cluster mode is enabled. The difference is the minimum number of shards. Valkey can be configured from a minimum of 3 shards, while Redis OSS can be configured from a minimum of 1 shard. Both engines support up to 12 shards.

The number of shards affects both performance and operational complexity. Increasing shards can help distribute data for scalability, but application data access patterns and cluster operation methods should also be considered. When using cluster mode with Valkey, plan the initial configuration based on the minimum of 3 shards.

When cluster mode is disabled, both engines create a cluster with a single-shard structure. A single-shard configuration is simpler to start with, but for environments that require high availability, review the node count and automatic failover policy together. Because the automatic backup option provided by MemStore is available only when there are 2 or more nodes, consider using at least 2 nodes for stable service operation.

Automatic failover​

When cluster mode is disabled, automatic failover settings differ clearly between the two engines. For Valkey, automatic failover is enabled automatically when there are 2 or more nodes. For Redis OSS, users can choose whether to enable automatic failover when there are 2 or more nodes, and can change the setting after cluster creation.

Automatic failover promotes a Replica node to Primary when the Primary node fails, helping maintain service continuity. For services that require high availability, review the engine, node count, subnet placement, and failover policy together.

Manual promotion​

Manual promotion also works differently. For Valkey, a Replica node can be promoted to Primary regardless of whether cluster mode or automatic failover is enabled. For Redis OSS, when cluster mode or automatic failover is enabled, the service automatically performs promotion when needed based on node failure conditions, and users cannot request promotion directly.

Manual promotion is useful when operators need direct control over node role changes during failure response or maintenance. If your operating procedure requires promoting a Replica to Primary at a specific time or explicitly controlling the failover flow, consider this difference when choosing an engine.

What to check before adoption​

Valkey 8.1 is an engine that can be selected when creating a new cluster. If you plan to configure a new Valkey-based cluster, first check the features and settings used by your application, along with restore conditions.

When restoring a cluster from backup, you can restore only to the same or a later engine version than the version used for the backup. Restore may also fail if the cache size of the source backup is 60% or more of the memory of the target cluster node type, so check the data size and target configuration together.

Before designing a new workload or adopting Valkey, review the following items.

• Whether the features and settings used by the application are supported by the selected engine version
• Whether the cluster mode setting, number of shards, and number of nodes fit the workload scale
• Whether the automatic failover and manual promotion policies match the operating procedure
• Whether the cache size of the source backup satisfies the memory condition of the target node type
• Whether any engine version past EOL is still being used

Get started​

You can create a Valkey 8.1-based MemStore cluster from Data Store > MemStore in the KakaoCloud Console. When creating a cluster, select the engine version and configure cluster mode, shards and nodes, VPC, security groups, automatic backup, TLS, and user authentication options.

If you are using MemStore for the first time, start with a small new cluster to check application connectivity, authentication, security groups, and backup policy. For production environments, adjust cluster mode, shard count, node count, and failover policy based on workload characteristics.

KakaoCloud will continue to expand supported engines and operational features so MemStore can serve as a stable data layer for applications that require fast responses.

Learn more about MemStore
MemStore release notes

Valkey® is a registered trademark of LF Projects. Redis® is a registered trademark of Redis Ltd.

The MySQL 8.0 series reached its official End of Life (EOL) at the end of April, and security updates and technical support are expected to end going forward. To strengthen service stability and security, KakaoCloud recommends upgrading the engine to MySQL LTS (Long Term Support) 8.4, and supports MySQL Engine Update work through the Maintenance service.

All instance groups currently using the MySQL 8.0 engine can upgrade their engine to version 8.4 by specifying the desired date and time directly. However, because this is a major version update, technical review such as backward compatibility and system variable changes must be performed before the actual work.

Therefore, in this post, we share the major changes and key checklist items that must be reviewed for stable service operation before updating from MySQL 8.0 to the 8.4 series.

---

Major changes in the MySQL 8.4 series​

The 8.4 LTS version includes various default value changes and feature improvements for performance optimization and stronger security.

1. Default authentication plugin changed​

The previously used mysql-native-password has been removed, and caching_sha2_password has been set as the default authentication plugin (password plugin).

2. Parameter default value changes​

The table below is excerpted and translated from the official MySQL documentation. In the 8.4 LTS version, default values for major parameters have been significantly changed to maximize system performance.

In particular, resource allocation methods such as InnoDB I/O capacity and log buffer size have been optimized for modern hardware specifications, so be sure to compare them with existing settings before upgrading. For detailed instructions on creating and managing parameter groups, see the separate documentation.

Performance and I/O related changes

Parameter	MySQL 8.4	MySQL 8.0
innodb_io_capacity	10000	200
innodb_io_capacity_max	2x innodb_io_capacity	Same (minimum default 2000)
innodb_flush_method (Linux)	O_DIRECT (fsync if unsupported)	fsync
innodb_use_fdatasync	ON	OFF
innodb_read_io_threads	1/2 of logical processors (minimum 4)	4
innodb_parallel_read_threads	1/8 of logical processors (minimum 4)	4

Memory and buffer management

Parameter	MySQL 8.4	MySQL 8.0
innodb_buffer_pool_instances	innodb_buffer_pool_size 1 GiB or less → 1 Over 1 GiB → Automatic calculation based on CPU/chunk (1~64)	8 (1 if less than 1 GiB)
innodb_log_buffer_size	64 MiB (67,108,864)	16 MiB (16,777,216)
innodb_buffer_pool_in_core_file	OFF if MADV_DONTDUMP is supported; otherwise ON	ON
innodb_numa_interleave	ON	OFF

InnoDB behavior changes

Parameter	MySQL 8.4	MySQL 8.0
innodb_change_buffering	none (not used)	all
innodb_adaptive_hash_index	OFF	ON
innodb_page_cleaners	Same as innodb_buffer_pool_instances	4
innodb_purge_threads	Logical processors ≤ 16 → 1 Over 16 → 4	4

Doublewrite and log handling

Parameter	MySQL 8.4	MySQL 8.0
innodb_doublewrite_files	2	2x innodb_buffer_pool_instances
innodb_doublewrite_pages	128	innodb_write_io_threads value (default 4)

Automation and server settings

Parameter	MySQL 8.4	MySQL 8.0
--innodb-dedicated-server	When enabled, no flush_method change Redo log capacity calculation method changed from memory-based to CPU-based	OFF

TempTable behavior changes

Parameter	MySQL 8.4	MySQL 8.0
temptable_max_ram	3% of total memory (automatically adjusted within 1~4 GiB)	1 GiB (1,073,741,824)
temptable_max_mmap	0 (not used)	1 GiB
temptable_use_mmap	OFF	ON

3. Automatic histogram update feature added​

An automatic histogram update feature for query optimization has been added. In previous versions, histograms had to be updated manually through ANALYZE TABLE, but starting with MySQL 8.4, they are updated automatically depending on conditions.

For detailed application methods, see the ANALYZE TABLE documentation.

4. Replication SQL syntax changed​

Replication-related terms have changed from MASTER/SLAVE to SOURCE/REPLICA, and major SQL syntax has changed as follows.

MySQL 8.4	MySQL 8.0	Function
SHOW BINARY LOG STATUS	SHOW MASTER STATUS	Binary log position that is the current server's start position (file name, position)
SHOW BINARY LOGS	SHOW MASTER LOGS	List of binary log files in the server
SHOW REPLICA STATUS	SHOW SLAVE STATUS	Detailed replication status (IO/SQL threads, delay, and more)
SHOW REPLICAS	SHOW SLAVE HOSTS	List of replicas connected to the current server

---

Required checklist for a stable upgrade​

To prevent server, authentication, and application-related failures that may occur during the upgrade process, be sure to check the following items in advance.

1. MySQL Shell Upgrade Checker​

Before upgrading, it is important to use the MySQL Shell utility to carefully review resource compatibility. This tool automatically analyzes the following items and diagnoses stability.

• Check server settings and schema structure
• Check compatibility of running SQL queries
• Detect removed features and conflicts with new reserved words

Through these checks, deprecated options and similar items can be identified in advance, effectively preventing server startup failures or unexpected feature errors that may occur immediately after the upgrade.

2. Check authentication plugin compatibility​

When upgrading the MySQL version, the database's default authentication method may change, so authentication plugin compatibility in the current application environment must be checked. In older environments that do not support the latest plugins, login failures may occur immediately after the upgrade.

In particular, check whether the environment supports the latest plugins such as caching_sha2_password. If unsupported, login itself may fail, so you must check the authentication plugin for user accounts in advance and determine whether driver upgrades or plugin changes are needed.

3. Pre-check MySQL Connector (driver)​

You must check compatibility between the MySQL connector used by the application and the server version in advance.
Language-specific drivers such as MySQL Connector/J are affected by server version in terms of authentication, protocol, and option compatibility. If old drivers are used, issues such as connection failures, TLS errors, or abnormal query behavior can occur, so driver compatibility must be checked in advance and replaced with the latest version if necessary.

---

So far, we have reviewed the need to upgrade to MySQL 8.4 LTS following the end of support for MySQL 8.0, the major changes, and the required checklist for a successful transition.

A major version upgrade is more than a simple engine replacement. It is an important opportunity to maximize modern hardware performance and strengthen the security system. However, because there are significant technical changes such as authentication method and driver compatibility, we recommend carefully reviewing them using the MySQL Shell Upgrade Checker and the pre-check guide introduced above.

KakaoCloud is working to provide the optimal environment and technical support so that customers' databases can operate stably without interruption. We hope this post helps you operate services safely. If you have any questions or need support, please contact us anytime through the Helpdesk.

Thank you.

Starting in August, KakaoCloud will release MemStore, a new in-memory data storage service, replacing the existing Redis® service. This service name change was decided to respond quickly to the recent Redis® license change and provide users with improved features and stability.

Why MemStore?​

In March this year, Redis Labs announced that it would change the existing BSD 3-Clause license to a dual license model called Redis Source Available License v2 (RSALv2) and Server Side Public License v1 (SSPLv1). As a result, a separate license is required to use Redis® commercially, affecting multiple cloud service providers including KakaoCloud.
In response to this change and to provide sustainable service, KakaoCloud is introducing MemStore, a managed cache database service.

Key features and benefits of MemStore​

KakaoCloud MemStore preserves the performance and features of the existing Redis® service while including cache database features that will be further expanded in the future.

• High performance and stability: MemStore stores all data in memory, providing high-speed data access and processing.
• Automatic backup and restore: Data is periodically backed up to separate storage so it can be easily restored in case of data loss. Snapshot and backup features are provided to protect user data from unexpected situations.
• Enhanced security: Security features are strengthened in line with the new license model, placing customer data safety first. In addition, virtual private cloud (VPC) network and security group connection features provide a secure database operating environment by controlling access from outside specific IP ranges.
• Redundant configuration and high availability: High availability is ensured through an Active-Standby redundant configuration. If a failure occurs on the Active server, the Standby server immediately takes over operations to minimize service interruption.

Support for existing users​

Redis® service resources of existing KakaoCloud users are automatically converted to MemStore without service impact. In addition, all services that can be used together with Redis® (Cloud Trail, Alert Center, Monitoring, and others) can be used without impact from the MemStore service name change.

Through MemStore, KakaoCloud will work to provide customers with a better service experience and build a sustainable service environment that keeps pace with the latest technology trends.

For more information, see the KakaoCloud website and technical documentation.
Thank you.

Redis® is a trademark of Redis Ltd. MemStore is based on open-source Redis® version 7.2 or earlier.

Hello, KakaoCloud's MySQL service is now available in the kr-central-2 region.

KakaoCloud MySQL is a fully managed database service built on an open-source relational database management system (RDBMS).

This release of KakaoCloud MySQL includes support for automatic instance recovery, adding read-only instances (read replicas), and high availability.

Key features and supported items of the MySQL service are as follows.

• High availability and Multi-AZ support: Ensures high availability and lets you create an instance group by selecting subnets through a Multi-AZ configuration.
• Auto Failover: Supports not only manual failover but also automatic failover. When a system failure occurs, the database can automatically switch to another node to minimize service interruption.
• MySQL 8.0.34 support: Lets you use the latest features and security updates of MySQL 8.0.34.
• Support for m2a and r2a instance specifications: Lets you choose an instance that fits your workload and expect resource optimization and performance improvement.

For more information, see the MySQL page.

We will continue working to provide safer and more convenient cloud services.

Thank you.