O que acontece com a replicação síncrona do MySQL quando a réplica de leitura não consegue responder?

MySQL não suporta replicação síncrona. Sempre haverá um atraso porque as alterações não serão gravadas no log binário até que você confirme uma transação, então a réplica deverá baixar o log binário e aplicar as alterações em sua instância.

O cliente que fez alterações na instância primária não espera que as mesmas alterações sejam aplicadas na réplica.

No caso de replicação semissíncrona , o cliente que faz alterações no primário aguarda COMMIT até que pelo menos uma réplica tenha baixado os respectivos eventos de log binário — mas o cliente ainda não espera que esses eventos de log binário sejam aplicados. É suficiente garantia de redundância saber que a réplica recebeu o log binário.

Isso ainda é realmente assíncrono, no sentido de que a alteração não está imediatamente disponível na réplica depois que o COMMIT é concluído na origem.

O NDB Cluster não é diferente no que diz respeito à replicação. Ao copiar dados de um cluster para um cluster remoto, ele funciona através do log binário como qualquer outro mecanismo de armazenamento MySQL e é sempre assíncrono (ou, na melhor das hipóteses, semi-síncrono).

A documentação que você viu que recomenda "para cenários onde a replicação síncrona é necessária, use NDB Cluster" é enganosa. NDB Cluster não é uma solução de replicação, é um mecanismo de armazenamento.

O que o autor dessa documentação pode ter querido dizer é que se o seu objetivo é garantir que os dados sejam armazenados em mais de um local, para proteger contra perda de dados em caso de falha de armazenamento, então o NDB Cluster pode ser uma solução porque armazenar quaisquer dados change copia os dados de forma síncrona para duas réplicas de fragmentos . As réplicas de fragmentos estão todas na mesma instância do MySQL Server. Nenhum log binário está envolvido.

Infelizmente, isso está sobrecarregando o termo "réplica" e pode ser confuso. Uma réplica de fragmento de cluster NDB não é uma réplica do MySQL Server.

O mecanismo de armazenamento NDB grava alterações em dois (ou mais) nós para obter redundância. Isso usa confirmação em duas fases, mas é tratado internamente no mecanismo de armazenamento NDB, não como parte da semântica da transação SQL.

Se um nó de um cluster NDB não responder ou ocorrer uma partição de rede que torne o nó inacessível a partir do nó de gerenciamento, o cluster desabilita esse nó. Sugiro que você leia sobre o árbitro em um Cluster NDB .

Re seu comentário:

portanto, leitura após gravação na réplica de leitura pode possivelmente ler dados obsoletos antes que o binlog seja aplicado na réplica de leitura

Sim esta correto. Você não pode confiar que a instância de réplica tenha aplicado eventos de log binário imediatamente após COMMIT na instância de origem. Sempre há um atraso, mesmo que seja pequeno.

Você pode medir o atraso (às vezes chamado de replication lag ) de várias maneiras, das quais presumo que você esteja ciente.

Você também pode ler uma réplica usando uma função de bloqueio SOURCE_POS_WAIT(), para ter certeza de que ela foi "alcançada", ou seja, aplicada pelo menos até uma posição específica do log binário. Se você souber qual era a posição do log binário na origem quando executou uma determinada atualização, isso permitirá que você espere até que os dados da réplica incluam essa alteração.

Outra definição de consistência (outro termo sobrecarregado com múltiplos significados) é que todas as restrições são satisfeitas antes e depois de qualquer transação. MySQL suporta isso por padrão. Ou seja, todas as transações são confirmadas atomicamente em uma réplica, mesmo que haja atraso.