Electric-SQL 项目中的数据库不存在错误处理机制

在 Electric-SQL 项目中，我们遇到了一个关于数据库连接管理的技术挑战：当底层 PostgreSQL 数据库被删除后，系统如何处理这种不可恢复的错误状态。本文将深入分析这一问题及其解决方案。

问题背景

在分布式数据库系统中，数据库实例可能因各种原因被删除或不可用。Electric-SQL 作为 PostgreSQL 的扩展层，需要稳健地处理这种异常情况。当前系统在遇到数据库不存在错误时，会产生以下行为链：

1. 数据库连接丢失
2. 系统尝试多次重连（均失败）
3. 系统尝试清理租户资源
4. 清理操作因"database does not exist"错误而失败

这种错误最终会以不可恢复的状态停留在系统中，影响用户体验和系统稳定性。

错误表现分析

错误的具体表现为 PostgreSQL 返回的特定错误结构：

{
  "code": "XX000",
  "severity": "ERROR",
  "message": "database \"write-patterns-pr-2479\" does not exist"
}

这种错误属于 PostgreSQL 的内部错误(XX000)，表明请求的数据库确实不存在于服务器上。从系统设计角度看，这是典型的不可恢复错误，因为数据库被删除后无法通过重试自动修复。

现有处理机制

当前系统已经实现了针对"slot无效"错误的特殊处理逻辑。当检测到复制槽无效时，系统会：

1. 发送栈事件通知
2. 启动异步任务关闭相关监督树
3. 停止对该错误的进一步处理

这种模式为处理不可恢复错误提供了良好范例，但尚未扩展到其他类型的致命错误。

解决方案设计

基于现有架构，我们提出以下改进方案：

1. 错误分类扩展

在stop_if_fatal_error函数中增加对数据库不存在错误的识别和处理：

defp stop_if_fatal_error(
       %Postgrex.Error{
         postgres: %{
           code: :internal_error,
           message: "database \"" <> _ <> "\" does not exist",
           pg_code: "XX000"
         }
       } = error,
       state
     ) do
  # 触发清理流程
  handle_fatal_database_error(state, error)
  {:noreply, state}
end

2. 资源清理策略

对于这类错误，系统应采取以下步骤：

1. 标记相关数据源为错误状态
2. 记录详细的错误信息
3. 通知相关监控系统
4. 释放相关资源

3. 用户界面考虑

从用户体验角度，我们建议：

1. 在管理界面明确显示错误状态
2. 提供手动删除功能
3. 考虑添加自动清理的配置选项

技术实现细节

实现这一改进需要注意以下技术要点：

1. 错误模式匹配：需要精确匹配PostgreSQL返回的错误消息结构
2. 资源释放顺序：确保在关闭连接前完成必要的清理工作
3. 并发控制：处理可能的竞态条件
4. 状态一致性：保证系统状态在各种异常情况下的正确性

未来优化方向

长期来看，可以考虑：

1. 实现更全面的错误分类系统
2. 添加自动修复机制（如数据库重建）
3. 改进用户通知系统
4. 增强监控和告警能力

通过这种系统化的错误处理机制，Electric-SQL 能够更稳健地应对底层数据库异常，提高系统的整体可靠性。