Applying Replication

One of the most critical aspects of high-performance databases is replication. Replication is the process of defining multiple MongoDB servers that have the same data. The MongoDB servers in the replica set will be one of three types, as illustrated in Figure 17.1:

Primary: The primary server is the only server in a replica set that can be written to. This way, the primary server can ensure the data integrity during write operations. A replica set can have only one primary server.

Secondary: A secondary server contains a duplicate of the data on the primary server. To ensure that the data is accurate, the replica servers apply the operations log or oplog from the primary server, ensuring that every write operation on the primary server also happens on the secondary servers, in the same order. Clients can read from secondary servers but not write to them.

Arbiter: The arbiter server is kind of interesting. It does not contain a replica of the data but can be used when electing a new primary if the primary server experiences a problem. When the primary server fails, the failure is detected, and other servers in the replica set elect a new primary, using a heartbeat protocol between the primary, secondary, and arbiter servers. Figure 17.2 shows an example of the configuration using an arbiter server.

Figure 17.1 Implementing a replica set in MongoDB.

Figure 17.2 Implementing an arbiter server in a MongoDB replica set to ensure an odd number of servers.

Replication provides two benefits: performance and high availability. Replica sets improve performance because although clients cannot write to secondary servers, they can read from them, which means multiple read sources for applications.

Replica sets provide high availability because if the primary server happens to fail, other servers that have a copy of the data can take over. The replica set uses a heartbeat protocol to communicate between the servers and determine whether the primary server has failed, at which point a new master is elected.

You should have at least three servers in a replica set. Also, having an odd number of servers makes it easier for the servers to elect a primary. This is where arbiter servers come in handy. They require a few resources but can save time when electing a new primary. Figure 17.2 shows the replica set configuration with an arbiter. Notice that the arbiter does not have a replica; it only participates in the heartbeat protocol.