In this blog, I will present the new features introduced with the latest release (2.6.0) of the MongoDB DMK.
The DMK is a set of standardized tools that aims at easing the work of DBAs by having dbi’s best practices embedded in common scripts across all the database servers of an organization.
dbi services provides the DMK (Database Management Kit) to its customers for multiple technologies: Oracle, Postgres, MongoDB, etc. This toolkit is provided free of charge to all clients who work with dbi services on a consulting project.
New features of the MongoDB DMK in 2.6.0
pymongo integration
DMK now uses pymongo as its default MongoDB connection backend where available, instead of always shelling out to mongosh. Every internal operation that used to spawn a mongosh subprocess and parse its printed output (status checks, session listing, replica set state) now runs the equivalent pymongo call directly in the same process. That skips the cost of starting a shell interpreter and a Node.js runtime for every single query. It also gets typed BSON values (timestamps, ObjectId, Decimal128) back natively instead of round-tripping them through JSON text.
A new mongo_connection.py module wraps either a pymongo client or a mongosh subprocess behind the same interface. It is automatically chosen based on whether pymongo is importable. Both backends return the same JSON-serializable shape, so the rest of DMK does not need to know which one is in use. pymongo is entirely optional: install it with pip3 install pymongo and DMK picks it up automatically the next time an alias or script runs. No restart and no configuration change are needed. Without it, DMK transparently falls back to the mongosh backend it has always used.
Set DMK_USE_PYMONGO=0 (or false/no) to force the mongosh backend even when pymongo is installed. This is useful to work around a pymongo-specific issue without uninstalling it. The dmkpymongo alias reports which backend is currently in use:
$ dmkpymongo
DMK is using the mongosh backend (pymongo is not installed).
Once pymongo is installed, the same alias instead reports DMK is using the pymongo backend (pymongo <version> installed).
Startup report in dmk_db_ctl.py
dmk_db_ctl.py gained a --startup-report option. After a start or restart, it scans the instance log for warnings/errors since the last startup and retrieves the server’s own startupWarnings buffer via getLog, then prints a combined report. If the start itself fails, the log is still scanned so the cause is visible.
dmk_db_ctl.py -i mdb01 -a start --startup-report
dmk_db_ctl.py -i mdb01 -a restart --startup-report --check-status
A successful restart reports both sources side by side, the log scan and the server’s own getLog buffer:
2026-09-02 15:22:05 | INFO | Restarting MongoDB instance mdb01 ...
2026-09-02 15:22:07 | INFO | MongoDB instance 'mdb01' is now 'STARTED'.
2026-09-02 15:22:08 | INFO | ------------------------------ Startup Report ------------------------------
2026-09-02 15:22:08 | INFO | Log scan since last startup: 10 warning(s), 0 error(s)/fatal(s). Server startupWarnings buffer: 6 entrie(s).
2026-09-02 15:22:08 | INFO | [W] 2026-09-02T15:22:05.865+00:00 (initandlisten) Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
2026-09-02 15:22:08 | INFO | [W] 2026-09-02T15:22:05.865+00:00 (initandlisten) We suggest setting swappiness to 0 or 1, as swapping can cause performance problems.
2026-09-02 15:22:08 | INFO | [W] 2026-09-02T15:22:06.006+00:00 (ftdc) Use of deprecated server parameter 'sslMode', please use 'tlsMode' instead.
2026-09-02 15:22:08 | INFO | [I] 2026-09-02T15:22:05.517+00:00 (initandlisten) Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem (getLog)
2026-09-02 15:22:08 | INFO | ------------------------------------------------------------------------------
A failed start scans only the log, since the server was never reachable and there is no getLog buffer to add, then still re-raises so the command’s own exit code stays non-zero:
2026-09-02 15:21:45 | INFO | Restarting MongoDB instance mdb01 ...
2026-09-02 15:21:47 | ERROR | Instance failed to start. Scanning log for the cause ...
2026-09-02 15:21:47 | INFO | ------------------------------ Startup Report ------------------------------
2026-09-02 15:21:47 | INFO | Log scan since last startup: 10 warning(s), 0 error(s)/fatal(s). Server startupWarnings buffer: 0 entrie(s).
2026-09-02 15:21:47 | INFO | ------------------------------------------------------------------------------
Without --check-status, dmk_db_ctl.py does not wait to confirm the server actually came up, so a start that silently fails to bind (a bad port in the configuration file, for example) still reports the previous startup’s log content as if it were current, with exit code 0. Pass --check-status alongside --startup-report whenever the report’s purpose is to catch a failed start, not just to review a successful one.
Default ~/.mongoshrc.js
DMK now bootstraps a ~/.mongoshrc.js on first run (never overwriting an existing one), setting a prompt that shows host:port, database name, and replica set/mongos role, plus a set of read-only show*() helper functions for users, database/collection/index sizes, locks, active sessions, replica set status, and sharding status.
On a standalone instance, the prompt reports standalone:
[standalone] 127.0.0.1:27017/admin>
On a replica set, it reports the replica set name and the member’s current role instead:
[dbirs:PRIMARY] 127.0.0.1:28001/admin>
Run showAliases() at any time to list every available show*() helper:
showUsers() - users across all databases
showAllDBSizes() - size of all databases, in MB
showAllCollections() - all collections across all databases, including system ones
showCollections() - all collections across all databases, excluding system ones
showIndexSizes() - index sizes for collections in the current database
showUserRoles() - user roles across all databases
showLocks() - current lock statistics
showWaits() - current lock queue / active clients
showActiveSessions() - currently active sessions/operations
showMongoDBVersion() - MongoDB server version
showMongoshVersion() - mongosh version
showReplicaSetInfo() - replica set status (rs.status())
showReplicaSetConfig() - replica set configuration (rs.conf())
showShardStatus() - list of shards in a sharded cluster
showChunkDistribution() - chunk count per shard, per sharded collection
showBalancerStatus() - whether the sharding balancer is enabled
New oplog alias
A new oplog alias (msp ${DMK_HOME}/js/oplog_info.js) shows a replica set member’s oplog configured/used size and the time window (first entry to last entry) it currently covers, formatted as days/hours/minutes/seconds:
$ oplog
Oplog size:
-------------
Configured size: 990.00 MB
Used: 978.19 MB (98.81%)
Oplog window:
---------------
First entry: Fri Aug 28 2026 15:44:01 GMT+0000 (Coordinated Universal Time)
Last entry: Wed Sep 02 2026 15:23:13 GMT+0000 (Coordinated Universal Time)
Covers: 4d 23h 39m 12s (430752s)
sess alias improvements
The session view (sess / dmk_status.py --sessions) now hides internal/background operations (replication threads, Checkpointer, TTLMonitor, and similar) by default, since they have no client connection behind them and are noise for “who’s connected” questions. Pass --include-internal (or --show-all) to bring them back. Session rows also now show planSummary.
Configuration file parsing fixes
Quote parsing in the DMK configuration file received further fixes. The YAML parser gained list support, and a bug where it could silently re-parent sibling keys into the wrong nested block was fixed. update_mongo_conf.py now edits a configuration file’s lines directly instead of rewriting the whole file, so comments, lists, and header formatting are no longer destroyed. A password containing an unquoted # in cred.yaml is no longer silently truncated as an inline comment.
systemd sudo grant check
dmk_db_ctl.py now checks that the current user actually has the sudo grants to run systemctl start|stop on the instance’s service before attempting it, failing fast with a clear message instead of surfacing sudo’s own cryptic stderr.
dmk_dbcreate.py improvements
Directory/config path variables (admin_path, log_path, data_path) are now read from the installer template rather than re-derived from environment variables that could differ from it, which could set up an instance’s directories in the wrong place. dmk_dbcreate.py also now checks the configured port for conflicts before creating an instance: it verifies the port is a valid integer, is not already assigned to another instance in mongodb.lst, and is not already accepted by a listening process, failing fast with a clear error instead of creating an instance that silently squats on a port already in use.
New DMK_DEBUG=3 trace tier
Level 2 debug output previously mixed operational debug (instance, connection, status) with high-volume configuration-file parsing/computation output, making it hard to isolate the signal that actually matters when troubleshooting. That parsing/computation noise now only appears at a new DMK_DEBUG=3 (TRACE) tier; levels 0-2 keep their existing meaning unchanged.
Bug fixes
A few notable bugs were fixed in this release:
- Session runtime was truncated to the low 32 bits on the
mongoshbackend, so operations running over roughly 71 minutes showed a wrong, wrapped time. Fixed. - Status table sorting on numeric columns was lexicographic, so port
9000sorted after port27017. Fixed. - A process-existence check could raise an error if an instance stopped between reading its process list and reading its PID file. Fixed.
Upgrading from an earlier version of DMK
If you are upgrading from DMK 2.5.0, replace the DMK folder with the new one:
cd /u01/app/mongodb/local
mv dmk .dmk_old
unzip /path/to/dmk_mongodb-2.6.0.zip
dmk
If you are upgrading from DMK 2.4.0 or earlier, read the release notes of DMK 2.5.0 first.