破坏临时表空间后的 Postgres 恢复答案

【问题标题】：Postgres recovery after destruction of temporary tablespace破坏临时表空间后的 Postgres 恢复
【发布时间】：2011-12-09 16:03:13
【问题描述】：

我正在尝试加快 ec2 上 postgresql 的性能。

一个 ec2 节点的结构如下 - 你有一个缓慢的、持久的网络附加存储 (EBS)，你还有一个快速、易失的存储（临时存储）。即，在系统崩溃时，临时存储将丢失。

为了提高数据库性能，我正在考虑将我的 postgres temp_tablespaces 设置为临时存储中的目录。然而，临时存储没有持久性保证——在系统崩溃时，它会被完全永久地销毁。

这是否存在任何数据丢失的风险？原则上，在我看来不应该，因为 temp_tablespace 用于临时对象。但我对 postgres 数据模型并不十分熟悉 - 这里有我遗漏的危险吗？

【问题讨论】：

【解决方案1】：

是的，那应该是安全的，如果您在需要临时表的操作完全提交之前崩溃，您应该恢复到操作之前的点。不过，我不知道 Postgresql 是否会在重新启动时清除该区域，我会自己检查。

现在一个合适的极客会尝试在Amazon's memcache equivalent 上实现一个文件系统并使用它...

【讨论】：

PostgreSQL 不使用事务日志来记录临时日期的内容，但对于临时表没有问题。但问题是表空间字典。在文件系统上销毁时，应手动将其删除到数据库中并手动重新创建-仅在少数情况下会在恢复过程中重新创建。