Fujitsu Logo
ENQUIRE

    Knowledge articles -High availability

    Is there a way to determine if the server is running as the primary or standby by obtaining information from a database or a file on that server?KB4001

    When you use the streaming replication feature, you can use the pg_is_in_recovery() function to check the server status.

    The function returns t if the server is a standby, or f if the server is a primary.

    In FUJITSU Enterprise Postgres, when you use Mirroring Controller to comprise the cluster system, you can use the Mirroring Controller command mc_ctl to determine which is primary and which is standby server as follows:

    mc_ctl status -M /mcdir/inst1

    The output will look like this:

    mirroring status
    -----------------
    switchable
     server_id  host_role  host           host_status  db_proc_status  disk_status 
    ------------------------------------------------------------------------------
     inst1p     standby    XXX.XX.XX.156  normal       normal          normal
     inst1s     primary    XXX.XX.XX.161  normal       normal          normal

    For more information on how to use the Mirroring Controller command mc_ctl to check the server role, refer to Cluster Operation Guide - Database Multiplexing > Chapter 3 - Operations in Database Multiplexing Mode > 3.3 - Checking the Database Multiplexing Mode Status.

    Applicable to

    Product: FUJITSU Enterprise Postgres SE, FUJITSU Enterprise Postgres AE, PostgreSQL

    Architecture: X86, S390x

    Operating System: Linux

    Versions: from 9.5

    When source (master) and destination (standby) database servers are synchronized using the streaming replication feature, what is the impact on database server updates if I promote the destination (standby) server to master?KB4002

    If you promote the standby server while the source (master) is still active, the standby server will become an updatable instance (client connections besides those of a replication type can update the database cluster).

    This situation where both database instances of a cluster are updatable is referred to as a split-brain scenario. It means that some clients can make changes to the original master but not to the original standby, while other clients can make changes to the original standby but not to the master, eventuating in two separate database clusters containing different sets of data. At this point, no matter which database cluster you connect to, some data will be missing (as it will exist on the other database instance).

    Recovering from a split-brain scenario is difficult because you need to identify the differences and ensure that missing data on one server is recovered from the other server. A new standby will need to be created from the newly recovered master before a high availability architecture can again be achieved.

    Before promoting a standby server to master, it is vital that the master database (source) is fenced, i.e., that it is made inaccessible to any clients. For more details on this topic, look up STONITH (Shoot The Other Node In The Head).

    For details on how to avoid split brains when using pgpool-II, refer to our PostgreSQL Insider article PostgreSQL High Availability using pgpool-II.

    Applicable to

    Product: FUJITSU Enterprise Postgres SE, FUJITSU Enterprise Postgres AE, FUJITSU Enterprise Postgres for Kubernetes, PostgreSQL

    Architecture: X86, S390x

    Operating System: Linux

    Versions: from 9.5

    Is it possible to resume streaming replication operations on a standby instance that has been restored from a logical dump (performed with pg_dump or pg_dumpall) of the primary database cluster?KB4003

    No, the recommend approach is to use a binary dump such as that performed by using pg_basebackup. This ensures that the necessary information is written to the database data files and WAL files in order to begin playing the WAL files from the correct position.

    The risk of using a logical dump is that data written since the start of the backup is not included in that backup, and that a restore is not able to identify the correct place in the WAL to start synchronising from.

    A restore of a binary backup by itself may not produce a consistent database (specifically when the database is being used while the backup is being executed), so the WAL files must be used to bring the database into a consistent state during restore.

    Applicable to

    Product: FUJITSU Enterprise Postgres SE, FUJITSU Enterprise Postgres AE, PostgreSQL

    Architecture: X86, S390x

    Operating System: Windows, Linux

    Versions: from 9.5

    Read our latest blogs

    Read our most recent articles regarding all aspects of PostgreSQL and FUJITSU Enterprise Postgres.