Self-Managed Replica Set Maintenance Tutorials
MongoDB 5.0 is end of life as of October 2024. This version of the documentation is no longer
supported. To upgrade your 5.0 deployment, see the MongoDB 6.0 upgrade procedures.
The following tutorials provide information in maintaining existing replica sets.
- Change the Oplog Size of Self-Managed Replica Set Members
- Increase the size of the oplog which logs operations. In most cases, the default oplog size is sufficient.
- Perform Maintenance on Self-Managed Replica Set Members
- Perform maintenance on a member of a replica set while minimizing downtime.
- Force a Self-Managed Replica Set Member to Become Primary
- Force a replica set member to become primary.
- Resync a Member of a Self-Managed Replica Set
- Sync the data on a member. Either perform initial sync on a new member or resync the data on an existing member that has fallen too far behind to catch up by way of normal replication.
- Configure Replica Set Tag Sets
- Assign tags to replica set members for use in targeting read and write operations to specific members.
- Reconfigure a Self-Managed Replica Set with Unavailable Members
- Reconfigure a replica set when a majority of replica set members are down or unreachable.
- Self-Managed Chained Replication
- Disable or enable chained replication. Chained replication occurs when a secondary replicates from another secondary instead of the primary.
- Change Hostnames in a Self-Managed Replica Set
- Update the replica set configuration to reflect changes in members' hostnames.
- Configure a Self-Managed Secondary's Sync Target
- Specify the member that a secondary member synchronizes from.
- Rename a Self-Managed Replica Set
- Rename an unsharded replica set.
- Modify a Self-Managed PSA Replica Set Safely
- Safely perform some reconfiguration changes on a primary-secondary-arbiter (PSA) replica set or on a replica set that is changing to a PSA architecture.
- Mitigate Performance Issues with a Self-Managed PSA Replica Set
- Reduce cache pressure and increased write traffic for a deployment that has a three-member primary-secondary-arbiter (PSA) architecture.