Frequently asked questions about the PolarDB engine-PolarDB(PolarDB)-阿里云帮助中心

This topic provides answers to frequently asked questions about , , and PolarDB for PostgreSQL (Compatible with Oracle).

General questions

Q: What is PolarDB?
A: PolarDB is a relational database cloud service deployed in data centers across more than 10 regions worldwide, offering an out-of-the-box experience. PolarDB supports three independent engines that are 100% compatible with MySQL, 100% compatible with PostgreSQL, and highly compatible with Oracle syntax. It provides a storage capacity of up to 200 TB. For more information, see , , or What is PolarDB for PostgreSQL (Compatible with Oracle)?
Q: Why is PolarDB a better choice than traditional databases?
A: Compared with traditional databases, PolarDB can store hundreds of terabytes of data and provides features such as high availability, high reliability, rapid elastic scaling, and lock-free backups. For more information, see , , or Benefits.
Q: When was PolarDB released and when did it become commercially available?
A: PolarDB was released for public preview in September 2017 and became commercially available in March 2018.
Q: What are clusters and nodes?
A: PolarDB Cluster Edition uses a multi-node architecture. A cluster contains one primary node and multiple read-only nodes. A single PolarDB cluster can be deployed across zones but not across regions. The service is managed and billed at the cluster level. For more information, see , , or Terms.
Q: What programming languages are supported?
A: PolarDB supports various programming languages, including Java, Python, PHP, Go, C, C++, .NET, and Node.js.
Q: After I purchase a PolarDB cluster, do I also need to purchase the PolarDB-X database middleware to implement sharding?
A: Yes.
Q: Does PolarDB support table partitioning?
A: Yes.
Q: Can I change the region of a PolarDB cluster after it is purchased?
A: No, you cannot change a cluster's region after purchase.
Q: Does PolarDB automatically include a partitioning mechanism?
A: Yes. PolarDB performs 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 runs on a single compute node for specific purposes. Although it has only one node, a single-node cluster leverages technologies such as instant compute scheduling and distributed multi-replica storage to ensure high service availability and data reliability.
Q: What should I do if I receive the error message Lock wait timeout exceeded; try restarting transaction when I run an SQL statement in Data Management (DMS)?
A: This error is caused by a lock wait timeout, which occurs because an uncommitted transaction is blocking the current session. We recommend that you log on to the DMS console again, create a new connection session, and then run the SQL statement again.
Q: How do I purchase a single-node PolarDB cluster?
A: The single-node product series is no longer available. However, you can create a cluster that functions as a single-node cluster by setting the number of read-only nodes to 0 when you purchase a PolarDB cluster.

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 , , or Specifications and pricing.
Q: What does the charged storage space include?
A: The charged storage space includes database table files, index files, undo log files, redo log files, slow log files, and a small number of system files. For more information, see , , or Specifications and pricing.
Q: How do I use PolarDB storage plans?
A: You can use storage plans to offset the storage fees of subscription or pay-as-you-go clusters. For example, if the total storage usage across your clusters is 120 GB, a 100 GB storage plan covers the first 100 GB. The remaining 20 GB is then billed on a pay-as-you-go basis. For more information, see , , or Purchase a storage plan.
Q: How am I charged if I add a read-only node?
A: The price of a read-only node is the same as the price of a primary node. For more information, see , , or Pricing details of compute nodes.
Q: If I add a read-only node, is the storage capacity doubled?
A: No. PolarDB uses an architecture that decouples compute and storage. When you purchase a read-only node, you are adding a compute resource, which does not increase the storage capacity.
Storage space is serverless, so you do not need to select a capacity when you make a purchase. It scales automatically as your data grows, and you are charged only for the amount of data that you use. Each cluster specification has a maximum storage capacity. To increase the storage limit, , , or change the specifications.
Q: How do I release a subscription PolarDB cluster?
A: You cannot directly release a subscription cluster. You must follow the unsubscription process. For more information, see Refund policy.
Q: How can I stop incurring charges for a pay-as-you-go cluster?
A: If you no longer need the cluster, you can release it. Releasing the cluster stops all future charges.
Q: Can I change the specifications of a cluster during a temporary upgrade?
A: During a temporary upgrade, while the cluster status is Running, you can manually upgrade the specifications. However, you cannot manually downgrade, enable auto-scaling, or add or remove nodes.
Q: What is the public bandwidth of PolarDB, and are there any associated costs?
A: PolarDB itself does not have a public bandwidth limit. The bandwidth primarily depends on the Server Load Balancer (SLB) service that you use. PolarDB does not charge for public connections.
Q: Why do I still see daily charges for a subscription cluster?
A: The billable items for PolarDB 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 requires you to prepay for the compute nodes when you create a cluster, but it does not cover the costs of storage space, data backups, and SQL Explorer. The fees for these pay-as-you-go items are deducted from your account on an hourly basis. Therefore, even with a subscription, you will still receive pay-as-you-go bills.
Q: Are there extra charges for one-click migration from ApsaraDB RDS for MySQL to PolarDB?
A: The one-click migration process is free of charge. You are charged only for the ApsaraDB RDS for MySQL instance and the PolarDB cluster itself.
Q: Why am I still charged for storage space after deleting data from a PolarDB table by using the DELETE command?
A: The DELETE command only marks rows for deletion. It does not release the table space.

Cluster access and read/write splitting

Q: How do I implement read/write splitting in PolarDB?
A: You only need to use the cluster endpoint in your application. Read/write splitting is then implemented based on the configured read/write mode. For more information, see , , or Configure the database proxy.
Q: What is the maximum number of read-only nodes supported in a PolarDB cluster?
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 workloads unbalanced among multiple read-only nodes?
A: Workload imbalance among read-only nodes can be caused by a low number of connections to the nodes or by a custom cluster endpoint that does not include all read-only nodes in its configuration.
Q: What causes the load on the primary node to be high or low?
A: A high load on the primary node can be caused by several factors: direct connections to the primary endpoint, the primary node accepting read requests, a large number of transaction requests, high replication latency causing requests to be routed to the primary node, or a read-only node failure causing read requests to be routed to the primary node.
A low load on the primary node may occur if the option to accept read requests on the primary node is disabled.
Q: How can I reduce the load on the primary node?
A: You can use the following methods to reduce the load on the primary node:
- Connect to the PolarDB cluster by using the cluster endpoint. For more information, see , , or Configure the database proxy.
- If a large number of transactions cause high pressure on the primary node, you can enable the transaction splitting feature in the console to route some queries within transactions to read-only nodes. For more information, see , , or Transaction splitting.
- If high replication latency causes requests to be routed to the primary node, you can consider lowering the consistency level, for example, by using eventual consistency. For more information, see , , or Consistency levels.
- If the primary node accepts read requests, it may also lead to a high load. You can disable read requests on the primary node from the console to reduce the number of read requests routed to it.
Q: Why can't I read data immediately after it is inserted?
A: This issue may be caused by the consistency level configuration. The cluster endpoint of a PolarDB cluster supports the following consistency levels:
- Eventual consistency: This level does not guarantee that you can immediately read newly inserted data, regardless of whether the read is from the same session (connection) or a different one.
- Session consistency: This level guarantees that you can read data that was inserted within the same session.
Note
Higher consistency levels lead to lower performance and greater pressure on the primary node. Choose the consistency level with caution. For most application scenarios, session consistency is sufficient to ensure normal business operations. For the few statements that require strong consistency, you can use the /*FORCE_MASTER*/ hint. For more information, see , , or Consistency levels.
Q: How can I force an SQL statement to run on the primary node?
A: When you use a cluster endpoint, you can prefix an SQL statement with /*FORCE_MASTER*/ or /*FORCE_SLAVE*/ to specify its routing direction. For more information, see , , or Best practices for selecting a consistency level.
- The /*FORCE_MASTER*/ hint forces a request to be routed to the primary node. This can be used for read requests that require a higher level of consistency.
- The /*FORCE_SLAVE*/ hint forces a request to be routed to a read-only node. This can be used in scenarios where the PolarDB proxy routes special syntax to the primary node by default to ensure correctness, such as calls to stored procedures or the use of multi-statements.
Note
- Hints have the highest routing priority and are not constrained by consistency levels or transaction splitting. Evaluate the potential impact before use.
- Do not include statements that modify GUC parameters in a hint, such as /FORCE_SLAVE/ SET enable_hashjoin = off;. Such statements can lead to unexpected query results.
Q: Can I assign different endpoints to different services? Can these endpoints provide isolation between services?
A: Yes, you can create multiple custom endpoints for different services. If these endpoints use different underlying nodes, they provide isolation and do not affect each other. For information about how to create a custom endpoint, see , , or Create a custom cluster endpoint.
Q: If I have multiple read-only nodes, how can I create a dedicated single-node endpoint for one of them?
A: You can create a single-node endpoint only if the read/write mode of the cluster endpoint is set to Read Only and the cluster has three or more nodes. For detailed steps, see , , or Create a custom cluster endpoint.
Warning
After you create a single-node endpoint, if the node fails, the endpoint may be unavailable for up to one hour. Do not use single-node endpoints in production environments.
Q: What is the maximum number of single-node endpoints I can create in a cluster?
A: If your cluster has three nodes, you can create a single-node endpoint for only one read-only node. If your cluster has four nodes, you can create separate single-node endpoints for two of the read-only nodes. This pattern continues as the number of nodes increases.
Q: I am only using the primary endpoint, but I see a load on the read-only nodes. Does the primary endpoint also support read/write splitting?
A: No, the primary endpoint does not support read/write splitting. It always connects only to the primary node. A small number of QPS on read-only nodes is normal and is not related to the primary endpoint.

Management and maintenance

Q: Is there a replication delay between the primary node and the read-only nodes?
A: Yes, a millisecond-level delay exists between them.
Q: What can cause an increase in replication delay?
A: Replication delay can increase in the following situations:
- A high write load on the primary node generates an excessive amount of redo logs, which the read-only nodes cannot apply in time.
- A high load on a read-only node consumes resources that are required to apply redo logs.
- An I/O bottleneck slows down the process of reading and writing redo logs.
Q: If there is a replication delay, how can I ensure query consistency?
A: You can use a cluster endpoint and select an appropriate consistency level for it. The available consistency levels, from highest to lowest, are session consistency, and eventual consistency. For more information, see , , or Configure the database proxy.
Q: Can a recovery point objective (RPO) of 0 be guaranteed in the event of a single node failure?
A: Yes.
Q: How are specification upgrades (for example, from 2 cores and 8 GB of memory to 4 cores and 16 GB) implemented in the backend? What is the impact on services?
A: PolarDB performs a rolling upgrade on both the proxy and database nodes to minimize service impact. An upgrade typically takes 10 to 15 minutes to complete, with a service impact of no more than 30 seconds. During this period, one to three transient connection errors may occur. For more information, see , , or Change specifications.
Q: How long does it take to add a node? Does it affect my services?
A: Adding a node takes about five minutes and does not affect your services. For information about how to add a node, see , , or Add a read-only node.
Note
After you add a read-only node, new read/write splitting connections will forward requests to that node. Read/write splitting connections established before the node was added will not forward requests to the new node. You must disconnect and reconnect them, for example, by restarting your application.
Q: How long does it take to upgrade to the latest revision version? Does it affect my services?
A: PolarDB uses a rolling upgrade method across multiple nodes to minimize the impact on your services. A version upgrade usually takes less than 30 minutes. During the upgrade, the database proxy or the DB kernel engine is restarted, which may cause transient connection errors. We recommend that you perform the upgrade during off-peak hours and ensure that your application has an automatic reconnection mechanism. For more information, see , , or Minor version management.
Q: How does automatic failover work?
A: PolarDB uses an Active-Active high-availability cluster architecture. Automatic failover occurs between the read-write primary node and the read-only nodes. The system automatically elects a new primary node. Each node in a PolarDB cluster has a failover priority, which determines its probability of being elected as the new primary node during a failover. If multiple nodes have the same priority, they have the same probability of being elected. For more information, see , , or Automatic and manual primary/standby switchover.
Q: What is the architecture of the database proxy? Does it have a failover mechanism? How is its high availability ensured?
A: The database proxy uses a dual-node high-availability architecture, distributing traffic evenly between the two proxy nodes. The system continuously checks the health status of the proxy nodes. If a node failure is detected, the system proactively disconnects the connections on that node, and the remaining healthy node automatically takes over all traffic to ensure uninterrupted service. At the same time, the system automatically rebuilds and restores the failed proxy node. This process is typically completed in about 2 minutes. During this time, the database cluster remains accessible.
In rare cases, connections to a failed node may not be disconnected in a timely manner and become unresponsive. To handle such situations, configure appropriate timeout policies on the client side, such as JDBC's socketTimeout and connectTimeout. This allows the application layer to promptly detect and terminate suspended connections, further improving the system's fault tolerance and response efficiency.

Backup and recovery

Q: How does PolarDB back up data?
A: PolarDB uses snapshots to back up data. For more information, see , , or Backup method 2: Manual backup.
Q: How fast can a database be restored?
A: Restoring a database from a backup set (snapshot) or cloning a database takes about 40 minutes per TB. If you restore data to a specific point in time, the time required to apply redo logs is also included. Applying redo logs takes about 20 to 70 seconds per GB. The total restoration time is the sum of these two parts.

Performance and capacity

Q: What is the maximum number of tables? At what point might performance degrade?
A: The maximum number of tables is limited by the number of files. For more information, see , , or Limits.
Q: Can table partitioning improve the query performance of PolarDB?
A: Generally, yes. If a query can be scoped to 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: Yes, 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 , , or Limits.
Q: How are IOPS limited and isolated? Can I/O contention occur between multiple PolarDB cluster nodes?
A: In a PolarDB cluster, each node has an IOPS limit based on its specifications. The IOPS of each node is isolated and does not affect other nodes.
Q: Can the performance of a slow read-only node affect the primary node?
A: Yes. If a read-only node has a high load or increased replication delay, it may slightly increase the memory consumption of the primary node.
Q: What is the performance impact of enabling SQL Explorer?
A: There is no impact on performance.
Q: What high-speed network protocol does PolarDB use?
A: PolarDB uses dual 25 Gbps RDMA technology for communication between its compute and storage nodes, and between its storage data replicas. This provides powerful I/O performance with low latency and high throughput.
Q: What is the maximum bandwidth for external connections to PolarDB?
A: The maximum bandwidth for external connections to PolarDB is 10 Gbit/s.