Utiliser la réplication entre centres de données

Sélectionnez une version de la documentation :

Cette page explique comment utiliser la réplication entre centres de données en créant et en utilisant des clusters de bases de données secondaires dans Kubernetes. Pour obtenir une présentation conceptuelle de la réplication entre centres de données, consultez [À propos de la réplication entre centres de données](/alloydb/omni/kubernetes/16.3.0/docs/cross-data-center-replication/about-cross-data-center-replication). ## Avant de commencer {: #before-you-begin } - Assurez-vous de disposer d'une connectivité réseau fiable et à faible latence entre les centres de données principal et secondaire, ce qui est essentiel pour que la réplication entre centres de données fonctionne efficacement. - [Installez](/alloydb/omni/kubernetes/16.3.0/docs/deploy-kubernetes) la dernière version de l'opérateur AlloyDB Omni pour déployer AlloyDB Omni sur un cluster Kubernetes dans le centre de données principal et un cluster Kubernetes dans le centre de données secondaire. La réplication entre centres de données est compatible avec l'opérateur AlloyDB Omni version 1.5.0 ou ultérieure. - [Créez un cluster de bases de données AlloyDB Omni](/alloydb/omni/kubernetes/16.3.0/docs/deploy-kubernetes#create) sur le cluster Kubernetes dans le centre de données principal. - Assurez-vous que les serveurs de base de données principal et de secours de votre cluster de bases de données principal disposent d'un espace de journalisation WAL (Write-Ahead Logging) suffisant pour accueillir les fichiers WAL requis pour la réplication vers le cluster secondaire. Toutes les données qui n'ont pas encore été répliquées dans le cluster secondaire sont stockées dans le cluster principal sous forme de fichiers WAL. Par conséquent, en fonction de la vitesse de connexion entre les clusters principal et secondaire, vous devrez peut-être disposer d'un espace disque supplémentaire à cet effet. ## Créer un cluster de bases de données secondaire {: #secondary-db-cluster-instance } Pour créer un cluster de bases de données secondaire AlloyDB Omni et activer la réplication à partir de votre cluster de bases de données principal, procédez comme suit :

  1. Assurez-vous que la connectivité externe est activée sur votre cluster de bases de données principal AlloyDB Omni. Si la connectivité externe n'est pas activée, ajoutez les éléments suivants à la section "spec" du fichier manifeste du cluster de bases de données :

    ...
spec:
  ...
  allowExternalIncomingTraffic: true

  2. Pour utiliser la réplication entre centres de données avec un cluster de bases de données principal pour lequel la haute disponibilité est activée, vérifiez que le champ replayReplicationSlotsOnStandbys est activé sur le cluster de bases de données principal :

    ...
spec:
  ...
  availability:
    ...
    replayReplicationSlotsOnStandbys: true

    L'activation de ce champ, ainsi que de logReplicationSlots expliqué à l'étape suivante, synchronise l'emplacement de réplication utilisé par le cluster de bases de données secondaire avec toutes les instances de secours à haute disponibilité. Cette configuration permet à la nouvelle instance principale à haute disponibilité de conserver tous les fichiers WAL (Write-Ahead Logging) qui n'ont pas encore été utilisés par le cluster de bases de données secondaire après un basculement ou une commutation, ce qui lui permet de reprendre la réplication sans interruption.

  3. Pour activer la réplication sur votre cluster de bases de données principal, appliquez un fichier manifeste semblable à celui-ci à votre cluster Kubernetes sur le centre de données principal :

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-DB_CLUSTER_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-DB_CLUSTER_NAME
    logReplicationSlot: true

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAME : nom du cluster de bases de données, par exemple, dbc-1.
    • ENCODED_PASSWORD : mot de passe de l'utilisateur de la base de données à utiliser pour la réplication à partir des bases de données secondaires, encodé sous forme de chaîne base64 (par exemple, Q2hhbmdlTWUxMjM= for ChangeMe123). La valeur par défaut est alloydbreplica.
    • REPLICATION_NAME : nom de la réplication, par exemple, replication-1.
    • LOG_REPLICATION_SLOT : données de l'emplacement de réplication du journal dans les fichiers WAL. Pour activer cette option, définissez sa valeur sur true. La valeur par défaut est false.

    Il est recommandé d'activer l'option logReplicationSlot avec un cluster de bases de données principal pour lequel la haute disponibilité est activée afin de garantir que la réplication peut continuer à fonctionner après un basculement ou une commutation.

    Attendez que l'état de la réplication soit prêt.

  4. Pour obtenir les informations de connexion en amont utilisées pour configurer la réplication sur le cluster de bases de données secondaire, exécutez la commande suivante :

    kubectl get replication REPLICATION_NAME
kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

    Voici un exemple de sortie :

      {
    "host": "35.230.32.36",
    "password": {
      "name": "ha-rep-pw-dbc-1"
    },
    "port": 5432,
    "replicationSlotName": "dbc_1_replication_1",
    "username": "alloydbreplica"
  }
  5. Notez la sortie, car vous en aurez besoin pour activer la réplication sur le cluster de bases de données secondaire à l'étape suivante.

  6. Créez un cluster AlloyDB Omni sur votre cluster Kubernetes dans le centre de données secondaire avec une configuration identique à celle de votre cluster de bases de données principal.

  7. Assurez-vous que la connectivité externe est activée sur votre cluster de bases de données secondaire AlloyDB Omni.

  8. Si la connectivité externe n'est pas activée, ajoutez les éléments suivants à la section "spec" de son fichier manifeste :

    ...
spec:
  ...
  allowExternalIncomingTraffic: true
  9. Pour activer la réplication sur votre cluster de bases de données secondaire, appliquez un fichier manifeste semblable à celui-ci à votre cluster Kubernetes sur le centre de données secondaire :

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  downstream:
    host: PRIMARY_HOST
    port: PRIMARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    replicationSlotName: PRIMARY_REPLICATION_SLOT
    control: setup

    Remplacez les éléments suivants :

    • SECONDARY_DB_CLUSTER_NAME : nom du cluster de bases de données secondaire, par exemple, dbc-2.
    • ENCODED_PASSWORD : mot de passe de l'utilisateur de la base de données à utiliser pour la réplication du cluster de bases de données principal, encodé sous forme de chaîne base64 (par exemple, Q2hhbmdlTWUxMjM= for ChangeMe123). La valeur par défaut est alloydbreplica.
    • SECONDARY_REPLICATION_NAME : nom de la réplication, par exemple, `replication-2`.
    • PRIMARY_HOST : point de terminaison de connexion du cluster de bases de données principal à partir de la sortie de l'étape 3 auquel la base de données secondaire peut accéder pour la réplication.
    • PRIMARY_PORT : port de connexion du cluster de bases de données principal à partir de la sortie de l'étape 3 auquel la base de données secondaire peut accéder pour la réplication.
    • PRIMARY_REPLICATION_SLOT : nom de l'emplacement de réplication sur le cluster de bases de données principal à partir de la sortie de l'étape 3 que la base de données secondaire peut utiliser pour la réplication.

Afficher la réplication sur le cluster de bases de données secondaire

Pour afficher des informations détaillées sur un cluster de bases de données secondaire AlloyDB Omni et son état de réplication, exécutez les commandes suivantes :

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Lorsque le cluster de bases de données secondaire est correctement configuré et qu'il dispose d'une réplication en flux continu à partir du cluster de bases de données principal, l'état de la réplication est à la fois prêt et sain.

Promouvoir un cluster de bases de données secondaire

Avant de promouvoir un cluster de bases de données secondaire, procédez comme suit pour vérifier que le cluster de bases de données secondaire a appliqué toutes les transactions reçues du cluster de bases de données principal :

  • Vérifiez l'état de la réplication du cluster de bases de données secondaire pour vous assurer qu'il est à la fois prêt et sain.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Arrêtez toutes les opérations en écriture sur le cluster de bases de données principal. Exécutez la requête suivante sur votre cluster de bases de données principal pour vérifier le délai de réplication de la base de données secondaire. Vérifiez que le résultat affiche un délai minimal.

    Une valeur de délai de 0 est idéale. Si le délai est supérieur à 0, vous pouvez toujours promouvoir le cluster de bases de données secondaire, au risque de perdre certaines transactions récentes déjà validées sur le cluster de bases de données principal.

    psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

Pour promouvoir un cluster de bases de données secondaire en cluster de bases de données principal, définissez le champ control du fichier manifeste de réplication de votre cluster de bases de données secondaire sur promote, puis appliquez-le à votre cluster Kubernetes sur le centre de données secondaire.

apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  downstream:
    host: PRIMARY_HOST
    port: PRIMARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    replicationSlotName: PRIMARY_REPLICATION_SLOT
    control: promote

Effectuer une commutation

Avant d'effectuer une commutation, vérifiez que les clusters de bases de données principal et secondaire appartenant aux deux centres de données sont en ligne et que les clusters de bases de données sont en bon état.

Pour garantir la cohérence des données de vos clusters de bases de données principal et secondaire lors de la commutation, procédez comme suit pour vérifier que le cluster de bases de données secondaire a appliqué toutes les transactions reçues du cluster de bases de données principal :

  • Vérifiez l'état de la réplication du cluster de bases de données secondaire pour vous assurer qu'il est à la fois prêt et sain.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Arrêtez toutes les opérations en écriture sur le cluster de bases de données principal. Exécutez la requête suivante sur votre cluster de bases de données principal pour vérifier le délai de réplication de la base de données secondaire. Vérifiez que le résultat affiche une valeur de délai de 0.

    psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

Pour effectuer une commutation, procédez comme suit :

  1. Pour convertir votre cluster de bases de données secondaire AlloyDB Omni en cluster de bases de données principal, mettez à jour son fichier manifeste de réplication sur votre cluster Kubernetes dans le centre de données secondaire comme suit :

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

    Attendez que l'état de la réplication soit prêt.

  2. Pour obtenir les informations de connexion en amont pour la réplication, exécutez la commande suivante :

    kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

    Voici un exemple de sortie :

      {
    "host": "34.23.207.137",
    "password": {
      "name": "ha-rep-pw-dbc-2"
    },
    "port": 5432,
    "replicationSlotName": "dbc_2_replication_2",
    "username": "alloydbreplica"
  }

  3. Pour convertir votre cluster de bases de données principal AlloyDB Omni en cluster de bases de données secondaire, mettez à jour son fichier manifeste de réplication sur votre cluster Kubernetes dans le centre de données principal comme suit :

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-DB_CLUSTER_NAME
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  downstream:
    host: SECONDARY_HOST
    port: SECONDARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-DB_CLUSTER_NAME
    replicationSlotName: SECONDARY_REPLICATION_SLOT
    control: rewind

    Attendez que l'état de la réplication devienne prêt et sain.

  4. Pour vérifier l'état de la réplication, utilisez :

    kubectl get replication REPLICATION_NAME