Triggers in MongoDB can be implemented through application-based or oplog/change stream-based approaches. Application-based triggers are self-implemented and offer more flexibility but require additional development. Oplog/change stream-based triggers allow monitoring database operations by tailing the oplog or using change streams. Considerations for oplog/change stream triggers include handling rollbacks, maintaining operation order, and filtering migration/orphan events in sharded clusters. An example use case is analyzing shard keys by monitoring operations on a collection to identify access patterns before defining the shard key.
3. Overview
• What is a Trigger
• Why is Useful
• Application Triggers
• Oplog Tailing
• 3.6+ Streams
• Use Cases
www.objectrocket.com
3
4. What is a trigger?
www.objectrocket.com
4
A trigger is a database object that is associated with a table.
It will be activated when a defined action is executed for the table.
Actions usually are:
- INSERT
- UPDATE
- DELETE
It can be invoked before or after the event.
12. Application Based Triggers
www.objectrocket.com
12
• Maintained internally
• Compatibility
• Flexibility
• Added Development Cycles
Self-Implemented
Open-Source Package
• Publically maintained
• Contributions and tested by a larger user base
• Potentially restricted to specific versions, client and server
17. Oplog Tailing
• The oplog
• Tailable cursors
• Replica Set
• Sharded cluster
• Advantages/Disadvantages/Co
nsiderations
www.objectrocket.com
17
18. The oplog
www.objectrocket.com
18
Capped collection (FIFO)
Fixed Size - oplogSizeMB (5% of free space is the default)
Located under local.oplog.rs
Holds every CRUD operation (Insert/Update/Delete/Commands)
MongoDB Replication
Idempotent by design
21. Anatomy of the local.oplog.rs
www.objectrocket.com
21
ts: timestamp of the oplog entry
t: election "term"
h: unique hash
v: version of the oplog
op: Type of operation (insert/update/delete/commands)
ns: Database & collection affected
o: The new state of the document after performing the change
o2: Contain the _id field of the affected document
ui: Collection’s UUID
wall: timestamp of the oplog entry
fromMigrate : Sparse field, is true when the operation comes from balancing
22. Tailable cursor
www.objectrocket.com
22
Equivalent to the tail Unix command with the -f option
Remains open after the client exhausts the results in the initial cursor
Ideal for capped collections (where indexes are not practical)
MongoDB replication uses tailable cursors to read the oplog
Initial scan is expensive – It scans the entire collection
Available on the vast majority of drivers
26. Using Sharded Cluster
www.objectrocket.com
26
s1 s2
Oplog is not visible thought the
mongos
A tailable cursor per shard
Adjust to topology changes
Must filter balancer events
Security issues
Trigger action must loop through
the mongos
28. Considerations
www.objectrocket.com
28
Apply before commit/commit errors (w:majority or w:n, n>1)
Preserve the order of operations – sharded clusters only
Filter out migration events (fromMigrate) – sharded clusters only
Filter out update events on Orphans – sharded clusters only
43. Mongo to Mongo connector
www.objectrocket.com
43
Reads the oplog on source
and replays on destination
source dest
Tailable cursor
Use Cases
• Selective replication
• Multisource replication
• Disaster recovery
• Heterogeneous
Replication
44. Use Case: Shard Key Analysis
www.objectrocket.com
44
Define a shard key is challenging:
• Can break your application
• Not an easy task to revert it (requires downtime)
Shard Key limitations (two out of many):
• Shard Key Value in a Document is Immutable.
• NULL values are not allowed
45. Use case: Shard Key Analysis
www.objectrocket.com
45
Query system.profile
• Requires extra room as default is 1MiB
• Adds overhead (extra writes)
• Snapshot of operations
Oplog or Streams
• Already present
• No extra overhead
• Covers bigger duration