Konzistence ve smyslu, jak se používá v ACID, znamená, že všechna omezení jsou splněna před a po jakékoli změně. Když systém ujišťuje, že nemůžete číst data, která jsou nekonzistentní, říká například, že nikdy nebudete číst data tam, kde podřízený řádek odkazuje na neexistující nadřazený řádek nebo kde byla použita polovina transakce, ale druhá polovina ještě nebyla uplatněna (v učebnicovém příkladu je odepsána částka z jednoho bankovního účtu, ale dosud nebyla připsána na bankovní účet příjemce).
Replikace v MySQL je ve výchozím nastavení asynchronní, v nejlepším případě „semisynchronní“. Určitě to v obou případech zaostává. Ve skutečnosti replika replikace vždy zaostává alespoň o zlomek sekundy, protože hlavní server nezapisuje změny do svého binárního protokolu, dokud není transakce potvrzena, pak si replika musí stáhnout binární protokol a předat událost.
Ale změny jsou stále atomické. Částečně změněná data nelze číst. Buď si přečtete potvrzené změny, v takovém případě jsou splněna všechna omezení, nebo změny ještě nebyly potvrzeny, v takovém případě uvidíte stav dat před zahájením transakce.
Takže můžete dočasně číst staré data v replikačním systému, který zaostává, ale nebudete číst nekonzistentní data.
Zatímco v „případně konzistentním“ systému můžete číst data, která jsou částečně aktualizovaná, kde jeden účet byl zatížen, ale druhý účet ještě nebyl připsán. Takže můžete viz nekonzistentní údaje.
Máte pravdu, že možná budete muset dávat pozor na čtení z replik, pokud vaše aplikace vyžaduje absolutně aktuální data. Každá aplikace má jinou toleranci pro zpoždění replikace a ve skutečnosti v rámci jedné aplikace mají různé dotazy různou toleranci pro zpoždění. Udělal jsem o tom prezentaci:Rozdělení čtení/zápisu pro MySQL a PHP (Webinář Percona 2013)