Transmite datos desde bases de datos de PostgreSQL

Puedes usar Datastream para replicar datos históricos y cambios continuos desde una base de datos de PostgreSQL hacia tu destino para realizar análisis en tiempo real y sincronizar la base de datos.

Para prepararte para la replicación de PostgreSQL en Datastream, revisa el comportamiento de la replicación, las versiones y los tipos de bases de datos compatibles, las prácticas recomendadas, los requisitos para las réplicas de lectura y las limitaciones conocidas.

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 esquemas específicos de una fuente de PostgreSQL determinada, así como todas las tablas del esquema 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 periódicamente mensajes de señal de monitoreo de funcionamiento a la base de datos de origen cuando está conectada 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. Consulta Replicación desde réplicas de lectura para obtener más información. Te recomendamos que tengas esto en cuenta si otras configuraciones de replicación leen desde la misma base de datos de origen.

Versiones

Datastream admite la versión 10 y posteriores de PostgreSQL.

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 de AlloyDB para PostgreSQL a BigQuery con el nivel gratuito, que proporciona hasta 100 GiB de datos de captura de datos modificados sin costo todos los meses. 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 y usarla con Datastream.

Usa varios flujos para evitar el bloqueo de línea

En el caso de 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 en la misma transmisión.

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

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

Evita las transacciones de larga duración

Las transacciones de larga duración pueden provocar la acumulación de registros de WAL. Debido a que el 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 de WAL.

Además, esto puede ralentizar la decodificación lógica. La ralentización se produce cuando las transacciones grandes vuelcan los cambios en el disco, lo que requiere un reensamblaje lento y con un uso intensivo de E/S en el momento de 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 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 retengan 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 sigue reteniendo 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 de WAL en tu servidor de PostgreSQL de origen.

Configura la identidad de la réplica correctamente

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

Si usas BigQuery como destino, evita establecer REPLICA IDENTITY en 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 índice UNIQUE NOT NULL y establece REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendado: Usa solo el parámetro de configuración REPLICA IDENTITY FULL en tablas sin 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 se replica en BigQuery.

Replicación desde réplicas de lectura

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

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: Mientras 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 de WAL: Datastream se basa en mensajes periódicos de latidos de WAL para su mecanismo de puntos 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 se deben generar de forma externa.

Una forma de configurar 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 con el que se 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 están limitadas a 10,000 tablas.
  • PostgreSQL rechaza estrictamente los bytes NULL (0x00) en las columnas de cadenas UTF-8. Datastream no quita los bytes NULL. Si una cadena de origen contiene bytes nulos 0x00, el lote de inserción falla y se detiene la replicación. Te recomendamos que limpies o reemplaces los caracteres CHAR(0) en la base de datos de origen antes de la replicación.
  • No puedes configurar los flujos de PostgreSQL para que comiencen desde la posición más reciente.
  • Una tabla que tiene más de 500 millones de filas no se puede reabastecer, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice de árbol B ú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 ser nula.
    4. Todas las columnas del índice están en orden ascendente o todas las columnas del índice están en orden 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 ni NOTHING. Se debe establecer 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 el medio de una tabla
    • Cambiar el tipo de datos de una columna
    • Reordenando columnas.
    • Descartar tablas (relevante si luego se vuelve a crear la misma tabla con datos nuevos agregados)
  • Datastream no admite columnas de los tipos de datos geometric, como BOX, CIRCLE, LINE, LSEG, PATH, POINT y POLYGON. Estas columnas se replican como NULL.
  • Datastream no admite columnas de los tipos de datos range.
  • Datastream no admite arrays de tipos de datos no admitidos (como tipos espaciales), arrays de LTREE, arrays de tipos de datos definidos por el usuario (incluido ENUM) ni arrays de DATE, TIMESTAMP o TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream ignora esas columnas durante la replicación.
  • En el caso de las transmisiones creadas antes del 17 de febrero de 2026, Datastream no admite la replicación de eventos UPDATE para filas que incluyan valores TOAST en columnas que formen parte de la identidad de réplica de la tabla. Estos eventos se descartan. Los flujos creados después de esa fecha no están sujetos a esta excepción.
  • Datastream no admite la replicación de filas que incluyan 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 incluyan 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. Esos registros se descartan.
  • Datastream no admite la replicación de tablas con políticas de seguridad a nivel de fila (RLS) definidas. Para obtener información sobre cómo omitir esta limitación, consulta Comportamiento y limitaciones de la fuente de PostgreSQL.
  • Para las columnas de transmisión con tipos de datos de longitud variable que usan la técnica de almacenamiento de atributos de gran tamaño (TOAST): Si se quita un valor de TOAST sin cambios del registro de WAL durante una operación UPDATE, Datastream realiza una búsqueda activa en la base de datos de origen para intentar recuperar el valor faltante. Por lo tanto, 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 esta operación de búsqueda activa. Esta limitación para las columnas de longitud variable que usan TOAST es particularmente relevante cuando se usa el modo de escritura de solo anexar, 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, por último, vuelvas a crear las ranuras de replicación. Si las transmisiones fallan, recupéralas especificando el nombre de la nueva ranura de replicación y realiza un reabastecimiento si se requiere coherencia de los 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 las ignora de forma silenciosa y no replica ningún dato ni cambio de ellas.

¿Qué sigue?