Konsistens i den forstand, det bruges i ACID, betyder, at alle begrænsninger er opfyldt før og efter enhver ændring. Når et system sikrer, at du ikke kan læse data, der er inkonsekvente, siger de for eksempel, at du aldrig vil læse data, hvor en underordnet række refererer til en ikke-eksisterende overordnet række, eller hvor halvdelen af en transaktion er blevet anvendt, men anden halvdel er endnu ikke blevet anvendt (eksemplet i lærebogen er debitering af én bankkonto, men endnu ikke krediteret modtagerens bankkonto).
Replikering i MySQL er asynkron som standard eller "semi-synkron" i bedste fald. Det halter bestemt i begge tilfælde. Faktisk halter replika-replikaen altid mindst en brøkdel af et sekund, fordi masteren ikke skriver ændringer til sin binære log, før transaktionen forpligtes, så skal replikaen downloade den binære log og videresende hændelsen.
Men ændringerne er stadig atomare. Du kan ikke læse data, der er delvist ændret. Du læser enten forpligtede ændringer, i hvilket tilfælde alle begrænsninger er opfyldt, eller også er ændringerne ikke blevet forpligtet endnu, i hvilket tilfælde du ser status for data fra før transaktionen begyndte.
Så du kan midlertidigt læse gammel data i et replikeringssystem, der halter, men du vil ikke læse inkonsekvent data.
Mens du i et "efterhånden konsistent" system kan læse data, der er delvist opdateret, hvor den ene konto er blevet debiteret, men den anden konto endnu ikke er blevet krediteret. Så du kan se inkonsistente data.
Du har ret i, at du muligvis skal være forsigtig med at læse fra replikaer, hvis din applikation kræver absolut aktuelle data. Hver applikation har en forskellig tolerance for replikeringsforsinkelse, og faktisk inden for en applikation har forskellige forespørgsler forskellig tolerance for forsinkelse. Jeg lavede en præsentation om dette:Læse-/skriveopdeling til MySQL og PHP (Percona webinar 2013)