2016-11-02 1 views
3

donc j'ai rencontré la question suivante récemment:perte de données due à une reprise inattendue de réplique MongoDB mis

J'ai un ensemble de réplicas 5 membres (priorité)

  • 1 x primaire (2)
  • 2 x secondaire (0,5)
  • 1 x sauvegarde cachée (0)
  • 1 x arbitre (0)

L'un des réplicas secondaires avec une priorité de 0,5 (appelons-le B) a rencontré un problème de réseau et avait une connectivité intermittente avec le reste de l'ensemble de réplicas. Cependant, malgré des données moins enthousiastes et une priorité inférieure à la primaire existante (appelons-le A) il a assumé le rôle principal:

[ReplicationExecutor] VoteRequester: A obtenu aucun vote de xxx parce que: les données du candidat est moins enthousiastes que le mien, respectivement: {terme: 29, voteGranted: false, la raison: "Les données du candidat est moins enthousiastes que le mien", ok: 1.0}

élection [ReplicationExecutor] a réussi, en supposant le rôle principal en terme 29

[ReplicationExecutor ] transition to PRIMARY

Et pour A, en dépit de ne pas avoir de problèmes de connexion avec le reste de l'ensemble réplique:

[ReplicationExecutor] en descendant de primaire, car un nouveau terme a commencé: 29

Donc Question 1 est, comment cela a-t-il pu être possible étant donné les circonstances?

Sur la route, A (maintenant un secondaire) ont commencé à faire reculer les données:

[rsBackgroundSync] À partir rollback en raison de OplogStartMissing: notre dernière fois op tiré par les cheveux: (terme: 28, horodatage: xxx) . GTE de source: (durée: 29, timestamp: xxx) hachages: (xxx/xxx)

[rsBackgroundSync] début rollback

[rsBackgroundSync] ROLLBACK 0

[ReplicationExecutor] transition rollback

Cela a provoqué la suppression des données qui ont été écrites. Donc La question 2 est: Comment un OplogStart disparaît-il?

Dernier point mais non des moindres, Question 3, comment cela peut-il être évité?

Merci d'avance!

Répondre

3

Vous utilisez la version 3.2.x et protocolVersion = 1 (vous pouvez le vérifier avec rs.conf() -command)? Parce qu'il y a un "bug" sur le vote. Vous pouvez éviter ce bug par (choisir l'un ou les deux):

  • changement protocolVersion à 0. cfg = rs.conf(); cfg.protocolVersion = 0; rs.reconfig (cfg);

  • changement toutes les priorités à même valeur

EDIT: Ce sont des billets qui expliquent .. plus ou moins .. Ticket 1 Ticket 2

+0

'' 3.2.4' et protocolVersion: 1 '! –

+0

Ce problème, n'est-ce pas? https://jira.mongodb.org/browse/SERVER-18453. Je vois ces réponses aux questions 2 et 3 ... mais qu'en est-il de la question 1? –