MongoDB

MongoDB ist die führende Open-Source, Document Datenbank die für einfache Entwicklung und Skalierung aber auch für Big Data Szenarien entwickelt wurde.

Hintergrundwissen Transaktionen: Sichere Secondary Reads

Marc-David Militz
Experte
  • Artikel von Dj Walker-Morgan

    • englischer Originalartikel
      https://www.mongodb.com/blog/post/transactions-background-part-5-safe-secondary-reads
      Übersetzung mit freundlicher Genehmigung von MongoDB

      • Zusammenfassung

        • Sichere Secondary Reads werden benötigt um eine Problematik zu lösen, die dann auftritt, wenn Chucks oder Dokumente zwischen Shards migriert werden.
          Damit wird sichergestellt, dass nicht nur die Primaries bei der Migration beteiligt sind, sondern auch die Secondaries.
          Die Migration ist abgeschlossen, wenn auch der Secondary davon Kenntnis hat, dass der Chunck oder Dokument umgezogen wurde.
          Auf diese Weise wurde das dynamisch und automatische Balancing von MongoDB sehr einfach zu nutzen.

          • Hintergrund

            • Vor der Einführung der "sicheren Secondary Reads" verfügten nur der Primary eines Shards über eine Routing Tabelle, in der der festgelegt war, welcher Shard über welche Chuncks verfügt.
              Wenn eine Abfrage bei dem Primary ankam, wurde diese Tabelle genutzt um herauszufinden, welche Dokumente gerade migriert wurden.
              Auf diese Weise wurde bei Abfragen über mehrere Shards verhindert Duplikate in den Ergebnissen zu bekommen.

              Wenn Daten-Chuncks gerade zwischen Shards migriert wurden - was typischerweise Teil des rebalancing Prozesses ist um Daten gleichmäßig über den Cluster zu verteilen - dann sah der Prozess folgendermaßen aus:
              Der Chunck wurde vom Quell- zum Ziel-Shard kopiert, die Routing Tabelle auf beiden aktualisiert um die neue Location des Daten zu haben und danach wurde der Chunck vom Quell-Shard gelöscht.

              Während dieses Vorgehen für Abfragen effektiv ist die auf den Primary geroutet wurden, waren sich die Secondaries dieser Migration nicht bewusst und lieferten für Abfragen die Ergebnisse, die sie hatten.
              Für einen bestimmten Zeitraum gibt es dabei eine Kopie der Daten auf den Secondaries beider Shards, weshalb ein Secondary Read beide Ergebnisse zurück liefern konnte.

              • Routing replizieren

                • Die Lösung des Problems, in ihrer einfachsten Form, war es die Routing Tabelle innerhalb eines Shards auch auf den Secondary zu replizieren.
                  Wenn sich die Routing Tabelle innerhalb einer Migration ändert, wird diese Änderung auch auf die Secondaries repliziert.
                  Auf diese Art sind sich auch die Secondaries der laufenden Migration bewusst und sind damit in der Lage Abfragen entsprechend zu routen.
                  Um diese Routing-Information auch zu nutzen sollten Read Operationen auf den Secondaries mit einem ReadConcern "local" oder "majority" versehen werden.

Neueste Mitgliederaktivitäten

Tags

Diesen Community Beitrag weiterempfehlen