Eu não estou ciente de uma solução para fazer o que você realiza, já que o MySQL não suporta nativamente servidores escravos replicando de múltiplos mestres.
A replicação circular é frágil e geralmente não é recomendada.
Se o seu mestre principal falhou, o que é um mestre em atuação para todos os escravos, você poderia re-apontá-los para o mestre secundário. Isso normalmente envolve escavar através dos binlogs, o que pode ser bastante entediante e é fácil cometer um erro. Você pode usar o utilitário mk-slave-move do Maatkit para tornar isso um pouco mais fácil.
Você poderia executar várias instâncias do MySQL em cada escravo e, em seguida, ter uma lógica de pulsação ou failover, que seria capaz de alternar no caso da falha principal do mestre. Isso teria que ter lógica substancial para não ser frágil.
Você pode executar um master duplo, ter um escravo de cada mestre e depois balancear a carga de ambos os escravos. Tenha verificação de disponibilidade em seu balanceamento de carga para remover o escravo no caso de uma única falha principal, o que provavelmente seria melhor do que ter vários escravos em cada servidor. Isso não seria bem escalado.
Supostamente, este conjunto de scripts ajuda nesse tipo de configuração, mas não tenho experiência com eles.
Se você deseja alta disponibilidade para consultas de somente leitura, recomendo que as consultas mais importantes sejam executadas nos servidores altamente disponíveis de mestre duplo. Para consultas que não precisam ser em tempo real, faz sentido executá-las contra os escravos de carga múltipla balanceada, o que poderia potencialmente não ter dados atuais em caso de falha do mestre.