3年部署3000套PG实例的架构设计与踩坑经验( 二 )

本文插图
可靠性对比
在可靠性方面，根据我们的测试和实际的生产运行，发现PostgreSQL也优于MySQL 。
1）复制延迟
MySQL在高并发写入场景很容易产生复制延迟，相同测试条件下PostgreSQL不仅写入的TPS更高而且没有观察到复制延迟。根据我们的测试， MySQL从库应用事务的速度在1w/s左右， PostgreSQL备库应用事务的速度则在10w/s以上。
产生这么大差异的原因在于MySQL是逻辑复制，主库的每条SQL在从库上都要完整的执行一遍， MySQL的从库即使启用并行复制，也难以达到主库的并行度。 PostgreSQL的物理复制，备库直接修改被变更的数据块即可，所以应用日志的速度很快。为确保MySQL的稳定运行，我们要求业务在使用MySQL时，单库的写入TPS不超过5000 。

本文插图
2）故障恢复
【3年部署3000套PG实例的架构设计与踩坑经验】在故障模拟测试和实际的生产运行环境中，我们发现MySQL在遇到宕机， RAID卡重置等硬件故障后容易出现主备数据不一致或者数据损坏无法启动的问题；同等条件下PostgreSQL出问题的概率小得多，通常重启就可以自动恢复。
对于普通的宕机我们可以通过切备机快速恢复生产，但是如果是断电导致的大面积宕机，就需要数据库在供电恢复后能快速启动快速恢复。宕机恢复对数据库来说是一项基本能力，但是在一些极端条件下，数据库也可能无法自动恢复。
下面这个表是在数据库的存储设备缺少掉电保护情况下发生断电故障后的测试数据。

本文插图
从上面可以看出PostgreSQL表现出了很强的健壮性，我们分析其主要原因有下面几点：

PostgreSQL的checkpoint周期一般比较长(我们配置的是半小时) ，可以修复更长时间内的数据错误；
PostgreSQL的WAL中保留有被更新页面的完整数据，可以整体替换数据文件中错误的的页面；
PostgreSQL的数据文件是heap结构，页面之间各自独立，容易恢复。

作为对比， MySQL使用了fuzzy checkpoint ，每隔7秒甚至更短的时间就要进行一次checkpoint 。在flush不能确保持久化的情况下，很近时间内产生的数据不一致就会导致数据库无法恢复，即使用了强制恢复模式(innodb_force_recovery=6) 。
另外，极端情况下数据文件出现坏页又不能通过备份恢复时， PostgreSQL支持设置一个参数再重启就可将坏掉的页面清零快速恢复生产；MySQL没有类似的功能，而且MySQL的索引组织表的页面之间有逻辑关系，技术上要做到这一点也比较困难。
选型结论
通过技术选型，我们决定引入PostgreSQL ，通过MySQL和PostgreSQL的组合来替代线上的商业数据库。在具体系统的数据库选型上，还需要考虑业务的使用习惯，周边工具配套等实际情况。
总体上遵守以下的规范进行数据库选型：

OLTP

MySQL + MyCAT
PostgreSQL + Citus

OLAP

PostgreSQL + Citus
GreenPlum

三、PosgreSQL的落地
业务场景

本文插图
我们上线的第一个PostgreSQL业务系统是一个实时大数据处理系统。这个系统的主要业务流程是从各个其它业务系统里面抽取相关数据放到它的数据库明细表里，然后再定时通过存储过程汇总明细表生成报表提供给分析平台进行展示。