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 copie 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.
/* 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 52.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.
/* 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.
/* 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.
Les deux premières étapes dans la procédure ci-dessus ont pour cible un abonné PostgreSQL. Il est recommandé d'exécuter ces étapes sur chaque nœud abonné, qui sera servi par le secondaire désigné après la bascule, pour obtenir la liste complète des slots de réplication. Cette liste peut ensuite être vérifiée à l'étape 3 pour s'assurer que la bascule est prête. Concernant les abonnées non PostgreSQL, ils peuvent utiliser leur propre méthode pour identifier les slots de réplication utilisés par leurs abonnements respectifs.
Dans certains cas, comme une bascule planifiée, il est nécessaire de confirmer que tous les abonnées, PostgreSQL ou autres, seront capables de continuer la réplication après la bascule d'un serveur secondaire donné. Dans de tels cas, utilisez la requête suivante au lieu de réaliser les deux premières étapes ci-dessus, pour identifier les slots de réplication du primaire qui ont besoin d'être synchronisés sur le secondaire qui sera promu. Cette requête renvoie les slots de réplication adéquats associés avec tous les abonnements dont l'option failover est activée.
/* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots
FROM pg_replication_slots r
WHERE r.failover AND NOT r.temporary;
slots
-------
{'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'}
(1 row)