27.2. Setting Up a BiHA Cluster #

The BiHA cluster is set up by means of the bihactl utility. There are several scenarios of using the bihactl utility:

Before you start setting up the BiHA cluster, carefully read Prerequisites and Considerations.

27.2.1. Prerequisites and Considerations #

Before you begin to set up the BiHA cluster, read the following information and perform the required actions if needed:

  • Ensure network connectivity between all nodes of your future BiHA cluster.

    If network isolation is required, when both the control channel and WAL transmission operate in one network, while client sessions with the database operate in another network, configure the BiHA cluster as follows:

    • Use host names resolving to IP addresses of the network for the control channel and WAL.

    • Add the IP address for client connections to the listen_addresses configuration parameter.

  • BiHA creates a number of auxiliary files and configures some Postgres Pro configuration parameters to ensure proper operation. For more information, see Postgres Pro Configuration.

  • To avoid any biha-background-worker issues related to system time settings on cluster nodes, configure time synchronization on all nodes.

  • It is not recommended to execute the bihactl commands in the PGDATA directory. The bihactl utility may create the biha_init.log and biha_add.log files in the directory where it is executed. However, the target PGDATA directory must be empty for proper execution of bihactl commands.

  • You can configure user authentication using the password file or the environment variable. For more information, see User Authentication Configuration.

  • During operation, BiHA uses its own mechanism to modify the Postgres Pro configuration dynamically. Some Postgres Pro parameters are managed by biha and cannot be modified using ALTER SYSTEM, as they are essential for biha operation. These parameters are the following:

    For more information, see Postgres Pro Configuration.

  • When using BiHA, it is not recommended to manually modify any configuration parameters related to WAL application as this may cause unexpected cluster behavior. For example, modifying the recovery_min_apply_delay value on a follower may interrupt its WAL receipt, even though the follower will be displayed as online and in the FOLLOWER state.

  • It is not recommended to use restore_command with the BiHA cluster. For more information about recovery from a backup, see Section 27.3.14.

  • In some operating systems, user session management may be handled by systemd. In this case, if your server is started using pg_ctl and managed remotely, be aware that all background processes initiated within an SSH session will be terminated by the systemd daemon when the session ends. To avoid such behavior, you can do one of the following:

    • Use the postgrespro-ent-18 systemd unit file to start the DBMS server on the cluster node.

    • Modify the configuration of the user session management service called systemd-logind in the /etc/systemd/logind.conf file, specifically, set the KillUserProcesses parameter to no.

27.2.2. User Authentication Configuration #

The biha_replication_user role is created during cluster initialization and has privileges to perform replication in a BiHA cluster. Before you start initializing your cluster, you must choose the authentication method for the biha_replication_user role and make the required preparations based on your choice.

Important

If you do not configure authentication using any of the methods listed below, you will be unable to add followers to your BiHA cluster.

BiHA supports the following ways to configure the biha_replication_user authentication:

27.2.2.1. Configuring Authentication via Environment Variables #

To avoid storing the biha_replication_user password in the pgpass password file, you can use PGPASSWORD and BIHA_REPLICATION_PASSWORD environment variables. The password must be the same in both environment variables and on all nodes of your BiHA cluster.

When you initialize the cluster using the bihactl bihactl cluster init command, the bihactl utility takes the password from BIHA_REPLICATION_PASSWORD.

When you add nodes to the cluster using the bihactl node add command, the bihactl utility takes the password from PGPASSWORD.

27.2.2.2. Configuring Authentication via the Password File #

To use authentication via the pgpass password file, you must specify the password for the biha_replication_user role in password files of all nodes of your BiHA cluster. When you initialize the cluster using the bihactl cluster init command and then add nodes using the bihactl node add command, the bihactl utility takes the password from the password file.

Important

To ensure connection between the leader and followers, the password of the biha_replication_user role must be the same on all nodes of the BiHA cluster.

You can specify the password using one of the following approaches:

  • The secure and recommended approach is to add a separate line for each node:

    echo 'hostname:port:biha_db:biha_replication_user:password' >> ~/.pgpass
    
    echo 'hostname:port:replication:biha_replication_user:password' >> ~/.pgpass
    
  • The simple approach is to add a single line for all nodes:

    echo '*:*:*:biha_replication_user:password' >> ~/.pgpass
    

27.2.3. Setting Up a BiHA Cluster from Scratch #

To set up a BiHA cluster from scratch, perform the following procedures.

Prerequisites

  1. On all nodes of your future cluster, install the postgrespro-ent-18-contrib package. Do not create a database instance.

  2. Ensure that you execute bihactl commands as the same user that starts the Postgres Pro Enterprise server.

    For example, if you start the server as user postgres, bihactl commands must also be run by user postgres.

  3. If you plan to use pg_probackup with biha, install the pg-probackup-ent-18 package.

  4. Choose the authentication method for the biha_replication_user role and make required preparations. For more information, see User Authentication Configuration.

Initializing the cluster

Use the bihactl cluster init command to initialize the cluster and create the leader node.

  1. Execute the bihactl cluster init command with the necessary options:

    bihactl cluster init \
        --biha-node-id=1 \
        --host=host \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
    

    At this stage, you can also enable SSL for cluster service connections and configure quorum-based synchronous replication.

  2. (Optional) Specify the password for the biha_replication_user role and re-enter the password for verification.

    Note

    bihactl prompts you to specify the password for the biha_replication_user role only if you have not configured any supported authentication methods. If so, the leader is created, however, adding followers is not available. To create a full-featured BiHA cluster, configure user authentication.

    The initdb utility is accessed, postgresql.conf and pg_hba.conf files are modified.

    When initializing the BiHA cluster, the magic string is generated. For more information on how to use the magic string, see Section 27.2.10.

  3. Start the DBMS using pg_ctl:

    pg_ctl start -D leader_PGDATA_directory -l leader_log_file
    
  4. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

Adding a follower node

Note

You must add nodes one by one. Do not add a new node if creation of a previously added node has not been completed yet and the node is in the CSTATE_FORMING state. Otherwise, an error may occur during node backup.

  1. Ensure that the leader node is in the LEADER_RO or LEADER_RW state.

  2. Ensure that you configure the biha_replication_user role authentication using one of the supported methods.

  3. Execute the bihactl node add command with the necessary options:

    bihactl add \
        --biha-node-id=2 \
        --host=node_2 \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
        --pgdata=follower_PGDATA_directory
    

    A backup of the leader node is created by means of pg_basebackup or pg_probackup depending on the value set in the --backup-method option. Besides, postgresql.conf and pg_hba.conf files are modified.

    Note

    During this process, all files are copied from the leader to the new node. The larger the database size, the longer it takes to add the follower.

    You can also add the leader node connection data using the magic string. For more information on how to use the magic string, see Section 27.2.10.

  4. Start the DBMS using pg_ctl:

    pg_ctl start -D follower_PGDATA_directory -l follower_log_file
    
  5. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

27.2.4. Setting Up a BiHA Cluster from the Existing Cluster with Streaming Replication #

Convert your existing Postgres Pro Enterprise 18 cluster with streaming replication and a configured database instance into a BiHA cluster. After conversion, the primary node of the existing cluster becomes the leader node, and standby nodes become follower nodes.

Prerequisites

  1. Ensure that you execute bihactl commands as the same user that starts the Postgres Pro Enterprise server.

    For example, if you start the server as user postgres, bihactl commands must also be run by user postgres.

  2. If you plan to use pg_probackup with biha, install the pg-probackup-ent-18 package.

  3. Choose the authentication method for the biha_replication_user role and make required preparations. For more information, see User Authentication Configuration.

Converting the existing primary node into the leader node

  1. Stop the existing primary node using pg_ctl:

    pg_ctl stop -D primary_PGDATA_directory
    
  2. Execute the bihactl cluster init command with the --convert option:

    bihactl init --convert \
        --biha-node-id=1 \
        --host=host \
        --port=PostgresPro_port \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
    

    At this stage, you can also enable SSL for cluster service connections and configure quorum-based synchronous replication.

    When converting the cluster, the magic string is generated. For more information on how to use the magic string, see Section 27.2.10.

  3. (Optional) Specify the password for the biha_replication_user role and re-enter the password for verification.

    Note

    bihactl prompts you to specify the password for the biha_replication_user role only if you have not configured any supported authentication methods. If so, the leader is created, however, adding followers is not available. To create a full-featured BiHA cluster, configure user authentication.

  4. Start the DBMS using pg_ctl:

    pg_ctl start -D leader_PGDATA_directory -l leader_log_file
    
  5. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

Converting the existing standby node into the follower node

  1. Ensure that you configure the biha_replication_user role authentication using one of the supported methods.

  2. Stop the existing standby node using pg_ctl:

    pg_ctl stop -D standby_PGDATA_directory
    
  3. Execute the bihactl node add command with the --convert-standby option:

    bihactl add --convert-standby \
      --biha-node-id=2 \
      --host=node_2 \
      --port=PostgresPro_port \
      --biha-port=5435 \
      --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
      --pgdata=follower_PGDATA_directory
    

    When converting an existing standby node into the follower node, biha creates the follower_PGDATA_directory/pg_biha/biha.conf and follower_PGDATA_directory/pg_biha/biha.state files required for the node to be connected to the cluster and modifies postgresql.conf and pg_hba.conf.

    You can also add the leader node connection data using the magic string. For more information on how to use the magic string, see Section 27.2.10.

  4. Start the DBMS using pg_ctl:

    pg_ctl start -D follower_PGDATA_directory -l follower_log_file
    
  5. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

27.2.5. Setting Up a BiHA Cluster from the Existing Database Server #

If your existing Postgres Pro Enterprise 18 server with a configured database has only one node, you can convert it into the leader and then add more nodes to your BiHA cluster using the bihactl node add command.

Prerequisites

  1. Ensure that you execute bihactl commands as the same user that starts the Postgres Pro Enterprise server.

    For example, if you start the server as user postgres, bihactl commands must also be run by user postgres.

  2. If you plan to use pg_probackup with biha, install the pg-probackup-ent-18 package.

  3. Choose the authentication method for the biha_replication_user role and make required preparations. For more information, see User Authentication Configuration.

Converting the existing node into the leader node

  1. Stop the existing node using pg_ctl:

    pg_ctl stop -D server_PGDATA_directory
    
  2. Execute the bihactl cluster init command with the --convert option:

    bihactl init --convert \
        --biha-node-id=1 \
        --host=host \
        --port=PostgresPro_port \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
    

    At this stage, you can also enable SSL for cluster service connections and configure quorum-based synchronous replication.

    The postgresql.conf and pg_hba.conf files are modified.

    When converting the node, the magic string is generated. For more information on how to use the magic string, see Section 27.2.10.

  3. (Optional) Specify the password for the biha_replication_user role and re-enter the password for verification.

    Note

    bihactl prompts you to specify the password for the biha_replication_user role only if you have not configured any supported authentication methods. If so, the leader is created, however, adding followers is not available. To create a full-featured BiHA cluster, configure user authentication.

  4. Start the DBMS using pg_ctl:

    pg_ctl start -D leader_PGDATA_directory -l leader_log_file
    
  5. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

Adding the follower node

  1. Ensure that the leader node is in the LEADER_RO or LEADER_RW state.

  2. Ensure that you configure the biha_replication_user role authentication using one of the supported methods.

  3. Execute the bihactl node add command with the necessary options:

     bihactl add \
         --biha-node-id=2 \
         --host=node_2 \
         --port=node_port_number \
         --biha-port=biha_port_number \
         --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
         --pgdata=follower_PGDATA_directory
     

    A backup of the leader node is created by means of pg_basebackup or pg_probackup depending on the value set in the --backup-method option. Besides, postgresql.conf and pg_hba.conf files are modified.

    You can also add the leader node connection data using the magic string. For more information on how to use the magic string, see Section 27.2.10.

  4. Start the DBMS using pg_ctl:

    pg_ctl start -D follower_PGDATA_directory -l follower_log_file
    
  5. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

27.2.6. Setting Up the Referee Node in the BiHA Cluster #

The referee node participates in elections and helps to manage split-brain issues.

Note

  • It is recommended to disable autovacuum before you start adding the referee node. When the referee is added, you can re-enable autovacuum.

  • You can use only pg_basebackup when adding the referee node to your cluster.

  • By default, only the biha_db database and system tables are copied to the referee node. The postgres database and user data are not copied. If you need the postgres database on your referee node, specify the --referee-with-postgres-db option.

To set up a referee node:

  1. Execute the bihactl node add command with the relevant value of the --mode option:

    bihactl add \
        --biha-node-id=3 \
        --host=node_3 \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
        --pgdata=referee_PGDATA_directory \
        --mode=referee
    

    or

    bihactl add \
        --biha-node-id=3 \
        --host=node_3 \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
        --pgdata=referee_PGDATA_directory \
        --mode=referee_with_wal
    

  2. Check the shared_buffers configuration parameter of the referee.

    If it is too high, set the value to the default 128 MB.

  3. Using pg_ctl, start the Postgres Pro instance where you have set up the referee:

    pg_ctl start -D referee_PGDATA_directory
    
  4. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

27.2.7. Setting Up a BiHA Cluster with proxima #

To extend high availability capabilities with a proxy server and a connection pooler functionality, you can enable the proxima extension while setting up your BiHA cluster.

You can also manage proxima in your existing BiHA cluster. For more information, see Managing proxima.

Note

proxima is not installed on the referee node.

  1. When initializing the BiHA cluster from scratch, specify the bihactl cluster init command with the --enable-proxima option. For example:

    bihactl init \
        --biha-node-id=1 \
        --host=host \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
        --enable-proxima
    

    The bihactl utility adds proxima to the shared_preload_libraries list in the postgresql.conf file, creates the postgresql.proxima.conf file and includes it into the postgresql.biha.conf file.

  2. Add followers.

    As followers are added by taking and restoring a backup of the leader, the proxima configuration is copied to the followers, just like other BiHA configuration parameters.

    If you add a referee node, the proxima configuration is not copied to the referee.

When your BiHA cluster is ready, you can modify the proxima configuration parameters.

27.2.8. Setting Up a Geo-Distributed and Disaster-Resilient BiHA Cluster #

You can either create your GDBiHA cluster from scratch, or convert your your existing Postgres Pro Enterprise 18 cluster with streaming replication and a configured database instance into a GDBiHA cluster.

In this example, you will create a GDBiHA cluster consisting of six nodes distributed among two segments.

Prerequisites

  1. If you set up your GDBiHA cluster from scratch, on all nodes of your future cluster, install the postgrespro-ent-18-contrib package. Do not create a database instance.

  2. Ensure that you execute bihactl commands as the same user that starts the Postgres Pro Enterprise server.

    For example, if you start the server as user postgres, bihactl commands must also be run by user postgres.

  3. If you plan to use pg_probackup with biha, install the pg-probackup-ent-18 package.

  4. Choose the authentication method for the biha_replication_user role and make required preparations. For more information, see User Authentication Configuration.

Initializing the Cluster

Use the bihactl cluster init command to initialize the cluster and create the leader node.

  1. Execute the bihactl cluster init command with the necessary options:

    bihactl cluster init \
        --biha-node-id=1 \
        --host=host \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
    

    If you convert your existing Postgres Pro Enterprise 18 cluster, additionally specify the --convert option.

  2. (Optional) Specify the password for the biha_replication_user role and re-enter the password for verification.

    The initdb utility is accessed, postgresql.conf and pg_hba.conf files are modified.

    When initializing the BiHA cluster, the magic string is generated. For more information on how to use the magic string, see Section 27.2.10.

  3. Start the DBMS using pg_ctl:

    pg_ctl start -D leader_PGDATA_directory -l leader_log_file
    
  4. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    

Adding a Segment

In this example, the GDBiHA cluster consists of two segments. The default segment with the 111 identifier is created automatically at the cluster initialization. You must add the second segment manually using the bihactl segment add command.

  • Execute the bihactl segment add command with the necessary options:

    bihactl segment add \
        --biha-node-id=segment_id \
        --use-leader "host=node_host port=node_port biha-port=node_biha_port" \
    

Adding Followers

As your GDBiHA cluster consists of six nodes, you must add five followers.

Note

  • You must add nodes one by one. Do not add a new node if creation of a previously added node has not been completed yet and the node is in the CSTATE_FORMING state. Otherwise, you may encounter the following error:

                  WARNING:  aborting backup due to backend exiting before pg_backup_stop was
                  called
              
  • When adding follower nodes, remember that you must distribute them between two segments. It is recommended to first add two followers to the default 111 segment, and then add three followers to the segment that you created manually.

  1. Ensure that the leader node is in the LEADER_RO or LEADER_RW state.

  2. Execute the bihactl node add command with the necessary options:

    bihactl node add \
        --biha-node-id=2 \
        --host=host \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --use-leader "host=leader_host port=leader_port biha-port=leader_biha_port" \
        --pgdata=follower_PGDATA_directory
        --segment-id=segment_id
    

    If you convert your existing Postgres Pro Enterprise 18 cluster, additionally specify the --convert-standby option.

    A backup of the leader node is created by means of pg_basebackup or pg_probackup depending on the value set in the --backup-method option. Besides, postgresql.conf and pg_hba.conf files are modified.

    Note

    During this process, all files are copied from the leader to the new node. The larger the database size, the longer it takes to add the follower.

    You can also add the leader node connection data using the magic string. For more information on how to use the magic string, see Section 27.2.10.

  3. Start the DBMS using pg_ctl:

    pg_ctl start -D follower_PGDATA_directory -l follower_log_file
    
  4. Check the node status in the biha.status_v view:

    SELECT * FROM biha.status_v;
    
  5. Repeat the steps above to create all the required followers.

  6. When all nodes are ready, check the cluster status in the biha.super_status_v view:

    SELECT * FROM biha.super_status_v;
    

27.2.9. Configuring SSL for Service Connections (Optional) #

When initializing your BiHA cluster, you can enable SSL for the cluster service connections by means of the --use-ssl option. To enable or disable SSL in the initialized BiHA cluster, use the procedure described in Managing SSL for Service Connections.

Preparing a Certificate and Key Pair

  • Using the OpenSSL utility, generate a certificate and a private key and save them in the /PGDATA/pg_biha directory on each cluster node:

    openssl req -x509 -newkey rsa:4096 -keyout path_to_key -out path_to_certificate -sha256 -days period_of_validity -nodes -subj "/CN=certificate_domain"
    

    For example:

    openssl req -x509 -newkey rsa:4096 -keyout /PGDATA/pg_biha/biha_priv_key.pem -out /PGDATA/pg_biha/biha_pub_cert.pem -sha256 -days 365 -nodes -subj "/CN=localhost"
    

    The following files are generated:

    • biha_priv_key.pem is a private key with read and write user access (0600)

    • biha_pub_cert.pem is a self-signed certificate issued for the specified time period and domain

    Important

    Ensure that you use the above mentioned names for your certificate and private key files as BiHA searches for the files by these names.

Enabling SSL

  1. When you initialize a BiHA cluster with bihactl cluster init, specify the --use-ssl option:

    bihactl init \
        --biha-node-id=1 \
        --host=host \
        --port=node_port_number \
        --biha-port=biha_port_number \
        --nquorum=number_of_nodes \
        --pgdata=leader_PGDATA_directory
        --use-ssl
    
  2. To ensure that SSL is enabled, when your BiHA cluster is set up, check that the biha.use_ssl parameter is set to true using the SHOW command:

    SHOW biha.use_ssl;
    

27.2.10. Using the Magic String (Optional) #

The magic string is a special string generated automatically when you initiate a BiHA cluster. It contains the data required to connect follower nodes to the leader node.

You can use the magic string in BiHA cluster setup scripts, as well as to avoid entering the leader node connection data manually when adding follower nodes.

Here is an example of how to use the magic string:

  1. Initialize the BiHA cluster using bihactl cluster init:

    bihactl init \
       --biha-node-id=1 \
       --host=host \
       --port=node_port_number \
       --biha-port=biha_port_number \
       --nquorum=number_of_nodes \
       --pgdata=leader_PGDATA_directory
    

    The bihactl cluster init command output represents the magic string. The magic string example looks as follows:

    dmVyc2lvbj0xIGhvc3Q9bG9jYWxob3N0IHBvcnQ9NTQzMiBiaWhhLXBvcnQ9NTQzMw==
    
  2. Copy and save the command output.

  3. When adding a follower node using bihactl node add, specify the bihactl cluster init command output as the --magic-string option value. For example:

    bihactl add \
     --biha-node-id=2 \
     --host=node_2 \
     --port=node_port_number \
     --biha-port=biha_port_number \
     --magic-string=dmVyc2lvbj0xIGhvc3Q9bG9jYWxob3N0IHBvcnQ9NTQzMiBiaWhhLXBvcnQ9NTQzMw== \
     --pgdata=follower_PGDATA_directory
    

    The follower node will now use the encoded data from the magic string to connect to the leader node.