Consistência no sentido em que é usada em ACID significa que todas as restrições são satisfeitas antes e depois de qualquer mudança. Quando um sistema garante que você não pode ler dados inconsistentes, eles estão dizendo, por exemplo, que você nunca lerá dados onde uma linha filho faz referência a uma linha pai inexistente ou onde metade de uma transação foi aplicada, mas o a outra metade ainda não foi aplicada (o exemplo do livro didático é debitar uma conta bancária, mas ainda não creditar a conta bancária do destinatário).

A replicação no MySQL é assíncrona por padrão ou, na melhor das hipóteses, "semi-síncrona". Certamente fica para trás em ambos os casos. Na verdade, a réplica de replicação está sempre atrasada pelo menos uma fração de segundo, porque o mestre não grava as alterações em seu log binário até que a transação seja confirmada, então a réplica precisa baixar o log binário e retransmitir o evento.

Mas as mudanças ainda são atômicas. Você não pode ler dados parcialmente alterados. Você lê as alterações confirmadas, caso em que todas as restrições são satisfeitas, ou as alterações ainda não foram confirmadas, nesse caso você vê o estado dos dados antes do início da transação.

Então você pode ler temporariamente antigos dados em um sistema de replicação com atraso, mas você não lerá inconsistente dados.

Considerando que em um sistema "eventualmente consistente", você pode ler dados parcialmente atualizados, onde uma conta foi debitada, mas a segunda conta ainda não foi creditada. Então você pode veja dados inconsistentes.

Você está certo de que pode precisar ter cuidado ao ler de réplicas se seu aplicativo exigir dados absolutamente atuais. Cada aplicativo tem uma tolerância diferente para atraso de replicação e, de fato, dentro de um aplicativo, consultas diferentes têm tolerância diferente para atraso. Fiz uma apresentação sobre isso:Divisão de leitura/gravação para MySQL e PHP (Webinar Percona 2013)