Se você entender seus dados e as razões pelas quais a replicação falha, não será necessário recarregar os escravos, embora essa seja a maneira mais fácil, pois pode ser entediante corrigir o escravo para que a replicação possa continuar.
Eu usei vários mestres por alguns anos, e os problemas que eu encontrei são causados principalmente por gatilhos que são realmente difíceis de depurar. Por essa razão, eu faria as transações tão atômicas e determinísticas quanto possível, e para bloquear o usuário ou sessão para o banco de dados mais local.
Eu uso uma tabela de pesquisa de dbs disponível indexada por um módulo do endereço ip decimalizado do usuário, para que o usuário sempre veja um banco de dados e não seja afetado pelo atraso de replicação causado pelo db hopping, como o mysql-proxy costumava fazer .
Conecte-se como um anel em túneis ssh ou vpn criptografados e tudo deve funcionar.
Inserir outro banco de dados no ringue é simples, mas se houver algum atraso de replicação, remover um deles corre o risco de um loop caro, potencialmente inserindo ou atualizando registros milhões de vezes antes de ser notado!
Eu gostaria de replicação - funciona bem quando funciona. Você pode pendurar mais escravos de cada mestre para relatórios e backups pontuais sem tempo de inatividade.