'Hello' to This Blog and MongoDB

The implicit change is that the hello response could be expected to take some time, as "Awaitable hello or legacy hello Server Specification" states ...

'Hello' to This Blog and MongoDB

This being the first post of this blog, it seems right for the topic to be about hello.

Previously, MongoDB had a function called isMaster which got deprecated out of political correctness. Like in other computer systems, the master/slave metaphor had to go due to the outbreak of woke culture. Although it does make sense in some cases, this discussion is beyond the topic of this post (but we might come back to it), so let's focus on the replacement function, hello.

What's the Purpose?

As the documentation states:

MongoDB drivers and clients use hello to determine the state of the replica set members and to discover additional members of a replica set.

Are There any Changes?

Yes, there are:

  1. Now renamed to hello, the old command, isMaster is referred to as 'legacy hello' in some documentation.
  2. Moving to streaming protocol for monitoring MongoDB 4.4+ servers, to reduce the time it takes for a client to discover server state changes.

The implicit change is that the hello response could be expected to take some time, as "Awaitable hello or legacy hello Server Specification" states:

As of MongoDB 4.4 the hello or legacy hello command can wait to reply until there is a topology change or a maximum time has elapsed. Clients opt in to this "awaitable hello" feature by passing new parameters "topologyVersion" and "maxAwaitTimeMS" to the hello or legacy hello commands.

By looking at multiple internal MongoDB Core Server tickets, and this example from calling hello on a local mongosh, the usual await time is 10s:

{
      type: 'op',
      host: 'mtrusanj.local:27017',
      desc: 'conn3',
      connectionId: 3,
      client: '127.0.0.1:49482',
      appName: 'mongosh 1.4.1',
      clientMetadata: {
        driver: { name: 'nodejs|mongosh', version: '4.6.0' },
        os: {
          type: 'Darwin',
          name: 'darwin',
          architecture: 'x64',
          version: '21.4.0'
        },
        platform: 'Node.js v16.15.0, LE (unified)',
        version: '4.6.0|1.4.1',
        application: { name: 'mongosh 1.4.1' }
      },
      active: true,
      currentOpTime: '2022-05-14T13:45:48.453+02:00',
      threaded: true,
      opid: 5451,
      secs_running: Long("1"),
      microsecs_running: Long("1808246"),
      op: 'command',
      ns: 'admin.$cmd',
      command: {
        hello: true,
        maxAwaitTimeMS: 10000,
        topologyVersion: {
          processId: ObjectId("627f941da09af704219843b0"),
          counter: Long("0")
        },
        '$db': 'admin'
      },
      numYields: 0,
      waitingForLatch: {
        timestamp: ISODate("2022-05-14T11:45:46.751Z"),
        captureName: 'AnonymousLatch'
      },
      locks: {},
      waitingForLock: false,
      lockStats: {},
      waitingForFlowControl: false,
      flowControlStats: {}
    }

Why is this important?

If you have been monitoring any slow operations in currentOp(), after upgrading to MongoDB 4.4+, you may have seen hello commands being reported as 'slow', or taking more than 1s.

As discussed, this is now expected behaviour, and should be ignored in any monitoring applications.

Subscribe to Tales from the Tail of the Oplog

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe