Hat die mySQL-Replikation unmittelbare Datenkonsistenz?

Question

Ich denke über eine NoSQL-Lösung für ein aktuelles Projekt nach, aber ich bin bei vielen dieser Datenbanken zögerlich bezüglich der "Eventual Consistency" -Klausel. Ist die letztendliche Konsistenz anders als der Umgang mit einer mySQL-Datenbank, bei der die Replikation verzögert wird? Eine Lösung, die ich in der Vergangenheit mit verzögerter Replikation verwendet habe, ist das Lesen vom Master, wenn sofortige Datenkonsistenz benötigt wird.

Allerdings bin ich dann verwirrt, warum relationale Datenbank eine starke Datenkonsistenz haben. Ich denke, ich sollte Transaktionen verwenden und das wird mir eine starke Konsistenz geben. Ist es dann eine gute Übung, Anwendungen zu schreiben, die annehmen, dass die mySQL-Replikation verzögert ist?

Answer 1

Konsistenz in dem Sinne, in dem es in ACID verwendet wird bedeutet, dass alle Einschränkungen vor und nach jeder Änderung erfüllt sind. Wenn ein System sicherstellt, dass Sie keine inkonsistenten Daten lesen können, sagen Sie zum Beispiel, dass Sie niemals Daten lesen werden, bei denen eine untergeordnete Zeile auf eine nicht vorhandene übergeordnete Zeile verweist oder wenn die Hälfte einer Transaktion angewendet wurde die andere Hälfte wurde noch nicht angewendet (das Lehrbuchbeispiel belastet ein Bankkonto, aber hat das Empfängerbankkonto noch nicht gutgeschrieben).

Die Replikation in MySQL ist standardmäßig asynchron oder bestenfalls "halb-synchron". Sicherlich ist es in beiden Fällen verzögert. Tatsächlich liegt der Replikations-Slave immer mindestens einen Bruchteil einer Sekunde zurück, da der Master erst dann Änderungen an seinem Binärprotokoll schreibt, wenn die Transaktion festgeschrieben ist. Dann muss der Slave das Binärprotokoll herunterladen und das Ereignis weiterleiten.

Aber die Änderungen sind noch atomar. Sie können keine Daten lesen, die teilweise geändert wurden. Entweder lesen Sie festgeschriebene Änderungen, in diesem Fall sind alle Einschränkungen erfüllt, oder die Änderungen wurden noch nicht festgeschrieben. In diesem Fall sehen Sie den Status der Daten vor Beginn der Transaktion.

So könnten Sie vorübergehend alte Daten in einem Replikationssystem lesen, hinkt, aber Sie werden inkonsistent Daten nicht lesen.

Während in einem "eventuell konsistenten" System, könnten Sie Daten lesen, die teilweise aktualisiert werden, wobei das eine Konto belastet wurde, aber das zweite Konto noch nicht gutgeschrieben wurde. So können Sie inkonsistente Daten sehen.

Sie haben recht, dass Sie beim Lesen von Replikations-Slaves vorsichtig sein müssen, wenn Ihre Anwendung absolut aktuelle Daten benötigt. Jede Anwendung hat eine andere Toleranz für die Slave-Verzögerung, und tatsächlich haben unterschiedliche Abfragen innerhalb einer Anwendung unterschiedliche Toleranz für die Verzögerung. Ich habe eine Präsentation darüber gemacht: http://www.slideshare.net/billkarwin/read-write-split