La cohérence dans le sens où elle est utilisée dans ACID signifie que toutes les contraintes sont satisfaites avant et après toute modification. Lorsqu'un système vous assure que vous ne pouvez pas lire des données incohérentes, il dit par exemple que vous ne liriez jamais les données où une ligne enfant fait référence à une ligne parent inexistante ou si la moitié d'une transaction a été appliquée, mais l'autre moitié n'a pas encore été appliquée (l'exemple de manuel débite un compte bancaire mais n'a pas encore crédité le compte bancaire du destinataire).
La réplication dans MySQL est asynchrone par défaut, ou "semi-synchrone" au mieux. Certes, il est en retard dans les deux cas. En fait, l'esclave de réplication est toujours en retard d'au moins une fraction de seconde, car le maître n'écrit pas de modifications dans son journal binaire tant que la transaction n'est pas validée, l'esclave doit télécharger le journal binaire et relayer l'événement.
Mais les modifications sont encore atomiques. Vous ne pouvez pas lire les données partiellement modifiées. Vous lisez les modifications validées, auquel cas toutes les contraintes sont satisfaites, ou bien les modifications n'ont pas encore été validées, auquel cas vous voyez l'état des données avant le début de la transaction.
Vous pouvez donc temporairement lire vieux données dans un système de réplication qui traîne, mais vous ne lirai pas données incohérentes. Considérant que dans un système "finalement cohérent", vous pouvez lire des données qui sont partiellement mises à jour, où le compte a été débité mais le deuxième compte n'a pas encore été crédité. Donc vous pouvez voir des données incohérentes.
Vous avez raison: vous devrez peut-être faire attention à la lecture des esclaves de réplication si votre application requiert des données absolument actuelles. Chaque application a une tolérance différente pour le décalage d'esclave, et en fait dans une application, différentes requêtes ont une tolérance différente pour le décalage. J'ai fait une présentation à ce sujet: http://www.slideshare.net/billkarwin/read-write-split
Je pense que la technologie la plus précise pour votre question est InnoDB, pas mysql. Le moteur de stockage est où la gestion de la réplication est comparable à d'autres options – Anthony
http://www.palominodb.com/blog/2012/06/20/mystery-solved-replication-lag-innodb – Anthony
Merci. Je suppose que les transactions empêcheraient une écriture sur le master et liraient de l'inconsistance des esclaves et vous le feriez avec innodb. Modifier ma question –