部署|3年部署3000套PG实例的架构设计与踩坑经验( 六 ) mysql|pg|postgresql|经验|架构

多副本的高可用方式，维护简单，但使用起来有一些限制，比如不支持Citus MX，写入性能下降明显等等，Citus官方手册上也认为多副本高可用只适合append only的业务场景。
因此，Citus更加通用的高可用方式是由底层PG做高可用，即CN节点以及下面每个Worker节点都采用流复制的方式部署一对主备机器。
Q9：有没有一个搭建citus集群的具体实施说明呢？
A：Citus部署实施相关的问题，可以参考一下《Citus生产部署和维护.pptx》(https://pan.baidu.com/s/1eRQsdAa)。
另外，Citus集群里每个节点都是PG，这些PG节点的参数配置以及HA部署和普通的PG是一样的，参考PG的相关资料即可。
Q10：磁盘是怎么规划的？如何规划性能更好？使用raid5、raid10还是单盘raid0？
A：对磁盘的规划需求，PG和其他数据库应该是类似的。raid5、raid10还是单盘raid0这其实是一个可靠性，性能还有成本的取舍，大家可以根据自己的情况判断。我们目前用的是raid5。
Q11：max_locks_per_transaction 这个参数有推荐的值吗？感觉这个参数和内存使用有很大的关系。
A：这个默认值是64，通常默认值应该就可以覆盖绝大多数情况不需要修改。每个锁占用的空间都不是很大，只要不把这个参数调得特别大，锁应该不是最消耗内存的地方。
Q12：Pacemake集群安全吗？
A：Pacemaker+corosync的HA方案中它的集群元数据存在每个集群节点上并实时同步，但是它的元数据的同步协议不是强一致的协议，一旦网络分区，有脑裂风险。
所以，基于Pacemaker的PG HA需要配置物理的fence设备防止脑裂，特别是一主一从的架构。
2020 Gdevops全球敏捷运维峰会·北京站即将于12月11日举办，部分精彩议题先睹为快：

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