Como escudar dados em tempo real de dois fontes MySQL que se fundem em um destino MySQL?

Question

Eu tenho duas instâncias diferentes do MySQL que eu gostaria de 'escravo' para uma terceira instância. (para que eu possa fazer junções fáceis na terceira instância)

por exemplo,

mysql1> show databases
db1
db2

mysql2> show databases
db3
db4

mysql3> show databases
db1
db2
db3
db4

Eu olhei para o maatkit (kit de ferramentas do percona) pt-table-sync mas as pessoas dizem pode corromper dados. (Aparentemente remove e adiciona novamente dados para gerar inserções)

O tipo arquivista-pt funciona para 'instantâneos', mas o db1 é de aproximadamente 6 GB e copiar tudo é muito mais do que realmente é necessário. As atualizações em tempo real são apenas cerca de 100 MB por dia.

O conceito natural para mim seria permitir que o mysql3 seja executado como uma réplica do escravo de ambos os mysql1 e mysql2, mas isso não parece ser uma opção no MySQL

O

Replicador de tungstênio parece permitir esse tipo de sincronização de dados, mas parece um pouco difícil de configurar e estou preocupado com a confiabilidade.

Alguém tem outras soluções que eles usaram para esse problema?

    

Answer 1

Por padrão, um processo mysqld não pode escutar simultaneamente dois Mestres diferentes.

O comando CHANGE MASTER TO só permite que você defina um mestre como fonte para ler.

Para emular isso, você teria que alternar entre os dois mestres programaticamente. Como você faz isso?

Eu descrevi no StackOverflow como conectar um Slave manualmente a diferentes mestres, onde cada mestre era um laptop e o escravo era um computador central.

Aqui está a ideia básica

• Master M1
• Mestre M2
• Escravo S1

Configura a replicação de M1 para S1 e depois M2 para S1 como este

• 1) Faça S1 executar CHANGE MASTER TO com M1 como a Fonte
• 2) START SLAVE;
• 3) Execute a replicação por pouco tempo
• 4) PARAR ESCRAVO;
• 5) Faça o S1 executar CHANGE MASTER TO com M2 como a Fonte
• 6) INICIAR ESCRAVO
• 7) Execute a replicação por pouco tempo
• 8) PARE ESCRAVO
• 9) Voltar para o Passo 1

Cada vez que você muda de um mestre para outro, você deve gravar dois valores de SHOW SLAVE STATUS\G

1. Relay_Master_Log_file
2. Exec_Master_Log_Pos

Esses dois valores representam a última declaração SQL que veio do mestre e estava próxima de ser executada no escravo.

Há uma grande precaução: enquanto o M1 e o M2 estiverem atualizando bancos de dados mutuamente exclusivos, esse algoritmo deve ser perfeito.

Acredite ou não, Abordei uma pergunta como esta no ServerFault em maio de 2011. Na verdade, eu expliquei como emular o verdadeiro multimaster / escravo simples usando o Mecanismo de Armazenamento BLACKHOLE baseado no livro "MySQL de Alto Desempenho".

    

Answer 2

Não há uma boa ferramenta de leitura para fazer isso. pt-table-sync não funciona exatamente como você foi informado (eu escrevi); mas não é a solução correta. Eu vi sua funcionalidade de sincronização bidirecional usada para reconciliar servidores para uma fonte central depois de ter sido intencionalmente desconectada e atualizada, mas essa não é a solução certa para o que você precisa.

Normalmente, não faço apresentações de vendas sobre tópicos como esse, mas honestamente esse é o caso em que eu envolvi a Percona para desenvolver uma nova ferramenta para você. Algumas pessoas escreveram pequenos roteiros que se adequam a seus cenários pessoais, mas ainda não existe uma solução de alta qualidade para uso geral, e não é tão difícil assim. O principal é que você precisa de testes formais, e os componentes do Percona Toolkit já são 90% do que você precisa - só precisa de um pouco de cola entre eles. Você poderia fazer isso sozinho, é claro, mas por que fazer uma roda quadrada e acabar mantendo-a você mesmo e descobrindo todos os seus insetos quando você menos deseja?

Dito isso (finalizar o discurso de vendas, desculpe) - a solução que sugiro deve evitar as tabelas de blackhole e seguir com técnicas mais simples e menos problemáticas. (Sim - eu escrevi o MySQL de Alta Performance também. Eu sei. Naquela época, eu não tinha visto tantos problemas com as tabelas blackhole quanto eu tenho hoje.) Deve ser mais ou menos o que Rolando sugere, mas há algumas sutilezas. Por exemplo, ele não deve permitir que o encadeamento de E / S envie um monte de dados do mestre, ficando muito à frente do encadeamento do SQL e, em seguida, elimine tudo quando ele rodar para o próximo servidor. Isso seria realmente um desperdício e causaria muito impacto no mestre. Há um monte de pequenos detalhes como este que precisam ser atendidos - outro que vem à mente não é a troca de mestres quando uma tabela temporária causada pela replicação está em uso.