A replicação pode quebrar ou se comportar mal de todas as maneiras divertidas e emocionantes. Você precisa monitorar três coisas:

1. A replicação está em execução e não parou devido a um erro

Para monitorar se a replicação está ou não em execução, basta verificar programaticamente SHOW SLAVE STATUSe observar os valores de Slave_IO_Runninge Slave_SQL_Running. Ambos devem ser "sim". pmp-check-mysql-replication-running do Percona Monitoring Plugins for Nagios foi escrito para esta tarefa.

2. A replicação está funcionando bem (o atraso do escravo em relação ao mestre está dentro de um intervalo aceitável)

Você precisa ter certeza de que o escravo não ficou muito atrás do mestre. "Longe demais" é determinado pelo que seu aplicativo pode tolerar e por quantos logs binários você mantém no servidor mestre. Como a replicação no escravo é de thread único, os escravos podem facilmente ficar para trás. SHOW SLAVE STATUStem o Seconds_Behind_Mastervalor, mas não é um indicador confiável do atraso real e, com frequência, irá pular. Para medir com precisão o atraso da replicação, você precisa de um aplicativo externo para inserir um carimbo de data/hora em uma tabela periodicamente. Você pode então medir esse valor do escravo e compará-lo com o tempo atual para obter o atraso de replicação real. pt-heartbeat é um daemon que irá inserir um heartbeat em uma tabela em seu servidor. Você pode alertar sobre esse valor compmp-check-mysql-replication-delay para garantir que esteja dentro dos parâmetros especificados.

3. Os dados nos servidores estão sincronizados.

Há muitas maneiras pelas quais um mestre e um escravo podem ficar fora de sincronia para que os dados sejam diferentes. Você precisa detectar essas diferenças e corrigi-las periodicamente porque uma pequena diferença pode, com o tempo, se transformar em uma diferença muito grande, especialmente com replicação baseada em instrução. Esta não é uma tarefa fácil, e pt-table-checksum é projetado para calcular essas diferenças. Executar esta semana. pmp-check-pt-table-checksum é um plug-in do Nagios para alertar quando o escravo tiver discrepâncias de dados em relação ao mestre. Para realmente corrigir as diferenças, use pt-table-sync .

pt-table-checksum foi recentemente reescrito e é muito fácil de usar. pt-table-sync tem muitas opções e pode ser confuso. Leia a documentação para eles completamente , pois você pode realmente dar um tiro no pé se não for cuidadoso. Aqui está um webinar sobre essas ferramentas.

Outra coisa: posso executar um banco de dados separado em meu banco de dados de replicação, que apenas executo para fins de teste?

Não há nada que o impeça de modificar (ou complementar) os dados no escravo, embora geralmente eu não recomende isso. A melhor prática é fazer com que o escravo seja read_only=1. No entanto, a vida real tende a superar as melhores práticas e, muitas vezes, os escravos são usados ​​como servidores de relatórios. Minha sugestão seria deixar os privilégios de acesso bem claros para aqueles que usam o escravo para modificação de dados e ter todas as tabelas adicionais em um esquema separado.

1. A replicação pode 'ficar inoperante' por vários motivos, o principal é que o escravo obterá um erro de sql ao executar um dos comandos que foram executados no mestre (por exemplo, atualizando uma linha que existe no mestre, mas não existe no escravo ), outro problema pode ser a configuração de variáveis ​​diferentes entre mestre e escravo, como max_allowed_packet. Em suma, a replicação é um recurso sólido.

2. Eu uso a densidade do servidor para monitorar a replicação (entre outros parâmetros no servidor), eles podem monitorar se a replicação está em execução, segundos atrás do escravo e muitos outros parâmetros no servidor (cpu, memória). Eles têm um aplicativo da web muito claro, um aplicativo para iphone e podem enviar notificações por push quando as coisas vão mal e o melhor é que a integração com eles leva 5 minutos.

3. Quanto ao banco de dados separado, não entendi o que você está tentando alcançar lá

Espero que isto ajude,

R