GTI ou Identificador de Transação Global foi introduzido no MySQL 5.6.5. Um GTID é um id globalmente exclusivo dado a todas as transações executadas em um servidor de hospedagem MySQL habilitado para GTID. Os GTIDs são uma combinação do UUID do servidor em que uma transação específica foi confirmada e o número de sequência dessa transação nesse servidor específico. Isso torna o GTID globalmente único.
Replicação MySQL
A replicação baseada em GTID é muito mais flexível em comparação com a replicação baseada em log binário mais antiga. Em uma configuração baseada em GTID, o escravo não precisa de um arquivo binlog mestre e posição para iniciar a replicação. Leia mais sobre replicação baseada em GTID. Nesta postagem do blog, discutiremos alguns problemas comuns de replicação do MySQL causados ao implantar um conjunto de réplicas baseado em GTID.
Transações erradas são transações aplicadas a um ou mais escravos que não precisam ser replicadas em outros nós. Podem ser correções intermitentes aplicadas no escravo ou gravações acidentais no escravo por um aplicativo.
O problema com essas transações errôneas surge quando o escravo que contém uma transação errônea é promovido a mestre. No caso de replicação baseada em GTID, isso causaria um problema. O novo mestre agora percebe que os escravos não executaram a transação errônea. Uma de duas coisas pode acontecer:
(1) A transação errônea ainda está presente no log binário do mestre e irá enviá-la para os escravos, isso pode corromper os dados ou causar um erro.
(2) A transação não está presente no log binário e, portanto, não pode ser enviado para o escravo, o que causa um erro de replicação.
Prevenção
Transações errôneas podem ser ativamente evitadas seguindo estas etapas. Se você tiver que aplicar uma correção a um escravo, uma maneira de mitigar transações errôneas é desativando temporariamente o log binário no escravo. Executar sql_bin_log =0 antes de executar a consulta errônea deve resolver o problema. Mais tarde, você pode habilitar o log binário executando sql_bin_log =1. Para evitar que qualquer aplicativo grave em escravos, Read-Only deve ser habilitado em um servidor quando configurado como escravo.
Detecção
Detectar uma transação errônea em um conjunto de réplicas MySQL baseado em GTID é fácil. O MySQL armazena todos os GTIDs executados em sua tabela Performance Schema/Information Schema com base em qual versão do MySQL você está usando. Pegar os GTIDs executados do escravo atual e subtraí-los dos GTIDs executados no mestre atual deve fornecer todas as transações errôneas nesse escravo específico. Utilitários como mysqlfailover ou mysqlrpladmin também podem ajudar na detecção de transações errôneas.
Solução
Depois que uma transação errônea é detectada, há duas maneiras de corrigir os erros de replicação causados após um failover. Uma maneira é excluir o GTID da transação errante do histórico de execução do GTID escravo. Dessa forma, quando o escravo for promovido a mestre, a transação errônea não será replicada para todos os nós. Outra maneira de lidar com transações errôneas é dizer a todos os outros escravos para pular a transação errônea. Isso incluiria inserir uma transação vazia com o mesmo GTID da transação errante para todos os outros nós do conjunto de réplicas. Isso fará com que todos os outros nós pensem que já aplicaram essa transação e, portanto, a ignorarão. O MySQL tem um utilitário chamado Mysqlslavetrx dedicado a isso. Este utilitário pode ser usado para inserir transações vazias com o GTID fornecido. Adicionar transações vazias também pode ter outros usos, conforme discutido aqui.
