小编jus*_*ile的帖子

我们注意到最近几周我们平台的性能下降，所以我运行了以下命令：

select relname, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze 
from pg_stat_user_tables 
where relname like 'core_%';

并注意到我们的主桌已经一个多星期没有自动清扫了。所以上周我跑了：

vacuum analyse verbose TABLENAME

这似乎有帮助，但我们现在又遇到了同样的问题。仔细检查后，很多表要么从未被分析过（自动或其他方式），除了vacuum analyse上周手动运行之外，没有一个表被手动清理过，而且很多其他表也没有被自动清理过，充其量是几天前，更糟的是几周前。

我对条款的理解如下：

• 真空：从磁盘中清除已删除的记录
• 分析：更新查询规划器

在 中postgres.conf，autovacuum 属性被注释掉了，但是文档指出这是默认打开的，所以我的假设是即使它被注释掉了，它仍然应该打开吗？

有人可以解释为什么这些表不会被频繁地清理和分析，更具体地说，这些没有更新的值实际上对系统有那么大的影响吗？

信息：Postgres 9.1 操作系统：Ubuntu 12.04

输出

SELECT relname as "Table",
pg_size_pretty(pg_total_relation_size(relid)) As "Size",
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
FROM pg_catalog.pg_statio_user_tables 
ORDER BY pg_total_relation_size(relid) DESC;


     Table       | Size | External Size
-----------------+------+---------------
"Primary Table"  | 27G  |     8232M

所以昨晚我们的 PG Slave 在大量重新配置磁盘空间、新驱动器等后空间不足，现在报告以下错误：

FATAL:  could not receive data from WAL stream: FATAL:  requested WAL segment 00000001000018F70000008A has already been removed

根据我所做的阅读，似乎唯一的解决方案是使用 pg_start_backup() 等重新同步从站。基于此，我有几个问题。

1. 有没有更好的方法来修复我只是错过或忽略的奴隶？
2. 在备份之前或备份期间，我是否需要清除从属和/或主服务器上的 WAL 文件？
3. 这段时间pg_start_backup 是否锁定了数据库？

根据要求，可以找到日志文件：http : //pastebin.com/9F8vJh6R，已删除文件的其余部分，因为它只有 5 个小时的相同重复错误

非常感谢