Se o servidor primário falhar, então o servidor em-espera deverá iniciar os procedimentos de comutação ^[153]. ^[154].

Se o servidor em-espera falhar, não será necessário haver nenhum procedimento de comutação. Se o servidor em-espera puder ser reiniciado, mesmo mais tarde, o processo de restauração também poderá ser reiniciado ao mesmo tempo, aproveitando o fato da restauração saber continuar de onde parou. Se o servidor em-espera não puder ser reiniciado, deverá ser criada uma nova instância completa do servidor em-espera.

Se o servidor primário falhar, e o servidor em-espera se tornar o novo servidor primário e, em seguida, o antigo servidor primário for reiniciado, deverá existir um mecanismo para informar ao antigo servidor primário que ele não é mais o servidor primário. Isto às vezes é conhecido como STONITH (Shoot The Other Node In The Head, atire no outro nó na cabeça), o que é necessário para evitar situações em que os dois sistemas pensem que são o primário, o que levará à confusão e, por fim, à perda de dados.

Muitos sistemas de comutação usam apenas dois sistemas, o primário e o em-espera, conectados por algum tipo de mecanismo de pulsação para verificar continuamente a conectividade entre os dois sistemas, e a viabilidade do sistema primário. Também é possível usar um terceiro sistema (chamado de servidor testemunha), para evitar alguns casos de comutação indevida, mas a complexidade adicional pode não valer a pena, a menos que seja configurado com cuidado suficiente e testes rigorosos.

O PostgreSQL não fornece software de sistema necessário para identificar uma falha no servidor primário e notificar o servidor de banco de dados em-espera. Muitas dessas ferramentas existem, e estão bem integradas aos recursos do sistema operacional necessários para realizar uma comutação bem-sucedida, como a migração de endereço de IP.

Ocorrendo a comutação para o servidor em-espera, haverá apenas um único servidor em operação. Isto é conhecido como estado degenerado. O antigo servidor em-espera agora é o servidor primário, mas o antigo servidor primário está inativo e deverá permanecer inativo. Para retornar à operação normal, deverá ser recriado um servidor em-espera, seja no antigo sistema primário quando este voltar a funcionar, ou em um terceiro sistema, possivelmente novo. Pode ser usado o utilitário pg_rewind para acelerar este processo em grandes agrupamentos de servidores. Uma vez concluído, o servidor primário e o servidor em-espera podem ser considerados como estando com papéis trocados. Algumas pessoas optam por usar um terceiro servidor para fornecer proteção para o novo servidor primário, até que o novo servidor em-espera seja recriado, embora claramente isto complique a configuração do sistema e os procedimentos operacionais.

Portanto, comutar do servidor primário para o servidor em-espera pode ser rápido, mas requer algum tempo para preparar novamente a formação original de comutação. A comutação regular do servidor primário para servidor em-espera é útil, porque permite tempo de inatividade regular em cada sistema para manutenção. Também serve como teste do mecanismo de comutação, para garantir que realmente irá funcionar quando for necessário. Se recomenda escrever os procedimentos de administração.

Se for optado pela sincronização por encaixes de replicação lógica (veja Replication Slot Synchronization), então, antes de comutar para o servidor em-espera, recomenda-se verificar se os encaixes de replicação sincronizados no servidor em-espera estão prontos para a comutação. Isto pode ser feito seguindo os passos descritos em Falha de replicação lógica.

Para acionar a comutação de um servidor em-espera de envio de WAL, deve-se executar pg_ctl promote ou chamar pg_promote(). Se estiver sendo configurado servidores de relatório usados ​​apenas para aliviar consultas de leitura-apenas do servidor primário, e não para fins de alta disponibilidade, não haverá necessidade de promoção.