Read-after-write-Konsistenz in einem Galera-Cluster

Commit heißt zertifiziert, nicht angewendet

Ein Galera-Cluster führt eine Transaktion auf einem Knoten aus. Beim Commit sendet dieser Knoten das Write Set an das Cluster, jeder Knoten zertifiziert es gegen die bereits laufenden Write Sets, und das Commit kehrt zum Client zurück. Von diesem Moment an ist der Write im Cluster dauerhaft und überall identisch geordnet.

Was noch nicht geschehen ist, ist das Apply. Jeder Knoten nimmt das zertifizierte Write Set und wendet es in seinen eigenen Applier-Threads auf seine eigene Kopie der Daten an, kurz nachdem das Commit zurückgekehrt ist. Zwei Uhren laufen: Die Zertifizierung ist clusterweit und Teil des Commits, das Anwenden ist lokal und kommt danach. In einem gesunden Cluster liegt der Abstand zwischen beiden bei Dutzenden bis einigen Hundert Millisekunden. Er wächst bei Write-Spitzen, großen Transaktionen und Schemaänderungen und ist als wsrep_local_recv_queue ungleich null auf dem Knoten sichtbar, der zurückliegt.

Wohin der Read geht

Ein Cluster mit verteilten Reads schickt Reads dorthin, wo der Proxy es entscheidet. Eine Anfrage schreibt auf Knoten A. Die nächste Anfrage desselben Benutzers, einige Hundert Millisekunden später, liest auf Knoten B. Hat Knoten B das Write Set empfangen, aber noch nicht angewendet, antwortet er mit der Zeile, wie sie vor dem Write war. Aus Sicht von Knoten B ist die Antwort korrekt: Das ist sein committeter Zustand. Nichts wird protokolliert, nichts alarmiert, und der Lag-Monitor bleibt still, weil er gebaut ist, anhaltenden Lag zu erkennen, nicht die ersten hundert Millisekunden nach einer Transaktion.

Deshalb wirkt das Symptom zufällig. Es hängt davon ab, welchen Knoten der Balancer gewählt hat, wie schnell der Benutzer zurückkam und wie beschäftigt die Applier in diesem Augenblick waren.

Wie es in einer Anwendung aussieht

Das Muster ist ein Write, dem sofort ein Read desselben Benutzers folgt, der auf einem anderen Knoten landet. In einem CMS ist es der verschwundene Absatz: speichern, neu laden, alter Text, neu tippen, speichern, und das zweite Speichern überschreibt das erste. In einem Onlineshop ist es eine Bestellung, die auf der Bestätigungsseite nicht existiert. In einem Authentifizierungsablauf ist es ein Token, das gerade ausgestellt wurde und nicht gefunden wird.

Zwei andere Mechanismen erzeugen eine ähnliche Geschichte und sollten zuerst ausgeschlossen werden. Der Back-Forward-Cache eines Browsers kann eine veraltete Kopie eines Formulars wiederherstellen, und ein erneutes Speichern schreibt dann diese veraltete Kopie. Ein Plugin kann aus zwei Anfragen ein Read-Modify-Write auf derselben Zeile ausführen. Beides ist real, und keines davon ist das Cluster. Eine Schleife, die einen Zeitstempel auf einen Knoten schreibt und ihn von den anderen zurückliest, trennt sie in einer Minute.

Die Einstellung: wsrep_sync_wait

wsrep_sync_wait ist eine Bitmaske. Mit gesetztem Bit 1 wartet ein SELECT, bis der Knoten jedes bis zu diesem Moment empfangene Write Set angewendet hat, bevor er läuft. Der Read sieht dann garantiert alles, was irgendwo im Cluster vor seinem Start committet wurde. Sie kann für eine Sitzung gesetzt werden, der richtige Umfang für einen Redaktions- oder Checkout-Pfad, oder global, wenn die gesamte Workload empfindlich auf Read-after-write reagiert.

-- for one session: the request path that writes and then reads
SET SESSION wsrep_sync_wait = 1;

-- for the whole node: my.cnf, under [mysqld]
wsrep_sync_wait = 1

Die Alternative ist Routing: Schicken Sie die Reads, die einem Write folgen, an den Knoten, der geschrieben hat, mit Query-Regeln im Proxy oder in der Anwendung. Das funktioniert für die Pfade, die es abdeckt. Ein Code-Pfad, den niemand geroutet hat, öffnet die Lücke wieder, und deshalb wird die Einstellung bevorzugt, wo der Preis bezahlt werden kann: Sie adressiert den Mechanismus, nicht einen Pfad durch ihn.

Was es kostet und wo Sie es bezahlen

Ein Read unter wsrep_sync_wait wartet darauf, dass der lokale Applier aufholt, zahlt also den Apply-Lag einmal pro Read, der einem Write folgt. In einem gesunden Cluster sind das Dutzende bis einige Hundert Millisekunden. Angemeldete Sitzungen, Admin- und Redaktionspfade und der Checkout sind die Stellen, an denen dieser Preis etwas kauft. Anonyme Seiten aus einem Edge-Cache berühren die Datenbank bei einem Treffer nicht und sind nicht betroffen. Die Einstellung wirkt ab der nächsten Anweisung und lässt sich auf demselben Weg zurücknehmen, sie kann also vor Ort mit der echten Workload gemessen statt geschätzt werden.

Wie Sie Ihr eigenes Cluster prüfen

Drei Messwerte entscheiden es. Ob Reads überhaupt warten. Wie weit ein Knoten bei einer Write-Spitze zurückfällt. Und wie oft ein knotenübergreifendes Read-after-write tatsächlich die Vergangenheit sieht, aus einer Schleife, die auf einen Knoten schreibt und auf den anderen liest.

SHOW GLOBAL VARIABLES LIKE 'wsrep_sync_wait';        -- 0 means reads do not wait
SHOW GLOBAL STATUS LIKE 'wsrep_local_recv_queue';    -- received, not yet applied

Wir betreiben Percona-XtraDB-Cluster mit verteilten Reads hinter ProxySQL und HAProxy und können diese drei Fragen für jedes Cluster beantworten, das wir betreiben, einschließlich dessen, was die Einstellung auf dieser konkreten Workload kostet.