Transmite datos desde bases de datos de PostgreSQL

En esta sección, se incluye información sobre lo siguiente:

  • El comportamiento de Datastream en el manejo de los datos que se extraen de una base de datos de PostgreSQL de origen
  • Las versiones de la base de datos de PostgreSQL que Datastream admite
  • Una descripción general de cómo configurar una base de datos de PostgreSQL de origen para que los datos se puedan transmitir a un destino
  • Limitaciones conocidas para usar la base de datos de PostgreSQL como fuente

Comportamiento

La base de datos de PostgreSQL de origen depende de su función de decodificación lógica. Esta función expone todos los cambios asignados a la base de datos y permite consumirlos y procesarlos en un formato fácil de usar con un complemento de salida. Datastream usa el complemento pgoutput, que es el complemento de decodificación lógica estándar de PostgreSQL para PostgreSQL 10 y versiones posteriores.

  • Se pueden seleccionar todos los esquemas o los esquemas específicos de una fuente de PostgreSQL determinada, así como todas las tablas de los esquemas o tablas específicas.
  • Se replican todos los datos históricos.
  • Se replican todos los cambios del lenguaje de manipulación de datos (DML), como las inserciones, las actualizaciones y las eliminaciones de las bases de datos y las tablas especificadas.
  • Solo se replican los cambios confirmados.
  • Si defines una REPLICA IDENTITY en una tabla, Datastream trata las columnas especificadas como claves primarias.
  • Datastream envía mensajes de latido periódicamente a la base de datos de origen cuando está conectado a una instancia principal. Como resultado, los eventos de mensajes de decodificación lógica (op:"m") se insertan directamente en el archivo WAL. Datastream requiere estos mensajes para garantizar la disponibilidad de la fuente y calcular la actualidad. Cuando usas una réplica de lectura como fuente, debes configurar los mensajes de latido de forma externa. Para obtener más información, consulta Replicación desde réplicas de lectura. Te recomendamos que lo tengas en cuenta si otras configuraciones de replicación leen desde la misma base de datos de origen.

Versiones

Datastream admite PostgreSQL 10 y versiones posteriores.

Datastream admite los siguientes tipos de bases de datos de PostgreSQL:

  • PostgreSQL autoalojado
  • Cloud SQL para PostgreSQL
  • AlloyDB para PostgreSQL
  • AlloyDB Omni
  • Amazon RDS para PostgreSQL
  • Amazon Aurora PostgreSQL

Nivel gratuito

Datastream te permite transmitir datos desde AlloyDB para PostgreSQL a BigQuery con el nivel gratuito, que proporciona hasta 100 GiB de datos de captura de datos modificados sin cargo por mes. Para obtener más información, consulta Precios de Datastream.

Prácticas recomendadas

En esta sección, se describen las prácticas recomendadas para configurar tu fuente de PostgreSQL para usarla con Datastream.

Usa varias transmisiones para evitar el bloqueo de línea

Para las fuentes de PostgreSQL, Datastream usa una sola ranura de replicación lógica para una transmisión completa. Una transacción grande o varias actualizaciones en una tabla de gran volumen pueden retrasar la replicación de datos para todas las demás tablas de la misma transmisión.

Para evitar el bloqueo de línea, crea transmisiones separadas para diferentes conjuntos de tablas. Por ejemplo, puedes crear una transmisión para tablas de gran volumen y otra para tablas de bajo volumen. Esto aísla las tablas de alta rotación y evita que retrasen la replicación de otras tablas.

Recomendación: Identifica las tablas con tasas de escritura (INSERT/UPDATE/DELETE) excepcionalmente altas y colócalas en su propia transmisión de Datastream dedicada con una ranura de replicación separada.

Evita las transacciones de larga duración

Las transacciones de larga duración pueden provocar la acumulación de registros WAL. Debido a que WAL es secuencial, PostgreSQL no puede quitar los archivos WAL antiguos que necesita la ranura de replicación hasta que se complete la transacción larga. Esto aumenta el uso del disco WAL.

Además, esto puede ralentizar la decodificación lógica. La desaceleración se debe a que las transacciones grandes derraman cambios en el disco, lo que luego requiere un reensamblaje lento y con uso intensivo de E/S en la confirmación, lo que bloquea la replicación de todas las transacciones posteriores. Recomendación: En la base de datos de origen, configura los parámetros statement_timeout y idle_in_transaction_session_timeout para evitar las transacciones de larga duración. Para obtener más información, consulta la documentación de PostgreSQL.

Usa el filtrado de tablas cuando crees publicaciones

Si replicas cambios de solo algunas tablas, asegúrate de crear una PUBLICATION que incluya solo esas tablas. Cuando una publicación se limita a tablas específicas, PostgreSQL conserva de manera eficiente los cambios solo para esas tablas en la ranura de replicación. Esto ayuda a reducir el tamaño de la ranura de replicación y mejora el rendimiento de la decodificación lógica.

Administra de forma proactiva las ranuras de replicación

Datastream usa una ranura de replicación lógica en tu instancia principal de PostgreSQL, lo que garantiza que los archivos WAL se conserven hasta que Datastream confirme que se procesaron. Si una transmisión falla, se pausa o se borra sin descartar la ranura de replicación, PostgreSQL continúa conservando los archivos WAL de forma indefinida. Esto puede llenar el disco del servidor de la base de datos y provocar una interrupción de la producción.

Recomendación: Configura alertas eficientes y supervisa el uso del disco WAL en tu servidor de PostgreSQL de origen.

Configura correctamente la identidad de la réplica

El parámetro de configuración REPLICA IDENTITY le indica a PostgreSQL qué datos escribir en WAL para los eventos UPDATE y DELETE, lo que permite que Datastream identifique qué filas se cambiaron.

Si usas BigQuery como destino, evita configurar REPLICA IDENTITY como FULL. Datastream usa las columnas registradas como una clave lógica para las operaciones MERGE de BigQuery. Si REPLICA IDENTITY se establece en FULL y una tabla tiene más de 16 columnas, se supera el límite de 16 columnas de BigQuery para las claves primarias en las operaciones MERGE y se interrumpe la transmisión.

Recomendaciones (en orden de preferencia):

  1. Mejor: Usa una clave primaria. El parámetro de configuración predeterminado de REPLICA IDENTITY DEFAULT usa de forma automática y eficiente la clave primaria existente.
  2. Bueno: Si no existe una clave primaria, crea un UNIQUE NOT NULL índice y establece REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendado: Solo usa el parámetro de configuración REPLICA IDENTITY FULL en tablas sin un identificador único. Ten en cuenta el impacto en el rendimiento, el límite de 16 columnas y la restricción de los tipos de datos admitidos para las claves primarias si realizas la replicación en BigQuery.

Replicación desde réplicas de lectura

Datastream admite la replicación desde instancias de réplicas de lectura de PostgreSQL para PostgreSQL 16 y versiones posteriores.

Para replicar desde una réplica de lectura, debes realizar los siguientes pasos de configuración en la instancia principal:

  1. Crea publicaciones en la instancia principal: Si bien Datastream se conecta a la réplica de lectura, las publicaciones que definen los datos que se replicarán deben crearse en la instancia principal.
  2. Configura los latidos WAL: Datastream depende de los mensajes de latido WAL periódicos para su mecanismo de punto de control. Cuando se conecta a una instancia principal, Datastream controla la generación de estos latidos. Sin embargo, para una réplica de lectura, estos latidos deben generarse de forma externa.

Una forma de configurar los latidos periódicos es crear una tarea cron en PostgreSQL con la extensión pg_cron:

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

Reemplaza lo siguiente:

  • DATABASE_NAME: Es el nombre de la base de datos para la que deseas generar latidos.
  • USERNAME: Es el nombre del usuario para ejecutar la tarea. Por lo general, postgres.

Limitaciones conocidas

Entre las limitaciones conocidas para usar Datastream con una base de datos de PostgreSQL como fuente, se incluyen las siguientes:

  • Las transmisiones se limitan a 10,000 tablas.
  • No se puede rellenar una tabla que tenga más de 500 millones de filas, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice B-tree único.
    2. El índice no incluye columnas de los siguientes tipos: DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, tipos de datos compuestos o tipos de datos geométricos.
    3. Ninguna de las columnas del índice puede aceptar valores nulos.
    4. Todas las columnas del índice están en orden ascendente o descendente.
    5. Todas las columnas del índice se incluyen en la transmisión.
  • Las tablas sin claves primarias deben tener una REPLICA IDENTITY. De lo contrario, solo se replican los eventos INSERT en el destino.
  • Las tablas con claves primarias no pueden tener la REPLICA IDENTITY establecida en FULL o NOTHING. Debe establecerse en DEFAULT.
  • No todos los cambios en el esquema de origen se pueden detectar automáticamente, en cuyo caso pueden ocurrir daños en los datos. Los siguientes cambios de esquema pueden causar daños en los datos o que no se puedan procesar los eventos en etapas posteriores:
    • Descarta columnas
    • Agregar columnas en medio de una tabla
    • Cambiar el tipo de datos de una columna
    • Reordenar las columnas
    • Descartar tablas (relevante si la misma tabla se vuelve a crear con datos nuevos agregados)
  • Datastream no admite columnas de los geometric tipos de datos.
  • Datastream no admite columnas de los tipos de datos range.
  • Datastream no admite arrays de tipos de datos no compatibles, arrays de tipos de datos definidos por el usuario (incluido ENUM) ni arrays de tipos de datos DATE, TIMESTAMP o TIMESTAMP WITH TIME ZONE. Se ignoran esas columnas.
  • Para las transmisiones creadas antes del 17 de febrero de 2026, Datastream no admite la replicación de eventos UPDATE para filas que incluyen valores TOAST en columnas que forman parte de la identidad de la réplica de la tabla. Se descartan esos eventos. Las transmisiones creadas después de esa fecha no están sujetas a esta excepción.
  • Datastream no admite la replicación de filas que incluyen valores JSON o JSONB con más de 2,950 objetos anidados. Los eventos que contienen esos valores JSON o JSONB no se replican en la base de datos de destino.
  • Datastream no admite la replicación de filas que incluyen valores NaN en columnas NUMERIC (precision, scale). Los valores de esas columnas se reemplazan por valores NULL.
  • Datastream no admite la replicación de columnas del tipo de datos hstore. Los valores de esas columnas se reemplazan por valores NULL.
  • Datastream no admite la replicación de registros que no sean ASCII desde una base de datos de origen codificada en SQL_ASCII. Se descartan esos registros.
  • Datastream no admite la replicación de tablas con políticas de seguridad a nivel de la fila (RLS) definidas. Para obtener información sobre cómo evitar esta limitación, consulta Comportamiento y limitaciones de la fuente de PostgreSQL.
  • Cuando se transmiten columnas con tipos de datos de longitud variable que usan la técnica de almacenamiento de atributos de gran tamaño (TOAST), Datastream debe consultar la base de datos de origen para recuperar los valores faltantes en un momento determinado (en un proceso de búsqueda activa llamado suplementación) si se descarta un valor TOAST sin cambios del registro WAL durante una operación UPDATE. Debido a que Datastream transmite estas columnas consultando la base de datos, es posible que no se capturen los cambios intermedios en situaciones que impliquen actualizaciones rápidas y consecutivas o una eliminación rápida después de una inserción. Ten en cuenta que las operaciones DELETE no activan la suplementación. Esta limitación es especialmente relevante cuando se usa el modo de escritura de solo anexos, que espera que se capturen todos los cambios intermedios.
  • Datastream no captura los cambios realizados en las columnas generadas.
  • Es posible que Datastream deje de funcionar o no capture ningún evento nuevo cuando se realice una actualización de la versión principal de PostgreSQL en la base de datos. Te sugerimos que descartes las ranuras de replicación antes de la actualización, luego actualices la base de datos y, luego, vuelvas a crear las ranuras de replicación. Si fallan las transmisiones, recupera la transmisión especificando el nuevo nombre de la ranura de replicación y realiza un relleno si se requiere coherencia de datos.
  • Datastream no admite la replicación de tablas del sistema de PostgreSQL cuando se usa el flujo de configuración de transmisión automatizada. Si editas la transmisión que creaste con el flujo automatizado y agregas tablas del sistema, Datastream ignora estas tablas de forma silenciosa y no replica ningún dato ni cambio de ellas.

¿Qué sigue?