Fazer um upgrade de versão secundária do banco de dados para o AlloyDB Omni no Kubernetes

Selecione uma versão da documentação:

Esta página descreve como fazer um upgrade da versão secundária do banco de dados para o AlloyDB Omni no Kubernetes.

Para fazer um upgrade da versão secundária do banco de dados, há duas opções:

  • Upgrade com pouco tempo de inatividade: esse recurso está em pré-lançamento. Para ambientes de alta disponibilidade (HA, na sigla em inglês) que executam o AlloyDB Omni versão 15.7.1 ou mais recente, o AlloyDB Omni faz upgrade das instâncias de espera primeiro. Em seguida, o operador do AlloyDB Omni realiza uma alternância, promovendo uma das instâncias de espera atualizadas para ser a nova instância principal. Depois que a alternância é bem-sucedida, a instância principal antiga é atualizada.

    Esse processo garante o mínimo de inatividade durante o upgrade.

  • Upgrade simultâneo: o método de upgrade simultâneo está disponível para todos os usuários (GA). Em todas as outras circunstâncias, o operador do AlloyDB Omni faz upgrade de todas as instâncias simultaneamente. Isso significa que você terá tempo de inatividade durante o upgrade.

Limitações

Para upgrades com pouco tempo de inatividade, uma instância em espera fica indisponível a qualquer momento. Para garantir que o cluster de banco de dados não atinja o objetivo de ponto de recuperação (RPO, na sigla em inglês) zero e não corra o risco de perder dados, ele precisa ter uma instância principal e pelo menos duas instâncias de espera.

Antes de começar

  • Se o cluster for de HA e a versão do AlloyDB Omni for anterior à 15.7.1, siga as etapas listadas em Atualizar os clusters de banco de dados antes de seguir este processo de upgrade da versão secundária.
  • Identifique um período de pouco tráfego em que você possa fazer o upgrade da versão secundária.
  • Para evitar a perda de dados, faça backup dos seus dados.

Ativar o processo de upgrade da versão secundária do banco de dados com pouco tempo de inatividade

Para ativar o processo de upgrade da versão secundária do banco de dados com pouco tempo de inatividade, adicione a seguinte anotação ao cluster de banco de dados.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

Substitua a seguinte variável:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome de cluster de banco de dados que você forneceu ao criá-lo. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

Fazer upgrade da versão do AlloyDB Omni

Para fazer upgrade da versão 15.12.0, atualize os campos databaseVersion e controlPlaneAgentsVersion no arquivo de manifesto do cluster e reaplique o arquivo.

A seguir, o início de um arquivo de manifesto que especifica a versão 15.12.0 para databaseVersion e a versão 1.5.0 para controlPlaneAgentsVersion:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "15.12.0"
    controlPlaneAgentsVersion: "1.5.0"
...

Substitua a seguinte variável:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome de cluster de banco de dados que você forneceu ao criá-lo. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

Monitorar o processo de upgrade

Depois de atualizar o arquivo de manifesto, o operador do AlloyDB Omni inicia o processo de upgrade. Para monitorar o processo de upgrade, verifique a condição DBCUpgradeInProgress.

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

Substitua a seguinte variável:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome de cluster de banco de dados que você forneceu ao criá-lo. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

Enquanto o processo estiver em andamento, o status será true. Quando o processo for concluído, o status da condição mudará para false.

Solução de problemas

Se você receber mensagens de falha durante o processo de upgrade, consulte as seções a seguir:

Falhas pré-upgrade

Se você receber uma falha pré-upgrade no cluster de banco de dados, verifique a mensagem e resolva o problema de acordo.

Se você quiser ignorar a mensagem de falha pré-upgrade, ative a anotação force-upgrade.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

Substitua a seguinte variável:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome de cluster de banco de dados que você forneceu ao criá-lo. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

Depois que o processo de upgrade for concluído, defina a anotação force-upgrade como false.

Falhas no upgrade

Durante o processo de upgrade automático, há vários pontos em que ele pode falhar em ambientes de HA. Para mais informações sobre cada cenário de falha e quais ações subsequentes o operador do AlloyDB Omni realiza, consulte a tabela a seguir.

Mensagem de falha Descrição Ações necessárias do usuário
standby instance upgrade succeeded but the replication lag of the standby(s) is too high to be promoted to synchronous standby(s)

O processo de upgrade foi bem-sucedido, mas a instância em espera não alcançou a instância principal para estabelecer a replicação síncrona.

Um grande volume de tráfego vai para a instância principal. À medida que o tráfego diminui, a instância em espera alcança gradualmente. Depois que isso acontece, a condição HAReady se torna true.

Escolha uma opção em Corrigir instâncias principais e de espera com versões secundárias diferentes .

all standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby.

As instâncias de espera foram atualizadas, mas o processo de alternância falhou.

  1. Verifique o status do recurso personalizado de alternância para determinar a causa da falha.
  2. Escolha uma opção em Corrigir instâncias principais e de espera com versões secundárias diferentes .
standby instance upgrade failed but rollback succeeded.

A instância em espera não foi atualizada, mas o operador do AlloyDB Omni a restaurou para a versão anterior com sucesso.

  1. Verifique as mensagens de falha de upgrade.
  2. Escolha uma opção em Corrigir instâncias principais e de espera com versões secundárias diferentes .
standby instance upgrade failed and rollback failed.

A instância em espera não foi atualizada e o operador do AlloyDB Omni não pode restaurar a instância para a versão anterior.

Entre em contato com o Suporte do Google para resolver o problema.

Corrigir instâncias principais e de espera com versões secundárias diferentes

Para resolver esse problema, escolha uma das seguintes opções:

  • Se o problema que causou a falha no upgrade for corrigido, tente novamente.

    Para tentar o upgrade novamente, remova a anotação start-time do upgrade da instância. Depois de remover a anotação, o operador do AlloyDB Omni gera um novo horário de início e reinicia o processo de upgrade.

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-

    Substitua a seguinte variável:

    • DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome de cluster de banco de dados que você forneceu ao criá-lo. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

  • Se o problema que causou a falha no upgrade persistir, faça o downgrade da instância para a versão anterior do operador do AlloyDB Omni.

    Para fazer o downgrade da instância, siga o processo de upgrade e mude os campos databaseVersion e controlPlaneAgentsVersion no arquivo de manifesto para a versão usada anteriormente.