Spójność w znaczeniu, w jakim jest używana w ACID, oznacza, że wszystkie ograniczenia są spełnione przed i po każdej zmianie. Kiedy system zapewnia, że nie możesz odczytać danych, które są niespójne, mówi na przykład, że nigdy nie odczytasz danych, w których wiersz podrzędny odwołuje się do nieistniejącego wiersza nadrzędnego lub gdy zastosowano połowę transakcji, ale druga połowa nie została jeszcze zastosowana (w podręcznikowym przykładzie obciążanie jednego konta bankowego, ale jeszcze nie uznano konta bankowego odbiorcy).
Replikacja w MySQL jest domyślnie asynchroniczna lub w najlepszym wypadku „półsynchroniczna”. Z pewnością w obu przypadkach pozostaje w tyle. W rzeczywistości replika replikacji zawsze pozostaje w tyle o co najmniej ułamek sekundy, ponieważ master nie zapisuje zmian w swoim dzienniku binarnym, dopóki transakcja nie zostanie zatwierdzona, a następnie replika musi pobrać dziennik binarny i przekazać zdarzenie.
Ale zmiany są nadal atomowe. Nie możesz odczytać danych, które zostały częściowo zmienione. Albo czytasz zatwierdzone zmiany, w którym to przypadku wszystkie ograniczenia są spełnione, albo zmiany nie zostały jeszcze zatwierdzone, w którym to przypadku widzisz stan danych sprzed rozpoczęcia transakcji.
Możesz więc tymczasowo przeczytać stare dane w systemie replikacji są opóźnione, ale nie odczytasz niespójności dane.
Natomiast w systemie „ewentualnie spójnym” można odczytać dane, które są częściowo aktualizowane, gdy jeden rachunek został obciążony, a drugi rachunek nie został jeszcze uznany. Więc możesz zobacz niespójne dane.
Masz rację, że możesz być ostrożny przy odczytywaniu z replik, jeśli Twoja aplikacja wymaga absolutnie aktualnych danych. Każda aplikacja ma inną tolerancję na opóźnienie replikacji iw rzeczywistości w ramach jednej aplikacji różne zapytania mają inną tolerancję na opóźnienie. Zrobiłem prezentację na ten temat:Podział odczytu/zapisu dla MySQL i PHP (Webinarium Percona 2013)
