{"id":46701,"date":"2026-09-04T07:34:49","date_gmt":"2026-09-04T05:34:49","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=46701"},"modified":"2026-09-04T07:34:53","modified_gmt":"2026-09-04T05:34:53","slug":"mongodb-dmk-2-6-0-pymongo-integration-and-new-features","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/mongodb-dmk-2-6-0-pymongo-integration-and-new-features\/","title":{"rendered":"MongoDB DMK 2.6.0 : pymongo integration and new features"},"content":{"rendered":"\n

In this blog, I will present the new features introduced with the latest release (2.6.0<\/code>) of the MongoDB DMK.<\/p>\n\n\n\n

The DMK is a set of standardized tools that aims at easing the work of DBAs by having dbi\u2019s best practices embedded in common scripts across all the database servers of an organization.<\/p>\n\n\n\n

dbi services provides the DMK<\/a> (Database Management Kit<\/em>) to its customers for multiple technologies: Oracle, Postgres, MongoDB, etc. This toolkit is provided free of charge<\/strong> to all clients who work with dbi services on a consulting project.<\/p>\n\n\n\n

New features of the MongoDB DMK in 2.6.0<\/code><\/h2>\n\n\n\n

pymongo<\/code> integration<\/h3>\n\n\n\n

DMK now uses pymongo<\/code> as its default MongoDB connection backend where available, instead of always shelling out to mongosh<\/code>. Every internal operation that used to spawn a mongosh<\/code> subprocess and parse its printed output (status checks, session listing, replica set state) now runs the equivalent pymongo<\/code> 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<\/code>, Decimal128<\/code>) back natively instead of round-tripping them through JSON text.<\/p>\n\n\n\n

A new mongo_connection.py<\/code> module wraps either a pymongo<\/code> client or a mongosh<\/code> subprocess behind the same interface. It is automatically chosen based on whether pymongo<\/code> 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<\/code> is entirely optional: install it with pip3 install pymongo<\/code> 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<\/code> backend it has always used.<\/p>\n\n\n\n

Set DMK_USE_PYMONGO=0<\/code> (or false<\/code>\/no<\/code>) to force the mongosh<\/code> backend even when pymongo<\/code> is installed. This is useful to work around a pymongo<\/code>-specific issue without uninstalling it. The dmkpymongo<\/code> alias reports which backend is currently in use:<\/p>\n\n\n\n

$ dmkpymongo\nDMK is using the mongosh backend (pymongo is not installed).<\/code><\/pre>\n\n\n\n
Once pymongo<\/code> is installed, the same alias instead reports DMK is using the pymongo backend (pymongo <version> installed).<\/code><\/p>\n\n\n\n
Startup report in dmk_db_ctl.py<\/code><\/h3>\n\n\n\n
dmk_db_ctl.py<\/code> gained a --startup-report<\/code> option. After a start<\/code> or restart<\/code>, it scans the instance log for warnings\/errors since the last startup and retrieves the server\u2019s own startupWarnings<\/code> buffer via getLog<\/code>, then prints a combined report. If the start itself fails, the log is still scanned so the cause is visible.<\/p>\n\n\n\n
dmk_db_ctl.py -i mdb01 -a start --startup-report\ndmk_db_ctl.py -i mdb01 -a restart --startup-report --check-status<\/code><\/pre>\n\n\n\n
A successful restart reports both sources side by side, the log scan and the server\u2019s own getLog<\/code> buffer:<\/p>\n\n\n\n
2026-09-02 15:22:05 | INFO | Restarting MongoDB instance mdb01 ...\n2026-09-02 15:22:07 | INFO | MongoDB instance 'mdb01' is now 'STARTED'.\n2026-09-02 15:22:08 | INFO | ------------------------------  Startup Report  ------------------------------\n2026-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).\n2026-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\n2026-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.\n2026-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.\n2026-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)\n2026-09-02 15:22:08 | INFO | ------------------------------------------------------------------------------<\/code><\/pre>\n\n\n\n
A failed start scans only the log, since the server was never reachable and there is no getLog<\/code> buffer to add, then still re-raises so the command\u2019s own exit code stays non-zero:<\/p>\n\n\n\n
2026-09-02 15:21:45 | INFO | Restarting MongoDB instance mdb01 ...\n2026-09-02 15:21:47 | ERROR | Instance failed to start. Scanning log for the cause ...\n2026-09-02 15:21:47 | INFO | ------------------------------  Startup Report  ------------------------------\n2026-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).\n2026-09-02 15:21:47 | INFO | ------------------------------------------------------------------------------<\/code><\/pre>\n\n\n\n
Without --check-status<\/code>, dmk_db_ctl.py<\/code> 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\u2019s log content as if it were current, with exit code 0. Pass --check-status<\/code> alongside --startup-report<\/code> whenever the report\u2019s purpose is to catch a failed start, not just to review a successful one.<\/p>\n\n\n\n
Default ~\/.mongoshrc.js<\/code><\/h3>\n\n\n\n
DMK now bootstraps a ~\/.mongoshrc.js<\/code> on first run (never overwriting an existing one), setting a prompt that shows host:port<\/code>, database name, and replica set\/mongos<\/code> role, plus a set of read-only\u00a0show*()<\/code>\u00a0helper functions for users, database\/collection\/index sizes, locks, active sessions, replica set status, and sharding status.<\/p>\n\n\n\n
On a standalone instance, the prompt reports standalone<\/code>:<\/p>\n\n\n\n
[standalone] 127.0.0.1:27017\/admin><\/code><\/pre>\n\n\n\n
On a replica set, it reports the replica set name and the member\u2019s current role instead:<\/p>\n\n\n\n
[dbirs:PRIMARY] 127.0.0.1:28001\/admin><\/code><\/pre>\n\n\n\n
Run showAliases()<\/code> at any time to list every available show*()<\/code> helper:<\/p>\n\n\n\n
showUsers()             - users across all databases\nshowAllDBSizes()        - size of all databases, in MB\nshowAllCollections()    - all collections across all databases, including system ones\nshowCollections()       - all collections across all databases, excluding system ones\nshowIndexSizes()        - index sizes for collections in the current database\nshowUserRoles()         - user roles across all databases\nshowLocks()             - current lock statistics\nshowWaits()             - current lock queue \/ active clients\nshowActiveSessions()    - currently active sessions\/operations\nshowMongoDBVersion()    - MongoDB server version\nshowMongoshVersion()    - mongosh version\nshowReplicaSetInfo()    - replica set status (rs.status())\nshowReplicaSetConfig()  - replica set configuration (rs.conf())\nshowShardStatus()       - list of shards in a sharded cluster\nshowChunkDistribution() - chunk count per shard, per sharded collection\nshowBalancerStatus()    - whether the sharding balancer is enabled<\/code><\/pre>\n\n\n\n
New oplog<\/code> alias<\/h3>\n\n\n\n
A new oplog<\/code> alias (msp ${DMK_HOME}\/js\/oplog_info.js<\/code>) shows a replica set member\u2019s oplog configured\/used size and the time window (first entry to last entry) it currently covers, formatted as days\/hours\/minutes\/seconds:<\/p>\n\n\n\n
$ oplog\nOplog size:\n-------------\n  Configured size: 990.00 MB\n  Used:            978.19 MB (98.81%)\n\nOplog window:\n---------------\n  First entry: Fri Aug 28 2026 15:44:01 GMT+0000 (Coordinated Universal Time)\n  Last entry:  Wed Sep 02 2026 15:23:13 GMT+0000 (Coordinated Universal Time)\n  Covers:      4d 23h 39m 12s (430752s)<\/code><\/pre>\n\n\n\n
sess<\/code> alias improvements<\/h3>\n\n\n\n
The session view (sess<\/code> \/ dmk_status.py --sessions<\/code>) now hides internal\/background operations (replication threads, Checkpointer<\/code>, TTLMonitor<\/code>, and similar) by default, since they have no client connection behind them and are noise for \u201cwho\u2019s connected\u201d questions. Pass --include-internal<\/code> (or --show-all<\/code>) to bring them back. Session rows also now show planSummary<\/code>.<\/p>\n\n\n\n
Configuration file parsing fixes<\/h3>\n\n\n\n
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<\/code> now edits a configuration file\u2019s lines directly instead of rewriting the whole file, so comments, lists, and header formatting are no longer destroyed. A password containing an unquoted #<\/code> in cred.yaml<\/code> is no longer silently truncated as an inline comment.<\/p>\n\n\n\n
systemd<\/code> sudo grant check<\/h3>\n\n\n\n
dmk_db_ctl.py<\/code> now checks that the current user actually has the sudo grants to run systemctl start|stop<\/code> on the instance\u2019s service before attempting it, failing fast with a clear message instead of surfacing sudo<\/code>\u2019s own cryptic stderr.<\/p>\n\n\n\n
dmk_dbcreate.py<\/code> improvements<\/h3>\n\n\n\n
Directory\/config path variables (admin_path<\/code>, log_path<\/code>, data_path<\/code>) 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\u2019s directories in the wrong place. dmk_dbcreate.py<\/code> 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<\/code>, 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.<\/p>\n\n\n\n
New DMK_DEBUG=3<\/code> trace tier<\/h3>\n\n\n\n
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<\/code> (TRACE<\/code>) tier; levels 0-2 keep their existing meaning unchanged.<\/p>\n\n\n\n
Bug fixes<\/h3>\n\n\n\n
A few notable bugs were fixed in this release:<\/p>\n\n\n\n