Atualizando seu banco de dados para o PostgreSQL versão 10 - O que você deve saber

Opções de atualização

1. Tradicional pg_dumpall(pg_dump) / pg_restore(psql)
2. Pg_upgrade tradicional
3. Replicação baseada em gatilho (Slony, auto-escrito)
4. Usando replicação pglógica

Despejo/Restauração Tradicional

pg_dump t > /tmp/f
psql -p 5433 -f /tmp/f

• Embora você possa passar muito tempo com um backup feito, a carga no servidor antigo é tão pequena quanto fazer um backup.
• Esse método é basicamente apenas uma sequência de backup-restauração (potencialmente com alguns feitiços, músicas e percussão)
• Usar este método é a maneira mais antiga de atualizar e foi verificado por MUITAS pessoas

Pg_upgrade tradicional

MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/initdb -D tl0 >/tmp/suppressing_to_save_screen_space_read_it

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/pg_upgrade -b /usr/local/Cellar/postgresql/9.5.3/bin -B /usr/local/Cellar/postgresql/10.2/bin -d t -D tl0 | tail
Creating script to delete old cluster                        ok

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.sh

• Tempo de inatividade mais curto do que o backup/restauração lógico
• Um processo organizado - pg_upgrade atualiza o banco de dados original com dados e estrutura existentes
• Já foi muito usado no passado e ainda seria a preferência para a maioria dos DBAs rodando a versão abaixo de 9.4 (que permite o uso do pglogical)

• Requer tempo de inatividade

Replicação baseada em gatilho

db=# create server upgrade_to_10 foreign data wrapper postgres_fdw options (port '5433', dbname 'dbl0');
CREATE SERVER
Time: 9.135 ms
db=# create user mapping for vao SERVER upgrade_to_10 options (user 'vao');
CREATE USER MAPPING
Time: 8.741 ms
db=# create foreign table rl0 (pk int, t text) server upgrade_to_10 options (table_name 'r');
CREATE FOREIGN TABLE
Time: 9.358 ms

db=# create or replace function tf() returns trigger as $$
begin
 if TG_0P = 'INSERT' then
   insert into r10 select NEW.*;
 elseif TG_0P = 'UPDATE' then
   delete from rl0 where pk = NEW.pk;
   insert into rl0 select NEW.*;
 elseif TG_0P = 'DELETE' then
   delete from rl0 where pk = OLD.pk;
 end if;
return case when TG_0P in ('INSERT','UPDATE') then NEW else OLD end;
end;
SS language plpgsql;
CREATE FUNCTION
Time: 8.531 ms
db=# create trigger t before insert or update or delete on r for each row execute procedure tf(); CREATE TRIGGER
Time: 8.813 ms

db=# insert into r(t) select chr(g) from generate_series(70,75) g;
INSERT 0 6
Time: 12.621 ms
db=# update r set t = 'updated' where pk=2;
UPDATE 1
Time: 10.398 ms
db=# delete from r where pk=1;
DELETE 1
Time: 9.634 ms
db=# select * from r;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 9.026 ms
db=# select * from rl0;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 1.201 ms

db=# select *,current_setting('port') from dblink('upgrade.to.lO','select setting from pg_settings where name=$$port$$') as t(setting_10 text);
 setting_10 | currerrt.setting
------------+------------------
 5433       | 5432
(l row)

Time: 23.633 ms

• Nenhum backup precisa ser feito e nenhum tempo de inatividade é necessário (especialmente você está atrás de algum pgbouncer ou haproxy).

• Alta complexidade de configuração
• Falta de documentação estruturada
• Não muito popular - menos casos de usuários para estudar (e compartilhar)

Replicação lógica com pglogical

• Basicamente sem tempo de inatividade
• Recurso extremamente promissor, muito menos esforço do que a replicação baseada em gatilho

• Ainda muito complexa de configurar (especialmente para versões mais antigas)
• Falta de documentação estruturada
• Não muito popular - menos casos de usuários para estudar (e compartilhar)

Ações a serem tomadas antes do upgrade

• Fazer backup
• Verifique se há espaço em disco suficiente
• Verifique suas extensões (importante que todos os módulos externos também sejam compatíveis com binários, embora isso não possa ser verificado pelo pg_upgrade)
• Certifique-se de usar o mesmo datcollate e datctype e assim por diante (verifique pg_database) no novo banco de dados
• Verifique (DDL + Drop) visualizações, funções, extensões, tipos que podem interromper a atualização
• Use --check antes de realmente pg_upgrade

Ações a serem tomadas após o upgrade

• Consulte pg_upgrade_server.log (se você usou pg_upgrade)
• Execute a análise em bancos de dados atualizados (opcional, pois seria feito por autovacuum, mas você pode escolher quais relações devem ser analisadas primeiro se fizer isso sozinho)
• Pré-aqueça páginas populares (opcional, mas pode melhorar o desempenho no início)

Conclusão

• pg_sequences foram introduzidos, alterando o comportamento do anteriormente popular SELECT * FROM sequence_name - agora apenas last_value | log_cnt | is_called são retornados, ocultando suas "propriedades iniciais" (ajuste qualquer código que dependa de comportamento alterado)
• pg_basebackup transmite WAL por padrão. Após a atualização, talvez seja necessário modificar seus scripts (opção -x removida)
• Todas as ações do pg_ctl estão aguardando a conclusão. Anteriormente, você precisava adicionar -w para evitar tentar se conectar ao banco de dados logo após o início do pg_ctl. Portanto, se você ainda quiser usar o início ou a parada "assíncrona", deverá marcá-lo explicitamente com -W. Talvez seja necessário ajustar seus scripts para que eles se comportem conforme o esperado.
• Todos os scripts para arquivamento de WALs ou monitoramento/controle de replicação de streaming ou PITR precisam ser revisados ​​para ajustá-los aos nomes de xlog alterados. Por exemplo. select * from pg_is_xlog_replay_paused() não mostrará mais o estado do replay dos WALs escravos - você deve usar select * from pg_is_wal_replay_paused() em vez disso. Também cp /blah/pg_xlog/* precisa ser alterado para /blah/pg_wal/* e assim por diante basicamente para todas as ocorrências de pg_xlog. A razão por trás de uma mudança tão grande e não compatível com versões anteriores é resolver o caso em que um newby remove logs de gravação antecipada para "limpar algum espaço" removendo logs e perde o banco de dados.
• Ajuste scripts usando pg_stat_replication para novos nomes (local alterado para lsn)
• Ajuste as consultas com funções de retorno definidas, se necessário
• Se você usava pglogical como extensão antes da versão 10, talvez seja necessário ajustar o valor pg_hba.conf alterando entre "colunas"
• Ajuste os scripts para um novo nome de pg_log que é log, algo como find /pg_data/pg_log/postgresql-*  -mmin +$((60*48)) -type f -exec bash /blah/moveto.s3 .sh {} \; trabalharia. Claro que você pode criar um link simbólico em vez disso, mas uma ação precisaria ser tomada para encontrar os logs no local padrão. Outra pequena alteração nos padrões é log_line_prefix - se sua expressão regular dependesse de um determinado formato, você precisa ajustá-la.
• Se você ainda estava usando senhas não criptografadas em seus bancos de dados Postgres, esta versão completa a remove. Então é hora de resolver as coisas para aqueles que confiaram em --unencrypted...
• O restante das alterações incompatíveis com versões anteriores são muito recentes para serem referenciadas em muito código (min_parallel_relation_size) ou muito antigas (external tsearch2) ou são muito exóticas (remoção do suporte a carimbos de data e hora de ponto flutuante na compilação), portanto vamos ignorá-los. Claro que eles estão listados na página de lançamento.
• Assim como na versão 9.5 a 9.6, talvez seja necessário ajustar seus scripts para consultar pg_stat_activity (uma nova coluna e novos valores possíveis)
• Se você estava salvando/analisando a saída detalhada do vácuo, talvez seja necessário ajustar seu código
• Você também pode dar uma olhada na nova implementação de particionamento - você pode querer refatorar seu "conjunto" existente para estar em conformidade com os novos "padrões"
• verifique a linha do tempo (será redefinida para o novo banco de dados se você pg_upgrade)