Si le serveur primaire plante alors le serveur secondaire devrait commencer les procédures de failover.

Si le serveur secondaire plante alors il n'est pas nécessaire d'effectuer un failover. Si le serveur secondaire peut être redémarré, même plus tard, alors le processus de récupération peut aussi être redémarré au même moment, en bénéficiant du fait que la récupération sait reprendre où elle en était. Si le serveur secondaire ne peut pas être redémarré, alors une nouvelle instance secondaire complète devrait être créée.

Si le serveur primaire plante, que le serveur secondaire devient le nouveau primaire, et que l'ancien primaire redémarre, vous devez avoir un mécanisme pour informer l'ancien primaire qu'il n'est plus primaire. C'est aussi quelquefois appelé STONITH (Shoot The Other Node In The Head, ou Tire Dans La Tête De L'Autre Nœud), qui est nécessaire pour éviter les situations où les deux systèmes pensent qu'ils sont le primaire, ce qui amènerait de la confusion, et finalement de la perte de données.

Beaucoup de systèmes de failover n'utilisent que deux systèmes, le primaire et le secondaire, connectés par un mécanisme de type ligne de vie (heartbeat) pour vérifier continuellement la connexion entre les deux et la viabilité du primaire. Il est aussi possible d'utiliser un troisième système (appelé un serveur témoin) pour éviter certains cas de bascule inappropriés, mais la complexité supplémentaire peut ne pas être justifiée à moins d'être mis en place avec suffisamment de précautions et des tests rigoureux.

PostgreSQL ne fournit pas le logiciel système nécessaire pour identifier un incident sur le primaire et notifier le serveur de bases de données secondaire. De nombreux outils de ce genre existent et sont bien intégrés avec les fonctionnalités du système d'exploitation nécessaires à la bascule, telles que la migration d'adresse IP.

Une fois que la bascule vers le secondaire se produit, il n'y a plus qu'un seul serveur en fonctionnement. C'est ce qu'on appelle un état dégradé. L'ancien secondaire est maintenant le primaire, mais l'ancien primaire est arrêté et pourrait rester arrêté. Pour revenir à un fonctionnement normal, un serveur secondaire doit être recréé, soit sur l'ancien système primaire quand il redevient disponible, ou sur un troisième, peut-être nouveau, système. L'utilitaire pg_rewind peut être utilisé pour accélérer ce processus sur de gros clusters. Une fois que ceci est effectué, le primaire et le secondaire peuvent être considérés comme ayant changé de rôle. Certaines personnes choisissent d'utiliser un troisième serveur pour fournir une sauvegarde du nouveau primaire jusqu'à ce que le nouveau serveur secondaire soit recréé, bien que ceci complique visiblement la configuration du système et les procédures d'exploitation.

Par conséquent, basculer du primaire vers le serveur secondaire peut être rapide mais requiert du temps pour re-préparer le cluster de failover. Une bascule régulière du primaire vers le secondaire est utile, car cela permet une période d'interruption de production sur chaque système pour maintenance. Cela vous permet aussi pour vous assurer que votre mécanisme de bascule fonctionnera réellement quand vous en aurez besoin. Il est conseillé que les procédures d'administration soient écrites.

Si vous avez opté pour la synchronisation du slot de réplication logique (voir Section 47.2.3), alors avant de basculer vers le serveur secondaire, il est recommandé de vérifier si les slots de réplication synchronisés sur le serveur secondaire sont prêts pour basculer. Ceci peut se faire en suivant les étapes décrites dans Section 29.3.

Pour déclencher une bascule failover sur un serveur secondaire en log-shipping, exécutez pg_ctl promote ou appelez pg_promote(). Si vous configurez des serveurs utilisés uniquement pour décharger le primaire des requêtes en lecture seule, et donc pas pour de la haute disponibilité, vous n'avez pas besoin de promouvoir un secondaire.