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 la versión 1.1.0 o posterior del operador de AlloyDB Omni para implementar AlloyDB Omni en un clúster de Kubernetes en el centro de datos principal y en 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 tu clúster de base de datos principal de AlloyDB Omni. Si la conectividad externa no está habilitada, agrega lo siguiente a la sección spec del manifiesto del clúster de base de datos:
kind: DBCluster spec: allowExternalIncomingTraffic: truePara usar la replicación entre centros de datos con un clúster de base de datos principal que tenga habilitada la HA, asegúrate de que los servidores de base de datos principal y en espera de tu clúster de base de datos principal tengan suficiente espacio de registro previo a la escritura (WAL) para alojar los archivos WAL necesarios para la replicación en el clúster secundario. Establece el tamaño del WAL para tu clúster de base de datos principal de AlloyDB Omni configurando la sección spec del manifiesto del clúster de base de datos:
kind: DBCluster spec: primarySpec: parameters: wal_keep_size: WAL_KEEP_SIZE max_wal_size: MAX_WAL_SIZEReemplaza lo siguiente:
WAL_KEEP_SIZE: Es el tamaño mínimo de los archivos WAL anteriores almacenados en el directorio WAL en caso de que un servidor secundario necesite recuperarlos para la replicación de transmisión. Si un servidor secundario conectado al servidor principal se retrasa en más dewal_keep_sizemegabytes, es posible que el servidor principal quite un segmento de WAL que el servidor secundario necesita. En este caso, se cancela la conexión de replicación. Como resultado, las conexiones de transmisión descendente también fallarán con el tiempo. EstableceWAL_KEEP_SIZEen un valor que admita los requisitos de tu carga de trabajo, según la tasa de generación de WAL, las características de la red de replicación y el retraso de replicación entre los centros de datos en los que se implementan tus clústeres de bases de datos principal y secundario. El valor predeterminado es 100 MB.MAX_WAL_SIZE: Es el tamaño máximo para permitir que la WAL crezca durante los puntos de control automáticos de la base de datos. El valor predeterminado es 1,504 MB. Este valor debe establecerse en un valor superior al dewal_keep_size.
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_NAMEReemplaza lo siguiente:
DB_CLUSTER_NAME: Es el nombre del clúster de la base 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 en Base64 (por ejemplo,Q2hhbmdlTWUxMjM= for ChangeMe123). El valor predeterminado esalloydbreplica.REPLICATION_NAME: Es el nombre de la replicación, 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 base de datos secundaria, ejecuta el siguiente comando:
kubectl get replication REPLICATION_NAMEkubectl get replication REPLICATION_NAME -o json | jq .status.upstreamEl 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 la base de datos secundaria 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 tu clúster de base de datos secundario de AlloyDB Omni.
Si la conectividad externa no está habilitada, agrega lo siguiente a la sección spec de su manifiesto:
allowExternalIncomingTraffic: truePara 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: setupReemplaza lo siguiente:
SECONDARY_DB_CLUSTER_NAME: Es el nombre del clúster de la base de datos secundaria, 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 la base de datos principal, codificada como una cadena base64 (por ejemplo,Q2hhbmdlTWUxMjM= for ChangeMe123). El valor predeterminado esalloydbreplica.SECONDARY_REPLICATION_NAME: Es el nombre de la replicación, por ejemplo,replication-2.PRIMARY_HOST: Es el extremo 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: Es el puerto de conexión del clúster de la base de datos principal que se obtuvo en el paso 3 y al que puede acceder la base de datos secundaria para la replicación.PRIMARY_REPLICATION_SLOT: Es el nombre de la ranura de replicación en el clúster de la base de datos principal que se obtuvo en el paso 3 y que la base de datos secundaria puede usar para la replicación.
Visualiza la replicación en el clúster de la base de datos secundaria
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_NAMEkubectl get replication SECONDARY_REPLICATION_NAME
Cuando el clúster de base de datos secundaria se configura correctamente y tiene replicación de transmisión desde el clúster de base de datos principal, el estado de replicación es tanto listo como correcto.
Cómo promover un clúster de base de datos secundaria
Antes de promover un clúster de base de datos secundaria, sigue estos pasos para verificar que el clúster de base de datos secundaria haya aplicado todas las transacciones recibidas del clúster de base 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_NAMEDeté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 rezago de 0 es ideal. Si el retraso es mayor que 0, puedes promover el clúster de base de datos secundaria, pero corres el riesgo de perder algunas transacciones recientes que ya se confirmaron 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 un clúster de base de datos principal, actualiza el campo control del manifiesto de replicación de tu 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 secundaria 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 principal y secundaria durante la conmutación por error, 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_NAMEDeté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 rezago 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_NAMEEspera a que el estado de replicación esté listo.
Para obtener la información de conexión ascendente para la replicación, ejecuta el siguiente comando:
kubectl get replication SECONDARY_REPLICATION_NAMEkubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstreamEl 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 manera 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: rewindEspera a que el estado de replicación esté listo y en buen estado.
Para verificar el estado de la replicación, usa el siguiente comando:
kubectl get replication REPLICATION_NAME