Cette page présente la documentation de la version 15.7.0 d'AlloyDB Omni.
Accédez à Versions de la documentation AlloyDB Omni pour choisir une autre version.

Cette page a été traduite par l'API Cloud Translation.

Commutation et basculement avec la réplication pglogical

Cette page explique comment effectuer un basculement et un basculement en cas de défaillance avec la réplication pglogical.

Avant de commencer

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

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

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

Basculer avec la réplication pglogical

Le switchover est un processus contrôlé qui permet de changer de rôle entre les bases de données du fournisseur et de l'abonné. Lorsque vous effectuez un basculement, 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 basculement 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 relation fournisseur/abonné.

Créer la nouvelle configuration du fournisseur/de l'abonné

Empêchez l'application d'écrire dans le système du fournisseur pour éviter toute autre modification 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 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 un basculement.

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 des abonnés en base de données de fournisseurs:
1. Arrêtez l'abonnement de l'abonné existant.
2. Ajoutez le jeu de réplication, si nécessaire.
3. Ajoutez les tables nécessaires à l'ensemble de réplication.
4. Créez un abonnement dans la nouvelle base de données des abonnés.
5. Rediriger les applications vers le nouveau fournisseur.
Arrêtez l'abonnement dans la base de données d'abonnés existante, qui devient le nouveau fournisseur:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Facultatif) Créez un ensemble de réplication correspondant à la définition de la base de données du fournisseur d'origine. Cette opération n'est pas requise 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 la table d'un propriétaire de schéma. Par exemple, ARRAY['public'].

Dans la nouvelle base de données d'abonnés, qui était auparavant la base de données du fournisseur, créez l'abonnement avec l'option synchronize_data définie sur false pour empêcher 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 du 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 du fournisseur, puis redémarrez les niveaux d'application.

Si vous modifiez les données sur l'ancien nœud du fournisseur après l'arrêt de l'abonné, ces modifications ne sont pas répliquées, ce qui entraîne une perte de données. Si des modifications de données non répliquées sont apportées à la base de données du 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 du fournisseur, qui est l'ancien abonné, vous devez créer complètement la nouvelle base de données des abonnés.

Supprimer l'ancien fournisseur et l'ancien abonnement

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

Supprimez l'ancien abonnement auprès du nouveau fournisseur:
```
SELECT pglogical.drop_subscription('<subscription name>')
```

Supprimez le jeu de réplication sur le nouvel abonné ou supprimez toutes les tables du jeu 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 la transition 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, réfléchissez à 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: appliquez toujours les modifications entrantes, quelles que soient les données de la base de données des abonnés. 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 validation est celle qui est validée.
first_update_wins: la version des données avec l'horodatage 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 la section Créer une table et l'ajouter au jeu de réplication par défaut dans la base de données du fournisseur AlloyDB sur Google Cloud pour créer un jeu de réplication qui duplique le jeu de réplication d'origine dans la base de données du fournisseur initiale.

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

Basculement avec la réplication pglogical

Le basculement se produit lorsque la base de données du fournisseur devient indisponible pour une raison quelconque, et que vous devez faire passer l'application à la base de données de l'abonné.

Pour éviter que des données en double ne soient appliquées accidentellement à la base de données d'abonnés en cas de basculement, vous devez désactiver l'abonnement. Cela garantit que les modifications apportées par 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');