Konsistens i den mening det används i ACID betyder att alla begränsningar är uppfyllda före och efter varje förändring. När ett system försäkrar att du inte kan läsa data som är inkonsekvent, säger de till exempel att du aldrig kommer att läsa data där en underordnad rad refererar till en obefintlig överordnad rad, eller där hälften av en transaktion har tillämpats men andra hälften har ännu inte tillämpats (exemplet i läroboken debiterar ett bankkonto men har ännu inte krediterat mottagarens bankkonto).
Replikering i MySQL är asynkron som standard, eller "halvsynkron" i bästa fall. Visst släpar det i båda fallen. Faktum är att replikeringsrepliken alltid släpar efter åtminstone en bråkdel av en sekund, eftersom mastern inte skriver ändringar i sin binära logg förrän transaktionen genomförs, då måste repliken ladda ner den binära loggen och vidarebefordra händelsen.
Men förändringarna är fortfarande atomära. Du kan inte läsa data som är delvis ändrade. Du läser antingen bekräftade ändringar, i vilket fall alla begränsningar är uppfyllda, eller så har ändringarna inte genomförts ännu, i vilket fall du ser tillståndet för data från innan transaktionen började.
Så du kan tillfälligt läsa gammal data i ett replikeringssystem som släpar, men du kommer inte att läsa inkonsekvent data.
Medan i ett "så småningom konsekvent" system kan du läsa data som är delvis uppdaterad, där det ena kontot har debiterats men det andra kontot ännu inte har krediterats. Så du kan se inkonsekventa uppgifter.
Du har rätt i att du kan behöva vara försiktig med att läsa från repliker om din applikation kräver absolut aktuella data. Varje applikation har olika tolerans för replikeringsfördröjning, och faktiskt inom en applikation har olika frågor olika tolerans för fördröjning. Jag gjorde en presentation om detta:Läs/skrivdelning för MySQL och PHP (Percona webbseminarium 2013)