La coerenza nel senso in cui viene utilizzata in ACID significa che tutti i vincoli sono soddisfatti prima e dopo qualsiasi modifica. Quando un sistema assicura che non puoi leggere dati incoerenti, sta dicendo ad esempio che non leggerai mai dati in cui una riga figlio fa riferimento a una riga padre inesistente o in cui è stata applicata metà di una transazione ma il l'altra metà non è stata ancora applicata (l'esempio da manuale prevede l'addebito su un conto bancario ma non l'accredito sul conto bancario del destinatario).
La replica in MySQL è asincrona per impostazione predefinita, o nella migliore delle ipotesi "semi-sincrona". Certamente è in ritardo in entrambi i casi. In effetti, la replica di replica è sempre in ritardo di almeno una frazione di secondo, perché il master non scrive le modifiche nel log binario fino a quando la transazione non viene eseguita, quindi la replica deve scaricare il log binario e inoltrare l'evento.
Ma i cambiamenti sono ancora atomici. Non è possibile leggere dati parzialmente modificati. Puoi leggere le modifiche salvate, nel qual caso tutti i vincoli sono soddisfatti, oppure le modifiche non sono ancora state salvate, nel qual caso puoi vedere lo stato dei dati prima dell'inizio della transazione.
Quindi potresti leggere temporaneamente vecchio dati in un sistema di replica che è in ritardo, ma non leggerai incoerente dati.
Mentre in un sistema "eventualmente coerente", potresti leggere dati parzialmente aggiornati, in cui un conto è stato addebitato ma il secondo conto non è stato ancora accreditato. Quindi puoi vedi dati incoerenti.
Hai ragione sul fatto che potrebbe essere necessario prestare attenzione alla lettura delle repliche se la tua applicazione richiede dati assolutamente aggiornati. Ogni applicazione ha una tolleranza diversa per il ritardo di replica e, infatti, all'interno di un'applicazione, query diverse hanno una tolleranza diversa per il ritardo. Ho fatto una presentazione su questo:Separazione lettura/scrittura per MySQL e PHP (Webinar Percona 2013)
