Applicable Scenarios of Multi-Master Replication (1) - Multi-IDC

3 multi-master replication

Previously, it was a single-master master-slave replication architecture. Master-slave replication has an obvious disadvantage: there is only one master node, and all writes must go through it ^iv.In the event that the network with the master node is interrupted and it is impossible to connect to the master node, the master-slave replication scheme affects all DB write operations.

To expand the master-slave replication model, you can configure multiple master nodes, each of which can handle writes. The process of subsequent replication is similar: each [master node] that processes writes must forward the data changes.to all other nodes.This is multi-master (also known as master-master, or active/active) replication.At this time, each master node also acts as a slave node of other master nodes at the same time.

3.1 Applicable scenarios

Using multiple masternodes within an IDC doesn't make much sense, as the complexity outweighs the benefits.But in some cases, the multi-active configuration is also reasonable:

3.1.1 Multiple IDC

To tolerate an entire IDC level failure or closer to the user, a copy of the DB can be spread across multiple IDCs.However, if the conventional master-slave replication model is used, the master node must be located in one of the IDCs, and all write requests must go through this IDC.

With the multi-master node replication model, master nodes can be configured in each IDC, as shown in Figure-6. Basic architecture:

• In each IDC, master-slave replication is used
• Between IDCs, the master node of each IDC is responsible for data exchange and update with the master nodes of other IDCs

Single-master vs. multi-master when comparing multiple data centers:

Performance

• Single live, each write must traverse the Internet and enter the master node data center.This can greatly increase write latency and go against the original intention of setting up multiple data centers (nearest access)
• Multiple activities, each write operation can respond quickly in the local IDC, and then use asynchronous replication to synchronize changes to other IDCs.Therefore, the network delay between IDCs is effectively shielded for upper-layer applications, so that the performance experienced by end users is better

Tolerating data center downtime

Under master-slave replication, if the IDC where M is located fails, it must be switched to another IDC, and one of the slave nodes will be promoted to M.In the multi-master model, each IDC can continue to operate independently of other IDCs, and the failed data center is updated to the latest state after recovery.

Tolerating network issues

Communications between IDCs are usually over a wide area network, which is mostly not as reliable as the local network within the IDC.A single-master configuration is very sensitive to connectivity issues between datacenters because writes over this connection are synchronous.Multi-active configurations with asynchronous replication are generally better able to withstand network issues: temporary network outages do not prevent writes being processed.

Some databases support multi-master configuration by default, but it is also common to use external tools such as MySQL's Tungsten Replicator.

Although multi-master replication has these advantages, it also has a big disadvantage: two different IDCs may modify the same data at the same time, and write conflicts must be resolved (conflict resolution in Figure-6).

Since multi-master replication is only a new feature in many databases, there are still subtle configuration flaws, and interactions with other database features such as auto-incrementing primary keys, triggers, and integrity constraints sometimes occur unexpectedly.Therefore, many people feel that multi-master replication is dangerous and should be avoided as much as possible.