This page shows documentation for version 15.5.5 of AlloyDB Omni.
See the latest AlloyDB Omni documentation.

Se usó la API de Cloud Translation para traducir esta página.

Trabaja con la replicación entre centros de datos

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

Para obtener una descripción general conceptual de la replicación entre centros de datos, consulta Acerca de la replicación entre centros de datos.

Antes de comenzar

Instala el operador de AlloyDB Omni versión 1.1.0 o una posterior para implementar AlloyDB Omni en un clúster de Kubernetes en el centro de datos principal y un clúster de Kubernetes en el centro de datos secundario.
Crea un clúster de base de datos de AlloyDB Omni en el clúster de Kubernetes del centro de datos principal.

Crea un clúster de base de datos secundario

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

Kubernetes

Asegúrate de que la conectividad externa esté habilitada en el clúster de base de datos principal de AlloyDB Omni. Si no está habilitada la conectividad externa, agrega lo siguiente a la sección de especificaciones del manifiesto del clúster de bases de datos:
```
  kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true
```
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
```
Reemplaza lo siguiente:
- DB_CLUSTER_NAME: Es el nombre del clúster de bases de datos, por ejemplo, dbc-1.
- ENCODED_PASSWORD: Es la 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 base64, por ejemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. El valor predeterminado es alloydbreplica.
- REPLICATION_NAME: Es el nombre de la réplica, por ejemplo, replication-1.
Espera a que el estado de replicación esté listo.

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

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

El resultado de muestra es similar al siguiente:

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

Toma nota del resultado, ya que lo necesitarás para habilitar la replicación en el clúster de bases de datos secundario en el siguiente paso.
Crea un clúster de AlloyDB Omni en tu clúster de Kubernetes en el centro de datos secundario con una configuración idéntica a la de tu clúster de base de datos principal.
Asegúrate de que la conectividad externa esté habilitada en el clúster de base de datos secundario de AlloyDB Omni.
Si no está habilitada la conectividad externa, agrega lo siguiente a la sección de especificaciones de su manifiesto:
```
 allowExternalIncomingTraffic: true
```
Para habilitar la replicación en el clúster de bases de datos secundario, 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
```
Reemplaza lo siguiente:
- SECONDARY_DB_CLUSTER_NAME: Es el nombre del clúster de base de datos secundario, por ejemplo, dbc-2.
- ENCODED_PASSWORD: Es la contraseña del usuario de la base de datos que se usará para replicar el clúster de base de datos principal, codificada como una cadena base64, por ejemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. El valor predeterminado es alloydbreplica.
- SECONDARY_REPLICATION_NAME: Es el nombre de la réplica, por ejemplo, replication-2.
- PRIMARY_HOST: Es el extremo 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_PORT: Es 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: Es el nombre del espacio de replicación en el clúster de la base de datos principal del resultado del paso 3 que la base de datos secundaria puede usar para la replicación.

Cómo ver la replicación en el clúster de bases 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 bases de datos secundario se configura correctamente y tiene replicación de transmisión desde el clúster de bases de datos principal, el estado de replicación está listo y en buen estado.

Asciende un clúster de base de datos secundario

Antes de promocionar un clúster de bases de datos secundario, 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

Verifica el estado de replicación 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
```
Detén todas las operaciones de escritura en el clúster de la base de datos principal. Ejecuta la siguiente consulta en tu clúster de base de datos principal para verificar el retraso de replicación de la base de datos secundaria. Confirma que el resultado muestre un retraso mínimo.

Un valor de retraso de 0 es ideal. Si el retraso es mayor que 0, puedes promocionar el clúster de bases de datos secundario, con el riesgo de perder algunas transacciones recientes que ya se confirmaron en el clúster de bases 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 promocionar un clúster de base de datos secundario a uno principal, actualiza el campo control del manifiesto de replicación del clúster de base de datos secundario a promote y aplícalo en tu 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

Realiza un cambio

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

Para garantizar la coherencia de los datos de tus clústeres de bases de datos principales y secundarios 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

Verifica el estado de replicación 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
```
Detén todas las operaciones de escritura en el clúster de la base de datos principal. Ejecuta la siguiente consulta en tu clúster de base de datos principal para verificar el retraso de replicación de la base de datos secundaria. Confirma que el resultado muestre un valor de retraso 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 realizar un cambio, completa los siguientes pasos:

Kubernetes

Para convertir tu clúster de base de datos secundario de AlloyDB Omni en un clúster de base de datos principal, actualiza su manifiesto de replicación en tu clúster de Kubernetes en el 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 replicación esté listo.

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

El resultado de muestra es similar al siguiente:

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

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 la siguiente manera:

    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 replicación esté listo y en buen estado.

Para verificar el estado de la replicación, usa lo siguiente:
```
kubectl get replication REPLICATION_NAME
```