ApsaraDB RDS:Upgrade a major version using zero-downtime mode

Como funciona

O modo de tempo de inatividade zero executa o pg_upgrade para atualizar um snapshot da instância para a versão de destino. Em seguida, usa replicação lógica nativa para sincronizar alterações incrementais da source. Verifique a instância de destino antes de acionar o switchover. Ao iniciar o switchover, a instância fica somente leitura brevemente enquanto as sequences são sincronizadas. Depois, o tráfego é direcionado para a nova versão.

Faturamento

Gratuito.

Pré-requisitos

Antes de começar, certifique-se de que:

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

• O tipo de armazenamento é disco cloud. Instâncias com discos locais de alto desempenho só podem usar o blue-green deployment mode.

• O método de faturamento é pagamento conforme o uso ou assinatura. Instâncias Serverless só podem usar o blue-green deployment mode.

• A instância não é uma read-only instance nem uma dedicated cluster instance.

• O parâmetro wal_level está definido como logical. As atualizações com tempo de inatividade zero dependem de replicação lógica. Portanto, se o wal_level estiver como replica ou minimal, a verificação pré-atualização falhará. Caso contrário, modify the instance parameters antes de prosseguir.

• O Babelfish não está ativado. O número da versão secundária do mecanismo não deve terminar com babelfish.

Observações de uso

Revise os pontos abaixo antes de iniciar a atualização.

Impacto nos negócios

Operações DDL (Data Definition Language) são proibidas desde o início da atualização até a conclusão do switchover. O tempo de inatividade da instância de source é medido em segundos e varia conforme a quantidade de sequences e o volume de gravações de transações grandes.

Slots de replicação

• Caso a instância de source possua uma publicação (extremidade publicadora de um slot de replicação), esse slot será perdido após a atualização.

• Se a instância de source tiver um assinante (extremidade assinante de um slot de replicação), a atualização pode causar problemas de sincronização de dados devido à preempção do slot. Consulte a seção de FAQ para mais detalhes.

Alterações de parâmetros

• Parâmetros não suportados pela versão de destino são excluídos automaticamente.

• Parâmetros cujos valores estejam fora do intervalo válido para a versão de destino são redefinidos para os valores padrão do modelo de parâmetros dessa versão.

• O statement_timeout é temporariamente definido como 0 durante a atualização e restaurado ao valor original posteriormente.

Tarefas do DTS

Se a instância for source ou destino do Data Transmission Service (DTS), recreate the DTS task após a atualização.

Compatibilidade de plugins

A atualização leva a instância automaticamente à versão secundária mais recente do mecanismo, o que pode gerar problemas de compatibilidade com plugins.

Backups

Um backup completo é realizado antes e depois da atualização para permitir recuperação baseada em clone.

Impacto nas diferentes etapas da atualização

Após o início da tarefa de atualização, acesse a aba Upgrade History. Na coluna Upgrade Log da tarefa desejada, clique em View Information para visualizar o processo detalhado da atualização.

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

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

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

   Se Major Version Upgrade não aparecer, verifique a versão e a configuração da sua instância. Para detalhes, consulte Prerequisites .

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

4. Selecione a versão de destino, defina o Upgrade Mode como Zero Downtime e clique em OK. O status da instância mudará para Maintaining Instance. Após a conclusão da verificação, o status retornará para Running.

5. Analise o resultado da verificação: Para ajuda na interpretação dos resultados, consulte Interpret an ApsaraDB RDS for PostgreSQL major version upgrade check report.

   • Success ou Warning: prossiga para a Etapa 2.

   • Failed: clique em View Information, corrija os problemas relatados e execute a verificação novamente.

   Importante

   • Se o resultado for Warning, corrija todos os problemas relatados e refaça a verificação até obter Success. - Se você criar um plugin na instância primária após uma verificação bem-sucedida, execute a verificação novamente antes de atualizar.

Etapa 2: Inicie a atualização

Antes de executar esta etapa, garanta que concluiu a Etapa 1: Execute uma verificação pré-atualização: na aba Upgrade Check, crie um relatório de verificação de atualização e confirme que o resultado é Success ou Warning antes de criar a tarefa de atualização.

1. Clique na aba Upgrade Instance, leia os avisos, selecione uma versão em Select The Destination Version 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 o Upgrade Mode como Zero Downtime e clique em Create.

Quando o status da instância mudar para Migrating, a tarefa de atualização terá sido iniciada.

O tempo necessário depende da quantidade de objetos de banco de dados na instância — quanto mais objetos, maior a duração. Acompanhe o progresso em Task Hub.

Etapa 3: Verifique e realize o switchover

Descrições dos resultados da atualização

A coluna Upgrade Result na aba Upgrade History exibe um dos seguintes valores durante a atualização.

Referência de API

FAQ

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

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');

-- Update if the incoming row has a newer timestamp
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;

-- Skip if the incoming row has an older timestamp
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;

-- Insert new rows normally
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;

Próximos passos

• Perform a major version upgrade in blue-green deployment mode

• Perform a major version upgrade in local upgrade mode

• Interpret an ApsaraDB RDS for PostgreSQL major version upgrade check report

• Best practices for zero-downtime major version upgrades