嵌入式Linux双进程读写BerkeleyDB最优配置与故障排查

当前出现的page on free list、DB_RUNRECOVERY致命错误，本质是三个配置和代码逻辑错误导致的数据库页损坏：

• 双进程操作同一个DB文件时没有初始化共享数据库环境（DB_ENV），默认模式下多进程并发读写无任何跨进程锁保护，相当于两个进程独立写同一个普通文件，必然会出现文件结构错乱
• 读进程遍历游标过程中直接删除当前记录，之后继续调用cursor.next()属于非法操作，会破坏BDB内部页指针
• 每次单条操作就调用全量sync()，高频强制刷盘在嵌入式Flash上容易出现写撕裂，进一步放大损坏概率

优先选DB_QUEUE，是最适配当前场景的选型：

• 天生支持FIFO语义，正好匹配CAN报文按写入顺序消费、处理完删除的业务逻辑，不需要自己生成UUID当主键
• 定长记录存储结构不需要维护B树排序索引，相同数据量下内存占用比DB_BTREE低30%以上，完全符合内存受限的要求
• 内置原子消费操作，支持跨进程安全的"读+删"逻辑，不需要额外实现锁

不推荐DB_RECNO：本质是整数键的B树变种，依然要维护B树索引结构，内存开销高于Queue，也没有内置的并发队列访问保护。当前用的DB_BTREE适合随机键值查询场景，顺序写入顺序消费的逻辑完全用不上B树能力，平白增加内存和写入开销。

必须启用轻量化事务，不要用默认的重事务配置（内存开销太大不适合嵌入式）：

• 第一步必须先初始化共享DB_ENV，两个进程必须挂载到同一个存储路径下的数据库环境，才能启用跨进程共享锁、共享内存缓存池，从根源解决并发写坏页的问题
• 数据库open标志必须添加DB_THREAD | DB_AUTO_COMMIT，不要开DB_DIRTY_READ（会读到半写入的损坏数据）
• 环境初始化时开启DB_TXN_WRITE_NOSYNC标志，关闭事务预写日志的强制刷盘逻辑，内存占用比默认事务模式低60%以上；本身已配置跳帧能力，可接受少量报文丢失，完全不需要事务的零丢失强一致保证，只要数据库不损坏即可
• 不需要开启全量事务日志：日志会额外占用Flash空间，不需要时间点恢复能力，只要保证进程重启后未删除的存量报文可访问即可
• 环境初始化必须传入DB_INIT_LOCK | DB_INIT_MPOOL | DB_INIT_TXN三个标志，启用跨进程锁、共享内存池、轻量事务能力。

当前每次单条写/删操作就调用sync()的做法完全错误：

• BDB的sync()是把整个缓存区的脏页全量刷盘，不是单条记录刷盘。按10-25ms一次的写入频率，每秒要做几十次全量刷盘，嵌入式Flash的IO带宽根本扛不住，刷盘过程中被另一个进程的写入打断就会出现页损坏
• 游标遍历删除的逻辑本身就有问题：不要持游标长时间遍历，更不要在游标遍历过程中删除记录后继续移动游标。如果用Queue类型，直接用内置的消费接口原子完成读+删，根本不需要游标
• 最优同步策略用定时+批量阈值触发：
  • 写进程累计写入16条报文，或者距离上次sync超过100ms时，执行一次sync
  • 读进程一次批量消费最多20条报文，全部处理完成后再执行一次sync
  • 单条操作后绝对不要调用sync，90%以上的IO都是完全浪费的。

完全可以不手动调用sync，只要做两个配置就能满足落盘要求：

• 给DB_ENV设置合理的共享缓存大小：嵌入式设备建议设为128KB~256KB即可，不要开太大占用宝贵内存，配置接口为set_cachesize(0, 256*1024, 1)
• 开启自动checkpoint刷盘：配置每累计写入32KB数据自动触发一次checkpoint把脏页刷到磁盘，不需要手动调用sync
• 这种配置下，系统掉电最多丢失最近32KB的写入数据（约几十条CAN报文），完全符合场景可靠性要求，也不会出现高频刷盘的IO冲击。

• 读进程Python侧废弃当前的游标遍历逻辑：如果用Queue类型，直接调用消费接口原子读取并删除队首记录，不需要游标，也不会出现非法游标操作的问题；如果暂时不换B树类型，每次处理完一条记录就关闭游标，下一次读取重新开新的游标取first记录，不要循环调用cursor.next()
• C侧写进程废弃单条写入就sync的逻辑，改成批量+定时sync
• 两边进程都必须通过同一个DB_ENV打开数据库，禁止直接裸打开DB文件。

内容的提问来源于stack exchange，提问作者Sash