# Feature proposal: Oplog management

**URL:** https://forums.percona.com/t/feature-proposal-oplog-management/40411
**Category:** Percona Operator for MongoDB
**Created:** [March 27, 2026, 7:57am UTC](https://forums.percona.com/t/feature-proposal-oplog-management/40411 "2026-03-27T07:57:58Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![horihel](https://avatars.discourse-cdn.com/v4/letter/h/f0a364/32.png) [@horihel](https://forums.percona.com/u/horihel)
#### Post date: [March 27, 2026, 7:57am UTC](https://forums.percona.com/t/feature-proposal-oplog-management/40411/1 "2026-03-27T07:57:58Z")

</div>

## Description:

This is one of the things that regularly happens in my deployment (which admittedly are mostly testing deployments for now): Adjust oplog maxsize. Usually it is increasing (of course).

The current approach is only declarative if one creates a new cluster (using `replsets.configuration` you can drop a snippet that causes mongod to create the desired oplog maxsize). Adjusting it during runtime though needs manual intervention (or a clever job/script) and since my mongodb is managed by an operator, I generally would like to keep “manual intervention” to emergencies.

Additionally, in a cluster with an “adjusted” oplog, if you ever need to replace a node (or do a physical restore), your oplog maxsize is again not deterministic.

Maybe I missed something, but as of now, I think psmdb-operator does not do oplog management. And I’m pretty certain that it’s a good idea that all nodes in a replicaset have the same oplog maxsize (correct me if i’m wrong).

It’s one of the _very_ few things I’m missing on psmdb-operator 🙂

---

<div class="post-metadata">

### Author: ![yunus.uyanik](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus.uyanik/32/19250_2.png) [@yunus.uyanik](https://forums.percona.com/u/yunus.uyanik)
#### Post date: [March 30, 2026, 10:01am UTC](https://forums.percona.com/t/feature-proposal-oplog-management/40411/2 "2026-03-30T10:01:46Z")

</div>

Hi @horihel

Not sure that should be automatically handled, but you can create a feature request from our Jira. That said, I’d suggest considering `oplogMinRetentionHours` instead of a fixed MB size.

---

<div class="post-metadata">

### Author: ![horihel](https://avatars.discourse-cdn.com/v4/letter/h/f0a364/32.png) [@horihel](https://forums.percona.com/u/horihel)
#### Post date: [March 30, 2026, 12:09pm UTC](https://forums.percona.com/t/feature-proposal-oplog-management/40411/3 "2026-03-30T12:09:31Z")

</div>

Hi @yunus.uyanik ,

thanks for considering. I’d prefer `oplogMinRetentionHours` too, but this is something that has to be cleared at higher levels because that setting is only safe when automatic volume expansion is enabled.

Otherwise very bursty workloads (which we see sometimes) would quickly result in disk-full errors.

And `oplogMinRetentionHours` also does not automatically replicate to new/replaced replicas.

I’ll bring my proposal to Jira then - Thank you & Best Regards
