Pbm-agent fails on replica set SECONDARY: "get config server connection URI: mongo: no documents in result" (non-sharded RS)

MongoDB Percona Backup for MongoDB
1

PBM agent fails on non-sharded replica set secondaries during topology discovery

Environment

  • MongoDB Community 8.0.34 (production) / 8.0.26 (sandbox)

  • Non-sharded replica set rs0 with primary and secondary members

  • MongoDB running in Docker with host-port mapping

  • Authentication enabled using keyFile

  • PBM user: pbmBackup with readWrite, backup, restore, clusterMonitor, and pbmAnyAction privileges on admin

  • PBM versions tested: 2.9.1, 2.14.0, and 2.17.0 — all exhibit the same failure

Agent connection URI

mongodb://pbmBackup:***@localhost:27027/?authSource=admin&directConnection=true

Problem

The PBM agent connects successfully when pointed at the primary but exits immediately when connected directly to a secondary.

E Exit: connect to PBM: get config server connection URI: mongo: no documents in result

Investigation

MongoDB command logging on the secondary confirms successful authentication followed by these commands:

  1. isMaster

  2. getCmdLineOpts

  3. find admin.system.version {_id: "shardIdentity"} — returns zero documents, followed by agent exit.

The isMaster response contains normal replica-set fields (setName, secondary, primary, hosts, etc.), without $configServerState or configsvr.

The getCmdLineOpts.parsed response contains only net, replication, and security, with no sharding configuration.

Expected behavior

PBM should recognize the secondary as a member of a non-sharded replica set and initialize successfully.

Actual behavior

PBM attempts config-server URI discovery and exits when shardIdentity is absent.

Impact

PBM agents cannot initialize on secondary members, preventing the intended backup and point-in-time recovery configuration.

Questions for Percona

  1. Why does PBM attempt config-server URI discovery on a secondary of a non-sharded replica set?

  2. Could another configuration or connection property trigger this behavior?

  3. Is this a known issue, and are there additional diagnostics or supported workarounds?

2

The issue is caused by directConnection=true in the PBM URI.

pbm-agent’s main connection needs to reach the primary. With directConnection=true, the agent on a secondary stays on that secondary only. Since it’s not the primary, PBM tries to find the config server and looks for the shardIdentity doc in admin.system.version. That doc doesn’t exist on a non-sharded replica set, so you get no documents in result. On the primary it works fine because it’s already the primary.

Please remove directConnection=true from the URI on all the agents, and point each agent to its own mongod, like:

PBM_MONGODB_URI="mongodb://pbmBackup:****@<node>:<port>/?authSource=admin"

Since you are using Docker, make sure the rs.conf() hostnames are reachable from where pbm-agent runs, otherwise you’ll get server selection error: context deadline exceeded. The easiest fix is to run pbm-agent on the same Docker network as the mongod containers.

Let us know how it goes.

3

Thanks Deepak, removing directConnection=true fixed it. All agents are now OK on every member, and backups and PITR are working. Appreciate the help!