Zum Hauptinhalt springen

Dateninkonsistenz direkt nach dem Schreiben mit Mongo DB Replication während der eigentlichen Dienstentwicklung lesen

Bei der Verwendung von MongoDB während der Entwicklung eines tatsächlichen Dienstes ist ein Problem aufgetreten. Das Problem bestand darin, dass die Daten nicht bestätigt wurden, wenn dieselben Daten unmittelbar nach dem Schreiben gelesen wurden. Damals wusste ich nicht viel über die Materie, also verbrachte ich viel Zeit und hatte es schwer. Ich habe über die Umstände und Ursachen dieses Problems geschrieben.

Problemsituation​

  • Damals nutzte das Unternehmen hauptsächlich MongoDB in vielen Diensten.
  • Beim Erstellen eines neuen Dienstes und bei der Vorbereitung für den weltweiten Start wurden Probleme festgestellt. Nach den Phasentests trat ungewöhnliches Verhalten auf, als der Dienst in Produktion ging
    • Vom Server angeforderte Abfragen schlagen zeitweise fehl (vom Client aufgerufene Serverabfragen schreiben intern Mongodb und lesen die Daten dann erneut)
    • Im Normalbetrieb müssen die geschriebenen Daten erneut gelesen und der nächste Vorgang ausgeführt werden. Im Fehlerfall tritt jedoch ein Fehler im Client auf.
    • Abfragen werden im folgenden Ablauf ausgeführt:
      • Kundenanruf
      • Fordern Sie den AWS-Dienst vom Server an und warten Sie auf das Ergebnis
      • Ergebnisse nach Abschluss des AWS-Dienstes in mongodb schreiben
      • Lesen Sie nach dem Schreiben die Daten erneut aus Mongodb und führen Sie die folgenden Aktionen aus
    • Bei der Betrachtung der AWS-Dienstabfrage auf dem Server zeigte sich, dass der AWS-Dienst normal funktionierte.
    • Als ich direkt zu mongodb ging, um den Schreibteil des Servers zu überprüfen, waren die Daten tatsächlich vorhanden. Mit anderen Worten: Es wurde bestätigt, dass beim Schreibvorgang kein Problem aufgetreten ist.
    • Der Leseteil der Serverabfrage ist fehlgeschlagen, es wurden jedoch Daten in die Datenbank geschrieben. Eine Situation, in der eine Korrektur schwierig war, da die genaue Ursache nicht bekannt war.
  • Bei der Überprüfung in der vorhandenen Testumgebung wurden keine Auffälligkeiten festgestellt
    • Die Testumgebung wird bereitgestellt. Bei dem Produkt trat ein Phänomen auf, das zum Zeitpunkt des Tests überhaupt nicht auftrat.

Auflösung​

  • Zunächst wurde kein Unterschied in der Umgebung erkannt, aber es wurde angenommen, dass es sich um einen Fehler im Code handelte, und die Logik wurde überprüft. Auch nach mehrmaliger Kontrolle konnte ich keine größeren Probleme feststellen.
  • Ich habe ständig nachgeschaut und konnte keine Lösung finden, also habe ich Kollegen gefragt, die mehr wussten, und gemeinsam nachgeschaut.
    • Es handelt sich um ein Problem, mit dem selbst meine Kollegen nicht vertraut sind, sodass die Lösung einige Zeit in Anspruch nimmt.
  • Damals lernte ich ein wenig über verteilte Datenbanken und konnte das Problem ableiten.
    • Vergleichen Sie die Unterschiede zwischen Bühne und Produktion, um Probleme zu identifizieren. Beim Vergleich der Unterschiede ergaben sich folgende Unterschiede:
    • In der Phase läuft MongoDB auf einem einzelnen Knoten ohne Replikation.
    • In der Produktion verfügt MongoDB über zwei sekundäre Knoten in der Replikation.
  • In der Produktionsumgebung wurde aus Gründen der Verfügbarkeit ein Replikatsatz konfiguriert.
    • Bei der Replikation schreibt die Produktions-MongoDB die Daten und verteilt sie dann auf den sekundären Knoten.
    • Da es keine separate Einstellung gab, wird der Lesevorgang ausgeführt, bevor die Daten an die sekundäre Datenbank weitergegeben werden, wenn Sie aus db schreiben und sofort lesen. sekundär übergibt vorhandene Daten als Antwortwert
      • Es wurde bestätigt, dass die Ausbreitungszeit etwa 2 bis 4 Sekunden beträgt.
    • Später, als ich die Daten im MongoDB-Kompass überprüfte, war die Ausbreitungszeit abgelaufen und die beim Lesen geschriebenen Daten waren korrekt sichtbar.
  • Die Methoden, die damals zur Lösung des oben genannten Problems entwickelt wurden, sind wie folgt.
    • Warten Sie, bis sich der DB-Status durch Abfrage vom Client ändert. Es schien die einfachste Methode zu sein.
    • Warten Sie, bis sich der DB-Status durch Abfrage vom Server ändert. Aus Sicht des Kunden können bestehende Abfragen unverändert weiterverwendet werden.
    • Sicherstellen, dass die Weitergabe an die Mongodb-Abfrage abgeschlossen und auf lesbar gesetzt ist, z. B. Abfragen oder Sammlungen
  • Ich habe die zweite der oben genannten Methoden ausprobiert. Anstatt dass der Lesevorgang unmittelbar nach dem Schreiben erfolgt, wird zwischen Schreiben und Lesen eine kleine Verzögerung hinzugefügt
    • Überprüfen Sie, ob es nach dem Hinzufügen einer Verzögerung normal funktioniert
  • Dadurch habe ich etwas mehr über die CAP-Theorie gelernt.
    • Im Fall einer verteilten Struktur weist sie drei Merkmale auf: Konsistenz, Verfügbarkeit und Partitionierungstoleranz.
    • Um das eine von Beständigkeit und Verfügbarkeit zu erfüllen, haben Sie keine andere Wahl, als das andere aufzugeben.
      • Wenn die Konsistenz erfüllt ist: Der Datenwert muss derselbe sein, unabhängig davon, auf welchen der verteilten Knoten zugegriffen wird. Wenn die Konsistenz unterbrochen ist, können beim Anfordern einer Abfrage unterschiedliche Daten übergeben werden.
      • Wenn die Verfügbarkeit erfüllt ist: Bietet die Möglichkeit, Anfragen normal zu verarbeiten, auch wenn die Synchronisierung eines oder mehrerer verteilter Knoten fehlschlägt.
    • Fall, bei dem die Konsistenz unterbrochen ist, weil die aktuelle Datenbankstruktur die Verfügbarkeit erfüllt.

organisieren​

  • Wenn die Replikation in der Datenbank eingerichtet ist, seien Sie vorsichtig, wenn die Schreib- und Lesezeiten unterschiedlich sind
  • Es war eine gute Erfahrung, die CAP-Theorie mit eigenen Augen zu sehen und zu spüren.
  • Lassen Sie uns, wann immer ich Zeit habe, etwas über den Dienst lernen, den ich entwickle. Man kann nicht alles wissen, aber je mehr man weiß, desto hilfreicher ist es bei der Fehlerbehebung.
  • Bitte beachten Sie, dass die Umgebung zwischen Bühne und Produktion unterschiedlich sein kann. Mit anderen Worten kann es zu Problemen kommen, wenn es einen Unterschied zwischen der Testumgebung und der tatsächlichen Betriebsumgebung gibt, und es wäre besser, darüber im Voraus nachzudenken.
    • Um die Debug-Zeit zu verkürzen, wäre es eine gute Idee, die Produktions- und Bühnenumgebung nahezu ähnlich oder identisch zu halten.
    • Zeit ist auch ein Kostenfaktor. Viele Dinge, wie z. B. Arbeitskosten und Verzögerungen bei der Serviceeröffnung, können sich verzögern oder zusätzliche Kosten verursachen. Ich dachte, es wäre in Ordnung, die gleichen Bühnen- und Produktionseinstellungen zu haben, solange die Kosten im Vergleich zu den Serverkosten nicht zu hoch wären.