En esta página, se documenta la versión 16.8.0 de AlloyDB Omni con la opción de implementación de Kubernetes. Elige otra opción de implementación.

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

Crea una ranura de replicación y una publicación

Selecciona una versión de la documentación:

En este documento, se describe cómo crear ranuras de replicación lógica en AlloyDB Omni. En PostgreSQL, la replicación lógica es un método para copiar los cambios de datos de una base de datos de publicación a uno o más suscriptores, que pueden ser bases de datos o cualquier otra aplicación. Puedes habilitar y configurar la replicación lógica en los clústeres que crees con el operador de Kubernetes de AlloyDB Omni.

Los cambios transmitidos pueden ser actualizaciones, inserciones o eliminaciones de filas individuales. Los suscriptores se conectan al publicador a través de una ranura de replicación única que garantiza una conexión persistente. Una conexión persistente mantiene el estado de transmisión de datos, por lo que, si se produce una interrupción, la transmisión se reanuda desde donde se detuvo.

Para obtener más información sobre la replicación lógica en PostgreSQL, consulta Replicación lógica.

Los fragmentos de código de esta página son ejemplos que puedes usar como modelos y reemplazar los valores por los de tus recursos de AlloyDB Omni.

Antes de comenzar

Instala Omni Operator en Kubernetes.

Crea un clúster de publicador

Antes de crear las ranuras de replicación, debes crear el clúster de publicador con la replicación lógica habilitada. Debes establecer el parámetro wal_level en logical en el manifiesto de DBCluster.

Para crear un clúster de base de datos de publicador con la replicación lógica habilitada, aplica el siguiente manifiesto:

  apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
    namespace: DB_CLUSTER_NAMESPACE
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
    namespace: DB_CLUSTER_NAMESPACE
  spec:
    databaseVersion: "ALLOYDB_OMNI_VERSION"
    spec:
    availability:
      numberOfStandbys: 1
    primarySpec:
      parameters:
        wal_level: "logical"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DISK_SIZE

Reemplaza lo siguiente:

DB_CLUSTER_NAME: El nombre de este clúster de base de datos, por ejemplo, publisher.
DB_CLUSTER_NAMESPACE (opcional): Es el espacio de nombres en el que deseas crear el clúster de base de datos, por ejemplo, publisher-namespace.
ENCODED_PASSWORD: Es la contraseña de acceso a la base de datos para el rol de usuario postgres predeterminado, codificada como una cadena en Base64; por ejemplo, Q2hhbmdlTWUxMjM= para ChangeMe123.
ALLOYDB_OMNI_VERSION: La versión de AlloyDB Omni, 15.7.0 o posterior.
CPU_COUNT: Es la cantidad de CPU disponibles para cada instancia de base de datos en este clúster de bases de datos.
MEMORY_SIZE: Es la cantidad de memoria por instancia de base de datos de este clúster de bases de datos. Te recomendamos que establezcas este valor en 8 gigabytes por CPU. Por ejemplo, si estableciste cpu en 2 anteriormente en este manifiesto, te recomendamos que establezcas memory en 16Gi.
DISK_SIZE: Es el tamaño del disco por instancia de base de datos, por ejemplo, 10Gi.

Crea una ranura de replicación

Después de crear el clúster de publicador, puedes crear una ranura de replicación lógica con el recurso Replication en el clúster de publicador. Cada recurso Replication está asociado con un recurso de clúster de base de datos correspondiente. Un clúster de base de datos puede tener varios recursos de replicación lógica asociados.

Para configurar una ranura de replicación en tu clúster de publicador, aplica el siguiente manifiesto:

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: USER_PASSWORD_SECRET_NAME
  namespace: USER_PASSWORD_SECRET_NAMESPACE
type: Opaque
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: NAMESPACE
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  upstream:
    logicalReplication:
      pluginName: DECODER_PLUGIN
      databaseName: DATABASE_NAME
    applicationName: APPLICATION_NAME
    replicationSlotName: REPLICATION_SLOT_NAME
    synchronous: "REPLICATION_MODE"
    username: APPLICATION_USER
    password:
      name: USER_PASSWORD_SECRET_NAME
      namespace: USER_PASSWORD_SECRET_NAMESPACE
EOF

Reemplaza lo siguiente:

REPLICATION_NAME: Es un nombre para este recurso Replication, por ejemplo, replication-1.
NAMESPACE: Es el espacio de nombres de Kubernetes para este recurso Replication. Debe coincidir con el espacio de nombres del clúster de la base de datos.
DB_CLUSTER_NAME: Es el nombre del clúster de la base de datos que asignaste cuando lo creaste.
DECODER_PLUGIN: Se establece en el complemento de decodificación, como pgoutput, que deseas usar para la replicación lógica. Para obtener más información sobre los distintos complementos de decodificación, consulta Complementos de salida.
DATABASE_NAME: Se establece en el nombre de la base de datos cuyos cambios deseas transmitir al slot de replicación. Asegúrate de que la base de datos ya se haya creado en el clúster del editor.
APPLICATION_NAME (opcional): Se establece en el nombre de la aplicación que se conectará a la ranura de replicación. Este campo es obligatorio cuando el modo de transmisión se establece como síncrono.
REPLICATION_MODE (opcional): Se establece en false para la replicación asíncrona. Si quieres habilitar la replicación síncrona, pero a costa de la velocidad, establece este valor como true. El valor predeterminado es false, si no se configura de forma explícita.
REPLICATION_SLOT_NAME: Es el nombre de la ranura de replicación que se creará y que usará el suscriptor, por ejemplo, logicalrepltestslot.
REPLICATION_USER (opcional): Es el nombre del usuario que se conecta a la ranura de replicación. Si configuras el usuario de replicación, deberás establecer el nombre, el espacio de nombres y la contraseña del secreto.
USER_PASSWORD_SECRET_NAME (opcional): Es el nombre del Secret de Kubernetes del usuario de la aplicación. Obligatorio si se configura el usuario de la aplicación.
USER_PASSWORD_SECRET_NAMESPACE (opcional): Es el espacio de nombres en el que se encuentra el secreto de Kubernetes para el usuario de la aplicación. Obligatorio si se configuró el usuario de la aplicación.

Consulta el estado de la ranura de replicación

Para ver el estado de las ranuras de replicación, ejecuta el siguiente comando:

kubectl get replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE -oyaml

El campo status, junto con otros detalles, se incluye en la respuesta:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: NAMESPACE
...
...
status:
  conditions:
  - lastTransitionTime: "2025-01-25T06:49:25Z"
    message: Ready for replication
    reason: Ready
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-01-25T06:49:25Z"
    message: Replication slot is not being used
    reason: Unhealthy
    status: "False"
    type: Healthy
  observedGeneration: 2
  upstream:
    host: DATABASE_ENDPOINT
    password:
      name: USER_PASSWORD_SECRET_NAME
      namespace: USER_PASSWORD_SECRET_NAMESPACE
    port: DATABASE_PORT
    replicationSlotName: REPLICATION_SLOT_NAME
    username: APPLICATION_USER

El campo DATABASE_ENDPOINT muestra la dirección IP que usas para conectarte a la base de datos. El estado TRUE en la columna READY indica que la ranura está lista para transmitir. Cuando el clúster de base de datos o la aplicación del suscriptor se conectan a la ranura de replicación, el estado de la columna HEALTHY cambia a TRUE.

Configura el clúster de publicadores

Busca el pod que necesitas.

$ kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database, dbs.internal.dbadmin.goog/ha-role=Primary"

Conéctate al Pod principal en el clúster de publicador con psql:
```
psql -h IP_ADDRESS -U USERNAME -d DATABASE_NAME
```
Reemplaza lo siguiente:
- IP_ADDRESS: Es la dirección IP del pod principal del clúster del publicador.
- USERNAME: Es el usuario de Postgres de la base de datos.
- DATABASE_NAME: Es la base de datos a la que el suscriptor desea suscribirse.
Si no existe el DATABASE_NAME especificado en el recurso de replicación, crea una base de datos.
```
CREATE DATABASE DATABASE_NAME;
```

Opcional: Para fines de prueba, agrega una tabla a la base de datos y, luego, inserta algunos datos. Puedes usar estos datos para observar la replicación de datos del publicador al suscriptor.

$ psql -h localhost -U postgres DATABASE_NAME
customer=# CREATE TABLE TABLE_NAME(
customer(#    ID INT PRIMARY KEY     NOT NULL,
customer(#    NAME           TEXT    NOT NULL,
customer(#    AGE            INT     NOT NULL,
customer(#    SALARY         REAL
customer(# );
CREATE TABLE
customer=# INSERT INTO TABLE_NAME (ID,NAME,AGE,SALARY) VALUES
customer-# (1, 'Quinn', 25, 65000.00),
customer-# (2, 'Kim', 22, 72250.00),
customer-# (3, 'Bola', 31, 53000.00),
customer-# (4, 'Sasha', 33, 105000.00),
customer-# (5, 'Yuri', 27, 85000.00);
INSERT 0 5
customer=# \dt
          List of relations
Schema |  Name   | Type  |  Owner
--------+---------+-------+----------
public | company | table | postgres
(1 row)

customer=# select * from TABLE_NAME;
id | name  | age | salary
----+-------+-----+--------
  1 | Quinn  |  25 |  65000
  2 | Kim  |  22 |  72250
  3 | Bola   |  31 |  53000
  4 | Sasha |  33 | 105000
  5 | Yuri |  27 |  85000
(5 rows)

Reemplaza TABLE_NAME por una tabla en la que desees almacenar los datos y a la que se suscriba el suscriptor.

Otorga los permisos:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO REPLICATION_USER;
GRANT USAGE ON SCHEMA public TO REPLICATION_USER;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO REPLICATION_USER;

Ejecuta el siguiente comando para crear la publicación:
```
CREATE PUBLICATION PUBLICATION_NAME;
ALTER PUBLICATION PUBLICATION_NAME ADD TABLE TABLE_NAME;
```
Reemplaza lo siguiente:
- PUBLICATION_NAME: Es el nombre de la publicación que usará el suscriptor para suscribirse.

Después de crear la publicación, puedes configurar tu clúster de suscriptores para la replicación lógica o configurar tu aplicación para comenzar la replicación.

Limitaciones

No se admiten actualizaciones en la configuración de la ranura de replicación. Para actualizar la configuración, descarta la ranura de replicación y vuelve a crearla con la configuración actualizada.

Para descartar la ranura de replicación, ejecuta el siguiente comando:
```
kubectl delete replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE
```
Solo puedes configurar la ranura de replicación lógica en la base de datos de publicación. La API de replicación no admite aplicaciones ni DBCluster suscriptores de replicación lógica.
Si el clúster de bases de datos al que hace referencia el objeto de replicación está configurado para la alta disponibilidad, la ranura de replicación lógica se vuelve a crear en la instancia en espera promocionada después de una conmutación por error. Después de que se vuelve a crear la ranura de replicación, la posición de la transmisión en la ranura ya no está disponible, y todas las aplicaciones que se suscriban a la transmisión deben volver a conectarse y reproducirla.

¿Qué sigue?

Configura el clúster suscriptor para la replicación lógica