Primary/Standby

Availability

This feature is available since MogDB 1.1.0.

Introduction

To ensure that a fault can be rectified, data needs to be written into multiple copies. Multiple copies are configured for the primary and standby nodes, and logs are used for data synchronization. In this way, MogDB has no data lost when a node is faulty or the system restarts after a stop, meeting the ACID feature requirements.

Benefits

Services can be switched to the standby node when the primary node is faulty. Therefore, data is not lost and services can be quickly restored.

Description

The primary/standby environment supports two modes: primary/standby/secondary and one-primary-multiple-standby. In the primary/standby/secondary mode, the standby node needs to redo logs and can be promoted to the primary. However, the secondary node can only receive logs and cannot be promoted to the primary. In the one-primary-multiple-standby mode, all standby nodes need to redo logs and can be promoted to the primary. The primary/standby/secondary mode is mainly used for the OLAP system, saving storage resources. The one-primary-multiple-standby mode provides higher DR capabilities and is more suitable for the OLTP system that processes a large number of transactions.

The switchover command can be used to trigger a switchover between the primary and standby nodes. If the primary node is faulty, the failover command can be used to promote the standby node to the primary.

In scenarios such as initial installation or backup and restoration, data on the standby node needs to be rebuilt based on the primary node. In this case, the build function is required to send the data and WALs of the primary node to the standby node. When the primary node is faulty and joins again as a standby node, the build function needs to be used to synchronize data and WALs with those of the new primary node. In addition, in online capacity expansion scenarios, you need to use build to synchronize metadata to instances on new nodes. Build includes full build and incremental build. Full build depends on primary node data for rebuild. The amount of data to be copied is large and the time required is long. Incremental build copies only differential files. The amount of data to be copied is small and the time required is short. Generally, the incremental build is preferred for fault recovery. If the incremental build fails, the full build continues until the fault is rectified.

To implement HA DR for all instances, in addition to the preceding primary/standby multi-copy replication configured for DNs, MogDB also provides other primary/standby DR capabilities, such as CM server (one primary and multiple standbys) and ETCD (one primary and multiple standbys). In this way, instances can be recovered as soon as possible without interrupting services, minimizing the impact of hardware, software, and human errors on services and ensuring service continuity.

Enhancements

None

Constraints

None

Dependencies

None