MongoDB Replication Overview

Tags:

This article explains MongoDB replication.

Replication

Replication is a mechanism that copies data to multiple database servers to provide redundancy and availability. It is a countermeasure against failures or disasters when data is stored in different data centers. Because the same data is available, it can also be used for load balancing in read-heavy applications.

Replication in MongoDB

MongoDB manages database instances that hold the same data as a single group called a replica set. MongoDB provides redundancy and availability through the way this replica set works.

The primary server receives all write operations, records changes to data, and leaves them in a log. Secondary servers copy and apply the primary server’s operation log to reach the same data state as the primary server. If the primary server fails, an appropriate secondary server is elected as the primary server and continues service.

MongoDB replication

Replica Set Members

There are three types of members included in a MongoDB replica set.

  • Primary
  • Secondary
  • Arbiter

Each is described in detail below.

Primary server

The primary server is the only writable server in a replica set. Write operation information on the primary server is stored in the oplog, and this operation log is sent to and copied by secondary servers.

If the primary server has a problem for any reason, the next primary server is elected by vote from the remaining secondary servers.

Secondary server

A secondary server is a read-only server that updates its data based on the primary server’s operation log. By preparing multiple secondary servers, large volumes of read operations can be handled.

Reads from clients are basically performed with secondary servers preferred, and only data that is needed immediately is read with the primary server preferred.

The basic secondary server settings are priority, hidden, and delayed.

  • Priority
    If Priority: 0 is specified, the server is not promoted to primary. The primary server is elected from servers with a priority greater than 0. A server with a higher priority value is preferentially elected as the primary server.
  • Hidden
    This setting copies operation logs from the primary server and keeps data up to date, but the server is not visible to client applications. Because it is not visible to client applications, it has a lower load than other servers. A hidden server is used as a dedicated machine for tasks different from normal work, such as data analysis or backup.
  • Delayed
    This setting copies operation logs from the primary server and applies them after a specified delay from the primary server. By applying data with a delay from the primary server, it can be used for recovery when an operation mistake occurs.

Arbiter server

An arbiter server is an adjustment server added to make the number of voting servers in a replica set odd. The arbiter server itself has no data, and its main role is to vote in the election of a new primary server when the primary server has a problem. Because it does not become the primary server itself, specify Priority: 0.

Replica Set Configuration

A replica set can include up to 50 members, and up to 7 of them can have voting rights. Design the number of voting servers to be odd. If the count is insufficient, add an arbiter to adjust it.

The minimum replica set has a three-member configuration, and the following configurations are possible.

  • Primary and two secondaries
  • Primary, secondary, and arbiter

Placing members in geographically distant data centers can provide higher availability.

Primary and two secondaries

This pattern has high availability because both secondary servers can become the primary server.

Normally, complete copies are created on the two secondary servers. If the primary server has a problem, the two remaining secondary servers vote, and one of them is promoted to primary.

Primary and two secondaries

Primary, secondary, and arbiter

This is a so-called two-server configuration. In practice, the primary server and secondary server are the two servers that operate, and the arbiter server participates in voting only when failover is performed. Because it is not recommended to promote an arbiter to a secondary, place it on a physically separate, lower-spec server such as a management server.

In this pattern, data is not copied to the arbiter server, so a full copy exists only on the secondary server. If the primary server has a problem, a primary election is performed, and the remaining secondary server is inevitably promoted to primary.

Primary, secondary, and arbiter

Automatic Failover

A replica set provides high availability through automatic failover. Specifically, when the primary server does not respond, the secondary servers elect the next primary server, and the elected secondary server is promoted to primary.

Each member performs a heartbeat, or ping, every 2 seconds. If no response is received for 10 seconds, that server is marked as faulty. When the primary server is marked as faulty, the remaining secondary servers start electing the next primary server.

When servers vote, the server with the higher priority is preferentially elected as the secondary server to promote. If a server with a lower priority has been elected and a server with a higher priority becomes available, another vote is performed so that the higher-priority server becomes the primary server.

Members that do not vote have their priority set to 0. Because a single replica set can have up to 7 voting members, when preparing more secondary servers than that, use servers with Priority set to 0 and votes also set to 0.

Reading and Writing Data

Data read and write settings can also be specified as options when creating MongoClient. There are three write settings, w, j, and wtimeout, and two read settings, readPreference and readConcern.level.

var {MongoClient, ReadPreference} = require("mongodb");
 
var URL = "mongodb://localhost:27017/test";
 
MongoClient.connect(URL, {
  // Write settings
  w: "majority",
  j: true,
  wtimeout: 5000,
  // Read settings
  readPreference: ReadPreference.SECONDARY_PREFERRED
  readConcern: {
    level: "local"
  }
}, (client) => {
  client.close();
});

Writing data

For writes, the Write Concern configuration specifies how many servers in the replica set write processing should be propagated to.

w

Setting Description
<number> Guarantees that the write is applied up to the specified number of servers.
"majority" Ensures that the write is recorded on a majority of servers with voting rights.

j

Setting Description
true Waits until the write is written to disk.
false Default value. Guarantees only that the write is made to memory.

wtimeout

Setting Description
<number> Specifies the write timeout in milliseconds. When setting this value, specify a value greater than 1. If 0 is specified, timeout processing is not performed.

Reading data

For reads, Read Preference settings can specify which server should be preferred when loading data.

readPreference

Setting Description
primary Default mode. Reads from the primary server.
primaryPreferred Reads from the primary server in most cases, but reads from a secondary server if the primary server cannot be accessed.
secondary Reads from a secondary server.
secondaryPreferred Reads from a secondary server in most cases, but reads from the primary server if a secondary server cannot be accessed.
nearest Reads from the server with the lowest latency, regardless of replica set member type.

readConcern.level
Specifies what data to read.

Setting Description
"local" Reads locally by default. Retrieves the latest data from the instance. It does not guarantee whether the data has been written to a majority of the replica set.
"available" Reads from secondaries by default. Retrieves the latest data from the instance. It does not guarantee whether the data has been written to a majority of the replica set.
"majority" Retrieves the latest data that has been written to a majority of members.
"linearizable" Retrieves data that will not be rolled back after all writes have completed.

Summary

This article summarized MongoDB replication. The key points are as follows.

  • Only the primary server can write.
  • If the primary server has a problem, a remaining secondary server is promoted to primary.

References