0

Today one of the users of our MongoDB 3.0.12 sharded cluster has (wrongly) issued a foreground index build on its own database (pride_archive_ms), after the operation completed on the primary member of each replica set (shard), it got replicated to the secondaries.

I was expecting the database where the index build still is in progress to be blocked for read and writes, but actually all the databases read/writes are blocked when using secondary or secondaryPreferred read preference. Any opened session simply gets appended. Is this the expected behaviour? The docs report that:

Any operation that requires a read or write lock on all databases (e.g. listDatabases) will wait for the foreground index build to complete.

But in our case are simple find() on distinct databases from the one the index is being built on.

Could anyone please shed some light?

Thanks

Gerald Schneider
  • 19,757
  • 8
  • 52
  • 79
user366221
  • 1
  • I can add a few more details: I can add a few more details. Basically on the secondaries where the index build is performed I can't connect to the admin database, the mongo shell simply remains hooked up without returning the prompt. If I connect to the any sharded database through the router, I can correctly perform the authentication, but any find() using secondaryPreferred as readPreference hangs. Basically the router seems not able to detect that the secondaries are unreadable for every database, why this happens is pretty unclear to me. – user366221 Jul 20 '16 at 14:01

1 Answers1

0

Thomas Schubert has provided an answer to this question in:

https://jira.mongodb.org/browse/SERVER-25168

Still, I wonder why the router is not detecting the read-locked secondaries and serve queries from the primary when the secondaryPreferred read preference is specified.

user366221
  • 1