2

Is it wise/recommended/possible to build an index on the oplog.rs collection? The reason I ask is that I believe that it is the cause of our constant alerts regarding scanned object/returned surpassing 1000. Is this possible or does that alert not take the oplog/local into account?

I have combed our code to ensure indexing is present for all queries (it is quite a small code base all in all). I have also gone through the logs to ensure there is no presence of any COLLSCAN - hence the possible explanation that the oplog.rs collection is responsible for these alerts. Another factor here being that the alert fluctuates extremely wildly - from sub 100 to 1500 - which sounds like it would be oplog related.

Thanks in advance!

Hemal
  • 1,617
  • 2
  • 12
  • 21
  • What exactly are you querying the oplog for? It is a "capped collection" and really should be treated as a FIFO and there should not be any real utility beyond processing items "in sequence" as they appear. If you want some sort of "analysis" then your probably better off listening for "change stream events" and writing to another collection to analyse. It's certainly not wise to expect data to remain in the oplog for any longer period of time than it's intended replication purpose. – Neil Lunn May 30 '18 at 01:40
  • It is not possible to create any secondary indexes on the oplog (see: https://stackoverflow.com/questions/15389325/index-on-ts-field-in-oplog-rs-is-not-updated). What system is generating these alerts? Ideally the alert message should include context of the namespace (database & collection). Is your application doing any custom queries or tailing with the oplog? Have you reviewed your MongoDB logs for slow queries? Depending on system resources, inefficient queries may not necessarily be slow but that's usually a good starting point. – Stennie May 30 '18 at 04:55
  • Cheers for the responses. I'll leave the oplog be as is - my concern was the alert I kept getting saying the ration of objects scanned to documents returned was going over 1000. That said, digging deeper, I found no slow queries (over 100ms) and no instances of any queries that were doing a full COLLSCAN. Monitoring the real time metrics in Mongo Atlas, the only query that kept coming up there in their list of slowest queries, were all queries on the oplog. However, with it being capped, it makes zero sense to index it, like you both say. Cheers. – Hemal May 31 '18 at 02:58
  • 1
    Are you using MeteorJS? I think a few users (including myself) are also running into this problem: https://forums.meteor.com/t/galaxy-mongo-issue-any-theories-spiked-query-targeting-scanned-objects-returned-ratio/50115/8 – williamli Dec 11 '19 at 06:59

0 Answers0