Gerenciar alta disponibilidade no Kubernetes

Selecione uma versão da documentação:

Nesta página, mostramos como ativar e testar a alta disponibilidade (HA) no cluster de banco de dados do AlloyDB Omni baseado no Kubernetes. Para realizar as tarefas documentadas aqui, é necessário ter conhecimentos básicos sobre como aplicar arquivos de manifesto do Kubernetes e usar a ferramenta de linha de comando kubectl.

Visão geral

É possível ativar a HA no cluster de banco de dados direcionando o operador do Kubernetes do AlloyDB Omni para criar réplicas de espera da instância do banco de dados principal. O operador do AlloyDB Omni configura o cluster de banco de dados para atualizar continuamente os dados nessa réplica, correspondendo a todas as mudanças nos dados da instância principal.

Ativar alta disponibilidade

Antes de ativar a HA no cluster de banco de dados, verifique se o cluster do Kubernetes tem o seguinte:

  • Armazenamento para duas cópias completas dos dados
  • Recursos de computação para duas instâncias de banco de dados em execução em paralelo

Para ativar a HA, siga estas etapas:

  1. Modifique o manifesto do cluster de banco de dados para incluir uma seção availability na seção spec. Essa seção define o número de instâncias de espera que você quer adicionar definindo o parâmetro numberOfStandbys.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Substitua NUMBER_OF_STANDBYS pelo número de instâncias de espera que você quer adicionar. O valor máximo é 5. Se você estiver configurando a HA e não tiver certeza sobre o número de instâncias de espera necessárias, comece definindo o valor como 1 ou 2.

  2. Reaplique o manifesto.

Desativar alta disponibilidade

Para desativar a HA, siga estas etapas:

  1. Defina numberOfStandbys como 0 no manifesto do cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Reaplique o manifesto.

Verificar a HA em um cluster de banco de dados

Para conferir o status atual da HA de um cluster de banco de dados, verifique a condição HAReady do status desse cluster. Se esse valor tiver um status definido como True, a HA será configurada e funcionará no cluster de banco de dados.

Para verificar esse valor na linha de comando, execute o seguinte comando:

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Substitua:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados.

  • NAMESPACE: o namespace do cluster de banco de dados.

Fazer failover para uma instância de espera

Se a instância principal ficar indisponível por mais de 90 segundos, o operador do AlloyDB Omni fará o failover automático da instância do banco de dados principal para a instância de espera.

Os failovers são uma boa opção quando você quer se recuperar rapidamente de uma falha inesperada e minimizar o tempo de inatividade, mesmo que isso signifique perder uma pequena quantidade de dados, se o banco de dados principal ficar indisponível antes que o backup seja totalmente atualizado.

O operador do AlloyDB Omni oferece suporte a failover automático e manual. O failover automático é ativado por padrão.

O failover resulta na seguinte sequência de eventos:

  1. O operador do AlloyDB Omni coloca a instância do banco de dados principal off-line.

  2. O operador do AlloyDB Omni promove a réplica de espera para ser a nova instância do banco de dados principal.

  3. O operador do AlloyDB Omni exclui a instância do banco de dados principal anterior.

  4. O operador do AlloyDB Omni cria uma nova réplica de espera.

Desativar o failover automático

Os failovers automáticos são ativados por padrão nos clusters de banco de dados.

Para desativar um failover, siga estas etapas:

  1. Defina enableAutoFailover como false no manifesto do cluster:

    spec:
  availability:
    enableAutoFailover: false

  2. Reaplique o manifesto.

Acionar um failover manual

Para acionar um failover manual, crie e aplique um manifesto para um novo recurso de failover:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Substitua:

  • FAILOVER_NAME: um nome para esse recurso. Por exemplo, failover-1.

  • NAMESPACE: o namespace desse recurso de failover, que precisa corresponder ao namespace do cluster de banco de dados a que ele se aplica.

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados para failover.

Para monitorar o failover, execute o seguinte comando:

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Substitua:

  • FAILOVER_NAME: o nome que você atribuiu ao recurso de failover ao criá-lo.

  • NAMESPACE: o namespace do cluster de banco de dados.

O comando retorna Success depois que a nova instância do banco de dados principal estiver pronta para uso. Para monitorar o status da nova instância de espera, consulte a próxima seção.

Alternar para uma instância de espera

A alternância é realizada quando você quer testar a configuração de recuperação de desastres ou outras atividades planejadas que exigem a troca de papéis do banco de dados principal e da réplica de espera.

Após a conclusão da alternância, os papéis da instância do banco de dados principal e da réplica de espera são invertidos, assim como a direção da replicação. É necessário optar por alternâncias se você quiser ter mais controle sobre o processo de teste da configuração de recuperação de desastres sem perda de dados.

O operador do AlloyDB Omni oferece suporte à alternância manual.

A alternância resulta na seguinte sequência de eventos:

  1. O operador do AlloyDB Omni coloca a instância do banco de dados principal off-line.

  2. O operador do AlloyDB Omni promove a réplica de espera para ser a nova instância do banco de dados principal.

  3. O operador do AlloyDB Omni alterna a instância do banco de dados principal anterior para uma réplica de espera.

Realizar uma troca

Antes de realizar uma alternância, verifique o seguinte:

Para realizar uma alternância, crie e aplique um manifesto para um novo recurso de alternância:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     NewPrimary: STANDBY_REPLICA_NAME

Substitua:

  • SWITCHOVER_NAME: um nome para esse recurso de alternância. Por exemplo, switchover-1.

  • DB_CLUSTER_NAME: o nome da instância do banco de dados principal a que a operação de alternância se aplica.

  • STANDBY_REPLICA_NAME: o nome da instância do banco de dados que você quer promover como principal.

    Para identificar o nome da réplica de espera, execute o seguinte comando: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Usar a réplica de espera como uma instância somente leitura

Para usar uma réplica de espera como uma instância somente leitura, siga estas etapas:

  1. Modifique o manifesto do cluster de banco de dados para definir o parâmetro enableStandbyAsReadReplica como true.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Reaplique o manifesto.

  3. Verifique se o endpoint somente leitura é informado no campo status do objeto DBCluster:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    O exemplo de resposta a seguir mostra o endpoint da instância somente leitura:

      Status:
  [...]
  Primary:
    [...]
    Endpoints:
      Name: Read-Write
      Value: 10.128.0.81:5432
      Name: Read-Only
      Value: 10.128.0.82:5432