Pour permettre à des nœuds abonnés de continuer de répliquer les
données du nœud publieur même quand ce dernier tombe, il doit y
avoir un secondaire physique correspondant au nœud publieur. Les
slots logique du serveur primaire correspondant aux souscriptions
peuvent être synchronisés sur le serveur secondaire en précisant
failover = true
lors de la création de la souscription.
Voir Section 47.2.3
pour les détails. Activer le paramètre
failover
assure une transition directe de ces souscriptions après la promotion
du secondaire. Ils peuvent continuer à souscrire aux publications du
nouveau serveur primaire.
Comme la logique de synchronisation du slot copies de façon asynchrone,
il est nécessaire de confirmer que les slots de réplication doivent être
synchronisés vers le serveur secondaire avant l'exécution du failover.
Pour s'assurer d'un failover réussi, le serveur secondaire doit être en avance sur l'abonné. Ceci peut se faire en configurant
synchronized_standby_slots
.
Pour confirmer que le serveur secondaire est prêt pour un failover, suivez ces étapes pour vérifier que tous les slots de réplication logique nécessaires ont bien été synchronisés sur le serveur secondaire :
Sur le nœud abonné, utilisez la requête SQL suivante pour identifier les slots de réplication devant être synchronisés sur le secondaire que nous souhaitons promouvoir. Cette requête renverra les slots de réplication adéquats avec les souscriptions dont l'option failover est activée.
test_sub=# SELECT array_agg(quote_literal(s.subslotname)) AS slots FROM pg_subscription s WHERE s.subfailover AND s.subslotname IS NOT NULL; slots ------- {'sub1','sub2','sub3'} (1 row)
Sur le nœud abonné, utilisez la requête SQL suivante pour identifier les slots de synchronisation qui doivent être synchronisés sur le secondaire que nous planifions de promouvoir. Cette requête a besoin d'être exécutée sur chaque base qui inclut les souscriptions dont l'option failover a été activée. Notez que le slot de synchronisation de table doit être synchronisé vers le serveur secondaire seulement si la copie de table est terminée (Voir Section 51.55). Nous n'avons pas besoin de nous assurer que les slots de synchronisation de table sont synchronisés dans les autres scénarios car ceux-là seront soit supprimés soit re-créés sur le nouveau serveur primaire.
test_sub=# SELECT array_agg(quote_literal(slot_name) AS slots FROM ( SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_identifier) AS slot_name FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscription s WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover ); slots ------- {'pg_16394_sync_16385_7394666715149055164'} (1 row)
Vérifiez que les slots de réplication logique identifiés ci-dessus existent sur le serveur secondaire et sont prêt pour un failover.
test_standby=# SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS failover_ready FROM pg_replication_slots WHERE slot_name IN ('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'); slot_name | failover_ready --------------------------------------------+---------------- sub1 | t sub2 | t sub3 | t pg_16394_sync_16385_7394666715149055164 | t (4 rows)
Si tous les slots sont présents sur le serveur secondaire et que le
résultat (failover_ready
) de la requête SQL ci-dessus
vaut true
, alors les souscriptions existantes
pourront continuer leur travail avec les publications sur le nouveau
serveur primaire.