GBase 8c provides distributed primary-standby deployment. GBase 8c supports both synchronous and asynchronous backup methods between the primary and standby nodes. Generally, asynchronous backup is used for remote disaster recovery nodes, while synchronous backup is used for local backup nodes. Primary-standby replication is achieved by physically replicating logs from the primary to the standby database. In high-bandwidth local area networks, it is recommended to use a one-primary-one-standby or one-primary-multiple-standby mode. Based on high availability needs and transmission methods, various combined replication transmission methods can be implemented. This document briefly describes high availability scenarios and configurations in primary-standby mode.

In primary-standby deployment, business data is stored on a single physical node. High availability between primary and standby nodes is achieved through synchronous or asynchronous methods. The data redundancy is supported by multiple copies, and data exchange between primary and standby replicas is done through logs, ensuring that any node failure in the cluster does not affect the database's external services, with no data loss and meeting ACID properties. When the primary node fails (including but not limited to server failure, database service failure, network disconnection, power failure, hard disk failure, etc.), the standby node can automatically upgrade to primary and continue to provide services. This process is transparent to the application and is not restricted by the primary-standby IP address. Once the standby node is activated, it is automatically assigned the IP address currently connected by the application, making the entire primary-standby switch seamless and without affecting external services.

As shown in the diagram, GBase 8c provides VIP (Virtual IP) functionality, allowing applications to directly connect to the VIP to access the primary database node. When a primary node failure occurs, causing a primary-standby switch, there is no need to manually switch the IP address connected by the application. The cluster will automatically bind the VIP to the new primary node, achieving automatic cluster switch and making it seamless for upper-layer applications.

VIP Details

VIP stands for Virtual IP. GBase 8c, when deployed in primary-standby mode, provides a virtual IP for the client to avoid the impact of primary-standby switching on the client. When the primary host fails, the VIP is unloaded from the original primary and re-bound to the new primary. Without VIP, client connections to the database usually have two methods:

Polling Mechanism: In the client connection string, all database IPs are listed. During a primary-standby switch, the system will determine and connect directly to the primary. The downside of this method is that after a primary-standby switch, it needs to poll each IP to establish a connection, which can be slow if the later nodes are primary. This is a commonly used method.
Direct Connection: The client needs to know which database node is primary and connect to that IP. When a primary-standby switch occurs, the connection IP needs to be changed accordingly, greatly affecting the client.

In both methods above, when the host IP changes, the client's IP needs to be updated in real-time.

In GBase 8c, you can use CM (Cluster Manager) to configure VIP, as shown in the "CM Node Deployment Information" example below. CM supports VIP management:

The VIP allows direct connection to the primary host, making reconnection faster and more accurate (millisecond level).
Supports host failure; when CM selects a new primary, the VIP drifts to the new primary.
In the case of dual-primary, the VIP can still access the unique primary, reducing the risk of data loss in dual-primary scenarios.

Common high availability deployment methods include one-primary-one-standby, one-primary-one-standby (with CM), one-primary-one-standby in series, one-primary-two-standby, one-primary-four-standby (supporting custom synchronization standby using FIRST or ANY settings), and other typical deployment schemes. These different primary-standby deployment configurations are implemented through the corresponding GBase 8c deployment configuration file.

Below is an example of a one-primary-one-standby configuration:

<?xml version="1.0" encoding="UTF-8"?>
<ROOT>
   <!-- Overall Information -->
   <CLUSTER>
       <PARAM name="clusterName" value="Cluster_template" />
       <PARAM name="nodeNames" value="gbase8c_5_67,gbase8c_5_68" />
       <PARAM name="gaussdbAppPath" value="/home/gbase/gbase500_db/install/app" />
       <PARAM name="gaussdbLogPath" value="/home/gbase/gbase500_db/log/omm" />
       <PARAM name="tmpMppdbPath" value="/home/gbase/gbase500_db/tmp"/>
       <PARAM name="gaussdbToolPath" value="/home/gbase/gbase500_db/install/om" />
       <PARAM name="corePath" value="/home/gbase/gbase500_db/corefile"/>
       <PARAM name="backIp1s" value="10.16.16.1,10.16.16.2"/>
   </CLUSTER>
   <!-- Node Deployment Information on Each Server -->
   <DEVICELIST>
       <!-- Node Deployment Information on node1 -->
       <DEVICE sn="gbase8c_5_67">
           <PARAM name="name" value="gbase8c_5_67"/>
           <PARAM name="azName" value="AZ1"/>
           <PARAM name="azPriority" value="1"/>
           <!-- If only one network card is available on the server, configure backIP1 and sshIP1 as the same IP -->
           <PARAM name="backIp1" value="10.16.16.1"/>
           <PARAM name="sshIp1" value="10.16.16.1"/>
           <!-- CM Node Deployment Information -->
           <PARAM name="cmsNum" value="1"/>
           <PARAM name="cmServerPortBase" value="15000"/>
           <PARAM name="cmServerListenIp1" value="10.16.16.1,10.16.16.2"/>
           <PARAM name="cmServerHaIp1" value="10.16.16.1,10.16.16.2"/>
           <PARAM name="cmServerlevel" value="1"/>
           <PARAM name="cmServerRelation" value="gbase8c_5_67,gbase8c_5_68"/>
           <PARAM name="cmDir" value="/home/gbase/gbase500_db/data/cmserver"/>
           <!-- dn -->
           <PARAM name="dataNum" value="1"/>
           <PARAM name="dataPortBase" value="15400"/>
           <PARAM name="dataNode1" value="/home/gbase/gbase500_db/install/data/dn,gbase8c_5_68,/home/gbase/gbase500_db/install/data/dn"/>
           <PARAM name="dataNode1_syncNum" value="0"/>
       </DEVICE>
       <!-- Node Deployment Information on node2, with the value of "name" configured as the host name -->
       <DEVICE sn="gbase8c_5_68">
           <PARAM name="name" value="gbase8c_5_68"/>
           <PARAM name="azName" value="AZ1"/>
           <PARAM name="azPriority" value="1"/>
           <!-- If only one network card is available on the server, configure backIP1 and sshIP1 as the same IP -->
           <PARAM name="backIp1" value="10.16.16.2"/>
           <PARAM name="sshIp1" value="10.16.16.2"/>
           <!-- CM -->
           <PARAM name="cmServerPortStandby" value="15000"/>
           <PARAM name="cmDir" value="/home/gbase/gbase500_db/data/cmserver"/>
       </DEVICE>
   </DEVICELIST>
</ROOT>

Typical High Availability Scenarios and Deployment Configuration for GBase 8c in Primary-Standby Mode

VIP Details