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 inter-data centers, consultez À propos de la réplication inter-data centers.

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 sur un cluster Kubernetes dans le centre de données secondaire.
  • Créez un cluster de bases 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 "spec" du fichier manifeste du cluster de bases 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-dessous à 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 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.

    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 secondaires, exécutez la commande suivante :

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

    Voici un exemple de résultat :

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

  4. Notez le résultat, car vous en aurez besoin pour activer la réplication sur le cluster de bases 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 "spec" 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-dessous à 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é 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 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

Lorsque le cluster de bases de données secondaire est correctement configuré et qu'il effectue 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 secondaires

Avant de promouvoir un cluster de bases de données secondaires, procédez comme suit pour vérifier qu'il 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 bases de données secondaires 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 dans 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 présente un décalage minimal.

    Une valeur de décalage de 0 est idéale. Si le décalage est supérieur à 0, vous pouvez toujours promouvoir le cluster de bases de données secondaires, 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 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 d'effectuer un basculement, vérifiez que les clusters de bases de données principaux et secondaires appartenant aux deux centres de données sont en ligne et 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 bascule, 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 bases de données secondaires 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 dans 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 une permutation, procédez comme suit :

Kubernetes

  1. Pour convertir votre cluster de bases de données secondaires 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
   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

    Voici un exemple de résultat :

     {
   "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 devienne "Prêt" et "OK".

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

    kubectl get replication REPLICATION_NAME