Utiliser la réplication entre centres de données

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.

Avant de commencer

  • Installez l'opérateur AlloyDB Omni version 1.1.0 ou ultérieure 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.
  • Créez un cluster de base de données AlloyDB Omni sur le cluster Kubernetes du centre de données principal.

Créer un cluster de base de données secondaire

Pour créer un cluster de base de données secondaire AlloyDB Omni et activer la réplication à partir de votre cluster de base de données principal, procédez comme suit:

Kubernetes

  1. Assurez-vous que la connectivité externe est activée sur votre cluster de base de données principal AlloyDB Omni. Si la connectivité externe n'est pas activée, ajoutez ce qui suit à la section de spécifications du fichier manifeste du cluster de base de données:

      kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true

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

    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
 upstream:
   password:
     name: ha-rep-pw-DB_CLUSTER_NAME

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAME: nom du cluster de base 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 de bases de données secondaires, encodé en tant que 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).

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

  3. 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

    Un exemple de sortie ressemble à ceci:

      {
   "host": "35.230.32.36",
   "password": {
     "name": "ha-rep-pw-dbc-1"
   },
   "port": 5432,
   "replicationSlotName": "dbc_1_replication_1",
   "username": "alloydbreplica"
  }

  4. Notez la sortie, car vous en aurez besoin pour activer la réplication sur le cluster de base de données secondaire à l'étape suivante.

  5. 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 base de données principal.

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

  7. Si la connectivité externe n'est pas activée, ajoutez ce qui suit à la section de spécifications de son fichier manifeste:

     allowExternalIncomingTraffic: true

  8. Pour activer la réplication sur votre cluster de base de données secondaire, appliquez un fichier manifeste semblable à celui-ci à votre cluster Kubernetes dans le centre de données secondaire:

      apiVersion: v1
  kind: Secret
  metadata:
    name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  type: Opaque
  data:
    rep-user-pw: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: Replication
  metadata:
    name: SECONDARY_REPLICATION_NAME
  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 base 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 base de données principal, encodé en tant que 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 base 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 base 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 base 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 base de données secondaire

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

Kubernetes 

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Une fois le cluster de base de données secondaire configuré et la réplication en streaming du cluster de base de données principal effectuée, l'état de la réplication est à la fois prêt et correct.

Promouvoir un cluster de base de données secondaire

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

Kubernetes

  • Vérifiez l'état de la réplication du cluster de base de données secondaire pour vous assurer qu'il est prêt et opérationnel.

    kubectl get replication SECONDARY_REPLICATION_NAME

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

    Une valeur de décalage de 0 est idéale. Si le délai est supérieur à 0, vous pouvez toujours promouvoir le cluster de base de données secondaire, au risque de perdre certaines transactions récentes déjà validées sur le cluster de base 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 base de données secondaire en cluster de base de données principal, mettez à jour le champ control (Contrôle) du fichier manifeste de réplication de votre cluster de base de données secondaire sur promote, puis appliquez-le à votre cluster Kubernetes dans le centre de données secondaire.

Kubernetes 

    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: SECONDARY_REPLICATION_NAME
    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 de procéder à un basculement, vérifiez que les clusters de base de données principaux et secondaires appartenant aux deux centres de données sont en ligne et qu'ils sont en bon état.

Pour garantir la cohérence des données de vos clusters de bases de données principaux et secondaires lors de la transition, 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:

Kubernetes

  • Vérifiez l'état de la réplication du cluster de base de données secondaire pour vous assurer qu'il est prêt et opérationnel.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Arrêtez toutes les opérations en écriture sur le cluster de base de données principal. Exécutez la requête suivante sur votre cluster de base de données principal pour vérifier le décalage de réplication de la base de données secondaire. Vérifiez que le résultat affiche une valeur de décalage 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 un basculement, procédez comme suit:

Kubernetes

  1. Pour convertir votre cluster de base de données secondaire AlloyDB Omni en cluster de base 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
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
    name: SECONDARY_REPLICATION_NAME
   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

    Un exemple de sortie ressemble à ceci:

     {
   "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 base de données principal AlloyDB Omni en cluster de base 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 soit prêt et correct.

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

    kubectl get replication REPLICATION_NAME