数据库连接错误信息生成器

错误代码：SQLSTATE 28P01（invalid_password），Severity: FATAL

错误描述： 在 2025-12-01T02:07:10Z，客户端通过 SSL 连接到 PostgreSQL 时发生认证失败。客户端收到 “FATAL: password authentication failed (SQLSTATE 28P01)”；服务端日志显示 “SCRAM 验证失败（scram-sha-256）”。当前驱动为 pgjdbc 42.6.0，pg_hba.conf 要求使用 scram-sha-256 方式进行 hostssl 认证。

可能原因：

1. 凭据未同步：发生密码/密钥轮换后，应用仍在使用旧密码，或连接池中缓存了使用旧密码的连接。
2. 连接字符串编码问题：密码包含保留字符（如 @、:、/ 等）且未按 URI 规范进行百分号编码，导致解析到的密码不正确。
3. 服务端侧凭据不一致：数据库中该角色的 SCRAM 存储密文未按预期更新，或近期密码更新操作未成功提交/生效，导致与客户端提供的密码不匹配。

解决方案：

1. 基线校验（独立于应用）：
   • 使用受控环境的 psql，手动输入当前认为正确的密码进行连接校验： psql "sslmode=require host= port= dbname=" -U
   • 若此处也失败，说明服务端与“当前密码”的映射不一致，请执行第 2 步。
2. 重新设置并验证服务端密码（需要具备相应权限）：
   • 在数据库中为目标角色重置密码（生成新的 SCRAM 密文），并立即验证： ALTER ROLE <ROLE_NAME> WITH PASSWORD '<NEW_PASSWORD>'; 备注：执行后可再次用 psql 进行人工校验，确认新密码有效。
3. 同步应用侧配置并清空连接池：
   • 将新密码同步至应用的配置来源（密钥管理系统、环境变量、Kubernetes Secret 等）。
   • 触发应用的滚动重启或刷新配置；清空/重建连接池，避免复用缓存的失败连接。
4. 校验连接字符串/URL 的编码与驱动配置：
   • 若使用 URI/URL 形式的连接串，确保对特殊字符进行百分号编码： 例如：@ → %40，: → %3A，/ → %2F
   • 对于 JDBC，请使用合法的 JDBC URL 且避免在 URL 中直接嵌入未编码的密码；优先使用独立的密码参数或安全凭据提供方式。
5. 确认认证方式与 pg_hba.conf 匹配：
   • 确保 pg_hba.conf 中匹配到该客户端来源的首条规则要求 scram-sha-256，且服务端已启用 SSL；修改后执行： SELECT pg_reload_conf();
   • 若存在多条可能匹配的规则，调整顺序确保命中期望的 scram-sha-256 规则。
6. 针对“定时轮换”的稳态做法（防止再次发生）：
   • 在轮换窗口内同时接受新旧密码一小段时间（分阶段发布），先更新应用侧，再撤销旧密码。
   • 为连接池启用失败快速切换策略（如短 TTL/最大存活时间），降低旧连接存活导致的认证抖动。

技术参考：

• PostgreSQL 官方文档（客户端认证 / SCRAM）：https://www.postgresql.org/docs/current/auth-password.html
• PostgreSQL 错误代码（SQLSTATE 28P01 invalid_password）：https://www.postgresql.org/docs/current/errcodes-appendix.html
• pg_hba.conf 配置说明：https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
• 连接字符串与 URI 编码（libpq）：https://www.postgresql.org/docs/current/libpq-connect.html
• PostgreSQL JDBC（pgjdbc）连接与认证说明：https://jdbc.postgresql.org/documentation/usage/connecting/

错误代码：Redis RESP 错误：-ERR max number of clients reached

错误描述： 在 2025-12-01T11:30:05Z，客户端连接被拒绝：Redis 实例达到并超过最大客户端连接数限制。监控信息显示 maxclients=10000、connected_clients=10052、blocked_clients=120。业务在 QPS 突增至平时约 3 倍并持续 8 分钟后出现该错误；应用侧每实例最大连接数为 500，且未启用重试退避策略，导致短时间内出现连接风暴与连接耗尽。

可能原因：

1. 总体并发连接数超过 Redis 的 maxclients 限制；多实例应用的连接池上限之和过大，且缺少退避/限流导致瞬时建连放大。
2. 存在较多阻塞或长耗时操作（blocked_clients=120），连接被长期占用，挤占可用连接名额。
3. 客户端连接复用不足或存在连接泄漏（短周期频繁建连/未及时释放），在高峰时叠加放大。

解决方案： 立即缓解

1. 启用连接重试的指数退避与抖动：为连接失败设置逐步延迟重试与随机抖动，避免同时大规模新建连接。
2. 临时下调每个应用实例的连接池上限，确保全体应用的连接总和不超过 maxclients 的 60%～70%，并预留复制、监控等系统连接名额。
3. 启用连接复用与命令管道化，避免按请求新建/销毁连接。
4. 在具备权限的前提下，清理异常或长时间空闲的连接：
   • 使用 CLIENT LIST 定位 IDLE 时间长或处于阻塞状态的连接
   • 通过 CLIENT KILL 结合 IDLE > N 等过滤条件，分批释放空闲/异常连接
5. 如确有需要且资源允许，可临时提升 maxclients（同时确认并提升操作系统可用文件描述符上限），缓解高峰期拒绝连接；高峰过后恢复为安全值。

根因与长期优化

1. 连接池容量规划：按 maxclients × 0.7 ÷ 应用实例数估算每实例连接上限，避免总量逼近上限；对只读/后台任务单独限额。
2. 在客户端统一启用带抖动的重试退避与连接超时；对连接失败快速失败并限流排队，避免瞬时连接风暴。
3. 优化/替代阻塞型命令：缩短 BLOCK 超时时间，或改用异步/非阻塞方案；定期检查慢操作，降低连接长时间占用。
4. 在流量突增场景启用限流与排队，确保连接增长受控。
5. 持续监控并告警：connected_clients、blocked_clients、rejected_connections、instantaneous_ops_per_sec；结合 SLOWLOG 排查导致连接占用的慢操作。

技术参考：

• maxclients 配置说明：https://redis.io/docs/latest/operate/oss_and_stack/management/config-file/#maxclients
• CLIENT LIST 命令：https://redis.io/commands/client-list/
• CLIENT KILL 命令：https://redis.io/commands/client-kill/
• INFO（含 clients 指标）：https://redis.io/commands/info/
• SLOWLOG 命令：https://redis.io/commands/slowlog/