This topic provides answers to commonly asked questions about PolarDB for PostgreSQL .

Basic information

  • What is PolarDB ?

    PolarDB is a cloud-based relational database service. PolarDB has been deployed in various data centers in more than 10 regions around the world. PolarDB provides out-of-the-box online database services. PolarDB supports three database engines. This allows PolarDB to be fully compatible with MySQL and PostgreSQL, and allows PolarDB to be compatible with the Oracle syntax. Each PolarDB cluster supports a maximum storage space of 100 TB. You can purchase the PolarDB service based on your business requirements by using the pay-as-you-go billing method. The unit price of the PolarDB service is as low as USD 0.2 per hour. After you purchase the service, you can use all the features of the service. For more information, see Overview.

  • What are the advantages of over traditional databases?

    Compared with traditional databases, can store hundreds of terabytes of data. PolarDB also provides a wide array of features, such as high availability, high reliability, fast elastic scaling, and lock-free backups. For more information, see Benefits.

  • When was PolarDB released? When was PolarDB available for commercial use?

    PolarDB was released for public preview in September 2017, and available for commercial use in March 2018.

  • What are clusters and nodes in PolarDB?

    PolarDB uses a cluster-based architecture. Each cluster consists of one primary node (read/write node) and multiple read-only nodes. A single PolarDB cluster can be deployed across zones but not across regions. The PolarDB service is managed based on clusters, and you are billed for the service based on clusters. For more information, see Glossary.

  • What are the development methods that are supported by PolarDB?

    The development methods that are supported by PolarDB include Java, Python, PHP, Golang, C, C++, .NET, and Node.js.

Billing

  • What are the billing items for a PolarDB cluster?

    The billing items for a PolarDB cluster include the storage space, primary node, read-only nodes, data backup feature, and SQL Explorer feature. The data backup feature is available for free, and you are billed for only the storage space that is occupied by the data backup files. Some storage space is provided for free to store the data backup files. Note that the SQL Explorer feature is optional. For more information, see Specifications and pricing.

  • Which files are stored in the storage space that incurs fees?

    The storage space that incurs fees stores database table files, index files, undo log files, redo log files, slow query log files, and a few system files. For more information, see Specifications and pricing.

  • How do I use storage packages for PolarDB ?

    You can purchase storage packages to deduct the storage fees of your PolarDB clusters. The PolarDB clusters can use the subscription billing method or the pay-as-you-go billing method. For example, if you have three PolarDB clusters and each cluster has a storage capacity of 40 GB, the total storage capacity is 120 GB. You can purchase a 100 GB storage package for the three clusters. You are billed for the excess 20 GB storage space based on the pay-as-you-go billing method. For more information, see Purchase a storage plan.

Cluster access policies based on read/write splitting

  • How do I implement read/write splitting in PolarDB ?

    To implement read/write splitting, use a custom cluster endpoint in your applications to connect to database services. You can create a custom cluster endpoint in the PolarDB console. When you create the custom cluster endpoint, set the Read/write Mode parameter to Read and Write (Automatic Read-write Splitting), and specify the reader nodes for processing read requests. For more information, see Create a custom cluster endpoint.

  • How many read-only nodes are supported in a PolarDB cluster?

    A PolarDB cluster supports a maximum of 15 read-only nodes. PolarDB uses a distributed cluster-based architecture. Each PolarDB cluster consists of a primary node and a maximum of 15 read-only nodes. At least one read-only node must be used to implement failovers to ensure high availability.

  • Why are loads unbalanced among read-only nodes in a PolarDB cluster?

    One of the possible reasons is that only a small number of connections are established to some read-only nodes. A large number of connections may be established to the other read-only nodes. Another possible reason is that one of the read-only nodes is not specified as a reader node when you create a custom cluster endpoint.

  • What are the causes of heavy or light loads on the primary node of my PolarDB cluster?

    Heavy loads on the primary node may occur due to the following causes: 1. The primary endpoint is used to connect your applications to the PolarDB cluster. 2. The offload reads from the primary node feature is disabled. 3. The primary node receives a large number of transaction requests. 4. Requests are routed to the primary node because of a high replication delay. The replication delay occurs when you replicate data from the primary node to the read-only nodes. 5. Read requests are routed to the primary node due to read-only node failures.

    The possible cause of light loads on the primary node is that the offload reads from the primary node feature is enabled.

  • How do I reduce the loads on the primary node of my PolarDB cluster?
    You can reduce the loads on the primary node by using the following methods:
    • You can use a cluster endpoint to connect your application to a PolarDB cluster. For more information, see Modify a cluster endpoint.
    • If a large number of transactions cause heavy loads on the primary node, you can enable the transaction splitting feature in the PolarDB console. After you enable this feature, PolarDB distributes the read requests in the transactions to the read-only nodes for load balancing. For more information, see Configure transaction splitting.
    • If requests are routed to the primary node because of a high replication delay, you can decrease the consistency level to reduce the loads on the primary node. For example, you can use the eventual consistency level. For more information, see Specify a consistency level.
    • If you disable the offload reads from the primary node feature, the loads on the primary node may become heavy. In this scenario, you can enable the offload reads from the primary node feature in the PolarDB console. This helps you reduce the number of read requests that are routed to the primary node of your PolarDB cluster.
  • Why am I unable to immediately retrieve the newly inserted data?
    The possible cause is that the specified consistency level does not allow you to immediately retrieve the newly inserted data. The cluster endpoints of PolarDB support the following consistency levels:
    • Eventual consistency: This consistency level does not ensure that you can immediately retrieve the newly inserted data based on the same session or connection or different sessions.
    • Session consistency: This consistency level ensures that you can immediately retrieve the newly inserted data based on the same session.
    Note A high consistency level results in heavy loads on the primary node of your PolarDB cluster. This compromises the performance of the primary node. Use caution when you specify the consistency level. In most scenarios, the session consistency level can ensure service availability. For a few SQL statements that require strong consistency, you can add the /* FORCE_MASTER */ hint syntax to the SQL statements to meet the consistency requirements. For more information, see Consistency levels.
  • How do I force an SQL statement to be executed on the primary node of my PolarDB cluster?
    If you use a cluster endpoint, add /* FORCE_MASTER */ before an SQL statement to execute the SQL statement on the primary node. You can add /* FORCE_SLAVE */ before an SQL statement to execute the SQL statement on a read-only node. For more information, see PolarProxy features.
    • /* FORCE_MASTER */ is added to an SQL statement to forcibly route the SQL statement to the primary node. In only a few scenarios, strong consistency is required for read requests. This method applies to these scenarios.
    • /* FORCE_SLAVE */ is added to an SQL statement to forcibly route the SQL statement to a read-only node. In only a few scenarios such as calling stored procedures and using multi-statements, PolarProxy routes the SQL statements that use specific syntax patterns to the primary node of PolarDB by default. The purpose is to ensure that these SQL statements are executed as expected.
    Note
    • If you need to execute the statements that contain the preceding hints in the client of the native MySQL system, add the -c parameter to the statements. Otherwise, the hints in the statements are filtered out and become invalid. For more information, see MySQL Client Options.
    • The route priorities that are determined by the hints are the highest and are not limited by consistency levels and transaction splitting. Before you execute SQL statements, evaluate the route priorities of the statements.
    • The hints cannot contain the settings that are used to change environment variables. For example, if you use the /*FORCE_SLAVE*/ set names utf8; hint, the query result may be unexpected.
  • Can I assign different cluster endpoints to different services? Can I use cluster endpoints to isolate my services?

    Yes, you can create custom cluster endpoints and assign them to different services. If the custom endpoints are associated with different nodes, the custom cluster endpoints can be used to isolate the services. For more information about how to create a custom cluster endpoint, see Modify a cluster endpoint.

  • How do I create an endpoint for a single read-only node if I have multiple read-only nodes?
    You can create a single-node endpoint only if the Read/write Mode parameter for the cluster endpoint is set to Read Only and the cluster has at least three nodes. For more information, see Modify a cluster endpoint.
    Warning However, if you create a single-node endpoint for a read-only node and the read-only node becomes faulty, the endpoint may be unavailable for up to 1 hour. We recommend that you do not create or use single-node endpoints in production environments.
  • What is the maximum number of single-node endpoints that I can create in a cluster?

    The maximum number of single-node endpoints that are allowed in a cluster varies based on the number of nodes in the cluster. For example, 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 the two read-only nodes. Similar rules apply if your cluster has five or more nodes.

  • Read-only nodes have loads when I use only the primary endpoint. Does the primary endpoint support read/write splitting?

    No, the primary endpoint does not support read/write splitting. The primary endpoint is always connected only to the primary node all the time. In some scenarios, only a small number of queries per second (QPS) run on read-only nodes. This does not indicate that service errors occur. The QPS for read-only nodes is not affected regardless of whether you use the primary endpoint.

Management and maintenance

  • Does a replication delay occur when I replicate data from the primary node to the read-only nodes of my PolarDB cluster?

    Yes, a replication delay of a few milliseconds exists.

  • When does a replication delay increase?
    A replication delay increases in the following scenarios:
    • The primary node of your PolarDB cluster processes a large number of write requests and generates large numbers of redo log files. As a result, these redo log files cannot be replayed on the read-only nodes in time.
    • To process heavy loads, the read-only nodes occupy a large number of resources that are used to replay redo log files.
    • The system reads and writes redo log files at a low rate due to I/O bottlenecks.
  • How do I ensure the consistency of query results if a replication delay occurs?

    You can create a cluster endpoint and specify an appropriate consistency level for the cluster endpoint. The following consistency levels are listed in descending order: session consistency, and eventual consistency. For more information, see Modify a cluster endpoint.

  • Can PolarDB ensure that the recovery point objective (RPO) is zero if a single node fails?

    Yes, PolarDB can ensure that the RPO is zero if a single node fails.

  • How are node specifications upgraded in the backend, for example, upgrading node specifications from 2 cores and 8 GB memory to 4 cores and 16 GB memory? What are the impacts of the upgrade on my services?

    Both PolarProxy and PolarDB nodes must be upgraded to the latest configurations. PolarDB uses a rolling upgrade method to minimize the impacts on your services. It takes about 10 to 15 minutes for each upgrade. The impacts on your services last for no more than 30 seconds. During this period, one to three transient connection errors may occur. For more information, see Change specifications.

  • How long does it take to add a node? Are my services affected when the node is added?
    It takes about 5 minutes to add a node. Your services are not affected when the node is added. For more information about how to add a node, see Add a read-only node.
    Note After you add a read-only node, a read/write splitter forwards the subsequent read requests to the read-only node. The read requests that are sent before you add the read-only node cannot be forwarded to the read-only node. To enable the read-only node to process these read requests, you must close the connection and establish the connection again. For example, you can restart the application to establish the connection.
  • How long does it take to upgrade a minor kernel version for a PolarDB cluster to the latest version? Does the version upgrade affect my services?

    PolarDB uses a rolling upgrade method to minimize the impacts on your services. It takes about 10 to 15 minutes for each upgrade. The impacts on your services last for no more than 30 seconds. During this period, one to three transient connection errors may occur. For more information, see Upgrade the minor version.

  • How is an automated failover implemented?

    A PolarDB cluster uses an active-active architecture to ensure high availability. This architecture allows for automated failovers between the primary node and the read-only nodes. Each node in a PolarDB cluster has a failover priority. If a failover occurs, a node may function as the primary node. This priority determines the probability at which a node functions as the primary node. If multiple nodes have the same failover priority, the probabilities for the nodes to function as the primary node are the same. For more information, see Perform a switchover.

Backup and restoration

  • How does PolarDB back up data?

    PolarDB uses snapshots to back up data. For more information, see Back up data.

  • How fast can a database be restored?

    It takes 40 minutes to restore or clone 1 TB of data in a database based on backup sets or snapshots. If you want to restore data to a specific time point, you must include the time required to replay the redo log files. It takes about 20 to 70 seconds to replay 1 GB of redo log data. The total restoration time is the sum of the time required to restore data based on backup sets and the time required to replay the redo log files.

Performance and capacity

  • What is the maximum number of tables for a single PolarDB cluster? What is the upper limit for the number of tables if I need to ensure that the performance is not compromised?

    The maximum number of tables for a single PolarDB cluster depends on the number of files. For more information, see Limits.

  • How are the input/output operations per second (IOPS) limited and isolated? Do the nodes of PolarDB clusters compete for I/O resources?

    The IOPS is specified for each node of a PolarDB cluster based on the node specifications. The IOPS of each node is isolated from that of the other nodes. Therefore, the nodes of PolarDB clusters do not compete for I/O resources.

  • Is the performance of the primary node of my PolarDB cluster affected if the performance of the read-only nodes is compromised?

    Yes, the performance of the primary node of your PolarDB cluster is affected if the performance of the read-only nodes is compromised. If the loads on the read-only nodes are excessively heavy and the replication delay increases, you may find a slight increase in the memory that is consumed by the primary node.

  • How is the database performance affected if I enable the SQL Explorer feature that allows you to analyze the performance based on SQL audit logs?

    If you enable the SQL Explorer feature, the database performance is not affected.

  • Which high-speed network protocol does PolarDB use?

    PolarDB uses dual-port Remote Direct Memory Access (RDMA) to ensure high I/O throughputs between compute nodes and storage nodes, and between data replicas. Each port provides a data rate of up to 25 Gbit/s at a low latency.

  • What is the maximum bandwidth that I can use if I access PolarDB from the Internet?

    If you access PolarDB from the Internet, the maximum bandwidth is 10 Gbit/s.

  • What can I do if it takes a long time to restart nodes?
    A larger number of files in your cluster result in the longer time that is consumed to restart nodes. In this case, you can specify the innodb_fast_startup parameter as ON to accelerate the restart process. For more information, see Specify cluster parameters.
    Note You can specify this parameter for only the 8.0 clusters.