Estuary mejora la captura de cambios en PostgreSQL con cargas retrospectivas de datos y descubrimiento escalable
Estuary ha lanzado varias mejoras para su conector de captura de datos modificados (CDC) de PostgreSQL, enfocadas en facilitar la recuperación de datos mediante cargas retrospectivas (backfills), optimizar el descubrimiento a gran escala y detectar cambios en los esquemas.
Recargas selectivas de datos
Los enlaces de captura (bindings) de PostgreSQL ahora permiten configurar un filtro adicional para las recargas de datos (Additional Backfill Filter). Esta funcionalidad permite aplicar una expresión SQL a las consultas de carga retrospectiva de una tabla específica.
De esta manera, es posible reducir la cantidad de información que debe volver a leerse cuando solo se necesita recuperar o volver a cargar retrospectivamente una parte de una tabla de PostgreSQL de gran tamaño. Por ejemplo, se puede utilizar un identificador indexado o una marca de tiempo para seleccionar únicamente los registros que deben incluirse en el proceso de recuperación.
Este filtro se aplica exclusivamente a las cargas retrospectivas. La captura continua de cambios (CDC) de PostgreSQL sigue registrando las nuevas modificaciones sin verse afectada por el filtro.
Como la expresión SQL se incorpora directamente a las consultas de carga retrospectiva, se trata de una funcionalidad avanzada que requiere una configuración cuidadosa. Si se modifica el filtro, será necesario volver a ejecutar la carga retrospectiva de datos correspondiente al enlace afectado.
Controles de descubrimiento para esquemas PostgreSQL de gran tamaño
Estuary también ha incorporado filtros de descubrimiento para PostgreSQL que permiten definir qué tablas se identifican y muestran durante el proceso de descubrimiento del conector.surfaced during connector discovery.
Ahora es posible configurar las capturas para:
- Incluir solo determinados esquemas de PostgreSQL
- Excluir esquemas específicos
- Identificar tablas mediante patrones de búsqueda de tipo glob
- Detectar, de forma opcional, tablas que aún no forman parte de la publicación de PostgreSQL
Estas opciones resultan especialmente útiles en entornos PostgreSQL con numerosos esquemas o tablas, donde solo una parte de la base de datos necesita integrarse en un flujo de captura de datos modificados (CDC).
Además, el descubrimiento de metadatos de las tablas ahora se realiza en grupos más pequeños, lo que mejora la fiabilidad del proceso cuando se trabaja con bases de datos que contienen un elevado número de tablas.
Redescubrimiento configurable
Las capturas de PostgreSQL ahora permiten configurar cada cuánto tiempo Estuary vuelve a ejecutar el proceso de descubrimiento mientras permanecen activas.
Este proceso permite detectar cambios, como la incorporación de nuevas tablas o las modificaciones en los esquemas. De forma predeterminada, se ejecuta cada 15 minutos, pero el intervalo puede ajustarse según las necesidades del entorno, ya sea para detectar cambios con mayor rapidez o para reducir la frecuencia de las comprobaciones.
De esta manera, los administradores de PostgreSQL pueden gestionar mejor el equilibrio entre el tiempo necesario para detectar cambios en los esquemas y la cantidad de consultas realizadas al catálogo del sistema.
CDC y cargas retrospectivas de datos en PostgreSQL
El conector de origen PostgreSQL de Estuary utiliza la replicación lógica para capturar las operaciones de inserción, actualización y eliminación registradas en el WAL (Write-Ahead Log) de PostgreSQL.
Al iniciar una nueva captura, Estuary puede realizar primero una carga retrospectiva de los datos existentes de las tablas seleccionadas y, una vez completado este proceso, continuar con la captura de cambios en tiempo real mediante CDC. Los nuevos controles de carga retrospectiva y descubrimiento de tablas ofrecen mayor flexibilidad para gestionar este procedimiento en entornos PostgreSQL de gran escala y en situaciones de recuperación.
El conector CDC de PostgreSQL admite la versión 10.0 y posteriores, tanto en implementaciones autogestionadas como en servicios administrados de PostgreSQL.

