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

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

Commutation et basculement avec la réplication pglogical

Sélectionnez une version de la documentation :

Cette page explique comment effectuer un basculement et une reprise après sinistre 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 true ni une réplication 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.

Basculer avec la réplication pglogical

La commutation est un processus contrôlé utilisé pour inverser les rôles entre les bases de données du fournisseur et de l'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 capacité 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.

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

Empêchez l'application d'écrire dans le système du 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 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 permutation.

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 fournisseur :
1. Arrêtez l'abonnement 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 pour un nouvel abonné dans la nouvelle base de données des abonnés.
5. Redirigez les applications vers le nouveau fournisseur.
Arrêtez l'abonnement sur 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 étape n'est pas nécessaire 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 des abonnés, qui était auparavant la base de données des fournisseurs, créez le nouvel abonnement avec l'option synchronize_data définie sur false pour éviter le chargement initial du tableau :

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 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 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 d'abonné.

Supprimer l'ancien fournisseur et l'ancien abonnement

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

Supprimez l'ancien abonnement auprès du 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 le basculement sans temps d'arrêt ni perte de données 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, pensez à 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 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 commit 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 se produise 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 du 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 du fournisseur initiale.

Vous devez ajouter un nouvel abonné auprès du fournisseur d'origine. Consultez Créer un nœud et un abonnement sur la base de données abonnée AlloyDB Omni pour créer un abonné en veillant à ce que le paramètre synchronize_data de la commande pglogical.create_subscription soit défini sur false. Cela évite la copie initiale des données de la table.

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 en sorte que l'application utilise 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 des abonnés basculée, vous devez désactiver l'abonnement. Cela permet de s'assurer 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');