Para começar, não tenho nenhum tipo de failover automatizado instalado.
Depois de dois cenários, não tenho certeza do estado do banco de dados e de quaisquer ações necessárias, se houver:
- Meu servidor master desaparece da face do planeta e eu
touch my_trigger_file, convertendo meu standby em um servidor master. - Meu servidor mestre trava e reinicia no modo de recuperação
Minha suposição é que o servidor em questão em cada um desses cenários estará primeiro no modo de recuperação, terminará a recuperação e finalmente estará pronto como um servidor mestre.
No cenário 2, minha suposição significa que as coisas voltaram ao normal, enquanto no cenário 1, minha suposição significa que o modo de espera não faz ideia de que já foi um modo de espera e agora é simplesmente um mestre.
Essas suposições estão corretas ou há outras ações que precisam ocorrer em um ou em ambos os cenários após o término da recuperação (além de criar um novo escravo no caso do cenário 1)?
Além disso, existe uma diferença técnica notável entre o estado de um servidor escravo depois de se tornar um mestre e um servidor mestre em recuperação após uma falha ou, no que diz respeito ao Postgres, ambos são essencialmente servidores mestres que acabaram de se recuperar de algo ?
Estou usando o Postgres 9.2 com replicação de streaming assíncrona.
Posso sugerir a atualização para o PostgreSQL 9.3 (recém-lançado!)? Alguns escrevem que o novo recurso Streaming-Only Remastering transforma uma réplica em um conjunto de réplicas no novo mestre para todas as outras réplicas. Aparentemente, é ainda mais útil em combinação com a replicação em cascata que você está usando no 9.2
No PostgreSQL 9.2, a replicação em cascata realmente requer arquivamento WAL baseado em arquivo para funcionar em caso de recuperação de desastre. O PostgreSQL 9.3 não exigirá isso: você pode configurar grandes clusters de replicação de qualquer comprimento que desejar, sem nenhum arquivamento do WAL.
Mais Informações: