This operation mode is based on PostgreSQL streaming replication. Other software such as cluster software is not required.
This mode replicates the database on all servers that comprise the cluster system. It achieves this by transferring the updated transaction logs of the database from the server that receives the updates (primary server) to another server (standby server), and then reflecting them on the standby server.
It consists of a feature that detects faults in the elements that are essential for the continuity of the database operation (such as the database process, disk, and network), as well as simplified switchover and standby server disconnection features. The database will be copied in synchronous mode.
Monitoring using database multiplexing mode
Operating system or server failures, and no-response state
By generating a heartbeat between Mirroring Controller on each server, operating system or server errors are detected and acknowledged between the relevant servers.
Database process failures, and no-response state
Mirroring Controller periodically accesses the database processes and checks the status. A process error is detected by monitoring whether an access timeout occurs.
Mirroring Controller periodically accesses the database processes and checks the status. A process error is detected by monitoring whether an access timeout occurs.
Disk failure
Mirroring Controller periodically creates files on the data storage destination disk. A disk error is detected when an I/O error occurs.
Failures that can be detected are those that physically affect the entire system, such as disk header or device power failures.
Figure 5.1 Failover from the primary server to the standby server
Figure 5.2 Standby server disconnection
When database multiplexing is used to perform monitoring and an error is detected, this option will automatically switch the primary server or disconnect the standby server.
Reference jobs can also be executed on the standby server.
Note
If the role of primary server was switched to another server and then starts degrading, the original primary server will not become the standby server automatically. Remove the cause of the error, and then change the role of the original primary server to the server currently acting as standby server. Refer to "8.1 Action Required when Server Degradation Occurs" for details.
See
Refer to "5.2.4 Notes on Executing Reference Jobs on the Standby Server (when the Mirroring Controller Option is Used) " for information on reference jobs.
The features that can be used will depend on the whether the Mirroring Controller option is used. Refer to "Features that can be Installed" in the Installation and Setup Guide for Server for details.
Point
If the standby server was disconnected, Mirroring Controller will automatically delete the target standby server from the synchronous_standby_names parameter in the postgresql.conf file of the primary server. Accordingly, you can prevent the application processing for the primary server being stopped.
