我一直想知道最长的时间,如果运行Postgres(即9.2.4)服务器的sudo重启可以(或肯定会)导致数据丢失或其他问题(例如,无法在系统启动时重新启动服务器).或者,重新启动会向正确关闭的进程发送正确的信号(例如,包括允许事务完成等).
如果您的服务器和硬件配置正确,即使您按下重置按钮,拉动电源线或触发内核崩溃,也不会丢失数据.
PostgreSQL is crash safe because of its write-ahead logging.
原文链接：https://www.f2er.com/postgresql/192399.html在评论中,唯一一个含糊不清的人就是“Zoredache”.
在以下情况下,您只会丢失数据
>您已通过设置fsync = off将Postgresql配置为不安全.
>您正在使用UNLOGGED表,这些表不是崩溃安全的(在这种情况下,您只会丢失未记录表中的数据);
>底层存储系统不是崩溃安全或忽视fsync,就像许多廉价的消费者SSD在没有适当备用电源的情况下对易失性缓存进行回写缓存;
我在in a blog post a few months ago上写了很多.
即使您使用廉价的SSD,只有当您的系统实际断电时,您仍然不会在突然重启时丢失数据.我已经看到一些系统在重置时对磁盘进行电源循环,如果使用廉价的SSD,这些系统会丢失数据.
对于Postgresql来说,“干净”关闭几乎是可选的;突然重启的唯一缺点是,由于在恢复期间应用预写日志所需的时间,数据库可能需要更长的时间才能启动,并且(根据文档)UNLOGGED表将被截断.
即使在所谓的“干净”关闭中,大多数init脚本也只会在有限的时间内等待服务器关闭.大多数init脚本使用“快速”关闭模式,这将中止当前事务,拒绝新会话,并快速但干净地关闭服务器.他们通常会超时,如果这需要太长时间而且只是关闭,有效地依赖于Postgresql的崩溃安全性.
如果要允许当前事务完成,则需要在关闭系统之前手动执行“智能”关闭,或修改init脚本以使用它.智能关机并不总是非常有用,因为一个长时间运行或被放弃的连接可以阻止整个服务器无限期地关闭,让它坐在那里拒绝所有连接.作为第一次尝试,您可以让它运行一分钟或快速关闭之前.
崩溃安全不是没有采取备份的理由 – 并对其进行测试.
