采用LocalExecutor与PostgreSQL的Airflow实例偶发崩溃，报连接拒绝错误求排查

安全阿岳

2026-7-21

Airflow连接PostgreSQL突然崩溃的常见操作失误分析

首先重现报错信息：

conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server at "127.0.0.1", port 5432 failed: Connection refused
    Is the server running on that host and accepting TCP/IP connections?

以下是可能存在的操作失误：

未保障PostgreSQL服务的高可用性：未给PostgreSQL配置自动重启机制（比如systemd管理时未设置Restart=always），导致PostgreSQL偶尔意外退出后无法自动恢复；同时未监控PostgreSQL的资源使用，当内存、CPU耗尽时服务被OOM killer终止，引发连接拒绝。
数据库连接池参数配置不合理：Airflow的sql_alchemy_pool_size和sql_alchemy_max_overflow设置不当，若sql_alchemy_pool_size过小，加上LocalExecutor启动的worker进程数超过池大小，且max_overflow预留不足，会导致连接耗尽；另外如果PostgreSQL的max_connections值小于Airflow连接池+其他业务连接的总和，极端情况下PostgreSQL会直接拒绝新连接。
本地连接环境存在不稳定因素：未固定PostgreSQL的5432端口，导致其他程序偶尔占用该端口；本地防火墙规则临时变更（如自动更新的策略）拦截了本地TCP连接；或者误修改了pg_hba.conf中127.0.0.1的连接规则，以及postgresql.conf里的listen_addresses被改为非127.0.0.1的值，导致本地TCP连接被拒绝。
Airflow进程资源管控缺失：LocalExecutor模式下每个任务会启动独立进程，若任务调度突然密集（即使DAG数量少），Airflow主进程或worker进程耗尽内存、CPU，导致无法正常发起数据库连接，表现为连接被拒绝的错误。
未配置合理的连接重试机制：Airflow的sql_alchemy_retry_limit和sql_alchemy_retry_interval参数设置过低，当PostgreSQL出现短暂连接波动时，Airflow未进行重试直接抛出错误导致崩溃，而非等待服务恢复。