Compartir a través de


Mantenimiento de canalizaciones de ingesta de PostgreSQL

Importante

El conector de PostgreSQL para Lakeflow Connect está en versión preliminar pública. Póngase en contacto con el equipo de su cuenta de Databricks para inscribirse en la Vista previa pública.

En esta página se describen las operaciones en curso para mantener canalizaciones de ingesta de PostgreSQL.

Mantenimiento general de canalizaciones

Las tareas de mantenimiento de canalización de esta sección se aplican a todos los conectores administrados de Lakeflow Connect.

Para ver las tareas generales de mantenimiento de canalización, consulte Tareas comunes de mantenimiento de canalización.

Eliminación de archivos de almacenamiento provisional sin usar

Para las canalizaciones de ingesta que cree después del 6 de enero de 2025, los datos de almacenamiento provisional del volumen se programan automáticamente para su eliminación después de 25 días y se quitan físicamente después de 30 días. Una canalización de ingesta que no se ha completado correctamente durante 25 días o más podría dar lugar a brechas de datos en las tablas de destino. Para evitar huecos, desencadene una actualización completa de las tablas de destino.

Para las canalizaciones de ingesta creadas antes del 6 de enero de 2025, póngase en contacto con el soporte técnico de Databricks para solicitar la habilitación manual de la administración automática de retención para los datos CDC de ensayo.

Los datos siguientes se limpian automáticamente:

  • Archivos de datos CDC
  • Archivos de instantáneas
  • Datos de tabla de almacenamiento provisional

Mantenimiento específico del conector de la pipelines

Las tareas de mantenimiento de canalización de esta sección son específicas del conector de PostgreSQL.

Adición de nuevas tablas a la replicación

Para agregar nuevas tablas a un flujo de replicación existente:

  1. Conceda los privilegios necesarios al usuario de replicación. Para obtener una lista completa de los privilegios necesarios, consulte Requisitos de usuario de base de datos postgreSQL.

  2. Establezca la identidad de réplica para las nuevas tablas en función de su estructura. Consulte Establecimiento de la identidad de réplica para las tablas para obtener instrucciones sobre cómo elegir la configuración de identidad de réplica correcta.

  3. Agregue las tablas a la publicación:

    ALTER PUBLICATION databricks_publication ADD TABLE schema_name.new_table;
    
  4. Actualice la configuración de canalización de ingesta para incluir las nuevas tablas. Puede hacerlo a través de la interfaz de usuario de Azure Databricks o actualizando el conjunto ingestion_definition en sus paquetes de recursos de Databricks Asset Bundles o el comando CLI.

  5. Reinicie la puerta de enlace de ingestión para descubrir las nuevas tablas. La puerta de enlace comprueba periódicamente las nuevas tablas, pero reiniciar la puerta de enlace acelera el proceso de detección.

Limpia las ranuras de replicación

Al eliminar una canalización de ingesta, ** la ranura de replicación no se quita automáticamente de la base de datos postgreSQL de origen **. Las ranuras de replicación sin usar pueden hacer que los archivos de Write-Ahead Log (WAL) se acumulen, llenando potencialmente el espacio en disco de la base de datos de origen.

Para enumerar todas las ranuras de replicación:

SELECT slot_name, slot_type, active, restart_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

Para quitar una ranura de replicación que ya no sea necesaria:

SELECT pg_drop_replication_slot('slot_name');

Limpieza del seguimiento de DDL en línea

Si deshabilita el seguimiento de DDL en línea, ejecute los pasos siguientes para limpiar los objetos de cada base de datos creados por el script de auditoría.

  1. Quite los desencadenadores de eventos:

    DROP EVENT TRIGGER IF EXISTS lakeflow_ddl_trigger CASCADE;
    
  2. Quite la tabla de auditoría de la publicación:

    ALTER PUBLICATION databricks_publication DROP TABLE public.lakeflow_ddl_audit;
    
  3. Eliminar la tabla de auditoría:

    DROP TABLE IF EXISTS public.lakeflow_ddl_audit CASCADE;
    

Supervisión de ranuras de replicación

Supervise el estado de las ranuras de replicación para asegurarse de que están activos y consumen datos WAL:

SELECT slot_name,
       active,
       wal_status,
       active_pid,
       restart_lsn,
       confirmed_flush_lsn,
       pg_current_wal_lsn() AS current_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS replication_lag
FROM pg_replication_slots
WHERE slot_name LIKE 'databricks%';

Los valores de retardo de replicación de gran tamaño pueden indicar uno de los siguientes problemas:

  • La pasarela de ingesta no sigue el ritmo de los cambios en la base de datos de origen.
  • La puerta de enlace de ingesta se ha detenido durante un período prolongado.
  • Problemas de conectividad de red entre la puerta de enlace y la base de datos de origen.

Si una ranura de replicación está inactiva (active = false) y ha confirmado que la canalización correspondiente ya no es necesaria, quite la ranura de replicación para liberar los recursos. Consulte Limpiar ranuras de replicación.

Supervisión del uso del disco WAL

Supervise el uso del espacio en disco del Registro de Escritura Anticipada (WAL) para prevenir problemas de espacio en disco.

SELECT pg_size_pretty(sum(size)) AS wal_size
FROM pg_ls_waldir();

Para comprobar la retención del WAL para una ranura de replicación específica:

SELECT slot_name,
       active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS pending_wal
FROM pg_replication_slots
WHERE slot_name = 'your_slot_name';

Nota:

Si max_slot_wal_keep_size se configura correctamente durante la configuración de origen (como se recomienda en Limitar la retención de WAL para las ranuras de replicación), las ranuras de replicación inactivas no provocarán un crecimiento ilimitado del WAL. La ranura se invalidará cuando se alcance el límite, lo que evitará fallos de la base de datos.

Si el uso del disco WAL es alto, realice los pasos siguientes:

  1. Verifique que la puerta de enlace de ingestión se esté ejecutando continuamente.

  2. Compruebe los registros de puerta de enlace para ver si hay errores que podrían impedir que consuma datos WAL.

  3. Considere la posibilidad de establecer max_slot_wal_keep_size para limitar la retención de WAL (PostgreSQL 13 o superior):

    ALTER SYSTEM SET max_slot_wal_keep_size = '10GB';
    SELECT pg_reload_conf();
    

    Advertencia

    Configurar max_slot_wal_keep_size puede hacer que las ranuras de replicación se invaliden si se supera el límite de retención WAL, requiriendo una actualización completa de todas las tablas.

Reinicia la puerta de enlace de ingesta

Para reducir la carga en la base de datos de origen, la puerta de enlace de entrada solo comprueba de forma periódica si hay tablas nuevas. La puerta de enlace puede tardar hasta 6 horas en detectar nuevas tablas. Si desea acelerar este proceso, reinicie la puerta de enlace.

Además, reinicie la puerta de enlace en las situaciones siguientes:

  • Ha realizado cambios de configuración en la base de datos de origen.
  • La puerta de enlace está experimentando errores o problemas de rendimiento.

Actualizar publicaciones

Si necesita modificar qué tablas se incluyen en la replicación:

-- Add a table to the publication
ALTER PUBLICATION databricks_publication ADD TABLE schema_name.table_name;

-- Remove a table from the publication
ALTER PUBLICATION databricks_publication DROP TABLE schema_name.table_name;

-- List all tables in a publication
SELECT schemaname, tablename
FROM pg_publication_tables
WHERE pubname = 'databricks_publication';

Después de actualizar la publicación, reinicie la puerta de enlace de ingesta para aplicar los cambios.