为什么停库可能会很慢？

文章目录文档用途详细信息相关文档文档用途在实际生产环境中运维人员会遇到执行 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待本次检查点完成后关闭数据库服务可避免此情况的出现。相关文档