Postgresql 如何选择正确的关闭模式

停止数据库的命令：

shutdown-mode有如下几种模式：

1. smart: 等所有的连接中止后，关闭数据库。如果客户端连接不终止， 则无法关闭数据库。

开启一个空会话：

用smart关闭数据库：

2. fast: 快速关闭数据库， 断开客户端的连接，让已有的事务回滚，然后正常关闭数据库。

查看关闭日志：

会话被强制中断，然后关闭数据库。

起一个事务，然后测试关闭：

不提交， 然后用FAST MODE去关闭数据库：

查看日志：

同样是直接中断会话， 而不去管事务有没有提交。

没有提交的数据， 在重启之后并不能查到。

3. immediate: 立即关闭数据库，立即停止数据库进程，直接退出，下次启动时会进行实例恢复。

关闭数据库：

查看日志：

启动数据库：

查看日志：

查看数据：

提交的数据已通过实例恢复。

小结：

对比以上三种关库模式：

smart最为安全，但最慢， 需要将所有连接都断开后，才会关库，默认关库模式。

fast强制中断会话，而不管有操作有没有提交，在做系统维护（系统维护时一般应用都正常关闭了，或者不再会有事务操作。）时，需要这种模式来关闭数据库。

immediate最暴力的方式，不管数据有没有落盘（POSGRE是遵循WAL机制），就直接关掉， 待启动时进行实例恢复， 如果在关库前有大量的事务没有写入磁盘， 那这个恢复过程可能会非常的漫长。

补充：postgresql 异步 stream replication 环境关闭 master 的验证

os: ubuntu 16.04

db: postgresql 9.6.8

验证在异步 stream replication环境下，主动关闭master时，数据是否有丢失，能丢失多少。

版本

用 pgbench 模拟数据库的大量数据操作

关闭 master

提升 slave

查看 old master 的 xlog location

可以看到 lsn: 0/16000028, prev 0/152C9A10, desc: CHECKPOINT_SHUTDOWN redo 0/16000028;

查看 new master 的 .history文件

可以看到关键记录

而 END_OF_RECOVERY 对应的 lsn 为 0/16000098，和 00000002.history 时间线文件的内容完全一致。

所以在异步 stream replication 环境下，主动关闭master时，会将最后一条记录(CHECKPOINT_SHUTDOWN)发送给slave，不会造成数据的丢失。

而 synchronous_commit = on 保证事务有两份持久化的落盘数据。

分析 pg_log 日志

old master 上的最后几条日志

注意倒数第二条信息 streaming 0/16000098 ，说明当时的master关闭时，已经和salve沟通过，确认已经接收到 END_OF_RECOVERY 之前所有的数据了。

old slave 日志

信息也是相当的清晰。

wal_retrieve_retry_interval = 5s 控制 salve 到 master 失败时，再次重试的等待时间。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方，望不吝赐教。

原文链接：https://www.cnblogs.com/o-to-s/articles/6881646.html