I am using a free M0 cluster on cloud.mongodb.com with a meteor-app and got recently notified about a performance-issue concerning a regex-query on oplog taking a minute or longer. As a result the database got throttled and is not reachable anymore until the issue is resolved.
The thing is, the app (using meteor 1.5.1) does not use any regex-queries nor does it use the facts package explicitly.
I got informed that: “Changes streams and triggers both reference oplog in the backend which can be a contributing factor.”
So I was wondering if meteor uses either Change streams or triggers internally and if this could lead to such long queries?
Did anybody experience this or similar issues?
How could I solve this?
Any pointers would be helpful as the app is offline until mongodb enables the database again.
to my knowledge, regex query isn’t fully supported by indexes, which means in many cases it will need to scan all your database records, it will take time.
I prefer using $text search over regex if possible.
However, it should not be problem for your app at all. If it is, I bet your database is shared with other, write-heavy services. If so, look up “oplog flood” on this forum.
Long story short, the only option would be to either stop using oplog or by using cultofcoders:redis-oplog (I’m not sure what Meteor versions are supported, though). And if you do the latter, I highly recommend using changestreamtoredis to ease the process.
The app does write to the database once in a while, but my I’m not sure it would flood oplog.
But anyways great hint, I will try with setting METEOR_OPLOG_TOO_FAR_BEHIND to a lower value.
MongoDB did not accept setting METEOR_OPLOG_TOO_FAR_BEHIND to a lower level on the shared database (as it would still use regex-queries). So I turned oplog-tailing off by not providing a MONGO_OPLOG_URL.