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 失败时,再次重试的等待时间。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方,望不吝赐教。