26.4. Reference for the biha Extension #

biha is a Postgres Pro extension that allows managing a BiHA cluster.

This section contains information about the biha extension configuration parameters, functions, and views.

26.4.1. Configuration Parameters #

The biha extension provides a set of configuration parameters described below that are specific to the BiHA cluster:

26.4.1.1. Cluster Configuration Parameters #

Important

  • When setting the cluster configuration parameters, you must ensure network reliability for the changes to affect all cluster nodes without any errors.

  • Values of these configuration parameters must be the same on all cluster nodes.

  • It is not recommended to modify any cluster configuration parameters while one of the nodes is in the NODE_ERROR state, as the changes may fail to be applied on that node.

service_mode (boolean) #

Determines weather the service mode is enabled in a BiHA cluster.

You can set the value with the biha.service_mode function.

Possible values:

  • f (default): The service mode is disabled.

  • t: The service mode is enabled.

ssl_certificate (text) #

Specifies the path to the SSL public certificate used to secure service connections between nodes of the initialized BiHA cluster. For more information, refer to Managing SSL for Service Connections.

You can set the value with the biha.set_ssl_certificate function. Node restart is required for the changes to take effect.

Default value: /PGDATA/pg_biha/biha_pub_cert.pem

ssl_mode (text) #

Specifies the authentication mode for the biha_replication_user role. For more information about SSL authentication configuration, refer to Configuring SSL for biha_replication_user. For more information about modes, refer to sslmode.

You can set the value with the biha.set_ssl_mode function. Node restart is required for the changes to take effect.

Possible values:

  • verify-full (default)

  • require

  • verify-ca

ssl_private_key (text) #

Specifies the path to the SSL private key used to secure service connections between nodes of the initialized BiHA cluster. For more information, refer to Managing SSL for Service Connections.

You can set the value with the biha.set_ssl_private_key function. Node restart is required for the changes to take effect.

Default value: /PGDATA/pg_biha/biha_priv_key.pem

synchronous_standby_names.count (integer) #

Enables quorum-based synchronous replication by setting the synchronous_standby_names parameter and specifying the number of synchronous standbys (quorum) with the ANY method.

You can set the value with the biha.set_sync_standbys function.

The value must be integer and greater than zero, as well as higher than the value of synchronous_standby_names.min parameter if set, and must not exceed the number of followers excluding referee. It is recommended to set the synchronous_standby_names.count value less than the value of minnodes.

synchronous_standby_names.min (integer) #

Enables relaxed quorum-based synchronous replication by specifying the MIN field value of the synchronous_standby_names parameter, which is the minimum number of synchronous standbys that must be available for the leader node to continue confirming transactions. If the parameter value is not specified, the BiHA cluster operates according to the default synchronous replication restrictions, i.e. the leader node is not available for write transactions until all followers catch up with its current state.

You can set the value with the biha.set_sync_standbys_min function.

The synchronous_standby_names.min value must be integer and equal to or greater than zero, as well as lower than synchronous_standby_names.count. When set to -1, relaxed quorum-based synchronous replication is disabled.

synchronous_standby_names.names (integer) #

Specifies a list of synchronous standbys in the synchronous_standby_names configuration parameter.

You can set the value with the biha.set_ssn function, as well as modify the list of synchronous standbys with biha.add_to_ssn or biha.get_ssn functions.

use_ssl (boolean) #

Specifies whether to use the protected mode of the service information exchange between cluster nodes with SSL/TLS over the biha control channel. For more information, refer to Managing SSL for Service Connections.

You can set the value with the biha.set_use_ssl function. Node restart is required for the changes to take effect.

Possible values:

  • false (default): SSL is disabled for BiHA service connections.

  • true: BiHA service connections are secured with SSL.

user_biha_cert (text) #

Specifies the path to the SSL public certificate used for the biha_replication_user role authentication. For more information about SSL authentication configuration, refer to Configuring SSL for biha_replication_user.

You can set the value with the biha.set_user_cert function.

user_biha_key (text) #

Specifies the path to the SSL private key used for the biha_replication_user role authentication. For more information about SSL authentication configuration, refer to Configuring SSL for biha_replication_user.

You can set the value with the biha.set_user_key function.

26.4.1.2. Segment Configuration Parameters #

The following configuration parameters can be set individually for each logical node (segment). The parameter values are inherited by nodes within the segment.

heartbeat_max_lost (integer) #

Specifies the maximum number of heartbeats that can be missed on BCP before the node is considered offline.

You can set the value with the biha.set_heartbeat_max_lost function.

Default value: 10

Minimal value: 3

Nodes in all states use the heartbeat timeout value calculated as heartbeat_max_lost * heartbeat_send_period to determine if other nodes are online. For example, if Node A receives no heartbeats from Node B within the heartbeat timeout, the Node B state changes to UNKNOWN in the biha.status_v view of Node A indicating that Node A considers Node B offline. The leader in the LEADER_RW state additionally uses the timeout specified in the no_wal_on_follower parameter.

heartbeat_send_period (integer) #

Specifies the heartbeat sending frequency, in milliseconds.

You can set the value with the biha.set_heartbeat_send_period function.

Default value: 1000

Minimal value: 500

Nodes in all states use the heartbeat timeout value calculated as heartbeat_max_lost * heartbeat_send_period to determine if other nodes are online. For example, if Node A receives no heartbeats from Node B within the heartbeat timeout, the Node B state changes to UNKNOWN in the biha.status_v view of Node A indicating that Node A considers Node B offline. The leader in the LEADER_RW state additionally uses the timeout specified in the no_wal_on_follower parameter.

minnodes (integer) #

Specifies the minimum number of operational nodes for the leader node to be open for write transactions.

You can set the value with the biha.set_minnodes function.

Default value: equals nquorum

When setting up this value, consider the split-brain risk. It is recommended to use the following formula: (total_number_of_nodes + 1)/2. For example, if your cluster has 3 nodes, the minnodes value must be 2.

Nodes with the can_vote parameter set to false are ignored by minnodes.

no_wal_on_follower (integer) #

Specifies the timeout of the replication slot position advancement, in milliseconds.

You can set the value with the biha.set_no_wal_on_follower function.

Default value: 20000

Minimum value: 5000

BiHA uses this configuration parameter for the following purposes:

  • When you nominate a follower as the new leader using the biha.set_leader function, the follower state changes to FOLLOWER_OFFERED.

    A follower in the FOLLOWER_OFFERED state checks whether its WAL location has been updated. Update of WAL location confirms that the follower keeps receiving replication data from the source. If the follower does not receive WAL records longer than no_wal_on_follower, the follower state changes back to FOLLOWER. In this case, the log contains the following message: Timed out waiting for new WAL records from current source.

  • The leader in the LEADER_RW state uses no_wal_on_follower in conjunction with the heartbeat timeout value (which is calculated as heartbeat_max_lost * heartbeat_send_period) to determine if other nodes are online.

    The leader checks the replication slot positions of other nodes. If the replication slot position updates, it means that the node receives replication data from the leader and the node is online. If the leader does not receive heartbeats from the node within the above mentioned heartbeat timeout and its replication slot position does not change within the no_wal_on_follower timeout value, the leader considers the node offline and its state changes to UNKNOWN in the biha.status_v view of the leader.

  • In a cascading BiHA cluster, if a node does not receive WAL within the time set in no_wal_on_follower, it starts searching for a new replication source as configured in repl_pref_roles.

nquorum (integer) #

Specifies the minimum number of nodes, which must vote for the new leader node if the current leader is down.

You can set the value with the biha.set_nquorum function.

Default value: 2

When setting up this value, consider the split-brain risk. It is recommended to use the following formula: (total_number_of_nodes + 1)/2. For example, if your cluster has 3 nodes, the nquorum value must be 2.

Nodes with the can_vote parameter set to false are ignored by nquorum.

26.4.1.3. Node Configuration Parameters #

The following configuration parameters can be set individually for each physical node.

asyncaction_timeout (integer) #

Specifies the waiting time for execution of asynchronous operations, such as adding segments and removing nodes, in milliseconds. If a segment or node is not added or removed within the specified time, BiHA terminates the SQL command.

The parameter value must be the same on all cluster nodes.

You can set the value with the biha.set_asyncaction_timeout function.

Default value: 30000

Minimum value: 1000

biha_hosts (string) #

Used by other nodes to connect to the current node by internal control channel (BCP), for example, using a proxy server or a tunnel. If the biha_hosts value is empty, by default, the biha_listen_addresses value of the current node is used.

You can set the value with the biha.set_biha_hosts function.

Possible values: one or several comma-separated addresses in the hostname:port format. port is an optional value, if not specified or set to -1, the biha_port value of the current node is used.

For example: biha-db-1:5433,biha-proxy:8081,biha-node-1

biha_listen_addresses (string) #

Determines on which addresses listening sockets are open for the internal BCP control channel.

You can set the value only with the bihactl utility.

Possible values: one or several comma-separated addresses in the hostname:port format. port is an optional value, if not specified or set to -1, the biha_port value of the current node is used.

For example: biha-db-1:5433,biha-proxy:8081,biha-node-1

biha_port (integer) #

Specifies the port used to exchange service information between nodes.

The parameter value is set with the bihactl utility and can be overridden when modifying biha_hosts, biha_listen_addresses, or replication_hosts configuration parameters.

callbacks_timeout (integer) #

Sets time for execution of all callbacks for a single event, in milliseconds.

You can set the value with the biha.set_callbacks_timeout.

Default value: 10000

Minimum value: 1000

config_send_period (integer) #

Determines the timeout to broadcast message with cluster configuration.

You can set the value with the biha.set_config_send_period function.

Default value: 10000

Minimum value: 500

deny_wal_sources (string) #

Specifies a list of nodes that cannot be used as replication sources for the current node. If a node identifier is in the list, the current node cannot replicate from such a node.

You can set the value with the biha.set_deny_wal_sources function.

Default value: empty

The deny_wal_sources configuration parameter has higher priority than repl_pref_roles. For example, if the leader node ID is in the deny_wal_sources list of a node, the node does not replicate from the leader even if its repl_pref_roles value is LF.

flw_ro (boolean) #

Determines whether a follower is available for read operations.

You can set the value with the biha.set_flw_ro function.

Possible values:

  • on (default): The follower is available for read operations.

  • off: Reading from this follower is allowed only for superusers, as well as for members of BIHA_CLUSTER_MANAGEMENT_ROLE and pg_monitor roles.

manage_slots_xmin (boolean) #

Determines whether BiHA monitors the xmin value of replication slots.

You can set the value with the biha.set_manage_slots_xmin function.

Possible values:

  • true (default): Monitoring of xmin is enabled.

  • false: Monitoring of xmin is disabled.

max_replicas (integer) #

Specifies the maximum number of biha replication connections to a node, i.e. the maximum number of walsenders where application_name is biha_node_*. For more information, refer to Section 26.1.5.2.

You can set the value with the biha.set_max_replicas function.

The value must be integer, greater than zero, and must not exceed the max_wal_senders value.

Other possible values:

  • INT_MAX (default): The number of connections is unlimited.

  • 0: No connections are allowed.

pg_port (integer) #

Specifies the node port for incoming connections to Postgres Pro.

The parameter value is set with the bihactl utility and can be overridden when modifying biha_hosts, biha_listen_addresses, or replication_hosts configuration parameters.

replication_hosts (string) #

Used by other nodes to connect to the current node by replication channel. The biha_listen_addresses value must include replication_hosts. If the replication_hosts value is empty, by default, the biha_listen_addresses value of the current node is used.

You can set the value with the biha.set_replication_hosts function.

Possible values: one or several comma-separated addresses in the hostname:port format. port is an optional value, if not specified or set to -1, the biha_port value of the current node is used.

The maximum string size is 1024 bytes, otherwise it is ignored.

For example: biha-db-1:5433,biha-proxy:8081,biha-node-1

sql_hosts (string) #

Used by other nodes to execute SQL queries to the current node. If the sql_hosts value is empty, by default, the replication_hosts value of the current node is used.

You can set the value with the biha.set_sql_hosts function.

Possible values: one or several comma-separated addresses in the hostname:port format. port is an optional value, if not specified or set to -1, the biha_port value of the current node is used.

The maximum string size is 1024 bytes, otherwise it is ignored.

For example: biha-db-1:5433,biha-proxy:8081,biha-node-1

watchdog_timeout (integer) #

Specifies the timeout for a node to stop accepting queries if the biha process does not respond, in seconds. For more information, refer to Section 26.3.9.

You can set the value with the biha.set_watchdog_timeout function. Node restart is required for the changes to take effect.

Default value: 2

Minimum value: 1

26.4.1.4. Configuration Parameters Common for Nodes and Segments #

The following configuration parameters can be set individually both for physical nodes or logical nodes (segments).

can_be_leader (boolean) #

Determines the ability of a node or a segment to become the leader.

You can set the value with the biha.set_can_be_leader function.

Possible values:

  • true (default): The node or segment can stand as a candidate in elections of the new leader.

  • false: The node or segment cannot stand as a candidate in elections of the new leader.

A node that cannot become the leader may have the largest WAL. In this case, if elections are required, those nodes that can stand as candidates attempt to receive missing data from that node. If they succeed, one of these nodes becomes the leader. If they fail to receive missing data, the automatic rewind process is launched on the node that cannot become the leader. If biha.autorewind is not enabled, the node state changes to NODE_ERROR.

can_vote (boolean) #

Determines whether a node or a segment is allowed to vote.

You can set the value with the biha.set_can_vote function.

Possible values:

  • true (default): The node or segment is allowed to vote.

  • false: The node or segment cannot vote, as well as cannot stand as a candidate in elections of the new leader.

leader_timeout (integer) #

Determines the maximum time for the switchover process to complete when biha.set_leader is called, in milliseconds. If the operation does not complete within the specified time, the node returns to the FOLLOWER state.

You can set the value with the biha.set_leader_timeout function.

Default value: 20000

Minimum value: 0

mode (text) #

Specifies the operation mode of a node or segment. The mode value is set with bihactl and cannot be modified after cluster initialization.

Possible values for a node:

  • regular (default): The node can operate as the leader or as a follower.

  • referee: The node only participates in the leader elections and does not contain any user databases.

  • referee_with_wal: The node participates both in the leader elections in the same way as in the referee mode and receives the entire WAL from the leader node.

Possible values for a segment: regular

name (text) #

Specifies the name of a node or segment. The name value is set with bihactl and cannot be modified after cluster initialization.

priority (integer) #

Sets the node or segment priority that affects both elections and replication in a cluster, in seconds.

You can set the value with the biha.set_priority function.

The value must be integer and greater than or equal to zero. The 0 value means the highest priority.

Default value: -1, meaning that the parameter is ignored.

Note

Once you modify the default value, you cannot set it again, i.e. disabling priority is not supported.

BiHA uses this configuration parameter for the following purposes:

  • To set the replication start timeout when selecting a replication source in a BiHA cluster with configured cascading replication. The higher the value, the later the node starts replication and allows connection of nodes with lower priority. The parameter is required for the nodes to establish the cascading replication schema automatically.

  • To set the node priority in a cluster with synchronous replication. The value determines the timeout that must be reached before the node stands as a candidate in elections. The zero value indicates the highest priority.

    Important

    To ensure correct operation of this parameter, set the --sync-standbys value one unit less than the total number of cluster nodes.

repl_pref_roles (text) #

Specifies the preferred role of a node acting as a replication source for the current node in a BiHA cluster with cascading replication.

You can set the value with the biha.set_pref_roles function.

Possible values: L (leader), F (follower), or R (referee), or their combinations. The value must be one to three symbols long and must not contain repeatable symbols. For example: L, F, LFR, or LF.

Default value: L, meaning that data is replicated from the leader or front follower depending on the segment where the node is located.

26.4.1.5. Optional Configuration Parameters #

The following configuration parameters are optional and can be modified with the ALTER SYSTEM SET command, for example:

ALTER SYSTEM SET biha.autorewind = true;

Values of these parameters can differ across cluster nodes.

biha.autorewind (boolean) #

Controls the automatic rewind policy for that node, against which the pg_rewind must be executed. For example, for the old leader when synchronizing it with the new leader. For more information, refer to Automatic Cluster Synchronization after Failover.

Possible values:

  • false (default): The automatic rewind is not performed.

  • true: The automatic rewind is performed after the error that usually causes the NODE_ERROR state of the node.

biha.autowaltrim (boolean) #

Manages the automatic WAL trimming policy within a single node. For more information, refer to Automatic Cluster Synchronization after Failover.

Possible values:

  • true (default): BiHA automatically schedules and executes the WAL trimming procedure if possible.

  • false: The WAL trimming procedure is not executed, cluster synchronization is performed by means of pg_rewind.

biha.wal_validation (boolean) #

Manages the WAL validation mechanism. The WAL validation procedure runs on history update and during the PRESTARTUP state to avoid the recovery process abortion caused by WAL inconsistency.

Possible values:

  • true (default): WAL validation is enabled.

  • false: WAL validation is disabled.

The WAL validation mechanism performs the following:

  • Validates timelines. If a TLI lacks complete WAL segments up to the switchpoint or has no segments at all, it is considered invalid.

  • Hides invalid timelines from BiHA nodes. This prevents a node with a higher but invalid timeline from becoming a leader candidate.

  • Restarts Postgres Pro in case of WAL inconsistency on the node that is about to be promoted.

  • Checks WAL consistency during prestartup and attempts to repair WAL automatically if required.

26.4.1.6. biha Logging Levels #

26.4.1.6.1. General Logging Levels #

General logging levels are used for biha components that have no designated logging levels.

biha.BihaLog_log_level (enum) #

Specifies the logging level to provide general information about the operation of biha components. The default value is LOG.

biha.BihaWarn_log_level (enum) #

Specifies the logging level to provide warnings of likely problems about the operation of biha components. The default value is WARNING.

biha.BihaDetails_log_level (enum) #

Specifies the logging level to provide detailed information about the operation of biha components. The default value is DEBUG1.

biha.BihaDebug_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of biha components. The default value is DEBUG2.

biha.BihaDebug2_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of biha components. The default value is DEBUG3.

26.4.1.6.2. BCP and Transport Logging Levels #
biha.BcpTransportLog_log_level (enum) #

Specifies the logging level to provide general information about the control channel operation. The default value is LOG.

biha.BcpTransportWarn_log_level (enum) #

Specifies the logging level to provide warnings of likely problems in the control channel. The default value is WARNING.

biha.BcpTransportDetails_log_level (enum) #

Specifies the logging level to provide detailed information about the control channel operation. The default value is DEBUG1.

biha.BcpTransportDebug_log_level (enum) #

Specifies the logging level to provide debugging information about the control channel operation. The default value is DEBUG2.

26.4.1.6.3. Node Controller Logging Levels #

The following logging levels provide information about the Node Controller component.

biha.NodeControllerLog_log_level (enum) #

Specifies the logging level to provide general information about the the Node Controller component. The default value is LOG.

biha.NodeControllerWarn_log_level (enum) #

Specifies the logging level to provide warnings of likely problems in the Node Controller component. The default value is WARNING.

biha.NodeControllerDetails_log_level (enum) #

Specifies the logging level to provide detailed information about operation of the Node Controller component. The default value is DEBUG1.

biha.NodeControllerDebug_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of the Node Controller component. The default value is DEBUG2.

biha.NodeControllerDebug2_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of the Node Controller component. The default value is DEBUG3.

26.4.1.6.4. Postgres Controller Logging Levels #

The following logging levels provide information about the Postgres Controller component.

biha.PgControllerLog_log_level (enum) #

Specifies the logging level to provide general information about the Postgres Controller component. The default value is LOG.

biha.PgControllerWarn_log_level (enum) #

Specifies the logging level to provide warnings of likely problems in the Postgres Controller component. The default value is WARNING.

biha.PgControllerDetails_log_level (enum) #

Specifies the logging level to provide detailed information about operation of the Postgres Controller component. The default value is DEBUG1.

biha.PgControllerDebug_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of the Postgres Controller component. The default value is DEBUG2.

biha.PgControllerDebug2_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of the Postgres Controller component. The default value is DEBUG3.

26.4.1.6.5. Config Controller Logging Levels #

The following logging levels provide information about the Config Controller component.

biha.BihaConfigLog_log_level (enum) #

Specifies the logging level to provide general information about the Config Controller component. The default value is LOG.

biha.BihaConfigWarn_log_level (enum) #

Specifies the logging level to provide warnings of likely problems in the Config Controller component. The default value is WARNING.

biha.BihaConfigDetails_log_level (enum) #

Specifies the logging level to provide detailed information about operation of the Config Controller component. The default value is DEBUG1.

biha.BihaConfigDebug_log_level (enum) #

Specifies the logging level to provide debugging information about the operation the Config Controller component. The default value is DEBUG2.

biha.BihaConfigDebug2_log_level (enum) #

Specifies the logging level to provide debugging information about the operation of the Config Controller component. The default value is DEBUG3.

26.4.2. Functions #

All functions listed below must be called from the biha_db database, for example:

biha_db=# SELECT biha.add_node(222, 1111);

If otherwise is not specified in the function description, a function must be called on the leader node.

26.4.2.1. Cluster Composition #

biha.add_node (id integer, parent_id integer) → boolean #

Adds a segment to the GDBiHA cluster. If parent_id is not specified, by default the root node with ID 1111 is assigned as the parent. For more information about changing cluster composition, refer to Section 26.3.1.

For example, add a segment with ID 222 to a cluster with ID 1111:

biha_db=# SELECT biha.add_node(222, 1111);
 add_node
-------------
 t
(1 row)
 
biha.set_leader (id integer, mode string) → boolean #

Sets the leader, front follower, or the leader segment manually. For more information about the manual switchover procedure, refer to Manual Switchover.

Note

Call this function on the node that you want to set as the new leader or front follower. Do not call the function on the current leader.

The following switchover modes are supported:

  • graceful (default): The promoted node waits for demotion of the old leader or front follower and, if required, catches up on WAL records. This is the default value.

  • immediate: The switchover occurs immediately, without waiting. The node with the specified ID changes its state directly to LEADER_RW/LEADER_RO or FRONT_FOLLOWER skipping the FOLLOWER_OFFERED state. In this mode, the LEADER_CHANGE_STARTED callback is not called. If the command in the immediate mode is executed on the current leader or front follower, it immediately starts changing its state to FOLLOWER and broadcasts a message about the leader change to other nodes.

    Important

    The immediate mode is not safe, using it may lead to data loss. Before performing switchover in this mode, it is recommended to do the following:

    • Enable automatic synchronization by setting the biha.autorewind configuration parameter to true.

    • Set the minnodes value to 1 for the leader to ignore other cluster node states.

For example, nominate the node with ID 2 as the new leader in the immediate mode:

biha_db=# SELECT biha.set_leader(2, 'immediate');
 set_leader
-------------
 t
(1 row)
biha.set_leader_timeout (id integer,timeout_value integer) → boolean #

Sets the value of the leader_timeout configuration parameter.

The biha.set_leader_timeout function can be called for an individual physical node or a segment depending on the identifier specified. When called for a segment, the timeout value applies to all nodes within that segment.

For example, set the timeout of 10000 ms for all nodes in segment 222:

biha_db=# SELECT * FROM biha.set_leader_timeout(222, 10000);
 set_leader_timeout
-------------
 t
(1 row)
biha.remove_node (id integer) → boolean #

Removes a node or a segment from the cluster. Before removing, the node must be stopped. You cannot remove a node if it is a parent of another node. For more information about changing cluster composition, refer to Section 26.3.1.

For example, remove a node with ID 3:

biha_db=# SELECT biha.remove_node(3);
 remove_node
-------------
 t
(1 row)

26.4.2.2. Cluster Configuration #

biha.config () → setof record #

Returns the configuration parameter values for every node and segment. You can also view the most critical configuration parameters using the Section 26.4.3.1 view.

The following parameters are displayed:

  • id: The node ID (integer).

  • nquorum: The current value of nquorum (integer).

  • minnodes: The current value of minnodes (integer).

  • heartbeat_send_period: The current value of heartbeat_send_period (integer).

  • heartbeat_max_lost: The current value of heartbeat_max_lost (integer).

  • no_wal_on_follower: The current value of no_wal_on_follower (integer).

  • sync_standbys_min: The current value of the MIN field of synchronous_standby_names (integer).

  • priority: The current value of priority (integer).

  • can_be_leader: The current value of can_be_leader (boolean).

  • can_vote: The current value of can_vote (boolean).

  • mode: The current value of mode (text).

  • proxima_enabled: The current status of proxima if supported by the current version of Postgres Pro Standard (integer).

  • name: The name of the node (text).

  • repl_pref_roles: Preferred roles of nodes for replication set in the repl_pref_roles configuration parameter (text).

  • max_replicas: The maximum number of replication connections to the node set in the max_replicas configuration parameter (integer).

  • config_version: The current version of the pg_biha/biha_conf_config_version.json configuration (integer).

  • parent_id: The unique identifier of the node that is the parent to the current node (integer).

  • service_mode: The current value of service_mode (boolean).

  • unit_type: The type of the unit. Possible values: NODE, SEGMENT.

  • deny_wal_sources: The current value of deny_wal_sources (string).

  • biha_hosts: The current value of biha_hosts (string).

  • replication_hosts: The current value of replication_hosts (string).

  • sql_hosts: The current value of sql_hosts (string).

  • leader_timeout: The current value of leader_timeout (integer).

  • use_ssl: The current value of use_ssl (boolean).

  • ssl_certificate: The current value of ssl_certificate (text).

  • ssl_private_key: The current value of ssl_private_key (text).

  • user_cert: The current value of user_biha_cert (text).

  • user_key: The current value of user_biha_key (text).

  • ssl_mode: The current value of ssl_mode (text).

  • flw_ro: The current value of flw_ro (boolean).

  • callbacks_timeout: The current value of callbacks_timeout (integer).

  • watchdog_timeout: The current value of watchdog_timeout (integer).

  • asyncaction_timeout: The current value of asyncaction_timeout (integer).

  • manage_slots_xmin: The current value of manage_slots_xmin (boolean).

  • config_send_period: The current value of config_send_period (integer).

For example, call the biha.config function for a node with ID 1:

biha_db=# select * from biha.config() where id = 1 \gx
  -[ RECORD 1 ]---------+--------------------------
  id                    | 1
  nquorum               | 3
  minnodes              | 1
  heartbeat_send_period | 1000
  heartbeat_max_lost    | 10
  no_wal_on_follower    | 20000
  sync_standbys_min     | -2
  priority              | -1
  can_be_leader         | t
  can_vote              | t
  mode                  | regular
  proxima_enabled       | f
  name                  | biha_node_1
  repl_pref_roles       | L
  max_replicas          | 2147483647
  config_version        | 12
  parent_id             | 111
  service_mode          | f
  unit_type             | NODE
  deny_wal_sources      |
  biha_hosts            | biha-db-1:5433,biha-proxy:8081
  replication_hosts     | biha-db-1:5432,postgres-proxy:8081
  sql_hosts             |
  leader_timeout        | 20000
  use_ssl               | f
  ssl_certificate       | pg_biha/biha_pub_cert.pem
  ssl_private_key       | pg_biha/biha_priv_key.pem
  user_cert             |
  user_key              |
  ssl_mode              |
  flw_ro                | t
  callbacks_timeout     | 10000
  watchdog_timeout      | 2
  asyncaction_timeout   | 30000
  manage_slots_xmin     | t
  config_send_period    | 10000
biha.config_json () → setof record #

Returns the configuration file content in the JSON format. To view the content of a JSON configuration tree branch at the specified JSON path, use the biha.get_option function.

For example:

biha_db=# select biha.config_json();
                      config_json
-------------------------------------------------------
 {                                                    +
     "unit": {                                        +
         "id": 1111,                                  +
         "mode": "regular",                           +
         "name": "biha_node_1111",                    +
         "nquorum": 1,                                +
         "can_vote": true,                            +
         "children": [                                +
             {                                        +
                 "id": 111,                           +
...
     "proxima_enabled": false,                        +
     "ssl_certificate": "pg_biha/biha_pub_cert.pem",  +
     "ssl_private_key": "pg_biha/biha_priv_key.pem",  +
     "synchronous_standby_names": {                   +
         "min": -2,                                   +
         "count": -1,                                 +
         "names": [                                   +
         ]                                            +
     }                                                +
}
(1 row)
biha.get_option (json_path text) → setof record #

Returns the content of a JSON configuration tree branch at the specified JSON path. To view the full JSON configuration file, use the biha.config_json function.

For example:

biha_db=# select biha.get_option('$.unit.children.[0].children.[1].biha_listen_addresses.[0].address');
 get_option
------------
 "node-3"
(1 row)
biha.set_config_send_period (id integer, config_send_period integer) → boolean #

Sets the value of the config_send_period configuration parameter.

26.4.2.3. Cluster Monitoring #

biha.error_details () → setof record #

Returns the description of why the node transferred to the NODE_ERROR state. The returned record contains the type of the error, its details, the place it occurred specifying begin_lsn, end_lsn, and identifier of the current and the next timeline, as well as replay_lsn.

For example:

biha_db=# \x
biha_db=# SELECT * FROM biha.error_details();
-[ RECORD 1 ]--+-------------------------------------------------------------------------------------                 │
type           | TIMELINE_ERROR                                                                                       │
details        | Timeline divergence detected: current timeline ended before replayLSN, rewind needed                 │
next_tli       | 3                                                                                                    │
next_begin_lsn |                                                                                                      │
next_end_lsn   |                                                                                                      │
cur_tli        | 2                                                                                                    │
cur_begin_lsn  | 0/17F53A0                                                                                            │
cur_end_lsn    | 0/3455FC8                                                                                            │
replay_lsn     | 0/34593B8
biha.monitoring () → setof record #

Displays a table that contains the monitoring data about the current status of cluster nodes. The table consists of the following columns:

  • id: The unique identifier of the node.

  • time: The time where the monitoring data was received.

  • biha_state: The current state of the node. For more information about possible states, see biha.status_v.

  • pg_state: The current state of Postgres Pro. Possible values: Prestartup, Startup, Recovery, Recovery_Pause, Promoting, Promoted.

  • online: Shows whether the node is online.

  • startup_progress: Shows percentage of the current startup progress when pg_state is Startup.

For example:

biha_db=# select * from biha.monitoring();
 id |          time          |   biha_state   | pg_state | online | startup_progress
----+------------------------+----------------+----------+--------+-----------------
  3 | 2025-09-02 13:49:57+03 | LEADER_RW      | Promoted | t      |
  1 | 2025-09-02 13:49:57+03 | CSTATE_FORMING | Startup  | t      |               81
  2 | 2025-09-02 13:49:57+03 | FOLLOWER       | Recovery | t      |
(3 rows)
biha.nodes () → setof record #

Displays the BiHA transport channel state of the current node to other nodes and defines the biha.nodes_v view, which is described in detail in the biha.nodes_v section.

The function displays a table with the following columns:

  • id: The node ID.

  • host: The host of the node.

  • port: The port of the node.

  • state: The connection state of the node. This column may contain one of the following values:

    • ACTIVE: The node has active client connections. Read-write operations are performed in this state.

    • CONNECTING: An attempt to establish a client connection with the node.

    • IDLE: The node is in the passive waiting state.

    • INIT: A client connection initialization.

    • SSLCONNECT: An attempt to establish a secure connection. This state is only displayed when SSL is enabled.

    • SSLACCEPT: An attempt to accept a secure connection. This state is only displayed when SSL is enabled.

  • conn_start: The time of connection start.

  • conn_count: The number of times the node was connected since the start of the cluster.

For example:

biha_db=# SELECT * FROM biha.nodes();
 id |   host    | port  | state  |       conn_start       | conn_count
----+-----------+-------+--------+------------------------+------------
  1 | localhost | 10001 | ACTIVE | 2023-07-05 17:17:17+07 |          1
  2 | localhost | 10002 |        |                        |
  5 | localhost | 10005 | ACTIVE | 2023-07-05 17:17:17+07 |          1
  3 | localhost | 10003 | ACTIVE | 2023-07-05 17:17:17+07 |          1
  4 | localhost | 10004 | ACTIVE | 2023-07-05 17:17:17+07 |          1
(4 rows)
biha.status () → setof record #

Defines the biha.status_v view, which is described in detail in the biha.status_v section. It is not recommended to use this function as it provides raw data for the view.

26.4.2.4. Replication #

The following functions are used to configure and manage replication.

biha.add_to_ssn (id integer) → boolean #

Note

You can call this function only when quorum-based synchronous replication is enabled.

Adds the specified node to the list of synchronous standbys listed by synchronous_standby_names.names. You must specify the node whose name is not yet in the list.

For example:

biha_db=# SELECT biha.add_to_ssn(3);
 add_to_ssn
-------------
 t
(1 row)
biha.get_ssn () → varchar #

Displays the current value of the synchronous_standby_names parameter.

For example:

biha_db=# SELECT biha.get_ssn();
                   get_ssn
---------------------------------------------
 ANY 1 (biha_node_1,biha_node_2,biha_node_3)
(1 row)
biha.set_deny_wal_sources (id integer, prohibited_ids integer[]) → boolean #

Sets the value of the deny_wal_sources configuration parameter for a specified node or resets the existing value.

The prohibited_ids array must meet the following requirements:

  • The specified nodes must be physical and be present in the cluster.

  • IDs must meet the node ID format and must not repeat.

  • The array size must not exceed the maximum allowed number of nodes in the cluster.

For example, you can prevent the node with ID 3 to replicate from the node with ID 1 as follows:

biha_db=# SELECT biha.set_deny_wal_sources(3, ARRAY[1]);
 set_deny_wal_sources
--------------
 t
(1 row)

To reset the parameter to an empty value, call the function with an empty array.

biha.set_max_replicas (id integer, max_replicas_num integer) → boolean #

Sets the value of the max_replicas configuration parameter.

For example, configure the node with ID 1 to have the maximum of 3 replicas:

biha_db=# SELECT biha.set_max_replicas(1, 3);
 set_max_replicas
------------------
 t
(1 row)
biha.set_pref_roles (node_id integer, value text) → boolean #

Sets the value of the repl_pref_roles configuration parameter.

For example:

biha_db=# SELECT biha.set_pref_roles(1, 'LFR');
 set_pref_roles
----------------
 t
(1 row)
biha.set_priority (node_id integer, value integer) → boolean #

Sets the value of the priority configuration parameter.

For example:

biha_db=# SELECT biha.set_priority(1, 10);
 set_priority
--------------
 t
(1 row)
biha.remove_from_ssn (id integer) → boolean #

Note

You can call this function only when quorum-based synchronous replication is enabled.

Removes the specified node from the list of synchronous standbys listed by synchronous_standby_names.names. You must specify the node which name is already in the list.

For example:

biha_db=# SELECT biha.remove_from_ssn(3);
  remove_from_ssn
-------------
 t
(1 row)
biha.set_ssn (VARIADIC ids integer[]) → boolean #

Note

You can call this function only when quorum-based synchronous replication is enabled.

Sets the value of the synchronous_standby_names.names configuration parameter.

For example:

biha_db=# SELECT biha.set_ssn(1, 2, 3);
 set_ssn
---------
 t
(1 row)
biha.set_sync_standbys (sync_standbys_count integer) → boolean #

Sets the value of the synchronous_standby_names.count configuration parameter.

Important

Use this function carefully, as modifying the number of synchronous standbys may affect operation of the priority system or cause hanging of client application when requesting data from a lagging node.

For example:

biha_db=# SELECT biha.set_sync_standbys(1);
 set_sync_standbys
-------------------
 t
(1 row)
biha.set_sync_standbys_min (sync_standbys_min_count integer) → boolean #

Note

You can call this function only when quorum-based synchronous replication is enabled.

Sets the value of the synchronous_standby_names.min configuration parameter.

Using this function, you can also manage relaxed quorum-based synchronous replication. To disable relaxed quorum-based synchronous replication, set the -1 value.

For example:

biha_db=# SELECT biha.set_sync_standbys_min(1);
 set_sync_standbys_min
-----------------------
 f
(1 row)

26.4.2.5. Elections and Quorum #

biha.set_minnodes (id integer, minnodes integer) → boolean #

Sets the value of the minnodes configuration parameter. If id belongs to a physical node, the minnodes value is set for the segment where the node is located. If id belongs to a segment, the value is set for this segment and the nodes located in it. You can set different values for each segment.

For example:

  biha_db=# SELECT biha.set_minnodes(3, 1);
   set_minnodes
  --------------------------
   t
  (1 row)
  
biha.set_nquorum (id integer, nquorum integer) → boolean #

Sets the value of the nquorum configuration parameter. If id belongs to a physical node, the nquorum value is set for the segment where the node is located. If id belongs to a segment, the value is set for this segment and the nodes located in it. You can set different values for each segment.

For example:

  biha_db=# SELECT biha.set_nquorum(3, 3);
   set_nquorum
  --------------------------
   t
  (1 row)
  
biha.set_nquorum_and_minnodes (id integer, nquorum integer, minnodes integer) → boolean #

Sets nquorum and minnodes values. If id belongs to a physical node, the nquorum and minnodes values are set for the segment where the node is located. If id belongs to a segment, the values are set for this segment and the nodes located in it. You can set different values for each segment.

For example:

  biha_db=# SELECT biha.set_nquorum_and_minnodes(3, 3, 1);
   set_nquorum_and_minnodes
  --------------------------
   t
  (1 row)
  
biha.set_can_be_leader (id integer, can_be_leader boolean) → boolean #

Sets the value of the can_be_leader configuration parameter.

For example, you can allow the node with ID 4 to become a leader candidate as follows:

biha_db=# SELECT biha.set_can_be_leader(4,true);
 set_can_be_leader
--------------
 t
(1 row)
biha.set_can_vote (id integer, can_vote boolean) → boolean #

Sets the value of the can_vote configuration parameter.

For example, you can allow the node with ID 4 to vote as follows:

biha_db=# SELECT biha.set_can_vote(4,true);
 set_can_vote
--------------
 t
(1 row)

26.4.2.6. Network Configuration #

biha.config_network () → setof record #

Displays the current values of network configuration parameters for physical nodes only. In the output, the biha_listen_addresses value is displayed for other network configuration parameter if their values were not specified.

For example:

  biha_db=# select * from biha.config_network();
    id | biha_listen_addresses | biha_hosts | biha_port | replication_hosts | sql_hosts | port
   ----+-----------------------+------------+-----------+-------------------+-----------+------
     1 | biha-db-1             | biha-db-1  |      5433 | biha-db-1         | biha-db-1 | 5432
     2 | biha-db-2             | biha-db-2  |      5433 | biha-db-2         | biha-db-2 | 5432
     3 | biha-db-3             | biha-db-3  |      5433 | biha-db-3         | biha-db-3 | 5432
     4 | biha-db-4             | biha-db-4  |      5433 | biha-db-4         | biha-db-4 | 5432
     5 | biha-db-5             | biha-db-5  |      5433 | biha-db-5         | biha-db-5 | 5432
  (5 rows)
  
biha.set_biha_hosts (id integer, VARIADIC biha_hosts text[]) → boolean #

Sets the value of the biha_hosts configuration parameter.

For example:

biha_db=# select biha.set_biha_hosts(1, 'biha-1:8080', 'biha-p', 'biha-2222:3333');
 set_biha_hosts
----------------
 t
(1 row)
biha.set_sql_hosts (id integer, VARIADIC sql_hosts text[]) → boolean #

Sets the value of the sql_hosts configuration parameter.

For example:

biha_db=# select biha.set_sql_hosts(1, 'bha-1:8080', 'bha-p', 'bha-2222:3333');
 set_sql_hosts
----------------
 t
(1 row)
biha.set_replication_hosts (id integer, VARIADIC replication_hosts text[]) → boolean #

Sets the value of the replication_hosts configuration parameter.

For example:

biha_db=# select biha.set_replication_hosts(1, 'bha-1:8080', 'bha-p', 'bha-2222:3333');
 set_replication_hosts
-----------------------
 t
(1 row)

26.4.2.7. Security Configuration #

biha.set_ssl_certificate (text) → boolean #

Sets the value of the ssl_certificate configuration parameter.

For example:

biha_db=# SELECT biha.set_ssl_certificate('/tmp/install/share/extension/biha_pub_cert.pem');
WARNING:  [BiHA] this parameter takes effect after node restart
 set_ssl_certificate
---------------------
 t
(1 row)
biha.set_ssl_mode (text) → boolean #

Sets the value of the ssl_mode configuration parameter.

For example:

biha_db=# SELECT biha.set_ssl_mode('verify-full');
WARNING:  [BiHA] this parameter takes effect after node restart
 set_ssl_mode
--------------
 t
(1 row)
biha.set_ssl_private_key (text) → boolean #

Sets the value of the ssl_private_key configuration parameter.

For example:

biha_db=# SELECT biha.set_ssl_private_key('/tmp/install/share/extension/biha_priv_key.pem');
WARNING:  [BiHA] this parameter takes effect after node restart
 set_ssl_private_key
---------------------
 t
(1 row)
biha.set_user_cert (text) → boolean #

Sets the value of the user_biha_cert configuration parameter.

For example:

biha_db=# SELECT biha.set_user_cert('/tmp/install/share/extension/biha_pub_cert.pem');
WARNING:  [BiHA] this parameter takes effect after node restart
 set_user_cert
---------------
 t
(1 row)
biha.set_user_key (text) → boolean #

Sets the value of the user_biha_key configuration parameter.

For example:

biha_db=# SELECT biha.set_user_key('/tmp/install/share/extension/biha_priv_key.pem');
WARNING:  [BiHA] this parameter takes effect after node restart
 set_user_key
--------------
 t
(1 row)
biha.set_use_ssl (boolean) → boolean #

Sets the value of the use_ssl configuration parameter.

For example:

biha_db=# SELECT biha.set_use_ssl(true)
WARNING:  [BiHA] this parameter takes effect after node restart
 set_use_ssl
-------------
 t
(1 row)

26.4.2.8. Callback Management #

biha.set_callbacks_timeout (node_id integer, timeout_value integer) → boolean #

Sets the value of the callbacks_timeout configuration parameter.

biha.register_callback (event text, function text, database text, executor text, priority integer) → integer #

Adds a new callback and returns its unique ID. This function can only be called from the leader node in the LEADER_RW state. The new callback is replicated to the followers.

Note

On the biha side, there is no check that func exists in database. If the specified function does not exist, the callback fails.

See Registering Callbacks for the example of using the biha.register_callback function.

Table 26.3. Variable Definitions

NameTypeDescription
eventtext Event of the BiHA cluster that triggers a callback. For more information about events and corresponding callback types, see Callback Types.
functiontext Name of the SQL function that biha executes when event happens. This function must be located in database, otherwise it cannot be executed.
databasetextDatabase where func is executed.
executortext

User that executes func. This parameter is optional. The default value is biha_callbacks_user.

priorityinteger The lower the value, the sooner the callback is executed. This parameter is optional. The default value is 0.

biha.unregister_callback(callback_id) #

Deletes a callback. This function can only be called on the leader node in the LEADER_RW state. Refer to Unregistering Callbacks for the example of using the biha.unregister_callback function.

26.4.2.9. Other Functions #

biha.get_magic_string() → string #

Generates a magic string for the cluster node. For example:

biha_db=# SELECT biha.get_magic_string();
                          get_magic_string
----------------------------------------------------------------------
 dmVyc2lvbj0xIGhvc3Q9bG9jYWxob3N0IHBvcnQ9NjU0MzIgYmloYS1wb3J0PTEwMDAx
(1 row)
biha.set_asyncaction_timeout (id integer, timeout_value integer) → boolean #

Sets the value of the asyncaction_timeout configuration parameter.

For example:

biha_db=# SELECT biha.set_asyncaction_timeout(1, 50000);
 set_asyncaction_timeout
-------------------------
 t
(1 row)
biha.set_flw_ro (id integer, available_for_read_only boolean) → boolean #

Sets the value of the flw_ro configuration parameter.

For example:

biha_db=# SELECT biha.set_flw_ro(1, true);
 set_flw_ro
------------
 t
(1 row)
biha.set_manage_slots_xmin (id integer, manage_slots_xmin boolean) → boolean #

Sets the value of the manage_slots_xmin configuration parameter.

biha.service_mode (enable_service_mode boolean, force boolean) → boolean #

Enables the service mode in a BiHA cluster. This function can only be called on the leader node. The function takes the following parameters:

  • enable: When set to true, the service mode is enabled. When not set or set to false, the service mode is disabled. Default is false.

  • force: When set to true, allows to disable the service mode ignoring all errors. When not set or set to false, the service mode cannot be disabled until you resolve all errors. Default is false.

biha.set_heartbeat_max_lost (integer) → boolean #

Sets the value of the heartbeat_max_lost configuration parameter.

For example:

biha_db=# SELECT biha.set_heartbeat_max_lost(7);
 set_heartbeat_max_lost
-------------
 t
(1 row)
biha.set_heartbeat_send_period (integer) → boolean #

Sets the value of the heartbeat_send_period configuration parameter, in milliseconds.

For example:

biha_db=# SELECT biha.set_heartbeat_send_period(2000);
 set_heartbeat_send_period
-------------
 t
(1 row)
biha.set_no_wal_on_follower (integer) → boolean #

Sets the value of the no_wal_on_follower configuration parameter, in milliseconds.

For example:

biha_db=# SELECT biha.set_no_wal_on_follower(10000);
 set_no_wal_on_follower
------------------------
 t
(1 row)
biha.set_watchdog_timeout (id integer, timeout_value integer) → boolean #

Sets the value of the watchdog_timeout configuration parameter.

For example:

biha_db=# SELECT biha.set_watchdog_timeout(1, 10);
WARNING:  [BiHA] this parameter takes effect after node restart
 set_watchdog_timeout
----------------------
 t
(1 row)
biha.reset_node_error () → boolean #

Resets the NODE_ERROR state on a node. Use this function after you fix the issue that caused the NODE_ERROR state. For more information, see Restoring the Node from the NODE_ERROR State.

26.4.3. Views #

To query the views listed below, you must first connect to the biha_db database.

26.4.3.1. biha.config_v #

This view displays the most critical parameters listed by the biha.config function.

For example:

biha_db=# select * from biha.config_v;
  id  | unit_type |      name      | parent_id |  mode   | nquorum | minnodes | heartbeat_send_period | heartbeat_max_lost
------+-----------+----------------+-----------+---------+---------+----------+-----------------------+--------------------
    1 | NODE      | biha_node_1    |       111 | regular |       3 |        1 |                  1000 |                 10
    3 | NODE      | biha_node_3    |       111 | regular |       3 |        1 |                  1000 |                 10
    4 | NODE      | biha_node_4    |       111 | regular |       3 |        1 |                  1000 |                 10
  111 | SEGMENT   | biha_node_111  |      1111 | regular |       1 |        1 |                  1000 |                 10
 1111 | SEGMENT   | biha_node_1111 |           | regular |       1 |        1 |                  1000 |                 10
(5 rows)

Table 26.4. The biha.config_v view

Column NameDescription
id The node ID (integer).
unit_type The type of the node. Possible values: NODE, SEGMENT.
name The name of the node (text).
parent_id The unique identifier of the node that is the parent to the current node (integer).
mode The current value of mode (text)
nquorum The current value of nquorum (integer).
minnodes The current value of minnodes (integer).
heartbeat_send_period The current value of heartbeat_send_period (integer).
heartbeat_max_lost The current value of heartbeat_max_lost (integer).

26.4.3.2. biha.nodes_v #

This view displays the connection status of nodes in the cluster. For the node that the view is queried on, the following columns contain NULL: state, since_conn_start, conn_count.

For example:

biha_db=# SELECT * FROM biha.nodes_v;
 id |   host    | port  | state  | since_conn_start | conn_count
----+-----------+-------+--------+------------------+------------
  1 | localhost | 10001 | ACTIVE | 00:02:28.42069   |          1
  2 | localhost | 10002 |        |                  |
  3 | localhost | 10003 | ACTIVE | 00:02:23.42069   |          1
  4 | localhost | 10004 | ACTIVE | 00:02:23.42069   |          1
  5 | localhost | 10005 | ACTIVE | 00:02:23.42069   |          1
(4 rows)

Table 26.5. The biha.nodes_v view

Column NameDescription
id The node ID.
host The host of the node.
port The port of the node.
state The connection state of the node. This column may contain one of the following values:
  • ACTIVE: The node has active client connections. Read-write operations are performed in this state.

  • CONNECTING: An attempt to establish a client connection with the node.

  • IDLE: The node is in the passive waiting state.

  • INIT: A client connection initialization.

  • SSLCONNECT: An attempt to establish a secure connection. This state is only displayed when SSL is enabled.

  • SSLACCEPT: An attempt to accept a secure connection. This state is only displayed when SSL is enabled.

since_conn_start The time since the node connection.
conn_count The number of times the node was connected since the start of the cluster.

26.4.3.3. biha.status_v #

This view displays the state of nodes in the cluster.

For example:

biha_db=# SELECT * FROM biha.status_v;
 id | leader_id | term | online |   state   | last_known_state |  since_last_hb
----+-----------+------+--------+-----------+------------------+-----------------
  1 |         1 |    4 | t      | LEADER_RW | LEADER_RW        |
  2 |         1 |    4 | t      | FOLLOWER  | FOLLOWER         | 00:00:01.931472
  3 |         1 |    4 | f      | UNKNOWN   | FOLLOWER         | 00:00:18.931472
  4 |         1 |    4 | t      | FOLLOWER  | FOLLOWER         | 00:00:01.931472
  5 |         1 |    4 | t      | FOLLOWER  | FOLLOWER         | 00:00:01.931472
(5 rows)

Table 26.6. The biha.status_v View

Column NameDescription
id The node ID (integer).
leader_id The leader node ID (integer).
term The term of the node (integer). This is used for the purposes of the leader election.
online Shows whether the node is online (boolean: t or f).
state

The state of the node (text). This column may contain one of the following values:

  • PRESTARTUP: The initial state of the node at the BiHA cluster launch. The node sends heartbeats and executes pg_rewind if scheduled. Otherwise, the node proceeds to STARTUP.

  • STARTUP: The node waits for the Postgres Pro startup process to reach the consistency point.

  • CSTATE_FORMING: The node receives and sends heartbeats to determine what state it must transfer to.

  • LEADER_RO: The node is the leader available for read-only operations.

  • LEADER_RW: The node is the leader available for read and write operations.

  • FOLLOWER: The node is a replica of the leader. If can_be_leader and can_vote are set to true, the follower can be elected as the new leader.

  • FRONT_FOLLOWER: The node is the front follower of its segment. For more information about segments and the front follower role, see Section 26.1.5.3.

  • FOLLOWER_OFFERED: The node was manually nominated as the new leader by means of the biha.set_leader function. This state is required for the nominated node to receive missing data from the old leader.

  • CANDIDATE: The node stands as a candidate in elections of the new leader.

  • REFEREE: The node is the cluster referee. The state is the same both for the referee and referee_with_wal modes.

  • NODE_ERROR: The node is non-operational due to an error. Nodes in this state are unable to vote during elections. Reading from such nodes is prohibited. To get more information about the error, use the biha.error_details function. To restore the faulty node, see Restoring the Node from the NODE_ERROR State.

  • UNKNOWN: The node is offline for the current node.

last_known_state The last known state of the node (text).
since_last_hb The time since the last received heartbeat message (interval).

26.4.3.4. biha.super_status_v #

The extended version of the biha.status_v view that additionally displays data for GDBiHA cluster.

The biha.super_status_v view contains the following additional columns:

  • name: The name of the node (text).

  • unit_type: The type of the unit. Possible values: NODE, SEGMENT.

  • parent_id: The unique identifier of the node that is the parent to the current node (integer).

  • segment_name: The name of the segment where the node belongs to (text).

FAQ