This has been fixed in the next major version v4.4: https://docs.mongodb.com/master/release-notes/4.4/#improved-routing-table-updates

Hi Mark.

> “If you drop a database and create a new database *with the same name*”

Yes, that is the revised text (both in the release notes page as of about 1.5 days ago, and then here in this article about half a day after that.) It was your comment 3 days earlier that led me to asking the questions in https://jira.mongodb.org/browse/DOCS-12474 that resulted in this documentation fix by the way.

(For readers who are wondering what the wrong documentation that came with GA release last week was: it was saying the workaround was needed at *any* dropDatabase (or movePrimary) which would have be a really big regression (yuck). But it is limited to the re-using-the-same-db-name case.)

You’re right on point #2 Mark that it possibly means downtime. (In fact I would say probably not just possibly, based on experience seeing most apps connecting to a single mongos host.) And it will be a pain for the DBAs who are affected.

For users who have applications that drop databases and recreate them as part of their operational process I suggest reading https://jira.mongodb.org/browse/SERVER-32198 in detail, and watch it for updates. Adding comments there explaining the impact for your client apps, if you have it.

The docs in pink state after movePrimary or “If you drop a database and create a new database with the same name” then you have two choices
1) restart all mongos and mongod
2) run flushRouterConfig command at all mongos and mongod

1 means downtime and downtime in the small (a second or two) can be just as bad in the aggregate as a rare big downtime.

2 might mean downtime. It definitely is a hassle and will be a serious pain to coordinate.

I hope they make this better.

Hi Mark (and other readers)

Although its not confirmed yet it looks my concern about dropDatabase might be mostly unwarranted. The description in the release notes seems to have been summarized a bit too much – please see https://jira.mongodb.org/browse/DOCS-12474.

Hi Mark. I wouldn’t think that it was feasible in most sites that a DBA could ask their app team to accept an application downtime; and MongoDB’s release note didn’t suggest it either. Instead I think the DBA would do the rolling restart of your shard replica sets, plus a restart of the mongos nodes, as soon as possible after the dropDatabase to merely limit the time window of risks caused by the stale cluster catalog cache.

The rolling replicaset restarts task is work and hassle for DBAs they certainly shouldn’t need to do for a dropDatabase command i.m.o, but it doesn’t cause any downtime.

The mongos node restarts task does cause short downtime to the client instances that are using it, unless they are connecting with a mongos node list (“mongodb://hostA:port,hostB:port,…/”) or DNS seedlist (“mongodb+srv://…/”) rather than a single mongos host:port address. In which case you merely restart only one of those mongos nodes at a time, similar to a replicaset rolling restart.

A note on mongos nodes topology:
Having apps that connect to only one mongos node has always meant there was a short outage when they are restarted, even for ordinary things like version upgrades. (The restart is usually only several seconds if no human interaction is needed in the middle). Changing to connect to a list of several mongos nodes is the way to avoid that, but there will be some work and at least one app restart to make it so. It may not really suit your application team to change the way they use mongos hosts (web app container images with a localhost mongos node are fairly common), so maybe some considerable inter-team hassle would occur there.

In general (not just to address this issue) it’s usually better, in my opinion, to move to a topology of having fixed-location mongos nodes managed by the DBAs rather than app localhost ones managed the app team(s). Or better yet to use DNS seedlist method, but that requires the DBAs get access to create and modify at any time SRV records in DNS, and that DNS is the authority in all networks that clients might possibly exist (think of all edge cases here like the network zone backups go to, including overseas ones, or the disaster recovery datacenter, etc.).