O que eu realmente posso fazer com a pt-table-sync do kit de ferramentas percona?

Question

Eu tenho procurado por uma ferramenta para sincronizar tabelas de 2 bancos de dados diferentes e encontrei pt-table-sync . Eu li a documentação e fiquei confuso: eles usavam principalmente exemplos referentes a um ambiente replicado, mas achei que o objetivo da replicação era cuidar da sincronização de dados para você, daí minhas perguntas:

PERGUNTAS

1. Qual é o sentido de usar pt-table-sync se o processo de replicação deve cuidar da sincronização de dados para você?

2. Posso usar pt-table-sync em um ambiente não replicado (entre 2+ hosts que não têm nada a ver um com o outro, é o papel do pt-table-sync --execute host1 host2 host3 fornecido)?

3. Se eu precisar usar pt-table-sync em um ambiente replicado, posso fazer isso sem o bin-logs no master (há um exemplo falando sobre como resolver as diferenças descobertas por pt-table-checksum , então estou pensando se bin-logs é absolutamente necessário)?

Answer 1

Resposta à pergunta 1

A replicação do MySQL sofre de dois grandes problemas

• A replicação do MySQL é assíncrona . Isso pode introduzir atraso de replicação. Isso se manifesta com problemas de comunicação entre um mestre e um escravo via thread de E / S escravo. Isso pode ser visto logicamente e numericamente em Seconds_Behind_Master .

• Data Drift . Essa é uma condição intermitente em que um mestre e um escravo estão simplesmente fora de sincronia devido a fatores fora do reino da Replicação do MySQL. Por exemplo, observe uma maneira de sincronizar melhor a replicação: use a opção sync-binlog . Quando você configura sync-binlog para 1, o mysqld irá executar um flush do log binário atual para cada entrada que você gravar no log binário. Isso pode ridicularizar um Mestre. Por padrão, sync-binlog é 0.

  • Aqui está uma pergunta: Com sync-binlog=0 , quem é responsável por liberar o log binário para o disco?
  • Resposta (por favor, sente-se para este): O SISTEMA OPERACIONAL !!!
  • Com essa resposta, isso coloca o Escravo como uma desvantagem terrível, porque seu encadeamento de E / S está à mercê do Sistema Operacional do Mestre. Quando o sistema operacional do Mestre se movimenta para liberar as alterações do log binário para o disco e o encadeamento de E / S do escravo pode detectar a próxima instrução SQL de entrada, a instrução é enviada através do encadeamento de E / S para o escravo.
  • Percona tem um PDF agradável ao lidar com a deriva de dados

Resposta à pergunta 2

A resposta direta aqui é não porque pt-table-sync foi projetado para detectar o thread de E / S de um Slave por meio da opção --sync-to-master .

Resposta à pergunta 3

A resposta direta aqui é não porque o MySQL Replication exige saber

• qual é o log binário atual no mestre? (isso é Master_Log_File de SHOW SLAVE STATUS\G )
• qual é a posição mais recente que o Escravo leu no registro binário atual do Mestre? (isso é Read_Master_Log_Pos de SHOW SLAVE STATUS\G )

Se você quer simplesmente que seus logs binários saiam do caminho, você pode fazer uma das duas coisas

• OPÇÃO 1: no mestre, defina expire-logs-days a 3 para manter os últimos 3 dias de registros binários
  • Adicione expire-logs-days=3 em /etc/my.cnf
  • Não é necessário reiniciar: basta executar SET GLOBAL expire_logs_days = 3;
• OPÇÃO 2: Executar SHOW SLAVE STATUS\G no Escravo. Pegue o valor de Relay_Master_Log_File . e use-o para limpar os logs binários no mestre para criar esse arquivo de log.
  • Suponha que você execute SHOW SLAVE STATUS\G no escravo
  • Você recebe este Relay_Master_Log_File: mysql-bin.000035
  • Execute isso no mestre: PURGE BINARY LOGS TO 'mysql-bin.000035';

SUGESTÃO

Se você quiser ter mais fé na sincronização da tabela de pt, tente usar a opção --print e redirecionar para um arquivo de texto em vez da opção --execute . Isso gerará o SQL que normalmente seria executado no mestre. Você poderia simplesmente executar o SQL diretamente nesse Slave depois disso. Pense nisso como um ensaio geral para --execute .

    

Answer 2

but I thought the whole point of replication was to take care of the synchronization of data for you

Sim, a replicação do MySQL tenta sincronizar um banco de dados replicado. No entanto, a replicação do MySQL é complicada e a replicação pode falhar por vários motivos. Erros de replicação em minha experiência são raros, mas acontecem durante falhas inesperadas do servidor, quando os usuários pressionam "Control-C" no meio de uma grande inserção no master, etc. O MySQL.com não fornece boas ferramentas para lidar com muitos problemas. desses problemas. Felizmente, alguns engenheiros como o Baron Schwartz (autor original do Percona Toolkit (anteriormente conhecido como Maatkit) desenvolveram ferramentas para facilitar a administração do MySQL.

Por exemplo, atualmente tenho uma tabela com 50 milhões de linhas. Um punhado de linhas está fora de sincronia devido a uma falha do servidor há algumas semanas. Preciso descobrir quais linhas estão fora de sincronia, mas isso seria doloroso de fazer manualmente. Eu uso pt-table-checksum para verificar erros de replicação na réplica e pt-table-sync para descobrir quais linhas estão faltando na réplica.

Se você está considerando a replicação do MySQL, eu recomendo que você investigue e use o Percona Toolkit. Se tivéssemos começado com o Percona Toolkit, a administração de nossos bancos de dados MySQL teria sido muito mais simples.

I read the documentation and got confused:

A documentação do Percona Toolkit está escrita como um manual técnico. Infelizmente, ele não faz um bom trabalho em descrever como usar as ferramentas, como elas ajudam você, etc. link tem algumas dessas informações , mas é em grande parte focado no garfo Percona do MySQL (É assim que eles ganham a vida), o que requer que o leitor faça alguma tradução.

    

Answer 3

Resposta à pergunta 1

pt-table-sync (togerther com pt-table-checksum ) pode ser usado para corrigir erros de replicação como corrupção de dados, alguém modificando dados diretamente no escravo, travamentos de servidor, mudanças de esquema na ordem errada, etc.

No entanto, pt-table-sync também pode ser usado sem replicação para manter as tabelas sincronizadas em tempo quase real, se os dados não mudarem muito.

Resposta correta à pergunta 2

É claro que você também pode usá-lo em ambientes não replicados, o manual também menciona isso. Eu uso do cron para manter 3 servidores mysql "em sincronia" a cada 5 minutos. Eles têm a mesma cópia de dados que muda apenas algumas vezes (no primeiro servidor), portanto, a replicação para esse propósito seria um exagero.

Você pode especificar bancos de dados individuais ou tabelas individuais a serem sincronizadas. Você pode ter vários servidores de destino. pt-table-sync usa vários algoritmos eficientes para detectar alterações nas tabelas do banco de dados e copiar apenas as alterações (categoriza as alterações em 4 grupos: Exclui, substitui, insere, atualiza).