☰

MongoDB wechselt häufig die Primärdatenbank

tag-icon • tag-icon vmware-esxi redhat mongodb
MongoDB wechselt häufig die Primärdatenbank

Wir betreiben ein Mongo 2.6-Replikatset mit 3 Mitgliedern: primär, sekundär, Arbiter. Fast jeden Tag wechselt unsere MongoDB den primären Server, was dazu führt, dass alle Verbindungen zu dieser DB unterbrochen werden. Es wäre völlig in Ordnung, wenn dies passieren würde, weil einer der Server tatsächlich ausgefallen ist. Die Herausforderung besteht darin, dass es in jedem Fall so aussieht, als wäre der „ausgefallene“ Server nicht wirklich ausgefallen. Er war die ganze Zeit aktiv.

Folgendes wissen wir:

  1. Der mongodProzess wurde auf allen drei Servern weder neu gestartet noch unterbrochen.
  2. Die Server meldeten sich die ganze Zeit über weiterhin bei New Relic.
  3. Aus dem Mongo-Protokoll geht hervor, dass es häufig zu Heartbeat-Ausfällen kommt.
  4. Die Server sind zu keinem Zeitpunkt einer wirklich hohen Belastung ausgesetzt. Ich sehe jede Stunde etwa 10 Minuten nach der vollen Stunde einen CPU-Spitzenwert, aber das passt nicht genau zu den Ausfällen.

Das Folgende ist das Ergebnis der show log rsEingabe während der Shell in den aktuellen Primärserver.

2015-05-17T15:05:49.339+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-17T15:05:49.358+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T15:05:56.444+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-17T22:11:36.638+0000 [rsHealthPoll] replSet info server1:27017 is down (or slow to respond):
2015-05-17T22:11:36.644+0000 [rsHealthPoll] replSet member server1:27017 is now in state DOWN
2015-05-17T22:11:37.495+0000 [rsMgr] not electing self, we are not freshest
2015-05-17T22:11:38.656+0000 [rsHealthPoll] replSet member server1:27017 is up
2015-05-17T22:11:38.656+0000 [rsHealthPoll] replSet member server1:27017 is now in state PRIMARY
2015-05-17T22:11:39.140+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T22:11:39.147+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-17T23:05:47.431+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-17T23:05:47.431+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T23:05:47.876+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-18T10:05:46.821+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-18T10:05:46.822+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-18T10:05:51.014+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-18T22:12:11.433+0000 [rsHealthPoll] replSet info server1:27017 is down (or slow to respond):
2015-05-18T22:12:11.434+0000 [rsHealthPoll] replSet member server1:27017 is now in state DOWN
2015-05-18T22:12:11.507+0000 [rsMgr] replSet info electSelf 3
2015-05-18T22:12:14.708+0000 [rsMgr] replSet PRIMARY
2015-05-18T22:12:14.709+0000 [rsHealthPoll] replSet member server1:27017 is up
2015-05-18T22:12:14.709+0000 [rsHealthPoll] replSet member server1:27017 is now in state PRIMARY
2015-05-18T22:12:21.610+0000 [rsHealthPoll] replSet member server1:27017 is now in state ROLLBACK
2015-05-18T22:12:23.612+0000 [rsHealthPoll] replSet member server1:27017 is now in state SECONDARY
2015-05-19T22:13:13.004+0000 [rsHealthPoll] couldn't connect to server1:27017: couldn't connect to server server1:27017 (x.x.x.x), connection attempt failed
2015-05-19T22:13:24.127+0000 [rsHealthPoll] couldn't connect to server1:27017: couldn't connect to server server1:27017 (x.x.x.x) failed, connection attempt failed
2015-05-19T22:13:29.267+0000 [rsHealthPoll] replset info server1:27017 just heartbeated us, but our heartbeat failed: , not changing state
2015-05-20T22:14:35.832+0000 [rsHealthPoll] replset info server1:27017 just heartbeated us, but our heartbeat failed: , not changing state

Sie können sehen, dass wir häufig Heartbeat-Ausfälle und Down-Benachrichtigungen erhalten, aber in jedem Fall wechselte der Server jedes Mal innerhalb von Sekunden von Down zu Back-up. Ich bin mir nicht wirklich sicher, wo ich als nächstes mit der Suche beginnen soll, um herauszufinden, was das Problem verursachen könnte.

Antwort1

Ich sehe das häufig und es liegt immer außerhalb des mongodProzesses. DNS-Resolver-Probleme, TCP/IP-Stack-Probleme, Netzwerkverbindungen, physische Hardware usw. Arbeiten Sie sich aus dem mongodProzess heraus. Überprüfen Sie Netzwerkfehler auf Ihrem Host-Betriebssystem, überprüfen Sie physische Verbindungen (wenn physische in der Gleichung eine Rolle spielen), überprüfen Sie Ihren Cloud-Anbieter zwischen den beiden Servern, wenn Sie Regionen überspannen. Höchstwahrscheinlich liegt dies an den Host-Betriebssystemen und hat nichts mit MongoDB selbst zu tun.

Antwort2

Dies wurde behoben. Das Hauptproblem bestand darin, dass unser Hosting-Anbieter VMWare-Snapshots als Backup-Mechanismus ausführte. Diese Snapshots führten dazu, dass die VM vorübergehend in eine Stasis-Phase ging. Ich glaube, der Fachbegriff dafür lautet, dass die VM in den Ruhezustand versetzt wird.

Nachdem diese Snapshots deaktiviert wurden, hatten wir keine Probleme mehr.

verwandte Informationen