我一直想知道sudo reboot
运行 Postgres(即 9.2.4)的服务器是否会(或肯定会)导致数据丢失或其他问题(例如,无法在系统启动时再次启动服务器)。或者,确实reboot
向进程发送适当的信号以允许它们正确关闭(例如,包括允许完成事务等)。
如果您的服务器和硬件配置正确,即使您按下重置按钮、猛拉电源线或触发内核崩溃,您也不会丢失数据。PostgreSQL 是崩溃安全的,因为它的 write-ahead logging。
唯一一个模糊正确的人是评论中的“Zoredache”。
您只会在以下情况下丢失数据:
fsync=off
;UNLOGGED
表,它不是崩溃安全的(在这种情况下,您只会丢失未记录表中的数据);fsync
,就像许多廉价的消费类 SSD 在没有适当备份电源的情况下将写回缓存到易失性缓存一样;即使您使用的是便宜的 SSD,您通常也不会在突然重启时丢失数据,只有在您的系统实际断电时才会丢失。不过,我已经看到一些系统在重置时对磁盘进行电源循环,如果使用便宜的 SSD,这些系统会丢失数据。
“干净”关闭对于 PostgreSQL 来说几乎是可选的;突然重启的唯一缺点是数据库可能需要更长的时间才能启动,因为在恢复期间应用预写日志需要时间,并且(根据文档)UNLOGGED
表将被截断。
即使在所谓的“干净”关闭中,大多数 init 脚本也只会等待服务器关闭的有限时间。大多数初始化脚本使用“快速”关闭模式,这将中止当前事务,拒绝新会话,并快速但干净地关闭服务器。如果这需要太长时间,它们通常会超时并且无论如何都会关闭,有效地依赖于 PostgreSQL 的崩溃安全性。
如果您想允许当前事务完成,您需要在关闭系统之前手动执行“智能”关闭,或者修改您的 init 脚本以使用它。智能关机并不总是很有用,因为一个长时间运行或被放弃的连接可以无限期地阻止整个服务器关闭,让它坐在那里拒绝所有连接。作为第一次尝试,让您运行一分钟或在快速关闭之前很有用。
碰撞安全不是不进行备份并测试它们的借口。
归档时间: |
|
查看次数: |
458 次 |
最近记录: |