AVISO! Se o seu banco de dados for muito grande, você precisará de muito espaço extra em disco (2x o tamanho do banco de dados) e deve ter muito cuidado com esta atualização!
Acabamos de implementar alterações para atualizar nossa imagem Docker para o PostgreSQL 13. Qualquer administrador de site que reconstrua o Discourse via linha de comando será atualizado para o PostgreSQL 13 a partir do PostgreSQL 12 anterior. Observe que, se você adiara a atualização quando a atualização do PostgreSQL 12 ocorreu em maio, você pode pular essa atualização e ir direto para o PostgreSQL 13.
Se você havia adiado a atualização anteriormente, altere o modelo do PostgreSQL no app.yml de templates/postgres.10.template.yml para templates/postgres.template.yml.
Como em qualquer atualização, é altamente recomendado fazer um backup antes de fazer qualquer coisa.
Atualizando
Guia de Instalação Oficial (contêiner único)
Na sua próxima reconstrução, você verá esta mensagem no final:
-------------------------------------------------------------------------------------
ATUALIZAÇÃO DO POSTGRES CONCLUÍDA
O banco de dados antigo 12 está armazenado em /shared/postgres_data_old
Para concluir a atualização, reconstrua novamente usando:
./launcher rebuild app
-------------------------------------------------------------------------------------
Isso significa que tudo correu bem na atualização! Você só precisa emitir uma nova reconstrução para colocar seu site de volta no ar.
Instalação com Contêiner de Dados
Se você estiver executando uma configuração com um contêiner de dados dedicado baseado no exemplo fornecido em nosso repositório discourse_docker, certifique-se de desligar o PostgreSQL de maneira segura e limpa.
Atualmente, temos jobs em segundo plano executando consultas que levam vários minutos, então desligar o contêiner web ajudará o contêiner de dados a ser desligado com segurança.
./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only
Antes de emitir a primeira reconstrução para o contêiner de dados, você pode seguir o log do PostgreSQL para ver se ele foi desligado corretamente.
Executar um tail -f shared/data/log/var-log/postgres/current deve fornecer o seguinte log se estiver limpo:
2020-05-13 18:33:33.457 UTC [36] LOG: received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG: worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG: shutting down
2020-05-13 18:33:33.479 UTC [36] LOG: database system is shut down
Fazendo uma atualização manual / ambientes com espaço limitado
VOCÊ DEVE FAZER UM BACKUP DOS DADOS DO POSTGRES ANTES DE TENTAR ISSO
Se você estiver em um ambiente com espaço limitado e sem nenhuma maneira de obter mais espaço, pode tentar o seguinte:
./launcher stop app #(ou ambos web_only e data, se for o seu caso)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/12/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/13/data \
tianon/postgres-upgrade:12-to-13
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
./launcher rebuild app #(ou primeiro data e depois web_only, se for o seu caso)
Em meus testes, este procedimento requer menos de 1x o tamanho atual do seu banco de dados em espaço livre.
Adiar a atualização
Se você precisar adiar a atualização na sua próxima reconstrução, pode trocar o modelo do PostgreSQL no seu arquivo app.yml alterando \"templates/postgres.template.yml\" para \"templates/postgres.12.template.yml\".
Isso não é recomendado, pois alguns administradores de site podem esquecer de reverter a alteração depois.
Tarefas opcionais pós-atualização
Otimizando estatísticas do PostgreSQL
Após a atualização, o novo PostgreSQL não terá estatísticas de tabela em mãos. Você pode gerar essas estatísticas usando:
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit
Ou esta versão de uma linha do acima:
/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"
Recriando os índices
A principal característica desta atualização é uma grande economia de arquivos na nossa maior tabela em cada instância, a tabela post_timings e seus índices. Após realizar uma atualização bem-sucedida, você precisará executar um comando para recriar os índices e colher os benefícios.
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
REINDEX SCHEMA CONCURRENTLY public;
\q
exit
exit
Se você puder verificar o tamanho de post_timings antes e depois do REINDEX, seria uma estatística legal para compartilhar aqui!
Você pode usar a consulta abaixo para verificar os 20 maiores objetos de dados; execute-a antes e depois do reindex:
WITH RECURSIVE pg_inherit(inhrelid, inhparent) AS
(select inhrelid, inhparent
FROM pg_inherits
UNION
SELECT child.inhrelid, parent.inhparent
FROM pg_inherit child, pg_inherits parent
WHERE child.inhparent = parent.inhrelid),
pg_inherit_short AS (SELECT * FROM pg_inherit WHERE inhparent NOT IN (SELECT inhrelid FROM pg_inherit))
SELECT table_schema
, TABLE_NAME
, row_estimate
, pg_size_pretty(total_bytes) AS total
, pg_size_pretty(index_bytes) AS INDEX
, pg_size_pretty(toast_bytes) AS toast
, pg_size_pretty(table_bytes) AS TABLE
FROM (
SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS table_bytes
FROM (
SELECT c.oid
, nspname AS table_schema
, relname AS TABLE_NAME
, SUM(c.reltuples) OVER (partition BY parent) AS row_estimate
, SUM(pg_total_relation_size(c.oid)) OVER (partition BY parent) AS total_bytes
, SUM(pg_indexes_size(c.oid)) OVER (partition BY parent) AS index_bytes
, SUM(pg_total_relation_size(reltoastrelid)) OVER (partition BY parent) AS toast_bytes
, parent
FROM (
SELECT pg_class.oid
, reltuples
, relname
, relnamespace
, pg_class.reltoastrelid
, COALESCE(inhparent, pg_class.oid) parent
FROM pg_class
LEFT JOIN pg_inherit_short ON inhrelid = oid
WHERE relkind IN ('r', 'p')
) c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
) a
WHERE oid = parent
) a
ORDER BY total_bytes DESC LIMIT 20;
Limpando dados antigos
Para uma instalação padrão, você pode excluir os dados antigos no formato PG12 com o seguinte comando:
cd /var/discourse
./launcher cleanup
Se você tiver um contêiner de dados separado, precisará remover a cópia de backup assim:
rm -fr /var/discourse/shared/data/postgres_data_old/
FAQ
O cluster de origem não foi desligado corretamente
Se você receber uma falha na atualização com a mensagem acima, pode tentar uma abordagem mais simples para colocá-lo em um estado melhor.
Reinicie o contêiner antigo com ./launcher start app. Aguarde alguns minutos até que ele volte a subir.
Agora desligue-o novamente com ./launcher stop app. Depois disso, siga os logs para ver se foi um desligamento limpo:
tail -f shared/data/log/var-log/postgres/current
2020-05-13 18:33:33.457 UTC [36] LOG: received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG: worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG: shutting down
2020-05-13 18:33:33.479 UTC [36] LOG: database system is shut down
Se os logs parecerem como acima, você pode tentar fazer a atualização novamente usando ./launcher rebuild app.
Os valores de lc_collate para o banco de dados “postgres” não correspondem
Esse erro ocorre se você estiver usando locais (locales) não padrão para seu banco de dados. Foi relatado que você precisa de 3 variáveis para que isso seja bem-sucedido. Certifique-se de que a seção env: do seu arquivo app.yml tenha as 3 linhas:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
Alterando en_US.UTF-8 para o seu local (locale).
Cada reconstrução faz a atualização novamente, ou seja, loop de atualização
Quando isso acontece, seus logs de atualização conterão:
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old/postgres_data': Directory not empty
mv: cannot move '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new': Directory not empty
Isso significa que ainda há arquivos da última atualização espalhados. Mova-os para outro lugar antes de continuar.
Scripts de sugestão “Atualização Concluída” - preciso fazer algo?
Uma vez que a atualização for concluída, você verá uma saída da mensagem pg_upgrade dizendo:
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
Você pode ignorar com segurança esta mensagem.
Eu pulei a atualização do PostgreSQL 12, o que fazer agora?
Você pode seguir as instruções padrão no topo deste guia e elas atualizarão da sua versão para a 13 sem problemas.
Se você estiver seguindo as instruções para ambientes com espaço limitado, adapte os números da versão de acordo.
