PostgreSQL 9.1 飞升之路 (上篇)

PostgreSQL upgrade

以升级 PostgreSQL 9.1 至 PostgreSQL 11 (跨越 9.2、9.3、9.4、9.5、9.6、10 六个大版本) 为例，本文将分享一下过去一年升级数十套 PostgreSQL 生产集群的实际经验。

此步骤同样适用于 PostgreSQL 9.1 之后的大版本升级。

准备工作

数据库升级周知

提前通过邮件或 IM 周知升级信息和相关注意事项，以便相关同学能够提前安排工作并在升级期间进行上线支持。尤其是需要停服务的应用，需要提前周知终端用户停服时间窗口。

检查已有日志有无报错

有没有遇到过这样的情景？

数据库升级后，开发同学发现应用有报错，比如访问某个表没有权限，甚至是某些应用访问不了数据库，抱怨都是数据库升级的问题。此时，把问题 fix 就完事了么？当然不是，还要查明原因，到底是哪个步骤出问题了。查到最后，竟发现升级操作没有问题。这时候可能会想起来查一下之前的数据库日志，如果你还没有删除的话。最后才知道，升级前就存在此问题。

或者数据库升级后，你查看数据库日志，一看没有某些表的访问权限。此时你可能就抓瞎了，一顿操作，终于把问题 fix 了，时间也已经早已过了之前周知的时间窗口。事后再查日志，才知道这是已有问题，与数据库升级无关，白白浪费那么多宝贵的升级时间。

所以有些报错并非是数据库升级造成的，而是升级之前就已经存在问题。此步骤就是尽早发现错误，提前排除与升级无关的错误。

可以通过如下命令检查 PostgreSQL 日志：

grep -i -E 'error:|fatal:|warning:' postgresql-*|less

如有报错，查看报错的上下文：

grep -A 2 -i -E 'error:|fatal:|warning:' postgresql-*|less

Merge ACL

如果集群没有做配置管理(如 Ansible)，或者没有机制保证集群各实例 pg_hba.conf 完全一致或符合一定规则，就需要人工检查对比，避免后续出现主从切换后由于 ACL 不一致而访问不了数据库的情况。

pg_hba.conf 等配置文件建议做配置管理。人工对比的话，那么多行，还集群的各个实例都要对比。写个脚本对比合并吧，不直观且脚本有 bug 不易发现，应用后续受到影响就为时已晚。有些实例还打开了所有子网的访问权限(如 10.0.0.0/8)，你不得不整个集群都打开所有访问权限，然而 ACL 放开了，数据库安全性就降低了。

高版本集群初始化

集群初始化

此处以配置管理自动化为例。

Ansible:

ansible-playbook playbooks/cluster.yml -i inv.ini -e 'server_group=cluster1' -D

Salt:

salt -E 'db[1-2].az1|db3.az2' state.sls cluster

postgres 数据库

若在 postgres 数据库存储了信息，如一些元数据、procedure、view 等，可以选择在初始化集群时