diff options
author | Ryan Timmons <ryan.timmons@10gen.com> | 2020-01-28 17:13:42 -0500 |
---|---|---|
committer | Evergreen Agent <no-reply@evergreen.mongodb.com> | 2020-04-02 04:17:38 +0000 |
commit | 1fe9bc6787ca4f53410f86d01b960b256bf65561 (patch) | |
tree | 3ad104ffeb838934525097a50c3a143b321703a2 | |
parent | 54a62babcd39d7641064a516feb50171aac17ed9 (diff) | |
download | mongo-1fe9bc6787ca4f53410f86d01b960b256bf65561.tar.gz |
SERVER-32903 Ambiguous field name error should be ignored during initial sync
create mode 100644 jstests/replsets/initial_sync_ambiguous_index.js
(cherry picked from commit 3423ca586b88566857f3fcdfeca1c6fdee7a0911)
-rw-r--r-- | jstests/replsets/initial_sync_ambiguous_index.js | 71 | ||||
-rw-r--r-- | src/mongo/db/index/index_access_method.cpp | 2 |
2 files changed, 73 insertions, 0 deletions
diff --git a/jstests/replsets/initial_sync_ambiguous_index.js b/jstests/replsets/initial_sync_ambiguous_index.js new file mode 100644 index 00000000000..85c1b673536 --- /dev/null +++ b/jstests/replsets/initial_sync_ambiguous_index.js @@ -0,0 +1,71 @@ +/** + * Asserts that inserting a document like `{a:[{"0":1}]}` on the + * primary doesn't cause initial-sync to fail if there was index + * on `a.0` at the beginning of initial-sync but the `dropIndex` + * hasn't yet been applied on the secondary prior to cloning the + * insert oplog entry. + */ + +(function() { + "use strict"; + + load("jstests/libs/check_log.js"); + + const dbName = 'test'; + const collectionName = 'coll'; + + // How many documents to insert on the primary prior to + // starting initial-sync. + const initialDocs = 10; + // Batch-size used for cloning. + // Used as a fail-point parameter as detailed below. + const clonerBatchSize = 1; + + // Setting initialDocs larger than clonerBatchSize causes + // the fail-point to be hit because we fetch + // multiple batches in the InitialSyncer. + + // Start one-node repl-set. + const rst = new ReplSetTest({name: "apply_ops_ambiguous_index", nodes: 1}); + rst.startSet(); + rst.initiate(); + const primaryColl = rst.getPrimary().getDB(dbName).getCollection(collectionName); + + // Insert the initial document set. + for (let i = 0; i < initialDocs; ++i) { + primaryColl.insertOne({_id: i, a: i}); + } + + // Add a secondary. + const secondary = rst.add({ + setParameter: {"numInitialSyncAttempts": 1, 'collectionClonerBatchSize': clonerBatchSize} + }); + secondary.setSlaveOk(); + const secondaryColl = secondary.getDB(dbName).getCollection(collectionName); + + // We set the collectionClonerBatchSize low above, so we will definitely hit + // this fail-point and hang after the first batch is applied. While the + // secondary is hung we clone the problematic document. + secondary.adminCommand({ + configureFailPoint: "initialSyncHangBeforeCopyingDatabases", + mode: "alwaysOn", + data: {nss: secondaryColl.getFullName()} + }); + rst.reInitiate(); + checkLog.contains(secondary, "initialSyncHangBeforeCopyingDatabases fail point enabled"); + + // Insert and delete the problematic document and then create the problematic index. + // The collection-cloner will resume when the failpoint is turned off. + primaryColl.insertOne({_id: 200, a: [{"0": 1}]}); + primaryColl.deleteOne({_id: 200}); + primaryColl.ensureIndex({"a.0": 1}); + + // Resume initial sync. The "bad" document will be applied; the dropIndex will + // be applied later. + secondary.adminCommand( + {configureFailPoint: "initialSyncHangBeforeCopyingDatabases", mode: "off"}); + + // Wait for initial sync to finish. + rst.awaitSecondaryNodes(); + rst.stopSet(); +})(); diff --git a/src/mongo/db/index/index_access_method.cpp b/src/mongo/db/index/index_access_method.cpp index ed6e0a9d206..8a1cb9a9ff9 100644 --- a/src/mongo/db/index/index_access_method.cpp +++ b/src/mongo/db/index/index_access_method.cpp @@ -586,6 +586,8 @@ void IndexAccessMethod::getKeys(const BSONObj& obj, 17262, // Hash 16766, + // Ambiguous array field name + 16746, // Haystack 16775, 16776, |