Replication

Concept of Replication
Replication in MongoDB is the process of synchronizing data across multiple servers to ensure high
availability and redundancy. It involves:
1. Replica Sets: A group of MongoDB servers that maintain the same data. One node act as the
primary, receiving all writes, while others are secondary nodes that replicate the primary's data.
2. Oplog: The primary node logs all changes in an oplog, which secondary nodes use to replicate the
data.
3. Automatic Failover: If the primary fails, a secondary can be elected as the new primary, ensuring
continuous operation.
4. Read Preference: Applications can read from primary or secondary nodes, allowing for load
balancing.
This setup enhances data availability, redundancy, and scalability.

Replica Set Member Roles

In MongoDB, members of a replica set can have specific roles, which define their responsibilities within the
cluster. Here are the key roles:
1. Primary:
o Handles all write operations.
o Maintains the oplog (operation log) to track changes.
o Only one primary exists in a replica set at any given time.
2. Secondary:
o Replicates data from the primary by reading the oplog.
o Can handle read operations if configured (read preference set to secondary).
o Can become the primary if the current primary fails and is eligible for election.
3. Arbiter:
o Does not store data or serve read/write operations.
o Participates in elections to help maintain an odd number of voting members.
o Useful in scenarios where additional data storage is not required, but quorum is necessary for
elections.
These roles work together to provide redundancy, high availability, and data consistency in MongoDB
deployments

Voting and Electing primary

After a replica set has a stable primary, the election algorithm will make a "besteffort " attempt to have the
secondary with the highest priority available call an election. Member priority affects both the timing and
the outcome of elections; secondaries with higher priority call elections relatively sooner than secondaries
with lower priority, and are also more likely to win. However, a lower priority instance can be elected as
primary for brief periods, even if a higher priority secondary is available. Replica set members continue to
call elections until the highest priority member available becomes primary.
Members with a priority value of 0 cannot become primary and do not seek election.

Role of Oplog in replication

The oplog (operation log) plays a crucial role in MongoDB's replication mechanism. Here’s how it
functions:
Key Functions of Oplog
1. Change Tracking:
o The oplog records all write operations (insert, update, delete) that occur on the primary node.
This log serves as a sequential record of changes.
2. Replication:
o Secondary nodes continuously read from the oplog to replicate changes. They apply these
operations to their own data set, ensuring data consistency across the replica set.
 3. Point in Time Recovery:
o The oplog allows for pointintime recovery of data. If necessary, you can use the oplog to
revert to a previous state of the database.
4. Capped Collection:
o The oplog is implemented as a capped collection, meaning it has a fixed size and operates in
a circular manner. Once it reaches its size limit, older entries are overwritten.
5. Latency Management:
o The oplog helps in managing replication lag by providing a clear trail of changes, allowing
secondary nodes to catch up efficiently with the primary.

Read and Write Concern

In MongoDB, Read Concern and Write Concern are critical components that define the consistency and
durability guarantees for read and write operations.
Write Concern
Write Concern specifies the level of acknowledgment requested from MongoDB for write operations. You
can control how many nodes in the replica set must confirm a write before it is considered successful.
Common options include:
 w: 1: Acknowledgment from the primary only.
 w: "majority": Acknowledgment from the majority of the replica set members.
 w: 0: No acknowledgment (fireandforget).
 wtimeout: A time limit for the acknowledgment process.
Read Concern
Read Concern determines the consistency level of the data being read. It defines what version of the data
you can read based on the replication state. Common options include:
 local: Returns the most recent data available on the node (even if it’s not acknowledged by the
majority).
 majority: Returns data that has been acknowledged by the majority of replica set members.
 linearizable: Guarantees that the data read is the most recent committed data and ensures that
subsequent reads will return data that reflects all prior writes.
 available: Returns data regardless of the acknowledgment state.

Arbiter, Hidden and Delayed Replica Node

Arbiter
Arbiters are mongod instances that are part of a replica set but do not hold data (i.e., do not provide data
redundancy). They can, however, participate in elections.
Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an
arbiter on an application server or a monitoring host.

Hidden Node
A hidden member maintains a copy of the primary's data set but is invisible to client applications. Hidden
members are good for workloads with different usage patterns from the other members in the replica set.
Hidden members must always be priority 0 members and so cannot become primary. The db.hello() method
does not display hidden members. Hidden members, however, may vote in elections.

Delayed Node
Delayed members contain copies of a replica set's data set. However, a delayed member's data set reflects an
earlier, or delayed, state of the set. For example, if the current time is 09:52 and a member has a delay of an
hour, the delayed member has no operation more recent than 08:52.
Because delayed members are a "rolling backup" or a running "historical" snapshot of the data set, they may
help you recover from various kinds of human error. For example, a delayed member can make it possible to
recover from unsuccessful application upgrades and operator errors including dropped databases and
collections.
Priority settings
In MongoDB, priority settings are used to control which members of a replica set are preferred to become
primary during elections. Each member of a replica set can be assigned a priority value, which affects its
likelihood of being elected as the primary.
Priority Settings
1. Priority Value:
o Ranges from 0 to 100.
o A higher priority means a higher chance of being elected as primary.
o A priority of 0 means the member cannot become primary.
2. Default Priority:
o By default, all members of a replica set have a priority of 1.
3. Use Cases:
o High Priority: Assign a higher priority to members that have better resources (e.g., more
RAM, CPU, or are geographically closer to your application).
o Low Priority: Assign a lower priority to members that are meant to be secondary (e.g., for
backup or read only purposes).
o Zero Priority: Use for arbiters or hidden nodes that should never become primary.
4. Setting Priority:
o You can configure the priority using the rs.reconfig() command to change the settings of an
existing replica set member.
Example
Here's an example of how to set priority using rs.reconfig():

cfg = rs.conf()
cfg.member[0].priority = 5 // Member 0 has high priority
cfg.member[1].priority = 3 // Member 1 cannot become primary
cfg.member[2].priority = 2 // Member 2 has normal priority
rs.reconfig(config);

Replica Set Node Health Check

In MongoDB, monitoring the health of replica set nodes is crucial for maintaining high availability and
performance. Here are several ways to check the health of replica set nodes:
1. Using the `rs.status()` Command
The `rs.status()` command provides detailed information about the state of the replica set members,
including their health status.

Command:
rs.status()

Output:
The output includes an array of members with fields like `health`, `state`, and `lastHeartbeat`.
`health`: A value of `1` means the node is healthy; `0` indicates it's unhealthy.
`state`: Indicates the current state (e.g., PRIMARY, SECONDARY, RECOVERING, etc.).
`lastHeartbeat`: Timestamp of the last heartbeat received from the member.

2. Using the `rs.isMaster()` Command

The `rs.isMaster()` command can be used to check the state of the current node and its role within the replica
set.
Command:
db.isMaster()
Output:
This will show details about the current primary, secondaries, and their health statuses.
 3. Monitoring with MongoDB Tools
MongoDB Atlas: If you are using MongoDB Atlas, it provides builtin monitoring tools that display the
health and performance metrics of your cluster.
Monitoring Tools: Use external monitoring tools (e.g., Prometheus, Grafana) to visualize metrics and set up
alerts for node health issues.
4. Logs and Alerts
Regularly check MongoDB logs for any warnings or errors related to replication or node health.
Set up alerts for significant changes in node health or state changes.

Concept of Resyncing the Nodes

In MongoDB, resyncing a node refers to the process of reinitializing a secondary member of a replica set to
ensure it has an up-to-date copy of the data from the primary. This is necessary in certain scenarios, such as:
When to Resync a Node
1. Data Corruption: If a secondary node experiences data corruption or inconsistency.
2. Stale Data: If a secondary has fallen too far behind the primary and cannot catch up through normal
replication.
3. Hardware Failures: If a node fails and needs to be rebuilt.
4. Configuration Changes: When significant configuration changes necessitate a clean state.
Resyncing Process
1. Step Down: If applicable, step down the current primary to avoid potential inconsistencies.
2. Remove Node: Use rs.remove(<hostname:port>) to remove the node from the replica set.
3. Re-add Node: Re-add the node using rs.add(<hostname:port>). The node will automatically start
the resync process.
4. Full Sync: The node will perform a full sync, which involves copying the entire dataset from the
primary to the secondary.
How to Initiate a Resync
To manually trigger a resync without removing the node, you can:
1. Run the Command:
db.adminCommand({ replSetSyncFrom: "<primary_hostname:port>" })
2. Shut Down and Restart: Alternatively, you can shut down the MongoDB service on the secondary
and restart it, which will also trigger a full resync upon rejoining the replica set.
Considerations
 Downtime: While resyncing is happening, the node will be unavailable for read operations until it is
fully synced.
 Resource Intensive: Full resyncs can be resource-intensive, impacting performance on the primary
and the network.
 Data Consistency: Always ensure that resyncing is done in a manner that maintains data consistency
and availability in your application.

Key file Authentication

Key file authentication is a method used to secure communication between members of a MongoDB replica
set or sharded cluster. Here's how it works and how you can set it up:
What is a Key File?
A key file is a shared secret used by MongoDB instances within the same replica set or sharded cluster to
authenticate each other. It contains a string of characters that must be identical on all members of the
deployment.
Setting Up Key File Authentication
1. Generate a Key File:
o You can generate a key file using a utility like openssl or any other secure random string
generator. For example:
openssl rand -base64 741 > /path/to/mongodb-keyfile
Ensure that the key file has proper permissions (chmod 600 to restrict access).
 2. Distribute the Key File:
o Copy the generated key file to all nodes (servers) in your MongoDB deployment. Place it in
the same location (/path/to/mongodb-keyfile) with the same permissions on each server.
3. Configure MongoDB with the Key File:
o Edit the MongoDB configuration file (mongod.conf for MongoDB instances).
o Add or modify the security.keyFile setting to point to the location of the key file:
security:
keyFile: /path/to/mongodb-keyfile
4. Restart MongoDB Instances:
o Restart each MongoDB instance (mongod process) to apply the new configuration.
5. Verify Authentication:
o Once configured and restarted, MongoDB instances will use the key file to authenticate each
other when they communicate within the replica set or sharded cluster.
6. Create the user administrator
o Add a user using the db.createUser() method. The user should have at minimum the
userAdminAnyDatabase role on the admin database.
o You must be c
o onnected to the primary to create users.
o The following example creates the user root with the userAdminAnyDatabase role on the
admin database.
o db.createUser( { user: "root", pwd: root@123, roles: [ { role: "root", db: "admin" } ] })

7. Authenticate as the User Administrator

Authenticate to the admin database.
In mongosh, use db.auth() to authenticate. For example, the following authenticate as the user
administrator root: