What are the frequently asked questions about PolarDB for PostgreSQL?-PolarDB(PolarDB)-阿里云帮助中心

This topic provides answers to frequently asked questions (FAQ) about PolarDB for PostgreSQL.

Basic information

Q: What is PolarDB?
A: PolarDB is a cloud-based relational database service. It is deployed in data centers across more than 10 regions worldwide and provides ready-to-use online database services.PolarDB is 100% compatible with PostgreSQL. By default, the storage capacity can reach up to 500 TB.
Note
PolarStore (PSL4/PSL5) provides petabyte-scale storage capabilities. If you have such requirements, Contact us to reserve the required resources.
Q: Why does PolarDB outperform traditional databases?
A: Compared with traditional databases, PolarDB can store hundreds of terabytes of data. It also provides high availability, high reliability, rapid elastic upgrades and downgrades, and lock-free backups. For more information, see Benefits.
Q: When was PolarDB released? 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: PolarDBCluster 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. Clusters are managed and billed on a per-cluster basis. For more information, see Glossary.
Q: Which programming languages are supported?
A: PolarDB supports programming languages such as Java, Python, PHP, Golang, C, C++, .NET, and Node.js.
Q: After I purchase PolarDB, do I still need to purchase PolarDB-X database middleware to implement sharding?
A: Yes.
Q: Does PolarDB support table partitioning?
A: Yes, table partitioning is supported.
Q: Does PolarDB automatically include a partitioning mechanism?
A: PolarDB implements partitioning at the storage layer. This is transparent and imperceptible to users.

Billing

Q: What are the billable items of PolarDB?
A: The billable items include the storage space, compute nodes, data backup (with a free quota), and SQL Explorer (optional). For more information, see Specifications and pricing.
Q: Which contents are included in the billable storage space?
A: The billable 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 Specifications and pricing.
Q: How do I use the storage plans of PolarDB?
A: You can use a storage plan to offset the storage fees of clusters that use the subscription or pay-as-you-go billing method. For example, if you have three clusters and each cluster has a storage capacity of 40 GB, the total storage capacity is 120 GB. The three clusters can share a storage plan of 100 GB, and the excess 20 GB is billed on a pay-as-you-go basis. For more information, see Purchase a storage plan.

Cluster access (read-write splitting)

Q: How do I implement read-write splitting in PolarDB?
A: You need only to use a cluster endpoint in your application to implement read-write splitting based on the configured read/write mode. For more information, see Configure PolarProxy.
Q: What is the maximum number of read-only nodes that a PolarDB cluster supports?
A: PolarDB uses a distributed cluster architecture. A cluster consists of 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 multiple read-only nodes?
A: Loads may be unbalanced among read-only nodes for the following reasons: a read-only node has a small number of connections, or a read-only node is not included when a custom cluster endpoint is allocated.
Q: What are the causes of heavy or light loads on the primary node?
A: Heavy loads on the primary node (primary database) may be caused by the following reasons: applications connect directly to the primary endpoint, the primary database accepts read requests, a large number of transaction requests exist, a high primary/secondary replication delay causes requests to be routed to the primary database, or read-only node exceptions cause read requests to be routed to the primary database.
A light load on the primary node may be caused by the offload reads from primary node option that is enabled on the primary database.
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 a cluster endpoint to connect to a PolarDB cluster. For more information, see Configure PolarProxy.
- If a large number of transactions cause heavy loads on the primary node, you can enable the transaction splitting feature in the console to route some queries in the transactions to the read-only nodes. For more information, see Read/write splitting.
- If requests are routed to the primary database because of a replication delay, you can consider decreasing the consistency level, such as using eventual consistency. For more information, see Read/write splitting.
- If the primary database accepts read requests, the load on the primary database may also become heavy. 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 database.
Q: Why am I unable to read the data that was just inserted?
A: This issue may be caused by the configured consistency level. The cluster endpoints of PolarDB support the following consistency levels:
- Eventual consistency: This level does not guarantee that the newly inserted data can be read immediately, whether within the same session (connection) or across different sessions.
- Session consistency: This level guarantees that the data inserted within the same session can be read.
Note
The higher the consistency level, the lower the performance and the heavier the load on the primary database. Exercise caution when you select a consistency level. For the majority of common scenarios, session consistency ensures that your services run as expected. For the few statements that require strong consistency, you can use the hint /* FORCE_MASTER */ to achieve this. For more information, see Consistency levels.
Q: How do I force an SQL statement to be executed on the primary node?
When you use a cluster endpoint, add /* FORCE_MASTER */ or /* FORCE_SLAVE */ before an SQL statement to forcibly specify the routing direction of the statement. For more information, see Read/write splitting.
- /* FORCE_MASTER */ forcibly routes requests to the primary database. This method applies to the few scenarios in which read requests have high consistency requirements.
- /* FORCE_SLAVE */ forcibly routes requests to a secondary database. This method applies to the few scenarios in which the PolarDB proxy requires special syntax to be routed to a secondary database to ensure correctness. For example, statements such as stored procedure calls and multistatement usage are routed to the primary database by default.
Note
- Hints have the highest routing priority and are not limited by consistency levels or transaction splitting. Evaluate the impact before you use hints.
- Do not include statements that change environment variables in a hint statement, such as /*FORCE_SLAVE*/ set names utf8; these statements may cause unexpected query results.
Q: Can I assign different endpoints to different services? Can different endpoints achieve isolation?
A: Yes, you can create multiple custom endpoints for different services. If the underlying nodes are different, the custom endpoints provide isolation and do not affect each other. For more information about how to create a custom endpoint, see Configure PolarProxy.
Q: If multiple read-only nodes exist, how do I separately create a single node endpoint for one of the read-only nodes?
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 more information about the procedure, see Configure PolarProxy.
Warning
After you create a single node endpoint, the endpoint may be unavailable for up to 1 hour if the node fails. Do not use single node endpoints in production environments.
Q: What is the maximum number of single node endpoints that can be created in a cluster?
A: If your cluster has three nodes, you can create a single node endpoint for only one of the read-only nodes. If your cluster has four nodes, you can create a single node endpoint for each of two read-only nodes. Similar rules apply to clusters with more nodes.
Q: I use only the primary endpoint, but I find that the read-only nodes also have loads. Does the primary endpoint support read-write splitting?
A: No, the primary endpoint does not support read-write splitting and is always connected only to the primary node. A small number of queries per second (QPS) on the read-only nodes is normal and is irrelevant 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 replication delay of a few milliseconds exists between them.
Q: In what scenarios does the replication delay increase?
A: The replication delay increases in the following scenarios:
- The write load on the primary node is heavy and generates excess redo logs, which the read-only nodes cannot replay in time.
- The load on the read-only nodes is excessively heavy and occupies too many resources that are originally used to replay redo logs.
- An I/O bottleneck occurs, which causes redo logs to be read and written too slowly.
Q: How do I ensure query consistency when a replication delay exists?
A: You can use a cluster endpoint and select an appropriate consistency level for it. The consistency levels are listed in descending order as follows: session consistency and eventual consistency. For more information, see Configure PolarProxy.
Q: Can the recovery point objective (RPO) be guaranteed to be zero when a single node fails?
A: When the database cluster parameters use the default settings, the RPO is not zero. You can modify the value of the sychronous_commit parameter to ensure that the RPO is zero. For more information about the default values of specific parameters, see Default cluster parameter values.
Q: How is a specification upgrade (for example, from 2 cores and 8 GB of memory to 4 cores and 16 GB of memory) implemented in the backend? What are the impacts on my services?
A: The PolarDB proxy and database nodes must be upgraded to the latest configurations. A rolling upgrade method is used to upgrade multiple nodes to minimize the impacts on your services. Currently, each upgrade takes about 10 to 15 minutes. The impacts on your services last for no more than 30 seconds, during which one to three transient connection errors may occur. For more information, see Change configuration.
Q: How long does it take to add a node? Are my services affected?
A: It takes about 5 minutes to add each node, and your services are not affected. For more information about how to add a node, see Add a read-only node.
Note
Read-write splitting connections that are established after a read-only node is added forward requests to the new read-only node. Read-write splitting connections that were established before the read-only node was added do not forward requests to the new read-only node. You must close such a connection and establish it again, for example, by restarting the application.
Q: How long does it take to upgrade to the latest revision version? Are my services affected?
A: PolarDB uses a rolling upgrade method for multiple nodes to minimize the impacts on your services. A version upgrade generally takes no more than 30 minutes. During the upgrade, the database proxy or the database engine is restarted, which may cause transient database connection errors. Perform the upgrade during off-peak hours and make sure that your application supports automatic reconnection. For more information, see Minor version management.
Q: How is an automatic failover implemented?
A: PolarDB uses an active-active high availability architecture. Automatic failover is performed between the primary node that supports reads and writes and the read-only nodes, and the system automatically elects a new primary node.PolarDB Each node has a failover priority, which determines the probability that the node is 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 failover and manual 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 and evenly distributes traffic between the two proxy nodes at a 1:1 ratio. The system continuously checks the health of the proxy nodes. If a node fails, the system proactively disconnects the connections on that node. The remaining healthy node automatically takes over all traffic so that the service is not interrupted. The system also automatically rebuilds and restores the failed proxy node. The whole process usually takes about 2 minutes, and the database cluster remains accessible during this time.
In rare cases, the connections on a failed node are not disconnected in time, but the node can no longer respond to requests. To handle this, configure appropriate timeout policies on the client, such as the JDBC socketTimeout and connectTimeout parameters, so that the application layer can promptly detect and terminate suspended connections. This further improves the fault tolerance and response efficiency of the system.

Backup and recovery

Q: What backup method does PolarDB use?
A: PolarDB uses snapshots to back up data. For more information, see Method 2: Manual backup.
Q: How fast can a database be restored?
A: Currently, the speed of restoring (cloning) a database based on a backup set (snapshot) is 40 minutes per TB. If you restore data to a specific point in time, the time required to replay redo logs must be included. The replay speed is approximately 20 to 70 seconds per GB. The total recovery time is the sum of these two parts.

Performance and capacity

Q: What is the maximum number of tables? At what number of tables may 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: In general, if a query SQL statement can be confined to a specific partition, the performance can be improved.
Q: Does PolarDB support creating 10,000 databases? What is the maximum number of databases?
A: PolarDB supports creating 10,000 databases. The maximum number of databases is limited by the number of files. For more information, see Limits.
Q: How are the input/output operations per second (IOPS) limited and isolated? Do multiple nodes of a PolarDB cluster compete for I/O resources?
A: Each node of a PolarDB cluster has its IOPS configured based on the node specifications. The IOPS of each node is independently isolated and does not affect the others.
Q: Is the primary node affected if the performance of the read-only nodes becomes slower?
A: When the load on the read-only nodes is excessively heavy and the replication delay increases, the memory consumption of the primary node may slightly increase.
Q: What is the impact on performance after SQL Explorer (full SQL log audit) is enabled?
A: There is no impact.
Q: Which high-speed network protocol does PolarDB use?
A: The PolarDB database compute nodes and storage nodes, as well as the multiple replicas of stored data, all use dual 25 Gbps RDMA technology to provide strong I/O performance with low latency and high throughput.
Q: What is the maximum bandwidth for PolarDB to connect over the Internet?
A: The maximum bandwidth for PolarDB to connect over the Internet is 10 Gbit/s.
Q: What can I do if it takes a long time to restart a node?
A: The more files that exist in your cluster, the longer it takes to restart a node. In this case, you can modify the innodb_fast_startup parameter to ON to accelerate the restart. For more information about how to modify parameters, see Set cluster parameters and node parameters.