erreur en essayant de StepDown mongodb réplicas

Question

Configuration:
1 primaire, 3 et 1 arbitre secondaries (tous les 5 sont en cours d'exécution.)

Quand je fais un abaisseur() dans le primaire, obtenir l'erreur ci-dessous dans le shell -

m101:PRIMARY> rs.stepDown() 
2017-06-07T15:01:21.357 E QUERY [thread1] Error: error doing query: failed: network error while attempting to run command 'replSetStepDown' on host '127.0.0.1:27018' : 
DB.prototype.runCommand@src/mongo/shell/db.js:132:1 
DB.prototype.adminCommand@src/mongo/shell/db.js:150:16 
rs.stepDown@src/mongo/shell/utils.js:1261:12 
@(shell):1:1 
2017-06-07T15:01:21.360 I NETWORK [thread1] trying reconnect to 127.0.0.1:27018 (127.0.0.1) failed 
2017-06-07T15:01:21.361 I NETWORK [thread1] reconnect 127.0.0.1:27018 (127.0.0.1) ok 
m101:SECONDARY> 

Notez que le primaire est devenu secondaire à la fin. Mais pourquoi je reçois cette erreur, "a échoué: erreur réseau" ici?

est inférieure à la section du fichier journal du primaire qui a été quitté -

2017-06-07T15:01:22.170 I REPL  [replication-5] Restarting oplog query due to error: InterruptedDueToReplStateChange: operation was interrupted. Last fetched optime (with hash): { ts: Timestamp 1496827872000|1, t: 2 }[-3490433912114125886]. Restarts remaining: 3 
2017-06-07T15:01:22.170 I REPL  [replication-5] Scheduled new oplog query Fetcher source: localhost:27018 database: local query: { find: "oplog.rs", filter: { ts: { $gte: Timestamp 1496827872000|1 } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 60000, term: 2 } query metadata: { $replData: 1, $oplogQueryData: 1, $ssm: { $secondaryOk: true } } active: 1 timeout: 65000ms shutting down?: 0 first: 1 firstCommandScheduler: RemoteCommandRetryScheduler request: RemoteCommand 159434 -- target:localhost:27018 db:local cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp 1496827872000|1 } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 60000, term: 2 } active: 1 callbackHandle.valid: 1 callbackHandle.cancelled: 0 attempt: 1 retryPolicy: RetryPolicyImpl maxAttempts: 1 maxTimeMillis: -1ms 
2017-06-07T15:01:22.173 W REPL  [rsBackgroundSync] Fetcher stopped querying remote oplog with error: InvalidSyncSource: Sync source's last applied OpTime { ts: Timestamp 1496827872000|1, t: 2 } is not greater than our last fetched OpTime { ts: Timestamp 1496827872000|1, t: 2 }. Choosing new sync source. 
2017-06-07T15:01:22.176 I REPL  [rsBackgroundSync] could not find member to sync from 
2017-06-07T15:01:22.180 I REPL  [ReplicationExecutor] Member localhost:27018 is now in state SECONDARY 
2017-06-07T15:01:27.335 I REPL  [SyncSourceFeedback] SyncSourceFeedback error sending update to localhost:27018: InvalidSyncSource: Sync source was cleared. Was localhost:27018 
2017-06-07T15:01:29.879 I -  [conn2] end connection 127.0.0.1:59400 (5 connections now open) 
2017-06-07T15:01:30.899 I NETWORK [thread1] connection accepted from 127.0.0.1:64421 #28 (5 connections now open) 
2017-06-07T15:01:30.899 I NETWORK [conn28] received client metadata from 127.0.0.1:64421 conn28: { driver: { name: "NetworkInterfaceASIO-Replication", version: "3.4.4" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } } 
2017-06-07T15:01:30.917 I NETWORK [thread1] connection accepted from 127.0.0.1:64425 #29 (6 connections now open) 
2017-06-07T15:01:30.920 I NETWORK [conn29] received client metadata from 127.0.0.1:64425 conn29: { driver: { name: "NetworkInterfaceASIO-Replication", version: "3.4.4" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } } 
2017-06-07T15:01:30.927 I NETWORK [thread1] connection accepted from 127.0.0.1:64428 #30 (7 connections now open) 
2017-06-07T15:01:30.928 I NETWORK [conn30] received client metadata from 127.0.0.1:64428 conn30: { driver: { name: "NetworkInterfaceASIO-Replication", version: "3.4.4" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } } 
2017-06-07T15:01:31.561 I REPL  [ReplicationExecutor] Starting an election, since we've seen no PRIMARY in the past 10000ms 
2017-06-07T15:01:31.562 I REPL  [ReplicationExecutor] conducting a dry run election to see if we could be elected 
2017-06-07T15:01:31.563 I REPL  [ReplicationExecutor] VoteRequester(term 2 dry run) received a no vote from localhost:27018 with reason "candidate's term is lower than mine"; response message: { term: 3, voteGranted: false, reason: "candidate's term is lower than mine", ok: 1.0 } 
2017-06-07T15:01:31.563 I REPL  [ReplicationExecutor] not running for primary, we have been superceded already 
2017-06-07T15:01:32.183 I REPL  [ReplicationExecutor] Member localhost:27019 is now in state PRIMARY 
2017-06-07T15:01:32.185 I REPL  [rsBackgroundSync] sync source candidate: localhost:27019 
2017-06-07T15:01:32.186 I ASIO  [NetworkInterfaceASIO-RS-0] Connecting to localhost:27019 
2017-06-07T15:01:33.198 I ASIO  [NetworkInterfaceASIO-RS-0] Successfully connected to localhost:27019, took 1012ms (1 connections now open to localhost:27019) 

Essayer de comprendre ce qui se passe ici. Toute piste serait appréciée.

Merci d'avance!

Answer 1

Ceci est un comportement attendu. Quand un primaire descend, il supprime toutes les connexions, y compris votre connexion active dans le shell mongo. Le shell mongo rétablit alors la connexion (selon le message "essayer de se reconnecter").

La documentation rs.stepDown() pourrait peut-être plus clair sur ce point avec un exemple de la sortie de la coquille, mais la description pertinente est:

Une fois abaisseur réussie, rs.stepDown() oblige tous les clients actuellement connectés au base de données à déconnecter. Cela permet de s'assurer que les clients conservent une vue précise de l'ensemble de réplicas. Étant donné que la déconnexion inclut la connexion utilisée pour exécuter la commande, vous ne pouvez pas récupérer l'état de retour de la commande si la commande aboutit; c'est-à-dire que vous ne pouvez récupérer l'état de retour de la commande qu'en cas d'erreur. Lorsque vous exécutez la commande dans un script, le script doit prendre en compte ce comportement.