Criei um backup do meu banco de dados em um PostgreSQL 11.6 (com extensão TimescaleDB 1.60) usando pg_dump
:
PGPASSWORD=mypassword pg_dump -h 127.22.0.4 -p 5432 -U postgres -Z0 -Fc database_development
e restaurou-o em um novo servidor executando as mesmas versões do PostgreSQL 11.6 (com extensão TimescaleDB 1.60) usando pg_restore
. Para a restauração, executei os seguintes comandos psql
como usuário postgres
:
CREATE DATABASE database_development;
\c database_development
CREATE EXTENSION timescaledb;
SELECT timescaledb_pre_restore();
\! time pg_restore -Fc -d database_development /var/lib/postgresql/backups/database_development_2020-02-29
SELECT timescaledb_post_restore();
O tamanho do banco de dados original era de 389 GB, mas o banco de dados restaurado era de 229 GB. Esses tamanhos foram obtidos executando
select pg_size_pretty(pg_database_size('database_development'))
Algumas diferenças:
O banco de dados antigo é armazenado em uma partição ext4, enquanto o novo banco de dados é armazenado em um sistema de arquivos ZFS com compactação desabilitada. Ambas as instâncias de banco de dados estão sendo executadas em um contêiner do Docker com um host Ubuntu 18.04.
Pergunta: Como podemos explicar as diferenças nos tamanhos dos bancos de dados? Não foram encontrados erros durante o pg_dump
e pg_restore
.
O despejo não leva em conta as tuplas mortas e só leva em consideração as tuplas vivas, mas as tuplas mortas levam em consideração o espaço, portanto, a diferença de espaço.
O motivo é que o dump, sendo lógico, só criará instruções para inserir seus dados e as linhas mortas seriam invisíveis para ele. Se você tiver muitas atualizações e exclusões acontecendo ou, em outras palavras, seu banco de dados for altamente transacional, ele criará mais versões de linhas mortas e precisará de um vácuo agressivo para lidar com o inchaço também. Se e quando você comparar as contagens de linhas mortas versus vivas, antes e depois da restauração, você verá a diferença.
Além disso, apenas para estar em um lado mais seguro, execute uma análise manual de vácuo no db após uma restauração de despejo, vi no passado que, devido a uma estimativa errada, o planejador altera o plano ideal a ser usado para as consultas.