Início / dba / Perguntas / 228764
Accepted
nbari
Asked: 2019-02-03 15:21:27 +0800 CST

ajudar a entender a consistência da galera (replicação baseada em certificação)

  • 772

O Galera usa uma replicação baseada em certificação para obter uma consistência forte.

Ao fazer uma transação, depois de fazer um, COMMITos outros nós irão certificar e se estiver ok, será confirmado com sucesso.

Mas o que acontece no caso de perder um nó que certificou o commit, mas ainda está buscando os dados, por exemplo, ao escrever um big blob?

Do meu entendimento, o processo de certificação é síncrono, mas a transferência de dados é assíncrona, o que significa que o cliente/usuário pode pensar que seus dados estão armazenados em todos os nós após a execução com sucesso COMMIT, mas enquanto na realidade está acontecendo no backend é que os dados ainda podem estar sincronizando entre os nós e em caso de interrupção da rede e dependendo do tipo de transação o nó pode estar em conflito, correto?

Se este for o caso, como o cluster poderia ser configurado para se auto-recuperar de possíveis conflitos ou imaginando se existe uma maneira de obter uma consistência forte, mesmo que isso impacte o tempo de retorno de cada COMMIT, já que só deve ser bem-sucedido após os dados serem full transmitido em todos os nós.

galera clustering

1 respostas

  1. Best Answer

    Mas o que acontece no caso de perder um nó que certificou o commit, mas ainda está buscando os dados, por exemplo, ao escrever um grande blob?

    Isso não é diferente de perder qualquer outro nó. Se o nó travar, ele tentará se juntar novamente ao cluster na próxima vez que ele aparecer. Um nó doador será encontrado e, preferencialmente, IST (transferência de estado incremental) ou alternativamente SST (transferência de instantâneo de estado) trará o nó para o estado correto.

    Do meu entendimento, o processo de certificação é síncrono, mas a transferência de dados é assíncrona, o que significa que o cliente/usuário pode pensar que seus dados estão armazenados em todos os nós após executar com sucesso um COMMIT, mas enquanto na realidade está acontecendo no backend é que os dados podem ser ainda sincronizando entre os nós e em caso de queda de rede e dependendo do tipo de transação o nó pode estar em conflito, correto?

    Você está certo de que a transferência de dados é assíncrona e há um curto período de tempo enquanto o estado do nó não é idêntico. Isso não é exatamente um conflito, apenas que os outros nós estão atrás. Eles vão pegar em breve.

    Se este for o caso, como o cluster poderia ser configurado para se auto-recuperar de possíveis conflitos ou imaginando se existe uma maneira de obter uma consistência forte, mesmo que isso impacte o tempo de retorno de cada COMMIT, pois só deve ser bem-sucedido após os dados foi totalmente transmitido em todos os nós.

    Sim, ele se auto-cura através de ISTs e SSTs.

    Há duas maneiras de ter certeza de que você está lendo a versão mais atualizada dos dados: Se você sempre grava em apenas um nó (por exemplo, por usar um proxy de banco de dados com um divisor de leitura e gravação), você pode certificar-se de também ler a partir desse mesmo nó. A outra opção é definir a variável de sessão wsrep_sync_wait =1 - consulte Obtendo semântica de leitura após gravação com Galera .

    • 2

relate perguntas