Normalmente, pulsação ( marca-passo ) ou MMM é usado para gerenciar um recurso de IP que falharia dinamicamente. Para que funcione de forma eficaz, você precisa compartilhar o mesmo segmento de rede.
Se os servidores não estiverem no mesmo espaço físico, até mesmo ter dois links da Internet diferentes para monitoramento é mais falível do que um dos links ser um cabo serial de vários pés.
Você precisará avaliar o risco e priorizar com base em suas necessidades. Qual é a sua prioridade? Disponibilidade ou integridade de dados? Se a integridade dos dados não for uma prioridade, você poderá fazer o failover automaticamente, mas ainda corre o risco de particionar. O teorema CAP explora isso em maiores detalhes.
Geralmente, não é aconselhável escrever nos dois servidores mestres ao mesmo tempo, pois pode haver conflitos de ID. Você pode configurar um deslocamento, mas isso é algo que precisa ser considerado em toda a sua arquitetura no contexto.
Com base no que sei do que você descreveu, eu provavelmente me inclinaria para a integridade de dados. Eu configurei o master duplo, só escrevo para um master IP do seu aplicativo. Em caso de falha no seu primário, eu teria o procedimento de failover manual para reenviar o aplicativo da Web para o banco de dados secundário.
Se você insistisse em failover automático, poderia escrever um script que considerasse mais de dois pontos de falha e minimizar o risco de dados com a lógica adicional. Essa arquitetura é substancialmente mais complicada, no entanto, e você teria que projetar algumas delas por conta própria.
Existe uma variedade de tecnologias disponíveis entre o clustering do MySQL (NDB) e os patches do Google, mas nada elimina completamente o teorema da CAP.