临时表空间破坏后的 Postgres 恢复
我正在尝试加快 ec2 上 postgresql 的性能。
ec2 节点的结构如下 - 您拥有缓慢、持久的网络附加存储 (EBS)，并且您还拥有快速、易失性存储（临时存储）。即，在系统崩溃时，临时存储将丢失。
为了加快数据库性能，我正在考虑将 postgres temp_tablespaces 设置为临时存储中的目录。然而，临时存储没有持久性保证——在系统崩溃时，它将被完全永久地破坏。
这是否存在数据丢失的风险？原则上，在我看来不应该，因为 temp_tablespace 用于临时对象。但我对 postgres 数据模型不太熟悉 - 这里是否存在我遗漏的危险？
I'm attempting to speed up the performance of postgresql on ec2.
An ec2 node is structured as follows - you have slow, durable network attached storage (EBS), and you also have a fast, volatile storage (ephemeral storage). I.e., in a system crash, ephemeral storage will be lost.
In order to speed up db performance I'm considering setting my postgres temp_tablespaces to a directory living in ephemeral storage. However, ephemeral storage has no durability guarantees - in a system crash it will all be completely and permanently destroyed.
Does this run the risk of any data loss? In principle, it seems to me it should not, since the temp_tablespace is used for temporary objects. But I'm not intimately familiar with the postgres data model - are there dangers here that I'm missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，这应该是安全的，如果在需要临时表的操作完全提交之前崩溃，您应该恢复到操作之前的点。不过，我不知道 Postgresql 是否在重新启动时清除该区域，我会自己检查一下。
现在，一个真正的极客会尝试通过 Amazon 的 memcache 等效项 实现一个文件系统并使用它......
Yes, that should be safe, if you crash before the operation that requires the temporary table is fully committed, you should recover to the point before the operation. Though, I don't know if Postgresql clears that area on a restart, I would check for yourself.
Now a proper geek would try to implement a file system over Amazon's memcache equivalent and use that...