Trabajar con la replicación entre centros de datos

Selecciona una versión de la documentación:

En esta página se describe cómo usar la replicación entre centros de datos creando y trabajando con clústeres de bases de datos secundarios en Kubernetes.

Para obtener una descripción general conceptual de la réplica entre centros de datos, consulta Información sobre la réplica entre centros de datos.

Antes de empezar

  • Asegúrate de que la conectividad de red entre los centros de datos principal y secundario sea fiable y tenga una latencia baja, ya que es fundamental para que la replicación entre centros de datos funcione correctamente.
  • Instala la versión más reciente del operador AlloyDB Omni para desplegar AlloyDB Omni en un clúster de Kubernetes del centro de datos principal y en un clúster de Kubernetes del centro de datos secundario. La replicación entre centros de datos se admite en la versión 1.5.0 o posterior del operador de AlloyDB Omni.
  • Crea un clúster de bases de datos de AlloyDB Omni en el clúster de Kubernetes del centro de datos principal.
  • Asegúrate de que los servidores de bases de datos principal y de espera del clúster de bases de datos principal tengan suficiente espacio de registro anticipado (WAL) para alojar los archivos WAL necesarios para la replicación en el clúster secundario. Los datos que aún no se hayan replicado en el clúster secundario se almacenan en el clúster principal como archivos WAL, por lo que, en función de la velocidad de conexión entre los clústeres principal y secundario, es posible que necesites espacio en disco adicional para este fin.

Crear un clúster de base de datos secundario

Para crear un clúster de base de datos secundaria de AlloyDB Omni y habilitar la replicación desde tu clúster de base de datos principal, sigue estos pasos:

Kubernetes

  1. Asegúrate de que la conectividad externa esté habilitada en tu clúster de base de datos principal de AlloyDB Omni. Si la conectividad externa no está habilitada, añada lo siguiente a la sección spec del manifiesto del clúster de bases de datos:

      kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true

  2. Para usar la replicación entre centros de datos con un clúster de bases de datos principal que tenga habilitada la alta disponibilidad, comprueba que el campo replayReplicationSlotsOnStandbys esté habilitado en el clúster de bases de datos principal:

    kind: DBCluster
  spec:
    availability:
      replayReplicationSlotsOnStandbys: true

    Si habilitas este campo junto con el logReplicationSlots que se explica en el siguiente paso, se sincronizará la ranura de replicación que usa el clúster de la base de datos secundaria con todos los servidores de reserva de alta disponibilidad. Esta configuración ayuda a que el nuevo nodo principal de alta disponibilidad conserve los archivos de registro de escritura anticipada (WAL) que aún no haya consumido el clúster de base de datos secundario después de una conmutación por error o una conmutación, lo que le permite reanudar la replicación sin interrupciones.

  3. Para habilitar la replicación en tu clúster de base de datos principal, aplica un manifiesto similar al siguiente a tu clúster de Kubernetes en el centro de datos 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
     logReplicationSlot: LOG_REPLICATION_SLOT

    Haz los cambios siguientes:

    • DB_CLUSTER_NAME: el nombre del clúster de la base de datos (por ejemplo, dbc-1).
    • ENCODED_PASSWORD: contraseña del usuario de la base de datos que se usará para la replicación desde bases de datos secundarias, codificada como una cadena de Base64 (por ejemplo, Q2hhbmdlTWUxMjM= for ChangeMe123). El valor predeterminado es alloydbreplica.
    • REPLICATION_NAME: el nombre de la réplica (por ejemplo, replication-1).
    • LOG_REPLICATION_SLOT: registra los datos de la ranura de replicación en los archivos WAL. Para habilitar esta opción, asigna el valor true. El valor predeterminado es false.

    Se recomienda habilitar la opción logReplicationSlot con el clúster de base de datos principal que tenga habilitada la alta disponibilidad para asegurarse de que la replicación pueda seguir funcionando después de una conmutación por error o una conmutación.

    Espera a que el estado de la réplica esté listo.

  4. Para obtener la información de la conexión upstream que se usa para configurar la replicación en el clúster de base de datos secundario, ejecuta el siguiente comando:

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

    La salida de ejemplo es similar a la siguiente:

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

  5. Anota el resultado, ya que lo necesitarás para habilitar la replicación en el clúster de base de datos secundario en el siguiente paso.

  6. Crea un clúster de AlloyDB Omni en tu clúster de Kubernetes del centro de datos secundario con una configuración idéntica a la de tu clúster de base de datos principal.

  7. Asegúrate de que la conectividad externa esté habilitada en tu clúster de base de datos secundaria de AlloyDB Omni.

  8. Si la conectividad externa no está habilitada, añade lo siguiente a la sección spec de su archivo de manifiesto:

     allowExternalIncomingTraffic: true

  9. Para habilitar la replicación en tu clúster de base de datos secundaria, aplica un manifiesto similar al siguiente a tu clúster de Kubernetes en el centro de datos secundario:

      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

    Haz los cambios siguientes:

    • SECONDARY_DB_CLUSTER_NAME: el nombre del clúster de base de datos secundario (por ejemplo, dbc-2).
    • ENCODED_PASSWORD: la contraseña del usuario de la base de datos que se usará para replicar el clúster de la base de datos principal, codificada como una cadena base64. Por ejemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. El valor predeterminado es alloydbreplica.
    • SECONDARY_REPLICATION_NAME: el nombre de la réplica (por ejemplo, replication-2).
    • PRIMARY_HOST: el endpoint de conexión del clúster de la base de datos principal del resultado del paso 3 al que puede acceder la base de datos secundaria para la replicación.
    • PRIMARY_PORT: el puerto de conexión del clúster de la base de datos principal de la salida del paso 3 al que puede acceder la base de datos secundaria para la replicación.
    • PRIMARY_REPLICATION_SLOT: el nombre del espacio de replicación en el clúster de la base de datos principal de la salida del paso 3 que la base de datos secundaria puede usar para la replicación.

Ver la replicación en el clúster de base de datos secundario

Para ver información detallada sobre un clúster de base de datos secundaria de AlloyDB Omni y su estado de replicación, ejecuta los siguientes comandos:

Kubernetes 

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Cuando el clúster de base de datos secundario se ha configurado correctamente y tiene una replicación de streaming desde el clúster de base de datos principal, el estado de la replicación es "Ready" (Listo) y "Healthy" (Correcto).

Promocionar un clúster de base de datos secundario

Antes de promover un clúster de base de datos secundario, sigue estos pasos para verificar que el clúster de base de datos secundario haya aplicado todas las transacciones recibidas del clúster de base de datos principal:

Kubernetes

  • Comprueba el estado de la réplica del clúster de la base de datos secundaria para asegurarte de que esté listo y en buen estado.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Detener todas las escrituras en el clúster de base de datos principal. Ejecuta la siguiente consulta en tu clúster de base de datos principal para comprobar el retraso de la réplica de la base de datos secundaria. Confirma que el resultado muestra un retraso mínimo.

    Lo ideal es que el valor de latencia sea 0. Si la latencia es superior a 0, puedes seguir promocionando el clúster de base de datos secundario, pero corres el riesgo de perder algunas transacciones recientes que ya se hayan confirmado en el clúster de base de datos 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;'

Para promover un clúster de base de datos secundario a clúster de base de datos principal, actualice el campo control del manifiesto de replicación del clúster de base de datos secundario a promote y aplíquelo en su clúster de Kubernetes en el centro de datos secundario.

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

Hacer un cambio

Antes de realizar un cambio, compruebe que los clústeres de bases de datos principal y secundario que pertenecen a ambos centros de datos estén online y que los clústeres de bases de datos estén en buen estado.

Para asegurar la coherencia de los datos de los clústeres de bases de datos principal y secundario durante el cambio, sigue estos pasos para verificar que el clúster de bases de datos secundario haya aplicado todas las transacciones recibidas del clúster de bases de datos principal:

Kubernetes

  • Comprueba el estado de la réplica del clúster de la base de datos secundaria para asegurarte de que esté listo y en buen estado.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Detener todas las escrituras en el clúster de base de datos principal. Ejecuta la siguiente consulta en tu clúster de base de datos principal para comprobar el retraso de la réplica de la base de datos secundaria. Comprueba que el resultado muestre un valor de latencia 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;'

Para hacer un cambio, sigue estos pasos:

Kubernetes

  1. Para convertir tu clúster de base de datos secundaria de AlloyDB Omni en un clúster de base de datos principal, actualiza su manifiesto de replicación en tu clúster de Kubernetes del centro de datos secundario de la siguiente manera:

       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

    Espera a que el estado de la réplica esté listo.

  2. Para obtener la información de conexión upstream para la replicación, ejecuta el siguiente comando:

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

    La salida de ejemplo es similar a la siguiente:

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

  3. Para convertir tu clúster de base de datos principal de AlloyDB Omni en un clúster de base de datos secundario, actualiza su manifiesto de replicación en tu clúster de Kubernetes en el centro de datos principal de forma similar a la siguiente:

        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

    Espera a que el estado de la réplica sea "Listo" y "Correcto".

  4. Para verificar el estado de la replicación, usa lo siguiente:

    kubectl get replication REPLICATION_NAME