为什么停库可能会很慢？

文档用途

在实际生产环境中，运维人员会遇到执行 pg_ctl stop 命令后需要等待一段时间后才能将数据库关闭。等待时间好像没有规律，有时只需一两秒，有时却需要几分钟。那么是什么原因导致该问题的出现呢？本文档旨在帮助理解为何某些情况下停库速度需要花费较长的时间。

详细信息

数据库有3种停库模式：
“Smart”模式等待所有客户端断开连接以及任何在线备份结束。如果该服务器是热备，一旦所有的客户端已经断开连接，恢复和流复制将被终止。
“Fast”模式（默认）不会等待客户端断开连接并且将终止进行中的在线备份。所有活动事务都被回滚并且客户端被强制断开连接，然后服务器被关闭。
“Immediate”模式将立刻中止所有服务器进程，而不是做一次干净的关闭。这将导致下一次重启时进行一次崩溃恢复。

简单点说就是：
smart ： 等待client进程自己断开连接，最后执行检查点。
fast： 主动断开client进程，最后执行检查点。
immediate： 直接强制关闭服务，不做检查点，但是启动时需要做崩溃恢复。

事实上，除了client进程以后，数据库可能会有 walsender 进程、归档进程等。immediate 模式不去说，当使用smart模式和fast 模式时，这些进程会做什么操作？

归档进程：

发起最后一次归档操作，将所有状态为.ready的wal日志进行归档，除非中间archive_command遇到错误，否则要等所有的.ready文件都归档成功。

walsender进程：

如果有walsender进程存在（例如有standby，有pg_basebackup，有pg_receivewal等利用流复制协议的客户端就会存在walsender进程），那么要等walsender将所有未发送完的wal日志都发送给下游后才可关闭该进程。

了解了归档进程和walsender进程需要执行的操作后，我们也就明白为什么有时候停库会花费很长的时间， wal没有发送完成，wal日志未归档完成都会导致这种情况的发生。

checkpoint进程：

检查点是PostgreSQL用来保证数据一致性的机制。在关闭数据库时，系统会执行一个完整的检查点操作，确保所有未写入磁盘的数据都被刷写到磁盘上。如果检查点操作耗时较长，关机时间也会随之变长。在计划停服务前，可登陆数据库手动触发一次checkpoint，待本次检查点完成后关闭数据库服务，可避免此情况的出现。