作者
digoal
日期
2021-04-28
标签
PostgreSQL , redo , 差异 , HA , walminer , WAL , XLOG , 修复
背景
PostgreSQL 常见的HA架构: 双机采用流复制构建主从实例. 这种架构的问题是, 在极端情况下, 发生HA时主节点的WAL可能没有完全发送给从库, 此时激活从库显然和原来的主库有一定的差距, 可能丢失部分事务信息.
如果要做0丢失怎么搞?
1、采用同步模式. 但是如果要同时提供可用性保障, 建议至少3个节点, 使用quorum based sync replication.
2、激活从库前, 比较从库的WAL和老的主库WAL文件, 把缺失的wal文件拷贝过来. 这个方法也有一定问题, 会导致HA的过程时间拉长, 因为需要补WAL文件.
如果已经发生了ha切换, 并且从库已经激活了, 此时从库已经启用了新的timeline时间线, 所以无法通过把差异的WAL拷贝过来直接进行物理的wal recovery APPLY, 这种情况怎么办?
1、找到WAL激活位点, 在pg_wal目录中可以找到history文件, 文件内有timeline和对应的激活位点. 根据pg_controldata文件可以看到从库激活后的timeline, 去history文件中找到这个时间线的激活位点. 根据这个位点去主库的WAL文件中找比这个位点大的wal文件.
2、使用WALminer解析差异WAL的内容, 转化成REDO SQL, 交给业务方判断如何修复. (也就是说使用SQL语句来补差异).
为什么需要业务方介入? 因为从库已经激活, 可能有了新的增删改操作, 直接回放差异REDO SQL 可能对数据库造成数据的二次伤害.
WalMiner
https://gitee.com/movead/XLogMiner
PostgreSQL 许愿链接
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
9.9元购买3个月阿里云RDS PostgreSQL实例
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
