Cette page décrit la version 15.5.5 d'AlloyDB Omni à l'aide de l'option de déploiement Kubernetes. Choisissez une autre option de déploiement.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Commutation et basculement avec la réplication pglogical

Sélectionnez une version de la documentation :

Cette page explique comment effectuer une commutation et un basculement avec la réplication pglogical.

Avant de commencer

Une fois la réplication pglogical configurée et une solution viable de haute disponibilité (HA) et de reprise après sinistre (DR) mise en place, et en sachant que la réplication logique ne fournit pas une réplication true et complète de tous les objets de base de données, vous devez tester cette configuration avant de commencer à l'utiliser.

Pour en savoir plus sur l'extension pglogical, consultez À propos de pglogical.

Pour en savoir plus sur la réplication des données à l'aide de pglogical, consultez Répliquer des données entre AlloyDB pour PostgreSQL et AlloyDB Omni et Répliquer des données entre AlloyDB Omni et d'autres bases de données.

Commutation avec la réplication pglogical

La commutation est un processus contrôlé utilisé pour inverser les rôles entre les bases de données de fournisseur et d'abonné. Lorsque vous effectuez une commutation, les rôles des deux bases de données, fournisseur et abonné, sont inversés. Le fournisseur devient l'abonné et l'abonné devient le fournisseur.

Cette fonctionnalité de commutation est importante pour les mises à niveau du système d'exploitation, les mises à niveau de PostgreSQL ou les tests de basculement.

Pour ce faire dans les configurations de réplication unidirectionnelle, vous devez configurer une nouvelle relation fournisseur/abonné et supprimer l'ancienne.

Créer la nouvelle configuration fournisseur/abonné

Empêchez l'application d'écrire dans le système de fournisseur pour éviter d'autres modifications de la base de données, puis vérifiez le décalage de réplication pour vous assurer que toutes les transactions sont rejouées sur le nœud d'abonné :

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Lorsque tous les champs de décalage affichent zéro, la réplication est à jour et la base de données est prête pour une commutation.

Le résultat ressemble à ce qui suit :

-[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

Convertissez la base de données d'abonné en base de données de fournisseur :
1. Arrêtez l'abonnement d'abonné existant.
2. Ajoutez l'ensemble de réplication, si nécessaire.
3. Ajoutez les tables nécessaires à l'ensemble de réplication.
4. Créez un abonnement d'abonné dans la nouvelle base de données d'abonné.
5. Redirigez les applications vers le nouveau fournisseur.
Arrêtez l'abonnement sur la base de données d'abonné existante, qui devient le nouveau fournisseur :
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Facultatif) Créez un ensemble de réplication qui correspond à la définition de la base de données de fournisseur d'origine. Cette étape n'est pas obligatoire si vous utilisez les ensembles de réplication par défaut :
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Ajoutez des tables à cet ensemble de réplication :
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
Remplacez les éléments suivants :
- REPLICATION_SET_NAME : nom de l'ensemble de réplication.
- TABLE_NAME : nom de table d'un propriétaire de schéma. Par exemple, ARRAY['public'].`

Dans la nouvelle base de données d'abonné, qui était auparavant la base de données de fournisseur, créez l'abonnement avec l'option synchronize_data définie sur false pour éviter le chargement initial de la table :

SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

Vérifiez si l'abonnement fonctionne sur le nœud de fournisseur :

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Si la réplication fonctionne, modifiez les chaînes de connexion de l'application pour utiliser la nouvelle base de données de fournisseur, puis redémarrez les niveaux d'application.

Si vous modifiez les données sur l'ancien nœud de fournisseur après l'arrêt de l'abonné, ces modifications ne sont pas répliquées et entraînent une perte de données. S'il existe des modifications de données non répliquées dans la base de données de fournisseur d'origine ou si le fournisseur d'origine, qui est le nouvel abonné, n'est pas dans un état cohérent avec la nouvelle base de données de fournisseur, qui est l'ancien abonné, vous devez créer complètement la nouvelle base de données d'abonné.

Supprimer l'ancien fournisseur et l'ancien abonnement

Si vous souhaitez une réplication unidirectionnelle, vous devez supprimer l'ancienne configuration fournisseur/abonné.

Supprimez l'ancien abonnement sur le nouveau fournisseur :

SELECT pglogical.drop_subscription('<subscription name>')

Supprimez l'ensemble de réplication sur le nouvel abonné ou supprimez toutes les tables de l'ensemble de réplication :

SELECT pglogical.drop_replication_set('<replication set name>')

SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

Réplication bidirectionnelle

Pour effectuer une commutation sans temps d'arrêt ou pour vous assurer qu'aucune donnée n'est perdue en raison de modifications de données non planifiées, vous devez utiliser la réplication bidirectionnelle. Lorsque vous implémentez la réplication bidirectionnelle, tenez compte de la résolution des conflits, sauf si des contrôles stricts sont en place pour empêcher l'accès en écriture aux deux nœuds en même temps.

Vous pouvez configurer la résolution des conflits à l'aide des paramètres pglogical.conflict_resolution suivants :

error : l'abonné s'arrête lorsqu'un conflit est détecté.
apply_remote: applique toujours les modifications entrantes, quelles que soient les données de la base de données d'abonné. Il s'agit du paramètre par défaut.
keep_local: ignore toujours les données entrantes en conflit et supprime la modification en conflit.
last_update_wins: la version des données avec le dernier code temporel de commit est celle qui est validée.
first_update_wins: la version des données avec le code temporel le plus ancien est celle qui est validée.

Pour configurer la réplication bidirectionnelle, configurez le fournisseur et l'abonné de sorte que la réplication s'effectue dans les deux sens. L'abonné d'origine devient également un fournisseur avec le même ensemble de réplication que le fournisseur d'origine. Consultez Créer une table et l'ajouter à l'ensemble de réplication par défaut sur la base de données de fournisseur AlloyDB pour PostgreSQL pour créer un ensemble de réplication qui duplique l'ensemble de réplication d'origine sur la base de données de fournisseur initiale.

Sur le fournisseur d'origine, vous devez ajouter un nouvel abonné. Consultez Créer un nœud et un abonnement sur la base de données d'abonné AlloyDB Omni pour créer un abonné en vous assurant que le synchronize_data paramètre pour la commande pglogical.create_subscription est défini sur false. Cela évite la copie initiale de la table de données.

Basculement avec la réplication pglogical

Le basculement se produit lorsque la base de données de fournisseur devient indisponible pour une raison quelconque et que vous devez basculer l'application pour qu'elle utilise la base de données d'abonné.

Pour éviter que des données en double ne soient appliquées accidentellement à la base de données d'abonné ayant basculé, vous devez désactiver l'abonnement. Cela garantit que les modifications d'un fournisseur restauré ne sont pas appliquées par erreur lorsque le fournisseur redevient disponible.

Arrêtez l'abonné, test_sub_1 :

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Vérifiez que l'état est défini sur disabled :

SELECT pglogical.show_subscription_status('test_sub_1');