This topic provides answers to frequently asked questions about PolarDB for MySQL, , and .
Basic questions
Q: What is PolarDB?
A: PolarDB is a relational database cloud service deployed in data centers across more than 10 regions worldwide. It provides out-of-the-box online database services. PolarDB supports three independent engines, which allows it to be fully compatible with MySQL and PostgreSQL, and highly compatible with Oracle syntax. A PolarDB cluster provides a maximum storage capacity of 200 TB. For more information, see What is PolarDB for MySQL Enterprise Edition?.
Q: Why does the cloud-native database PolarDB outperform traditional databases?
A: Compared with traditional databases, the cloud-native database PolarDB can store hundreds of terabytes of data. It also provides a wide array of features, such as high availability, high reliability, rapid elastic upgrades and downgrades, and lock-free backups. For more information, see Benefits.
Q: When was PolarDB released? When was it available for commercial use?
A: PolarDB was released for public preview in September 2017 and became available for commercial use in March 2018.
Q: What are clusters and nodes?
A: PolarDB Cluster Edition uses a multi-node cluster architecture. A cluster has one primary node and multiple read-only nodes. A single PolarDB cluster can be deployed across zones but not across regions. The PolarDB service is managed and billed at the cluster level. For more information, see Glossary.
Q: Which programming languages does PolarDB support?
A: PolarDB supports programming languages including Java, Python, PHP, Go, C, C++, .NET, and Node.js. Programming languages that can interact with native MySQL can also interact with PolarDB for MySQL. For more information, visit the MySQL official website.
Q: Which storage engines does PolarDB support?
A: PolarDB has two editions. The available storage engines vary based on the edition.
PolarDB for MySQL Cluster Edition exclusively uses the InnoDB storage engine for all tables. When you create a table, PolarDB for MySQL automatically converts non-InnoDB engines, such as MyISAM, Memory, and CSV, to the InnoDB engine. Therefore, data tables that did not use InnoDB before migration can still be migrated to PolarDB for MySQL.
Q: Is PolarDB a distributed database?
A: Yes, it is. PolarDB is a distributed storage cluster based on the Parallel Raft consensus protocol. Its compute engine consists of 1 to 16 compute nodes that are distributed on different servers. The cluster provides a maximum storage capacity of 200 TB and a maximum of 88 CPU cores and 710 GB of memory. The cluster allows online dynamic scaling of storage and computing resources, which ensures that normal business operations are not affected during the scaling process.
Q: After I purchase PolarDB, do I need to purchase PolarDB-X database middleware to implement sharding?
A: Yes, you do.
Q: Does PolarDB support table partitioning?
A: Yes, it does.
Q: After I purchase a PolarDB cluster, can I change its region?
A: No, you cannot. You cannot change the region of a cluster after you purchase it.
Q: Does PolarDB have a default partitioning mechanism?
A: PolarDB implements partitioning at the storage layer, which is transparent to users.
Q: How does a single-node cluster ensure service availability and data reliability?
A: A single-node cluster is designed to operate a single compute node for specific purposes. Although it has only one node, a single-node cluster uses technologies such as second-level compute scheduling and distributed multi-replica storage to ensure high service availability and data reliability.
Q: How do I purchase a single-node PolarDB cluster?
A: Single-node clusters are no longer sold. However, you can create a single-node PolarDB cluster by setting the number of read-only nodes to 0 in the Number Of Nodes section when purchasing a cluster.
Compatibility
Q: Is PolarDB for MySQL compatible with MySQL Community Edition?
A: Yes, PolarDB for MySQL is fully compatible with MySQL Community Edition.
Q: What transaction isolation levels are supported?
A: PolarDB for MySQL supports the READ_UNCOMMITTED, READ_COMMITTED (default), and REPEATABLE_READ isolation levels. It does not support the SERIALIZABLE isolation level.
Q: Are the query results of the SHOW PROCESSLIST statement in PolarDB for MySQL the same as those in MySQL Community Edition?
A: If you use the primary endpoint to execute the SHOW PROCESSLIST statement, the query results are the same. If you use the cluster endpoint to execute the SHOW PROCESSLIST statement, the query results are different. In the query results of the statement in a PolarDB for MySQL cluster, you can find multiple records that have the same thread ID. Each of these records corresponds to a node in the cluster.
Q: Is the metadata lock (MDL) mechanism of PolarDB for MySQL the same as that of MySQL Community Edition?
A: The metadata lock (MDL) mechanism of PolarDB for MySQL is the same as that of MySQL Community Edition. However, the database nodes of PolarDB for MySQL are based on a shared storage architecture. This means that when data definition language (DDL) operations are performed on the primary node, the read-only nodes may access intermediate data from the DDL operations, which can cause data inconsistency. To prevent this, PolarDB for MySQL uses redo logs to synchronize the exclusive MDLs that are involved in DDL operations to read-only nodes. This prevents other user threads on the read-only nodes from accessing the table data during the DDL operations. In specific scenarios, this may block DDL operations. You can execute the
show processlistcommand to view the state of DDL operations. If the DDL operations are in theWait for syncing with replicasstate, this indicates that such blocking has occurred. For information about how to resolve this issue, see View the DDL execution status and MDL status.Q: Is the binary logging format of PolarDB for MySQL the same as the native binary logging format of MySQL?
A: There is no difference.
Q: Does PolarDB support the performance schema and the sys schema?
A: Yes, it does.
Q: Does PolarDB for MySQL use the same table statistics collection mechanism as MySQL Community Edition?
A: The table statistics of the primary node in PolarDB for MySQL are consistent with those in MySQL Community Edition. To ensure that execution plans are consistent between the primary node and read-only nodes, each update of table statistics on the primary node is synchronized to the read-only nodes. You can also execute the
ANALYZE TABLEoperation on a read-only node to proactively load the latest statistics from the disk.Q: Does PolarDB support XA transactions? Is it different from the official MySQL?
A: Yes, it is. There is no difference.
Q: Does PolarDB support full-text indexes?
A: Yes, it does.
NoteCurrently, when you use full-text indexes, some data latency exists in the index cache on read-only nodes. We recommend that you use the primary endpoint for both read and write operations that involve full-text indexes to read the latest data.
Q: Is Percona Toolkit supported?
A: Yes, it is, but we recommend that you use online DDL.
Q: Is gh-ost supported?
A: Yes, it is, but we recommend that you use online DDL.
Billing
Q: What are the billable items of a PolarDB cluster?
A: The billable items include storage space, compute nodes, backups (with a free quota), and SQL Explorer (optional). For more information, see Billable items.
Q: Which files are stored in the billable storage space?
A: The billable storage space stores database table files, index files, undo log files, redo log files, binary log files, slow log files, and a small number of system files. For more information, see Overview.
Q: How do I use storage plans for PolarDB?
A: You can use storage plans to offset the storage fees of subscription or pay-as-you-go clusters. For example, if you have three clusters that each have a storage capacity of 40 GB, the total capacity is 120 GB. You can use a 100 GB storage plan for the three clusters. Then, you are charged for the excess 20 GB of storage on a pay-as-you-go basis. For more information, see Purchase a storage plan.
Q: How am I charged if I add a read-only node to the cluster?
A: The price of a read-only node is the same as that of a primary node. For more information, see Pricing details for compute nodes.
Q: Is the storage capacity doubled after I add a read-only node?
A: No, it is not. PolarDB uses a compute-storage decoupled architecture. The read-only node that you purchase is a computing resource. Therefore, the storage capacity is not increased.
Storage space is serverless. You do not need to select a capacity when you purchase a cluster. The storage capacity automatically scales as your data grows. You are charged only for the actual amount of data that you use. Each cluster specification has a corresponding maximum storage capacity. To increase the storage capacity limit, you can upgrade the cluster specifications.
Q: How can I stop being charged for a pay-as-you-go cluster?
A: If you no longer need the cluster, you can release the cluster. After the cluster is released, no more fees are generated.
Q: Can I change the specifications of a cluster during a temporary upgrade?
A: During a temporary upgrade (when the cluster is in the running state), you can manually upgrade the specifications. However, you cannot manually downgrade the specifications, enable automatic specification changes, or add or remove nodes.
Q: What is the public bandwidth of PolarDB? Are there any fees?
A: PolarDB itself does not have a public bandwidth limit. The limit depends on the bandwidth of the SLB service that you use. You are not charged for the public connections of PolarDB.
Q: Why are fees still generated every day for a subscription cluster?
A: The billable items of PolarDB mainly include compute nodes (primary and read-only nodes), storage space, data backups (charged only when the free quota is exceeded), SQL Explorer (optional), and Global Database Network (GDN) (optional). For more information, see Billable items. The subscription billing method means that you prepay the fees for the compute nodes of a cluster when you create it. The fees for storage space, data backups, and SQL Explorer are not included. During actual database use, a certain amount of storage fee is deducted from your account on an hourly basis based on the storage space occupied by the cluster. Therefore, pay-as-you-go bills are still generated for subscription clusters.
Q: Am I charged extra for migrating an RDS instance to PolarDB with a single click?
A: The one-click migration process is free. You are charged only for the RDS instance and the PolarDB cluster itself.
Q: Why am I still charged for storage space after deleting table data in PolarDB using the
deletecommand?A: The
deletecommand only marks the table as deleted. It does not release the tablespace.
Cluster access (read/write splitting)
Q: How do I implement read/write splitting in PolarDB?
A: You can simply use the cluster endpoint in your application. Read/write splitting is then implemented based on the configured read/write mode. For more information, see Configure a database proxy.
Q: How many read-only nodes can a PolarDB cluster support?
A: PolarDB uses a distributed cluster architecture. A cluster contains one primary node and up to 15 read-only nodes. At least one read-only node is required to ensure high availability.
Q: Why are loads unbalanced among read-only nodes?
A: Loads may be unbalanced among read-only nodes because there are few connections to the read-only nodes or a read-only node is not included when a custom cluster endpoint is allocated.
Q: What causes high or low loads on the primary node?
A: High loads on the primary node can be caused by several factors: direct connections to the primary endpoint, the primary node accepting read requests, many transaction requests, high primary/secondary replication latency that causes requests to be routed to the primary node, or read-only node exceptions that cause read requests to be routed to the primary node.
Low loads on the primary node may occur because the option to offload reads from the primary node is enabled.
Q: How do I reduce the load on the primary node?
A: You can use the following methods to reduce the load on the primary node:
Use the cluster endpoint to connect to the PolarDB cluster. For more information, see Configure a database proxy.
If many transactions cause high pressure on the primary node, you can enable the transaction splitting feature in the console. This routes some queries in the transactions to read-only nodes. For more information, see Transaction splitting.
If requests are routed to the primary node due to replication latency, you can consider lowering the consistency level. For example, you can use eventual consistency. For more information, see Consistency level.
If the primary node accepts read requests, the load on the primary node may be high. You can enable the offload reads from primary node feature in the console to reduce the number of read requests that are routed to the primary node. For more information, see Offload reads from primary node.
Q: Why can I not read the data that I just inserted?
A: This issue may be caused by the consistency level configuration. The cluster endpoint of PolarDB supports the following consistency levels:
Eventual consistency: Regardless of whether it is the same session (connection) or a different session, eventual consistency does not guarantee that you can immediately read the newly inserted data.
Session consistency: You can always read the data inserted in the same session.
Global consistency: You can always read the latest data in both the same session and different sessions.
NoteThe higher the consistency level, the poorer the performance and the greater the pressure on the primary node. Select the consistency level with caution. For most application scenarios, session consistency can ensure that your business runs as expected. For a few statements that have strong consistency requirements, you can use the
/* FORCE_MASTER */hint. For more information, see Consistency level.Q: How do I force an SQL statement to be executed on the primary node?
A: When you use a cluster endpoint, you can add
/* FORCE_MASTER */or/* FORCE_SLAVE */before an SQL statement to force its routing direction. For more information, see Hint syntax./* FORCE_MASTER */forces requests to be routed to the primary node. This can be used to handle a few read requests that have high consistency requirements./* FORCE_SLAVE */forces requests to be routed to a read-only node. This can be used to handle a few scenarios where the PolarDB proxy requires special syntax to be routed to a read-only node to ensure correctness. For example, statements that call stored procedures and use multistatement are routed to the primary node by default.
NoteHints have the highest routing priority and are not subject to the constraints of consistency levels and transaction splitting. Evaluate the impact before you use hints.
Do not include statements that modify GUC parameters in the hint, such as /*FORCE_SLAVE*/ set enable_hashjoin = off;. Such statements may cause unexpected query results.
Q: Can I assign different endpoints to different services? Can services be isolated using different endpoints?
A: You can create multiple custom endpoints for different services. If the underlying nodes are different, the custom endpoints can also provide an isolation effect and will not affect each other. For more information about how to create a custom endpoint, see Add a custom cluster endpoint.
Q: If there are multiple read-only nodes, how do I create a separate single-node endpoint for one of them?
A: You can create a single-node endpoint only when the read/write mode of the cluster endpoint is Read-only and the cluster has three or more nodes. For more information, see Set a cluster endpoint.
WarningAfter you create a single-node endpoint, if the node fails, the endpoint may be unavailable for up to 1 hour. Do not use it in a production environment.
Q: What is the maximum number of single-node endpoints that can be created in a cluster?
A: If your cluster has 3 nodes, you can create a single-node endpoint for only 1 read-only node. If your cluster has 4 nodes, you can create single-node endpoints for 2 read-only nodes. The same rule applies to other numbers of nodes.
Q: I use only the primary endpoint, but I find that the read-only nodes also have loads. Does the primary endpoint also support read/write splitting?
A: The primary endpoint does not support read/write splitting. It always connects only to the primary node. It is normal for read-only nodes to have a small number of queries per second (QPS). This is not related to the primary endpoint.
Management and maintenance
Q: How do I add fields and indexes online?
A: You can use tools such as the native online DDL, pt-osc, and gh-ost. We recommend that you use the native online DDL operation.
NoteWhen you use the pt-osc tool, do not use parameters for setting primary/secondary detection, such as the
recursion-methodparameter. This is because the pt-osc tool performs primary/secondary detection based on binary logging replication. However, PolarDB uses physical replication internally and does not have replication information based on binary logging.Q: Is the bulk insert feature supported?
A: Yes, it is.
Q: If I write data only to the write-only node, is bulk insert supported? What is the maximum number of values that can be inserted at a time?
A: Yes, it is. The maximum number of values that can be inserted at a time is determined by the value of the max_allowed_packet parameter. For more information, see Replication and max_allowed_packet.
Q: Can I perform bulk insert operations using a cluster endpoint?
A: Yes, you can.
Q: Is there a replication delay between the primary node and read-only nodes?
A: Yes, there is a millisecond-level delay between them.
Q: In what situations does the replication delay increase?
A: The replication delay increases in the following situations:
The write load on the primary node is high, which generates more redo logs than the read-only nodes can apply in time.
The load on the read-only nodes is too high, which preempts resources that were originally used to apply redo logs.
An I/O bottleneck occurs, which slows down the reading and writing of redo logs.
Q: If a replication delay exists, how do I ensure query consistency?
A: You can use a cluster endpoint and select an appropriate consistency level for it. The current consistency levels from highest to lowest are global consistency (strong consistency), session consistency, and eventual consistency. For more information, see Consistency level.
Q: Can a recovery point objective (RPO) of 0 be guaranteed in the event of a single node failure?
A: Yes, it can.
Q: How are specification upgrades, such as from 2 CPU cores and 8 GB of memory to 4 CPU cores and 16 GB of memory, implemented in the backend? What is the impact on my business?
A: The proxy and database nodes of PolarDB are upgraded to the new specifications. A rolling upgrade of multiple nodes is used to minimize the impact on your business. Currently, each upgrade takes about 10 to 15 minutes, and the impact on your business lasts no more than 30 seconds. During this period, one to three transient connections may occur. For more information, see Manually change specifications.
Q: How long does it take to add a node? Does it affect my business?
A: It takes 5 minutes to add a node. This does not affect your business. For more information about how to add a node, see Add a read-only node.
NoteAfter a new read-only node is added, new read/write splitting connections forward requests to that read-only node. Read/write splitting connections that were established before the new read-only node was added do not forward requests to the new read-only node. You must disconnect and re-establish the connection. For example, you can restart the application.
Q: How long does it take to upgrade to the latest revision version? Does it affect my business?
A: PolarDB uses a rolling upgrade of multiple nodes to minimize the impact on your business. A version upgrade usually takes no more than 30 minutes. During the upgrade, the database proxy or the DB kernel engine is restarted, which may cause transient database connections. We recommend that you perform the upgrade during off-peak hours and make sure that your application has an automatic reconnection mechanism. For more information, see Minor version management.
Q: How is an automatic failover performed?
A: PolarDB uses an active-active high availability cluster architecture. An automatic failover is performed between the read/write primary node and read-only nodes, where the system automatically elects a new primary node. Each node in PolarDB has a failover priority, which determines the probability of being elected as the primary node during a failover. When multiple nodes have the same priority, they have the same probability of being elected as the primary node. For more information, see Automatic/manual primary/secondary failover.
Q: What permissions are required to terminate a connection in PolarDB for MySQL?
A: In MySQL, you must have the required permissions to terminate a connection using the
KILLcommand. Specifically, to terminate the connection of another regular user, you must have thePROCESSpermission.NoteTerminate your own connection: Any user can terminate their own connection. No extra permissions are required.
Terminate other sessions of the same user: The
PROCESSpermission is required.Terminate connections of other regular users: In PolarDB for MySQL, a privileged account must use the
KILLcommand with caution.
Q: The error message
[ERROR] InnoDB: fil_space_extend space_name:xxxappears in the running log. Does this affect my business?A: No, this does not affect your business. This log indicates that after the read/write node of a PolarDB cluster extends the file size, the read-only node synchronizes the file size information in its memory. For a cluster that runs MySQL 5.7, the log level is not adjusted from
ERROR. Therefore, this can be considered anINFO-level log on the read-only node and does not affect your business.
Backup and restoration
Q: What backup method does PolarDB use?
A: PolarDB uses snapshots to back up data. For more information, see Backup method 1: Automatic backup and Backup method 2: Manual backup.
Q: How fast can a database be restored?
A: Currently, it takes 40 minutes per TB to restore (clone) data from a backup set (snapshot). If you restore data to a point in time, the time required to apply redo logs is also included. This part of the restoration takes about 20 to 70 seconds per GB. The total restoration time is the sum of these two parts.
Performance and capacity
Q: Why does a PolarDB for MySQL cluster fail to show significant performance improvements over an RDS for MySQL instance?
A: Before you compare the performance of a PolarDB for MySQL cluster with that of an RDS for MySQL instance, note the following to obtain accurate and reasonable performance comparison results:
Use a PolarDB for MySQL cluster and an RDS for MySQL instance that have the same specifications for the performance comparison.
Use a PolarDB for MySQL cluster and an RDS for MySQL instance that are of the same version for the performance comparison.
This is because implementation mechanisms vary by version. For example, MySQL 8.0 is optimized for multi-core CPUs by separately abstracting threads, such as Log_writer, log_fluser, log_checkpoint, and log_write_notifier. However, if only a few CPU cores are used, the performance of MySQL 8.0 is lower than that of MySQL 5.6 or 5.7. We do not recommend that you compare PolarDB for MySQL 5.6 with RDS for MySQL 5.7 or 8.0 because the optimizer of MySQL 5.6 is older and does not perform along with that of later versions.
We recommend that you simulate the loads in actual online environments or use sysbench to compare the performance. This makes the obtained performance data closer to that obtained in actual online scenarios.
When you compare read performance, we do not recommend that you use a single SQL statement.
This is because PolarDB uses a compute-storage decoupled architecture. A single statement is affected by network latency, which can cause the read performance to be lower than that of RDS. The cache hit ratio for an online database is typically above 99%. Only the first read calls I/O, which reduces the read performance. Subsequent data is in the buffer pool and does not require I/O calls. Therefore, the performance is the same.
When you compare write performance, we also do not recommend that you use a single SQL statement. We recommend that you simulate a production environment and perform a stress test.
To compare with RDS performance, use PolarDB (primary node + read-only node) and RDS (primary instance + semi-synchronous read-only instance). This is because the architecture of PolarDB uses the Quorum mechanism for data writes by default. This means that when data is written, it is written to a majority of the three replicas by default. If the data is written to two or more of the three replicas, the write operation is considered successful. PolarDB already provides data redundancy at the storage layer and ensures strong synchronization and high reliability of the three replicas. Therefore, it is more reasonable to use semi-synchronous replication (rather than asynchronous replication) of RDS for MySQL for the comparison.
For more information about the performance comparison results between PolarDB for MySQL and RDS for MySQL, see Performance comparison between PolarDB for MySQL and RDS for MySQL.
Q: What is the maximum number of tables? At what number of tables might performance start to degrade?
A: The maximum number of tables is limited by the number of files. For more information, see Limits.
Q: Can table partitioning improve the query performance of PolarDB?
A: Generally, if an SQL query can fall within a specific partition, performance can be improved.
Q: Can I create 10,000 databases in a PolarDB cluster? What is the maximum number of databases?
A: You can create 10,000 databases in a PolarDB cluster. The maximum number of databases is limited by the number of files. For more information, see Limits.
Q: Is the number of read-only nodes related to the maximum number of connections? Can I increase the maximum number of connections by adding read-only nodes?
A: The number of read-only nodes is not related to the maximum number of connections. The maximum number of connections for PolarDB is determined by the node specifications. For more information, see Limits. To increase the number of connections, you can upgrade the specifications.
Q: How are IOPS limited and isolated? Do multiple PolarDB cluster nodes compete for I/O?
A: The IOPS for each node of a PolarDB cluster is set based on its specifications. The IOPS of each node is isolated and does not affect other nodes.
Q: Does the performance of read-only nodes affect the primary node if it slows down?
A: If the load on a read-only node is too high and the replication delay increases, the memory consumption of the primary node may slightly increase.
Q: What is the impact on performance after I enable binary logging?
A: Enabling binary logging does not affect query (SELECT) performance. It only affects write and update (INSERT, UPDATE, and DELETE) performance. In general, in a database with balanced reads and writes, enabling binary logging affects performance by no more than 10%.
Q: What is the impact on performance after I enable SQL Explorer (full SQL log audit)?
A: There is no impact.
Q: What high-speed network protocol does PolarDB use?
A: PolarDB uses dual 25 Gbps RDMA technology between its database compute nodes and storage nodes, and between its storage data replicas. This provides strong I/O performance with low latency and high throughput.
Q: What is the bandwidth limit for Internet connections to PolarDB?
A: The bandwidth limit for Internet connections to PolarDB is 10 Gbit/s.
Large tables
Q: Compared with traditional databases that use local disks, what are the advantages of storing large tables in PolarDB for MySQL?
A: A table in PolarDB for MySQL is physically split and stored on N storage servers. Therefore, the I/O for a table is distributed across multiple storage disks. The overall I/O read throughput (not I/O latency) is much better than that of a centralized database that uses local disks.
Q: How do I optimize large tables?
A: We recommend that you use partitioned tables.
Q: In what situations is it suitable to use partitioned tables?
A: Partitioned tables are suitable for scenarios where you need to prune large tables to control the amount of data accessed by queries, and you want the pruning to be transparent to the business code without requiring any modifications. For example, you can use partitioned tables to periodically clean up business history data. You can delete the partition for the earliest month and create a new partition for the next month to retain only the data for the last six months.
Q: In the same PolarDB for MySQL database, what is a suitable way to copy a very large table, for example, copying all of table A to table B?
A: You can use the following SQL statement to copy the table directly:
create table B as select * from A
Stability
Q: Can I optimize PHP short-lived connections under high concurrency?
A: Yes, you can. In the cluster endpoint settings, you can enable the session-level connection pool for optimization. For more information, see Set a cluster endpoint.
Q: How do I prevent a few inefficient SQL statements from overwhelming the entire database?
A: If your PolarDB for MySQL cluster runs version 5.6 or 8.0, you can use the Concurrency Control feature to limit the flow of specified statements.
Q: Does PolarDB support idle session timeout?
A: Yes, it does. You can modify the wait_timeout parameter to customize the timeout period for idle sessions. For more information, see Set cluster and node parameters.
Q: How do I find slow SQL statements?
A: You can find slow SQL statements in the following two ways:
Query slow SQL statements directly in the console. For more information, see Slow SQL statements.
Connect to the database cluster and execute
show processlist;to find the SQL statements that take a long time to run. For more information about how to connect to a database cluster, see Connect to a database cluster.
Q: How do I terminate a slow SQL statement?
A: After you find a slow SQL statement, you can view its ID and then execute
kill <Id>to terminate it.
Data lifecycle
Q: How does a PolarDB for MySQL cluster archive hot and warm data as cold data?
A: A PolarDB for MySQL cluster supports archiving hot data from the InnoDB engine and warm data from the X-Engine in PolarStore to a cold storage medium in OSS in CSV or ORC format by specifying a DDL policy. After archiving, the storage space on PolarStore is released, and the overall database storage cost is reduced. For more information, see Manually archive cold data.
Q: Does a PolarDB for MySQL cluster support automatic separation and storage of hot, warm, and cold data? How is this implemented?
A: A PolarDB for MySQL cluster supports automatic separation and archiving of hot, warm, and cold data. By specifying a DLM policy, you can automatically archive data from PolarStore to a low-cost OSS storage medium. This reduces database storage costs and optimizes the effect. For more information, see Automatically archive cold data.