ApsaraDB RDS:In-place major version upgrade

Pré-requisitos

Antes de começar, verifique se:

• A instância executa ApsaraDB RDS for PostgreSQL 16 ou uma versão anterior.

• O tipo de armazenamento é disco em nuvem.

• O método de faturamento é pagamento conforme o uso ou assinatura.

• A instância não é uma instância somente leitura nem uma instância de cluster dedicado.

• O Babelfish não está ativo. O número da versão secundária do engine não termina com babelfish.

Faturamento

Gratuito.

Considerações de uso

Leia as informações a seguir antes de iniciar o upgrade.

SELECT count(1) FROM pg_class;

Etapa 1: Execute uma verificação pré-upgrade

1. Acesse o console do ApsaraDB RDS. Na barra de navegação superior, selecione a região onde a instância está localizada. Localize e clique em no ID da instância.

2. (Opcional) Se a instância tiver instâncias somente leitura, altere o endpoint da aplicação do endpoint da instância somente leitura para o endpoint da instância primária e exclua as instâncias somente leitura.

   Nota

   Altere o endpoint da aplicação durante horários de baixo tráfego para minimizar o impacto no serviço.

3. No painel de navegação à esquerda, clique em Major Version Upgrade.

   Nota

   Se

   Major Version Upgrade

   não aparecer, verifique a versão e a configuração da instância. Para mais informações, consulte

   Pré-requisitos

   .

4. Na aba Upgrade Check, clique em Create upgrade check report.

5. Selecione a versão de destino, defina Upgrade Mode como Local Upgrade e clique em OK. O status da instância muda para Maintaining Instance enquanto a verificação é executada e retorna a Running quando a verificação é concluída.

6. Analise os resultados da verificação:

   • Success ou Warning: prossiga para a Etapa 2.

   • Failed: clique em View Information, corrija os problemas identificados no relatório e execute a verificação novamente. Para detalhes sobre erros comuns, consulte Interpretar o relatório de verificação de upgrade de versão principal do ApsaraDB RDS for PostgreSQL.

   Importante

   • Se o resultado for Warning, corrija os problemas e execute a verificação novamente até que o resultado seja Success. - Caso crie um plugin na instância primária após a verificação ser bem-sucedida, execute a verificação novamente.

Etapa 2: Faça o upgrade da versão principal do engine

1. Clique na aba Upgrade Instance. Leia os avisos, selecione a versão de upgrade e clique em Create Upgrade Task.

2. Na caixa de diálogo, leia o aviso e clique em OK.

3. Na seção Create Major Engine Version Upgrade Task, defina Upgrade Mode como Local Upgrade e configure Cutover time:

   • immediately: a alternância ocorre imediatamente após a conclusão da migração.

   • Instance operation and maintenance time: a alternância ocorre dentro da janela de manutenção configurada.

4. Clique em Create now. O status da instância muda para Migration in Progress quando a tarefa de upgrade é iniciada. A duração varia conforme o número de objetos do banco de dados. Acompanhe o progresso no Task Hub.

   Importante

   • Tarefas de upgrade não podem ser modificadas ou excluídas após a criação. - Enquanto a instância estiver em Migration in Progress, operações como modificar parâmetros, reiniciar ou liberar a instância ficam indisponíveis.

5. O upgrade está concluído quando a instância de source e a de destino exibem o status Running.

   Nota

   Na aba

   Upgrade History

   , clique em

   View Information

   na coluna

   Upgrade Log

   para visualize a duração do estado somente leitura e o log detalhado do upgrade. A duração do estado somente leitura corresponde ao intervalo entre

   Cutover Time

   e

   Cutover End Time

   , excluindo o período de liberação do cache DNS.

Próximos passos

Se você excluiu instâncias somente leitura antes do upgrade:

1. Crie instâncias somente leitura na instância de destino.

2. Na aplicação, atualize o endpoint para apontar para a nova instância somente leitura.

Referência de resultados de upgrade

A coluna Upgrade Result na aba Upgrade History exibe um dos seguintes status:

Referência de API

Referências

• Introdução aos upgrades de versão principal

• Fazer upgrade de uma versão principal do engine pelo método zero-downtime

• Fazer upgrade de uma versão principal do engine pelo método de implantação blue-green

• Interpretar o relatório de verificação de upgrade de versão principal do engine

Perguntas frequentes

Posso modificar a instância durante um upgrade de versão principal do engine?

Não. Aguarde a conclusão do upgrade antes de fazer alterações na instância.

Upgrades automáticos de versão principal do engine são compatíveis?

Não. Os upgrades de versão principal do engine devem ser iniciados manualmente.

Downgrades de versão principal do engine são compatíveis?

Não. Para execute uma versão inferior, adquira uma nova instância na versão desejada e use o DTS para migrar os dados.

Após o upgrade, recebo um erro de conflito de raster_overviews ao crie uma view. Como resolver?

Esse problema afeta versões do PostGIS anteriores à 2.5.2 no PostgreSQL 10 ou 11 ao fazer upgrade para o PostgreSQL 12. Siga estas etapas:

1. Na instância de source, faça o upgrade do plugin PostGIS. Execute o seguinte comando duas vezes para garantir que ele seja concluído com êxito:

   SELECT PostGIS_Extensions_Upgrade();
   SELECT PostGIS_Extensions_Upgrade();

2. Escolha a correção com base no uso ou não do plugin PostGIS Raster.

Se você usa o PostGIS Raster:

1. Na instância de source, remova a view raster_overviews da extensão e substitua-a por um placeholder:

   ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
   CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;

2. Faça o upgrade da instância PostgreSQL para pelo menos o PostgreSQL 12.

3. Na instância de destino, recrie a view completa e adicione-a de volta à extensão:

   CREATE OR REPLACE VIEW raster_overviews AS
   SELECT
     current_database() AS o_table_catalog,
     n.nspname AS o_table_schema,
     c.relname AS o_table_name,
     a.attname AS o_raster_column,
     current_database() AS r_table_catalog,
     split_part(split_part(s.consrc, '''::name', 1), '''', 2)::name AS r_table_schema,
     split_part(split_part(s.consrc, '''::name', 2), '''', 2)::name AS r_table_name,
     split_part(split_part(s.consrc, '''::name', 3), '''', 2)::name AS r_raster_column,
     trim(both from split_part(s.consrc, ',', 2))::integer AS overview_factor
   FROM
     pg_class c,
     pg_attribute a,
     pg_type t,
     pg_namespace n,
     (
       SELECT connamespace, conrelid, conkey, pg_get_constraintdef(oid) AS consrc
       FROM pg_constraint
     ) AS s
   WHERE
     t.typname = 'raster'::name
     AND a.attisdropped = false
     AND a.atttypid = t.oid
     AND a.attrelid = c.oid
     AND c.relnamespace = n.oid
     AND c.relkind = ANY(ARRAY['r'::char, 'v'::char, 'm'::char, 'f'::char])
     AND s.connamespace = n.oid
     AND s.conrelid = c.oid
     AND s.consrc LIKE '%_overview_constraint(%'
     AND NOT pg_is_other_temp_schema(c.relnamespace)
     AND has_table_privilege(c.oid, 'SELECT'::text);
   
   ALTER EXTENSION PostGIS_Raster ADD VIEW raster_overviews;

Se você não usa o PostGIS Raster:

1. Na instância de source, remova a extensão:

   DROP EXTENSION PostGIS_Raster;

2. Faça o upgrade da instância PostgreSQL para pelo menos o PostgreSQL 12.

Como evitar inconsistência de dados causada por preempção de slot de replicação durante um upgrade?

Escolha uma das abordagens a seguir com base em onde os dados da assinatura devem residir após o upgrade.

Manter os dados da assinatura na instância de source:

Certifique-se de que a instância de source não fique indisponível por carga excessiva durante o upgrade. Se isso ocorrer, o slot de replicação pode ser preemptado pela instância de destino, causando inconsistência de dados. Após o upgrade, desative a assinatura no banco de dados de destino:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Mover os dados da assinatura para a instância de destino:

Antes do upgrade, desative a assinatura na instância de source:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Após o upgrade, ative a assinatura na instância de destino:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Como corrigir inconsistência de dados na assinatura após um upgrade?

1. Na instância de destino (versão superior), exclua os dados da tabela afetada. Em seguida, recrie a assinatura com copy_data=true. Para detalhes, consulte ALTER SUBSCRIPTION.

2. Use ON CONFLICT para importar os dados da instância de source (versão inferior) para a de destino. O exemplo a seguir ilustra o padrão:

   CREATE TABLE my_tbl(id INT PRIMARY KEY, t TIMESTAMP, val TEXT);
   
   INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'a');
   INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP, 'b');
   INSERT INTO my_tbl VALUES (3, CURRENT_TIMESTAMP, 'c');
   
   -- Newer timestamp: update the existing row
   INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'd') ON CONFLICT(id) DO UPDATE
       SET t = excluded.t,
           val = excluded.val
       WHERE my_tbl.t < excluded.t;
   
   -- Older timestamp: skip the row
   INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP - '10 hours'::interval, 'e') ON CONFLICT(id) DO UPDATE
       SET t = excluded.t,
           val = excluded.val
       WHERE my_tbl.t < excluded.t;
   
   -- New row: insert
   INSERT INTO my_tbl VALUES (5, CURRENT_TIMESTAMP - '10 hours'::interval, 'f') ON CONFLICT(id) DO UPDATE
       SET t = excluded.t,
           val = excluded.val
       WHERE my_tbl.t < excluded.t;

Por que é necessário exclua instâncias somente leitura antes de um upgrade de versão principal do engine?

Os nós somente leitura e seus slots de replicação permanecem vinculados à instância de source após o upgrade e não são transferidos automaticamente para a instância de destino. Exclua-os antes do upgrade e recrie-os na instância de destino após a conclusão.