O grande problema da replicação é verificar
- que os nós estão todos em cima,
- todos os nós estão se comunicando (não dividem o cérebro)
- e processando logs de replicação
- e o atraso de replicação
1, 3 e 4 podem ser capturados usando-se SHOW MASTER STATUS / SHOW SLAVE STATUS nos nós relevantes, embora o atraso de replicação tenha apenas 1 segundo de precisão e somente em cada salto. O kit de ferramentas Percona possui scripts para obter lags de replicação mais precisos.
Usando a replicação multimestre (por exemplo, tungstênio , Percona ) poupa muita dor, mas precisa de esforço / software adicional para configurar.
Se a rede entre ndoes falhar, então todos os processos podem estar rodando bem - mas não poderão transferir dados - você precisa monitorar em cada nó para verificar se ele pode contatar o nó upstream.
a MySQL Master database which replicates to a few Slave databases
A melhor prática seria designar um dos escravos como um mestre também - replicação bidirecional. Dessa forma, você pode alternar facilmente no caso de uma interrupção ou para tarefas de manutenção, como a reconstrução de índices, backups, alterações de esquema.
Dependendo do número de nós escravos, você também pode designar um nó fanout para propagar as alterações.
Em termos de gerenciamento de escalações, agendamento de scripts para coleta de dados, etc., há muitas ferramentas disponíveis que fazem isso - eu uso nagios, assim como muitas outras pessoas.