diff options
author | Jack Mulrow <jack.mulrow@mongodb.com> | 2018-01-17 14:24:27 -0500 |
---|---|---|
committer | Jack Mulrow <jack.mulrow@mongodb.com> | 2018-01-19 17:50:24 -0500 |
commit | 9ed0b147b5cb71b8fbc7d28f43d66aa623b08ac1 (patch) | |
tree | 6ce5ab60d6dc869eb7e6d31c4f230285a822c212 | |
parent | 194ec4857fa0db8085da88e22eaae96687902d66 (diff) | |
download | mongo-9ed0b147b5cb71b8fbc7d28f43d66aa623b08ac1.tar.gz |
SERVER-32463 Remove / modify FCV dependent sharding UUID tests
4 files changed, 13 insertions, 135 deletions
diff --git a/buildscripts/resmokeconfig/suites/sharding_last_stable_mongos_and_mixed_shards.yml b/buildscripts/resmokeconfig/suites/sharding_last_stable_mongos_and_mixed_shards.yml index 8fd0c4098ad..1708ffabfaf 100644 --- a/buildscripts/resmokeconfig/suites/sharding_last_stable_mongos_and_mixed_shards.yml +++ b/buildscripts/resmokeconfig/suites/sharding_last_stable_mongos_and_mixed_shards.yml @@ -85,7 +85,6 @@ selector: - jstests/sharding/time_zone_info_mongos.js - jstests/sharding/uuid_propagated_to_config_server_on_shardCollection.js - jstests/sharding/uuid_propagated_to_recipient_shard_on_recvChunkStart.js - - jstests/sharding/uuid_propagated_to_shards_on_setFCV_3_6.js - jstests/sharding/write_transactions_during_migration.js - jstests/sharding/json_schema.js - jstests/sharding/current_op_no_shards.js diff --git a/jstests/sharding/uuid_propagated_to_config_server_on_shardCollection.js b/jstests/sharding/uuid_propagated_to_config_server_on_shardCollection.js index d8dffb2f455..fb610a68925 100644 --- a/jstests/sharding/uuid_propagated_to_config_server_on_shardCollection.js +++ b/jstests/sharding/uuid_propagated_to_config_server_on_shardCollection.js @@ -1,13 +1,11 @@ /** - * 1) Tests that in fcv=3.4, the shardCollection command does not persist a UUID in - * config.collections. - * - * 2) Tests that in fcv=3.6, the shardCollection command obtains the collection's UUID from the - * primary shard and persists it in config.collections. + * Tests that the shardCollection command obtains the collection's UUID from the primary shard and + * persists it in config.collections. */ (function() { + "use strict"; - load('jstests/libs/uuid_util.js'); + load("jstests/libs/uuid_util.js"); let db = "test"; @@ -16,29 +14,8 @@ assert.commandWorked(st.s.adminCommand({enableSharding: db})); st.ensurePrimaryShard(db, st.shard0.shardName); - // Check that in fcv=3.4, shardCollection does not persist a UUID. - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.4"})); + // Check that shardCollection propagates and persists UUIDs. for (let i = 0; i < 3; i++) { - let coll = "foo" + i; - let nss = db + "." + coll; - - // It shouldn't matter whether the collection existed on the shard already or not; test - // both cases. - if (i === 0) { - assert.writeOK(st.s.getDB(db).getCollection(coll).insert({x: 1})); - } - - assert.commandWorked(st.s.adminCommand({shardCollection: nss, key: {_id: 1}})); - - // Check that the entry in config.collections does not have a uuid field. - assert.eq(undefined, getUUIDFromConfigCollections(st.s, nss)); - } - - // Check that in fcv=3.6, shardCollection propagates and persists UUIDs. - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.6"})); - for (let i = 0; i < 3; i++) { - // Use different collection names because the ones starting with 'foo' are already sharded - // and will have a UUID generated for them on setFCV=3.6. let coll = "bar" + i; let nss = db + "." + coll; @@ -60,4 +37,5 @@ assert.eq(listCollsUUID, collEntryUUID); } + st.stop(); })(); diff --git a/jstests/sharding/uuid_propagated_to_recipient_shard_on_recvChunkStart.js b/jstests/sharding/uuid_propagated_to_recipient_shard_on_recvChunkStart.js index 72bb2633a72..94ac86dbb97 100644 --- a/jstests/sharding/uuid_propagated_to_recipient_shard_on_recvChunkStart.js +++ b/jstests/sharding/uuid_propagated_to_recipient_shard_on_recvChunkStart.js @@ -1,16 +1,11 @@ /** - * 1. Tests that if the donor and recipient shards are in fcv=3.4, the recipient shard accepts the - * chunk even though the donor does not return a UUID as part of listCollections. - * - * 2. Tests that a recipient shard in fcv=3.6 expects listCollections against the donor shard - * primary to return a UUID, and fails if it does not (i.e., the donor shard primary has fcv < 3.6). - * - * 3. Tests that if the donor and recipient shards are in fcv=3.6, the recipient shard uses the UUID - * obtained from the donor shard when creating the collection on itself. + * Tests that the recipient shard uses the UUID obtained from the donor shard when creating the + * collection on itself as part of a migration. */ (function() { + "use strict"; - load('jstests/libs/uuid_util.js'); + load("jstests/libs/uuid_util.js"); let db = "test"; let coll = "foo"; @@ -27,37 +22,9 @@ assert.commandWorked(st.s.adminCommand({shardCollection: nss, key: {_id: 1}})); }; - // 1. Check that if both the donor and recipient are in fcv=3.4, the recipient accepts the - // chunk even though the donor does not return a UUID. + // Check that the recipient accepts the chunk and uses the UUID from the recipient when creating + // the collection. - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.4"})); - setUp(); - assert.commandWorked( - st.s.adminCommand({moveChunk: nss, find: {_id: 0}, to: recipient.shardName})); - - assert.commandWorked(st.s.getDB(db).runCommand({dropDatabase: 1})); - - // 2. Check that if the donor is in fcv=3.4, but the recipient is in fcv=3.6, the recipient - // fails to accept the chunk. - - assert.commandWorked(recipient.adminCommand({setFeatureCompatibilityVersion: "3.6"})); - setUp(); - assert.commandFailed( - st.s.adminCommand({moveChunk: nss, find: {_id: 0}, to: recipient.shardName})); - - // Sanity check that the recipient shard did not create the collection on itself. - let listCollsRes = recipient.getDB(db).runCommand({listCollections: 1, filter: {name: coll}}); - assert.commandWorked(listCollsRes); - assert.neq(undefined, listCollsRes.cursor); - assert.neq(undefined, listCollsRes.cursor.firstBatch); - assert.eq(0, listCollsRes.cursor.firstBatch.length); - - assert.commandWorked(st.s.getDB(db).runCommand({dropDatabase: 1})); - - // 3. Check that if both the donor and recipient are in fcv=3.6, the recipient accepts the chunk - // and uses the UUID from the recipient when creating the collection. - - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.6"})); setUp(); assert.commandWorked( st.s.adminCommand({moveChunk: nss, find: {_id: 0}, to: recipient.shardName})); @@ -75,4 +42,5 @@ assert.neq(undefined, collEntryUUID); assert.eq(donorUUID, collEntryUUID); + st.stop(); })(); diff --git a/jstests/sharding/uuid_propagated_to_shards_on_setFCV_3_6.js b/jstests/sharding/uuid_propagated_to_shards_on_setFCV_3_6.js deleted file mode 100644 index f5663359faa..00000000000 --- a/jstests/sharding/uuid_propagated_to_shards_on_setFCV_3_6.js +++ /dev/null @@ -1,67 +0,0 @@ -/** - * Tests that after setFeatureCompatibilityVersion=3.6, for all sharded collections, the UUID - * reported by the shard in listCollections matches the UUID in config.collections. - * - * This should be true even if setFCV upgrade/downgrade is called repeatedly on the cluster, and - * even if drops, recreates, and shardCollections are called in between the upgrades/downgrades. - */ - -// Checking UUID consistency involves talking to a shard node, which in this test is shutdown -TestData.skipCheckingUUIDsConsistentAcrossCluster = true; - -(function() { - let st = new ShardingTest({shards: {rs0: {nodes: 1}}, other: {config: 3}}); - - // Start in fcv=3.4. - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.4"})); - - // We will manipulate collections across two databases. - let db1 = "test1"; - let db2 = "test2"; - assert.commandWorked(st.s.adminCommand({enableSharding: db1})); - st.ensurePrimaryShard(db1, st.shard0.shardName); - assert.commandWorked(st.s.adminCommand({enableSharding: db2})); - st.ensurePrimaryShard(db2, st.shard0.shardName); - - jsTest.log("shard some collections in each database"); - for (let i = 0; i < 3; i++) { - let coll = "foo" + i; - let nss1 = db1 + "." + coll; - let nss2 = db2 + "." + coll; - assert.commandWorked(st.s.adminCommand({shardCollection: nss1, key: {_id: 1}})); - assert.commandWorked(st.s.adminCommand({shardCollection: nss2, key: {_id: 1}})); - } - - jsTest.log("upgrade the cluster to fcv=3.6"); - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.6"})); - - st.checkUUIDsConsistentAcrossCluster(); - - // Drop some collections, shard some new collections, and drop and recreate some of the - // collections as sharded with the same name. - assert.commandWorked(st.s.getDB(db1).runCommand({drop: "foo0"})); - assert.commandWorked(st.s.adminCommand({shardCollection: db1 + ".bar0", key: {_id: 1}})); - assert.commandWorked(st.s.getDB(db1).runCommand({drop: "foo1"})); - assert.commandWorked(st.s.adminCommand({shardCollection: db1 + ".foo1", key: {_id: 1}})); - - st.checkUUIDsConsistentAcrossCluster(); - - jsTest.log("downgrade the cluster to fcv=3.4"); - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.4"})); - - // Drop, recreate, and shard some collections again, now while downgraded. - assert.commandWorked(st.s.getDB(db2).runCommand({drop: "foo0"})); - assert.commandWorked(st.s.adminCommand({shardCollection: db2 + ".bar0", key: {_id: 1}})); - assert.commandWorked(st.s.getDB(db2).runCommand({drop: "foo1"})); - assert.commandWorked(st.s.adminCommand({shardCollection: db2 + ".foo1", key: {_id: 1}})); - - // We do not check UUID consistency after downgrading back to fcv=3.4, because the UUIDs are - // deleted from shards on downgrade, but not from the config server's metadata. - - jsTest.log("re-upgrade the cluster to fcv=3.6"); - assert.commandWorked(st.s.adminCommand({setFeatureCompatibilityVersion: "3.6"})); - - st.checkUUIDsConsistentAcrossCluster(); - - st.stop(); -})(); |