Estou executando o Percona MySQL 5.5.39 em dois mestres com manutenção de monitoramento de um VIP que fará o failover para o mestre em espera se o mestre primário ficar escuro. Ao testar a tolerância a falhas da minha configuração no laboratório, notei que estou obtendo entradas de chave duplicadas em ambos os mestres.
Basicamente, eu executo o cerco para emular a carga do usuário, por cinco minutos, dentro desse tempo, desligo o mestre primário e, após cerca de 10 segundos, o keepalived detecta a interrupção, o VIP é trocado pelo mestre em espera, momento em que tudo está funcionando como esperado. Então, depois de um minuto ou mais, enquanto o cerco ainda está em execução, ligo o mestre primário e, quando online, ele assume o VIP.
É durante a troca do VIP que acho que está ocorrendo o problema de entrada duplicada. Eu segui esta postagem explicando como implementar a replicação 'resistente a falhas', mas depois de implementar as alterações sugeridas no my.cnf e reexecutar a simulação do usuário, acabei com a mesma replicação quebrada.
Há também a capacidade do mestre em espera de incrementar seus índices em 2 em vez de 1 para evitar colisões com o mestre primário, mas acho que isso é mais um truque do que uma solução.
Existe alguma maneira melhor de evitar colisões de chave primária em um ambiente HA?
Isso não é um hack. É a intenção deles: Usar
auto_increment_increment
eauto_increment_offset
http://dev.mysql.com/doc/refman/5.6/en/replication-options-master.html#sysvar_auto_increment_increment
Sua arquitetura não é adequada para replicação assíncrona. Eu recomendo fortemente não executar uma replicação padrão mestre-mestre em um sistema totalmente automatizado, pois você encontrará exatamente o problema que está descrevendo.
Embora você possa não estar gravando em ambos os servidores ao mesmo tempo, o fato de estar replicando de maneira não síncrona significa que você deve ter em conta problemas como gravações pendentes sendo enviadas para o escravo ou gravações pendentes sendo aplicadas a ele localmente. Um failover automático não é fácil ou trivial com essas condições e, menos ainda, o switch-back.
Há coisas que podem ajudá-lo a fazer isso:
O
auto_increment_increment
pode resolver colisões de inserção entre nós, mas não atualizações entre nós diferentes ou inserções das mesmas consultas no mesmo nó duas vezes devido a incompatibilidades de log binário.Não há uma resposta certa, mas há muitas erradas. Eu elogio seus métodos (mesmo que o produto final não esteja certo): teste, teste e teste se quiser algo que atenda às suas necessidades.
Se você acha que é um hack, experimente o PXC (Percona XtraDB Cluster).
PXC usa Galera Cluster (por Codership), que é replicação síncrona com InnoDB.