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:

Nesta página, descrevemos como fazer um upgrade de 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 tempo de inatividade reduzido: para ambientes de alta disponibilidade (HA) 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 faz uma alternância, promovendo uma das instâncias de espera atualizadas para ser sua nova instância principal. Depois que a substituição for concluída, a instância principal antiga será atualizada.

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

  • Upgrade simultâneo: em todas as outras circunstâncias, o operador do AlloyDB Omni faz upgrade de todas as instâncias simultaneamente. Isso significa que você vai ter um tempo de inatividade durante o upgrade.

Limitações

Para upgrades com pouco tempo de inatividade, uma instância de 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) zero e não corra o risco de perder dados, ele precisa ter uma instância principal e pelo menos duas instâncias em espera.

Antes de começar

  • Se o cluster for de alta disponibilidade e a versão do AlloyDB Omni for anterior a 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 baixo 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 baixo tempo de inatividade

Para ativar o processo de upgrade da versão secundária do banco de dados com baixo 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 criar. 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 16.8.0, atualize os campos databaseVersion e controlPlaneAgentsVersion no arquivo de manifesto do cluster e reaplique o arquivo.

A seguir, está o início de um arquivo de manifesto que especifica a versão 16.8.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: "16.8.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 criar. 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 criar. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

Enquanto o processo está em andamento, o status é 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 antes do upgrade

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

Se quiser ignorar a mensagem de falha antes da atualização, 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 criar. 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 alta disponibilidade. 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 concluído, mas a instância de espera não alcançou a instância principal para estabelecer a replicação síncrona.

Uma grande quantidade de tráfego vai para a instância principal. À medida que o tráfego diminui, a instância de espera se recupera gradualmente. Depois disso, a condição HAReady se torna true.

Escolha uma opção em Corrigir instâncias principal 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 em espera foram atualizadas, mas o processo de failover falhou.

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

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

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

A instância de espera não foi atualizada corretamente, e o operador do AlloyDB Omni não consegue restaurar a instância para a versão anterior.

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

Corrigir instâncias principal e em 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 de novo.

    Para tentar fazer o upgrade de novo, remova a anotação start-time do upgrade da sua instância. Depois de remover a anotação, o operador do AlloyDB Omni vai gerar um novo horário de início e reiniciar 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 criar. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.

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

    Para fazer 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 antes.