Feature proposal: Oplog management

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 :slight_smile:

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.

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

1 Like