PostgreSQL 备份和恢复,大小不同

And*_*ria 6 postgresql

我的 postgreSQL 中有一个 Wordpress 数据库,在 phppgadmin 中,该数据库的大小为 273 MB。

我跑sudo -u postgres pg_dump -Fp -f wordpress.sql wordpress做数据库备份,结果是一个只有 18MB 的文件。

我已将原始数据库的名称更改为 Wordpress2,然后:

我创建了一个名为 Wordpress 的新数据库并进行了恢复sudo -u postgres psql wordpress < wordpress.sql ,结果是一个大小为 19 MB 的数据库,是否缺少某些内容?

下面是phppgadmin的打印,wordpress作为导入的备份,wordpress2作为原始数据库。 管理员

自动吸尘器

postgres=# select setting from pg_settings where name = 'autovacuum';
 setting
---------
 on
(1 row)
Run Code Online (Sandbox Code Playgroud)

索引空间

postgres=# select pg_size_pretty(sum(pg_relation_size(indexrelid))) from pg_index;
     pg_size_pretty
    ----------------
     2600 kB
    (1 row)
Run Code Online (Sandbox Code Playgroud)

原始数据库大小

postgres=# select pg_size_pretty(pg_database_size('wordpress2'));
 pg_size_pretty
----------------
 273 MB
(1 row)
Run Code Online (Sandbox Code Playgroud)

已恢复

postgres=# select pg_size_pretty(pg_database_size('wordpress'));
 pg_size_pretty
----------------
 20 MB
(1 row)
Run Code Online (Sandbox Code Playgroud)

我复制了原始数据库

CREATE DATABASE newdb WITH TEMPLATE wordpress2 OWNER postgres;
Run Code Online (Sandbox Code Playgroud)

并在这个“newdb”中进行了一次真空

vacuumdb -f -d newdb -z -v
Run Code Online (Sandbox Code Playgroud)

结果是“newdb”从 273MB 减少到 17MB

postgres=# select pg_size_pretty(pg_database_size('newdb'));
 pg_size_pretty
----------------
 17 MB
(1 row)
Run Code Online (Sandbox Code Playgroud)

And*_*ria 12

我会回答我自己的问题,

来自:https : //stackoverflow.com/questions/13505785/postgresql-database-size-is-less-after-backup-load-on-heroku

这是因为它的MVCC系统。每次更新数据库中的任何记录时,它都会创建此记录的另一个“版本”,而不是重写前一个。这个“过时”的记录将被 VACUUM 进程删除,当它们不需要时。

我在 PostgreSQL 文档中搜索,我发现: 与使用锁进行并发控制的传统数据库系统不同,PostgreSQL 通过使用多版本模型(Multiversion Concurrency Control,MVCC)来保持数据一致性。这意味着在查询数据库时,每个事务都会看到一段时间前的数据快照(数据库版本),而不管底层数据的当前状态如何。这可以防止事务查看可能由(其他)并发事务更新对相同数据行造成的不一致数据,从而为每个数据库会话提供事务隔离。

使用并发控制而不是锁定的 MVCC 模型的主要优点是,在 MVCC 中,为查询(读取)数据而获取的锁与为写入数据而获取的锁不冲突,因此读取从不阻塞写入,写入从不阻塞读取。

来自:https : //stackoverflow.com/questions/924993/postgresql-database-size-increasing 如果死元组堆积的数量超出了 max_fsm_pages 中可以解释的范围,常规 VACUUM 将无法释放所有内容。最终结果是,随着死空间的不断积累,数据库将随着时间的推移变得越来越大。运行 VACUUM FULL 应该可以解决这个问题。不幸的是,在大型数据库上可能需要很长时间。

如果您经常遇到此问题,则需要更频繁地进行吸尘(autovacuum 在这里可以提供帮助)或增加 max_fsm_pages 设置。运行 VACUUM VERBOSE 时,它会告诉您释放了多少页,并在超出 max_fsm_pages 时向您发出警告,这可以帮助您确定该值应该是多少。有关更多信息,请参阅手册。

来自:postgres 备份/恢复:恢复后的数据库小得多?

也许这只是索引膨胀。VACUUM FULL 对索引膨胀没有帮助,相反,如 8.4 的文档中所述:

不建议将 FULL 选项用于日常使用,但在特殊情况下可能有用。例如,当您删除或更新表中的大部分行并希望表物理缩小以占用更少的磁盘空间并允许更快的表扫描时。VACUUM FULL 通常会比普通的 VACUUM 缩小表格更多。FULL 选项不会收缩索引;仍然建议定期进行 REINDEX。事实上,删除所有索引、VACUUM FULL 并重新创建索引通常更快。

(在最近的版本中,此建议已消失,因为 VACUUM FULL 已以不同方式重新实现)。

请参阅例行驯服和 REINDEX 命令。

重新索引的最简单方法是使用拥有它的 db 用户连接到数据库并发出:

REINDEX database test_db;

理想情况下,它应该在 VACUUM FULL 之后立即完成,并且此时数据库应该收缩到其可能的最低大小。