Em um blog recente sobre o que há de novo no PostgreSQL 13, revisamos alguns dos novos recursos desta versão, mas agora vamos ver como atualizar para poder aproveitar todas essas funcionalidades mencionadas .
Atualizando para o PostgreSQL 13
Se você deseja atualizar sua versão atual do PostgreSQL para esta nova, você tem três opções nativas principais para realizar esta tarefa.
-
Pg_dump/pg_dumpall:É uma ferramenta de backup lógico que permite despejar seus dados e restaurá-los no nova versão do PostgreSQL. Aqui você terá um período de inatividade que irá variar de acordo com o tamanho dos seus dados. Você precisa parar o sistema ou evitar novos dados no nó primário, executar o pg_dump, mover o dump gerado para o novo nó do banco de dados e restaurá-lo. Durante esse tempo, você não pode escrever em seu banco de dados PostgreSQL primário para evitar inconsistência de dados.
-
Pg_upgrade:É uma ferramenta do PostgreSQL para atualizar sua versão do PostgreSQL no local. Pode ser perigoso em um ambiente de produção e não recomendamos esse método nesse caso. Usando este método, você também terá tempo de inatividade, mas provavelmente será consideravelmente menor do que usando o método pg_dump anterior.
-
Replicação lógica:Desde o PostgreSQL 10, você pode usar este método de replicação que permite realizar atualizações de versão principais com tempo de inatividade zero (ou quase zero). Dessa forma, você pode adicionar um nó de espera na última versão do PostgreSQL e, quando a replicação estiver atualizada, poderá realizar um processo de failover para promover o novo nó do PostgreSQL.
Então, vamos ver esses métodos um por um.
Usando pg_dump/pg_dumpall
Caso o tempo de inatividade não seja um problema para você, este método é uma maneira fácil de atualizar.
Para criar o dump, você pode executar:
$ pg_dumpall > dump_pg12.outOu para criar um dump de um único banco de dados:
$ pg_dump world > dump_world_pg12.outEntão, você pode copiar este dump para o servidor com a nova versão do PostgreSQL e restaurá-lo:
$ psql -f dump_pg12.out postgresTenha em mente que você precisará parar seu aplicativo ou evitar escrever em seu banco de dados durante este processo, caso contrário, você terá inconsistência de dados ou uma potencial perda de dados.
Usando pg_upgrade
Primeiro, você precisará ter as versões nova e antiga do PostgreSQL instaladas no servidor.
$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64Então, primeiro, você pode executar pg_upgrade para testar a atualização adicionando o sinalizador -c:
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*As bandeiras significam:
-
-b:O antigo diretório executável do PostgreSQL
-
-B:O novo diretório executável do PostgreSQL
-
-d:O antigo diretório de configuração do cluster de banco de dados
-
-D:O novo diretório de configuração do cluster de banco de dados
-
-c:Verifique apenas clusters. Não altera nenhum dado
Se tudo estiver bem, você pode executar o mesmo comando sem o sinalizador -c e ele atualizará seu servidor PostgreSQL. Para isso, você precisa parar sua versão atual primeiro e executar o comando mencionado.
$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.shQuando estiver concluído, como a mensagem sugere, você pode usar esses scripts para analisar o novo servidor PostgreSQL e excluir o antigo quando for seguro.
Usando replicação lógica
A replicação lógica é um método de replicação de objetos de dados e suas alterações, com base em sua identidade de replicação. É baseado em um modo de publicação e assinatura, onde um ou mais assinantes assinam uma ou mais publicações em um nó publicador.
Com base nisso, vamos configurar o editor, neste caso o servidor PostgreSQL 12, da seguinte forma.
Edite o arquivo de configuração postgresql.conf:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4Edite o arquivo de configuração pg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
host all rep1 10.10.10.141/32 md5Use o endereço IP do assinante lá.
Agora, você deve configurar o assinante, neste caso o servidor PostgreSQL 13, da seguinte forma.
Edite o arquivo de configuração postgresql.conf:
listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8Como este PostgreSQL 13 será o novo nó primário em breve, você deve considerar adicionar os parâmetros wal_level e archive_mode nesta etapa, para evitar uma nova reinicialização do serviço posteriormente.
wal_level = logical
archive_mode = onEsses parâmetros serão úteis se você quiser adicionar uma nova réplica ou usar backups PITR.
Algumas dessas alterações exigem a reinicialização do servidor, portanto, reinicie o editor e o assinante.
Agora, no editor, você deve criar o usuário a ser utilizado pelo assinante para acessá-lo. A função utilizada para a conexão de replicação deve ter o atributo REPLICATION e, para poder copiar os dados iniciais, também precisa do privilégio SELECT na tabela publicada:
world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANTVamos criar a publicação pub1 no nó do editor, para todas as tabelas:
world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATIONComo o esquema não é replicado, você deve fazer um backup em seu PostgreSQL 12 e restaurá-lo em seu PostgreSQL 13. O backup será feito apenas para o esquema, pois as informações serão replicadas no transferir.
No PostgreSQL 12, execute:
$ pg_dumpall -s > schema.sqlNo PostgreSQL 13, execute:
$ psql -d postgres -f schema.sqlDepois de ter seu esquema no PostgreSQL 13, você precisa criar a assinatura, substituindo os valores de host, dbname, user e password pelos que correspondem ao seu ambiente.
world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTIONO acima iniciará o processo de replicação, que sincroniza o conteúdo inicial das tabelas na publicação e, em seguida, inicia a replicação de alterações incrementais nessas tabelas.
Para verificar a assinatura criada, você pode usar o catálogo pg_stat_subscription. Essa exibição conterá uma linha por assinatura para o trabalhador principal (com PID nulo se o trabalhador não estiver em execução) e linhas adicionais para trabalhadores que manipulam a cópia de dados inicial das tabelas inscritas.
world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid | 16421
subname | sub1
pid | 464
relid |
received_lsn | 0/23A8490
last_msg_send_time | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn | 0/23A8490
latest_end_time | 2021-07-23 22:42:26.358605+00Para verificar quando a transferência inicial está concluída, você pode verificar a variável srsubstate no catálogo pg_subscription_rel. Este catálogo contém o estado de cada relação replicada em cada assinatura.
world=# SELECT * FROM pg_subscription_rel;
srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
16421 | 16408 | r | 0/23B1738
16421 | 16411 | r | 0/23B17A8
16421 | 16405 | r | 0/23B17E0
16421 | 16402 | r | 0/23B17E0
(4 rows)Descrições das colunas:
-
srsubid:Referência à assinatura.
-
srrelid:Referência à relação.
-
srsubstate:Código de estado:i =inicializar, d =dados estão sendo copiados, s =sincronizado, r =pronto (replicação normal).
-
srsublsn:Fim do LSN para estados s e r.
Quando a transferência inicial estiver concluída, você terá tudo pronto para apontar sua aplicação para o seu novo servidor PostgreSQL 13.
Conclusão
Como você pode ver, o PostgreSQL tem diferentes opções de atualização, dependendo de seus requisitos e tolerância ao tempo de inatividade.
Não importa que tipo de tecnologia você esteja usando, manter seus servidores de banco de dados atualizados realizando atualizações regulares é uma tarefa necessária, mas difícil, pois você precisa ter certeza de que não haverá perda de dados ou inconsistência de dados após a atualização. Um plano detalhado e testado é a chave aqui e, claro, deve incluir uma opção de reversão, por precaução.
