Transmite datos desde bases de datos de PostgreSQL

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

  • El comportamiento de Datastream en relación con 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. La decodificación lógica 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 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 un REPLICA IDENTITY en una tabla, Datastream trata las columnas especificadas como claves primarias.
  • Datastream envía mensajes de monitoreo de funcionamiento periódicamente a la base de datos de origen. Como resultado, los eventos de mensajes de decodificación lógica (op:"m") se insertan directamente en el archivo WAL. Datastream necesita estos mensajes para garantizar la disponibilidad de la fuente y calcular la actualidad. 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 versiones 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

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

En el caso de las fuentes de PostgreSQL, Datastream usa una sola ranura de replicación lógica para toda la transmisión. 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 el mismo flujo.

Para evitar el bloqueo de cabeza de línea, crea transmisiones separadas para diferentes conjuntos de tablas. Por ejemplo, puedes crear un flujo para las tablas de gran volumen y otro para las de bajo volumen. Esto aísla las tablas con una 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 independiente.

Evita las transacciones de larga duración

Las transacciones de larga duración pueden generar una acumulación del registro de escritura anticipada (WAL). Debido a que el WAL es secuencial, PostgreSQL no puede vaciarlo hasta que se complete la transacción larga, incluso mientras se consumen otras transacciones. Esto puede aumentar el tamaño de la ranura de replicación y ralentizar la decodificación lógica, ya que los cambios de las transacciones de larga duración que se superponen con la transacción actual deben decodificarse repetidamente.

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 solo replicas cambios de unas pocas tablas, asegúrate de crear un objeto PUBLICATION que incluya solo esas tablas. Cuando una publicación se limita a tablas específicas, PostgreSQL conserva los cambios de manera eficiente 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 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 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 el 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 en FULL. Datastream usa las columnas registradas como una clave lógica para las operaciones de 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 de MERGE y se interrumpe la transmisión.

Recomendaciones (en orden de preferencia):

  1. Mejor opción: Usa una clave primaria. El parámetro de configuración predeterminado de REPLICA IDENTITY DEFAULT usa de forma automática y eficiente la clave principal existente.
  2. Correcto: Si no existe una clave primaria, crea un índice UNIQUE NOT NULL y establece REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendable: Solo usa 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 en los tipos de datos admitidos para las claves principales si realizas la replicación en BigQuery.

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 completar 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 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 admite valores nulos.
    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 los eventos INSERT se replican en el destino.
  • Las tablas con claves primarias no pueden tener el valor FULL o NOTHING establecido en REPLICA IDENTITY. Debe establecerse en DEFAULT.
  • Datastream no puede replicar datos desde una instancia de réplica de lectura porque PostgreSQL no admite la decodificación lógica en las réplicas de lectura.
  • 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:
    • Se descartan columnas.
    • Agregar columnas en medio de una tabla
    • Cambiar el tipo de datos de una columna
    • Reordenar las columnas
    • Borrar tablas (relevante si luego se vuelve a crear la misma tabla con datos nuevos)
  • Datastream no admite columnas de los tipos de datos geometric.
  • Datastream no admite columnas de los tipos de datos range.
  • Datastream no admite arrays de tipos de datos no admitidos, 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.
  • Datastream no admite la replicación de eventos UPDATE para las filas que incluyen valores TOAST en las columnas que forman parte de la identidad de réplica de la tabla. Estos eventos se descartan.
  • 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 de NULL.
  • Datastream no admite la replicación de columnas del tipo de datos hstore. Los valores de esas columnas se reemplazan por valores de NULL.
  • Datastream no admite la replicación de registros que no son ASCII desde una base de datos de origen codificada como SQL_ASCII. Estos registros se descartan.
  • 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.
  • Datastream no captura los cambios realizados en las columnas generadas.
  • Es posible que Datastream deje de funcionar o no capture eventos nuevos 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, especifica el nuevo nombre de la ranura de replicación para recuperarlas y realiza un reabastecimiento si se requiere coherencia de los datos.

¿Qué sigue?