CLN节点数据库损坏问题分析与修复方案

问题背景

在运行Core Lightning (CLN) v24.11.1版本时，节点在同步区块高度至882019时突然崩溃，错误日志显示数据库断言失败。具体表现为db_col_sha256函数中关于payment_hash列长度的断言失败，导致节点无法重新启动。

错误现象

节点崩溃时显示的关键错误信息包括：

lightningd: db/bindings.c:572: db_col_sha256: Assertion `db_column_bytes(stmt, col) == size' failed.

这表明在读取channel_htlcs表中的payment_hash列时，获取的数据长度与预期不符（预期为32字节的SHA256哈希值）。

根本原因分析

通过数据库查询发现，部分HTLC记录的payment_hash列值为NULL或长度不正确。正常情况下，每个HTLC都应有一个32字节的支付哈希值。这种数据损坏可能是由于：

1. 数据库事务未正确提交，导致部分数据不完整
2. 程序逻辑错误，在异常情况下未正确设置支付哈希
3. 并发操作导致的数据不一致

值得注意的是，损坏的HTLC记录ID是连续的，表明问题可能发生在某个特定时间段或特定操作期间。

修复方案

临时解决方案

对于已经损坏的数据，可以采用以下SQL语句将所有无效的payment_hash设置为全零值（"all balls"）：

UPDATE channel_htlcs
    SET payment_hash = unhex('0000000000000000000000000000000000000000000000000000000000000000')
    WHERE length(payment_hash) = 32 IS NOT TRUE;

这种方法比直接删除记录更安全，至少能保证节点可以启动。但需要注意：

1. 这些HTLC可能无法正常结算
2. 对端节点尝试解析这些HTLC时可能出现问题
3. 可能导致资金损失，需要后续人工核查

长期改进建议

1. 数据库约束增强：应在数据库模式中添加NOT NULL约束，确保关键字段如payment_hash不会出现空值
2. 事务处理优化：改进事务提交逻辑，确保数据一致性
3. 数据验证机制：增加写入前的数据验证，防止无效数据进入数据库
4. 容错处理：对于非关键性错误，应考虑记录警告而非直接崩溃
5. 备份策略：实施定期数据库备份和验证机制

后续影响

修复后节点可以重新启动，但需要注意：

1. 部分通道可能仍处于异常状态
2. 路由活动可能需要时间恢复
3. 需要监控资金流动，确认没有进一步问题
4. 建议逐步重建与主要通道伙伴的连接

经验总结

这次事件凸显了关键金融系统数据完整性的重要性。对于类似CLN这样的金融基础设施：

1. 数据库设计应更加严谨，利用数据库本身的约束机制
2. 错误处理应更加健壮，避免单点故障导致整个系统崩溃
3. 应建立更完善的数据验证和恢复机制
4. 定期备份和验证数据库健康状态至关重要

对于运行重要节点的用户，建议考虑实施数据库复制方案，并定期验证数据完整性，以降低类似风险。