ApsaraDB RDS:Upgrade a major version using blue-green deployment

Pré-requisitos

Antes de começar, verifique se:

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

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

• O Babelfish não está ativado na instância (o número da versão secundária do mecanismo não termina com babelfish)

Faturamento

Ao iniciar uma atualização com blue-green deployment, o sistema cria uma nova instância baseada na instância de origem. Ambas as instâncias são faturadas separadamente até que você libere a instância de origem.

Após confirmar a estabilidade dos serviços na nova instância, converta o faturamento dela para assinatura e libere ou cancele a assinatura da instância de origem.

Impactos potenciais

Analise os itens a seguir antes de iniciar a atualização.

Etapa 1: Executar a 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. (Opcional) Se existirem instâncias somente leitura associadas à instância de origem, altere o endpoint da instância somente leitura na aplicação para o endpoint da instância primária durante o horário de menor movimento e, em seguida, exclua a instância somente leitura.

   Excluir as instâncias somente leitura antes da atualização é necessário porque nós somente leitura e slots de replicação não são transferidos automaticamente para a nova instância. Após a atualização, crie novas instâncias somente leitura na nova instância.

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

   Se Major Version Upgrade não estiver visível, verifique se sua instância atende aos pré-requisitos listados acima.

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

5. Selecione a versão de destino, defina o Upgrade Mode como Blue-green Deployment 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.

6. Analise o resultado do relatório de verificação:

   • Success ou Warning: prossiga para a Etapa 2.

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

   Importante

   • Para um resultado Warning, corrija todos os itens sinalizados e execute a verificação novamente 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 prosseguir.

Próximos passos

1. Se você atualizou usando o método blue-green deployment (cutover), após confirmar a estabilidade dos serviços na nova instância, libere a instância de origem. Converta o método de faturamento da nova instância para assinatura para reduzir custos.

   Liberar uma instância por assinatura antes do vencimento pode resultar em perda financeira. A nova instância não herda descontos da instância de origem. Os reembolsos estão sujeitos à fatura real de cancelamento da assinatura e não são processados em tempo real.

2. (Opcional) Se você excluiu uma instância somente leitura antes da atualização, recrie-a na nova instância:

   1. Criar uma instância somente leitura do PostgreSQL na nova instância.

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

Referência de API

Referências

• Introdução às atualizações de versão principal

• Realizar uma atualização de versão principal usando o modo zero-downtime

• Realizar uma atualização de versão principal usando o modo in-place upgrade

• Interpretar o relatório de verificação de atualização de versão principal do ApsaraDB RDS for PostgreSQL

Perguntas frequentes

Posso modificar a instância durante uma atualização de versão principal?

Não. A instância não pode ser modificada enquanto uma atualização está em andamento. Modificações só estão disponíveis após a conclusão da atualização.

Atualizações automáticas de versão principal são suportadas?

Não. As atualizações de versão principal devem ser acionadas manualmente.

Downgrades de versão principal são suportados?

Não. Não há suporte para downgrade após uma atualização de versão principal. Para executar uma versão inferior, adquira uma nova instância nessa versão e use o Data Transmission Service (DTS) para migrar seus dados.

Após uma atualização de versão principal, recebo um conflito raster_overviews ao criar uma view na nova instância. Como resolvo isso?

Esse problema ocorre quando a versão do PostGIS é anterior a 2.5.2 e você está atualizando do PostgreSQL 10 ou 11 para o PostgreSQL 12 sem antes atualizar o plugin PostGIS.

Etapa 1: Atualize o plugin PostGIS na instância de origem.

Execute o comando a seguir duas vezes para garantir que a atualização seja concluída com êxito:

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

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

Se o plugin PostGIS Raster estiver em uso:

1. Na instância de origem, desanexe 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. Atualize a instância PostgreSQL para pelo menos o PostgreSQL 12.

3. Após a atualização, recrie a view na nova instância:

   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 o plugin PostGIS Raster não estiver em uso:

1. Remova o plugin na instância de origem:

   DROP EXTENSION PostGIS_Raster;

2. Atualize a instância PostgreSQL para pelo menos o PostgreSQL 12.

Como evito inconsistência de dados causada por preempção de slot de replicação durante uma atualização?

Se a instância de origem for um assinante de slot de replicação, o slot poderá ser preemptado pela nova instância durante a atualização, o que pode causar inconsistência de dados.

Para manter os dados de assinatura na instância de origem (versão inferior): garanta que a instância de origem não falhe devido a carga excessiva durante a atualização, evitando que o slot de replicação seja preemptado. Após a conclusão da atualização, desative a assinatura na nova instância:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Para preservar os dados de assinatura na nova instância (versão superior): desative a assinatura na instância de origem antes de iniciar a atualização e, em seguida, ative-a na nova instância após a conclusão da atualização.

Desative na instância de origem:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Ative na nova instância:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Para mais informações, consulte Assinatura Lógica e Change Tracking.

Como trato a inconsistência de dados de assinatura após uma atualização?

Se a inconsistência já tiver ocorrido, use a seguinte abordagem para reconciliação:

1. Na nova instância, exclua os dados da tabela afetada e recrie a assinatura com copy_data=true. Para detalhes, consulte ALTER SUBSCRIPTION.

2. Use ON CONFLICT para importar dados da instância de origem. O exemplo a seguir mostra como lidar com diferentes cenários de conflito:

   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: keep the existing 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 directly
   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 preciso excluir instâncias somente leitura antes da atualização?

Nós somente leitura e slots de replicação na instância de origem não são transferidos automaticamente para a nova instância após a atualização. Excluir a instância somente leitura antes da atualização evita conflitos de endpoint e garante um cutover limpo. Após a atualização, crie uma nova instância somente leitura na nova instância e atualize o endpoint da aplicação adequadamente.