Galaxy

MongoDB Oplog Setup

Enable oplog tailing for real-time reactivity in your Meteor apps and better monitoring with Monti APM. This guide walks you through creating an oplog user and configuring your connection.

Want faster, more efficient real-time updates in your Meteor app? Oplog tailing is the answer. Instead of polling your database for changes, your app listens directly to MongoDB's operations log. The result? Instant reactivity with less database load.

What is the Oplog?

The oplog (operations log) is a special capped collection in MongoDB that records every write operation. It's how replica sets stay in sync, but it's also incredibly useful for applications that need to react to data changes in real-time.

For Meteor apps, oplog tailing supercharges reactivity. Your observeChanges callbacks fire instantly when data changes, rather than relying on polling. This means snappier UIs and happier users.

Oplog tailing requires a MongoDB replica set. Standalone MongoDB instances don't have an oplog. Galaxy Database clusters and most production MongoDB services (like MongoDB Atlas) run as replica sets by default.

Why Set Up Oplog Tailing?

There are a few good reasons to enable oplog tailing:

  • Better Meteor reactivity: Your app sees database changes instantly. No more waiting for the next poll interval.
  • Reduced database load: Polling means constant queries asking "did anything change?" Oplog tailing eliminates that overhead.
  • Monti APM insights: With oplog configured, Monti APM can show you detailed metrics around observeChanges and oplog notifications. Without it, those graphs stay empty.
  • Third-party integrations: Many tools that sync with MongoDB rely on oplog tailing to detect changes in real-time.

Creating an Oplog User

Your oplog user needs read access to the local database (where the oplog lives). Here's how to set it up.

Connect to Your Database

Use MongoDB Shell, MongoDB Compass, or any MongoDB client to connect to your database with admin credentials.

mongosh "mongodb://admin:password@your-host:27017/admin"

Create the Oplog User

Switch to the admin database and create a user with read access to the local database:

use admin;

db.createUser({
  user: "oploguser",
  pwd: "YourSecurePassword",
  roles: [{ role: "read", db: "local" }]
});

The read role on the local database is all your oplog user needs. Keep it minimal for security.

Verify the User

Test that your new user can authenticate:

mongosh "mongodb://oploguser:YourSecurePassword@your-host:27017/local?authSource=admin"

If you can connect without errors, you're good to go.

Use a strong, unique password for your oplog user. This credential will be stored in your app's environment variables. Treat it like any other database credential.


Building the Oplog Connection String

The oplog connection string looks similar to your main MONGO_URL, but it points to the local database where the oplog resides.

Here's the format:

mongodb://oploguser:password@host1:27017,host2:27017,host3:27017/local?authSource=admin&replicaSet=yourReplicaSetName

Let's break that down:

PartDescription
oploguser:passwordThe credentials you just created
host1:27017,host2:27017,...Your replica set hosts (same as your main connection)
/localThe database containing the oplog (always local)
authSource=adminWhere your oplog user was created
replicaSet=yourReplicaSetNameYour replica set name

Find your replica set name and hosts in your MongoDB connection string. For Galaxy Database, check the Overview tab of your cluster details page.


Configuring Your Meteor App

Add the MONGO_OPLOG_URL environment variable to your Meteor settings. Place it in the galaxy.meteor.com.env section, right below your MONGO_URL:

{
  "galaxy.meteor.com": {
    "env": {
      "ROOT_URL": "https://your-app.meteorapp.com",
      "MONGO_URL": "mongodb+srv://user:password@cluster.mongodb.net/yourdb",
      "MONGO_OPLOG_URL": "mongodb://oploguser:password@cluster.mongodb.net/local?authSource=admin&replicaSet=rs0"
    }
  }
}

Notice the parameters at the end of MONGO_OPLOG_URL. Each one serves a specific purpose:

ParameterWhy It's Needed
/localThe oplog lives in MongoDB's local database, not your application database. This tells Meteor where to find the oplog collection.
authSource=adminYour oplog user was created in the admin database. This parameter tells MongoDB where to look up the credentials for authentication. Without it, MongoDB tries to authenticate against local and fails.
replicaSet=rs0Identifies which replica set to connect to. Required for oplog tailing since the oplog only exists on replica sets. Replace rs0 with your actual replica set name.

Save your settings and deploy. Meteor automatically detects MONGO_OPLOG_URL and enables oplog tailing.

Which Environment Variable?

Use MONGO_OPLOG_URL for modern Meteor versions. You might see references to METEOR_OPLOG_URL in older documentation, but that's legacy. Stick with MONGO_OPLOG_URL.


Verifying Oplog Tailing

How do you know it's working? A few ways:

  • Check your app logs: When Meteor starts with oplog tailing enabled, you'll see messages about connecting to the oplog.
  • Test reactivity: Open your app in two browser windows. Make a change in one. If oplog tailing is working, the other window updates almost instantly.
  • Monti APM: If you're on Galaxy's Professional plan, check the Monti APM dashboard. The observeChanges and Oplog graphs should now show data. If these were empty before, that's your confirmation.

Common Issues


Quick Reference

Here's everything in one place:

Create the user:

use admin;
db.createUser({
  user: "oploguser",
  pwd: "YourSecurePassword",
  roles: [{ role: "read", db: "local" }]
});

Connection string format:

mongodb://oploguser:password@hosts/local?authSource=admin&replicaSet=rsName

Meteor settings:

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL": "your-main-connection-string",
      "MONGO_OPLOG_URL": "your-oplog-connection-string"
    }
  }
}

That's it. Deploy, and your Meteor app will use oplog tailing for lightning-fast reactivity.


What's Next?