> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Fix Oplog Issues

Replication Oplog alerts can be triggered when the amount of [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) data generated on a [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) cluster member is larger than the cluster's configured oplog size.

## Alert Conditions

You can configure the following alert conditions in the project-level [alert settings](https://www.mongodb.com/docs/atlas/configure-alerts.md#std-label-configure-alerts) page to trigger alerts.

[`Replication Oplog Window is (X)`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Replication-Oplog-Window-is) occurs if the approximate amount of time available in the primary replication oplog meets or goes below the specified threshold. This refers to the amount of time that the primary can continue logging given the current rate at which oplog data is generated.

[`Oplog Data Per Hour is (X)`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Oplog-Data-Per-Hour-is) occurs if the amount of data per hour being written to a primary's replication oplog meets or exceeds the specified threshold.

## Common Triggers

These are a few common events which may lead to increased oplog activity:

- Intensive write and update operations in a short period of time.

- The cluster's [configured oplog size](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-more-configuration-options) is smaller than the value in the Oplog GB / Hour graph observed in the cluster [metrics view.](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-monitor-cluster-metrics)

## Fix the Immediate Problem

These are a few possible actions to consider to help resolve Replication Oplog Alerts:

- Increase the oplog size by [editing your cluster's configuration](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-more-configuration-options) to ensure it is higher than the *peak* value from the Oplog GB / Hour graph in the cluster [metrics view.](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-monitor-cluster-metrics)

- Increase the oplog size if you foresee intense write and update operations occurring in a short time period.

  **Note:**

  You may need to [increase your cluster's storage](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-modify-cluster) to free enough space to resize the oplog.

- Ensure that all write operations specify a [write concern](https://www.mongodb.com/docs/manual/reference/write-concern.md#std-label-write-concern) of `majority` to ensure that writes are replicated to at least one node before moving on to the next write operation. This controls the rate of traffic from your application by preventing the primary from accepting writes more quickly than the secondaries can handle.

  On an Atlas Infinite cluster, the storage layer replicates your data and `majority` refers to a majority within the storage layer rather than a majority of the cluster's nodes. To learn more, see [Write Concern on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-architecture.md#std-label-atlas-infinite-write-concern)

## Implement a Long-Term Solution

To learn about `oplog` sizing requirements for your use case, see [Workloads that Might Require a Larger Oplog Size.](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md#std-label-replica-set-large-oplog-required)

You can't set the oplog size on an Atlas Infinite cluster. To learn how Atlas manages the oplog on these clusters, see [Oplog on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-architecture.md#std-label-atlas-infinite-oplog)

## Monitor Your Progress

You might observe the following scenarios when these alerts trigger:

- The Oplog GB / Hour graph in the [metrics view](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-monitor-cluster-metrics) spikes upward.

- The Replication Oplog Window graph in the [metrics view](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-monitor-cluster-metrics) is low.

- The Atlas [View and Download MongoDB Logs](https://www.mongodb.com/docs/atlas/mongodb-logs.md#std-label-mongodb-logs) of [secondary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary) or unhealthy nodes display the following message:

  ```none
  We are too stale to use <node>:27017 as a sync source.
  ```

- An Atlas node is reporting a state of [STARTUP2](https://www.mongodb.com/docs/manual/reference/replica-states/#mongodb-replstate-replstate.STARTUP2) and [RECOVERING](https://www.mongodb.com/docs/manual/reference/replica-states/#mongodb-replstate-replstate.RECOVERING) for an extended period of time.

  Typically, this indicates that the node has "fallen off the oplog" and is unable to keep up with the oplog data being generated by the primary node. In this case, the node will require an [initial sync](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) in order to recover and ensure that the data is consistent across all nodes. You can check the state of a node using the [`rs.status()`](https://www.mongodb.com/docs/manual/reference/method/rs.status.md#mongodb-method-rs.status) shell method.