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 conhecimento básico sobre aplicação de arquivos de manifesto do Kubernetes e uso da ferramenta de linha de comando kubectl.

Visão geral

É possível ativar a alta disponibilidade no cluster de banco de dados direcionando o operador do Kubernetes do AlloyDB Omni para criar réplicas em espera da instância de banco de dados primária. 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 alta disponibilidade no cluster de banco de dados, verifique se o cluster do Kubernetes tem o seguinte:

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

Para ativar a alta disponibilidade, siga estas etapas:

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

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Substitua NUMBER_OF_STANDBYS pelo número de standbys que você quer adicionar. O valor máximo é 5. Se você estiver configurando a alta disponibilidade e não tiver certeza sobre o número de servidores em espera necessários, comece definindo o valor como 1 ou 2.

  2. Reaplique o manifesto.

Desativar a alta disponibilidade

Para desativar a alta disponibilidade, siga estas etapas:

  1. Defina numberOfStandbys como 0 no manifesto do cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Reaplique o manifesto.

Verificar a alta disponibilidade em um cluster de banco de dados

Para conferir o status atual de alta disponibilidade 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 alta disponibilidade 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 um período configurável, o operador do AlloyDB Omni fará failover automático da instância do banco de dados principal para a instância de espera. O tempo padrão para acionar o failover automático é de 90 segundos.

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 é compatível com 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 desativa a instância de banco de dados primária.

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

  3. O operador do AlloyDB Omni exclui a instância de banco de dados primário 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

Ajustar as configurações de acionamento de failover automático

É possível usar as configurações para ajustar os failovers automáticos de cada cluster de banco de dados.

O operador do AlloyDB Omni emite verificações de integridade regulares a cada 30 segundos. Se uma instância atingir o limite de acionamento de failover automático, o operador do AlloyDB Omni vai acionar um failover automático.

O valor padrão para o limite de acionamento de failover automático é 3. O valor do limite é o número de falhas consecutivas na verificação de integridade antes que um failover seja acionado. Para mudar o valor do limite, defina autoFailoverTriggerThreshold como um número inteiro no manifesto do cluster:

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

Substitua:

  • TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas na verificação de integridade antes de um failover ser acionado. O valor padrão é 3.

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 de banco de dados principal estiver pronta para uso. Para monitorar o status da nova instância em espera, consulte a próxima seção.

Failover para uma instância de espera

A alternância é realizada quando você quer testar a configuração de recuperação de desastres ou qualquer outra atividade planejada que exija a troca de papéis do banco de dados principal e da réplica em espera.

Depois que a alternância for concluída, as funções da instância de banco de dados principal e da réplica em espera serão invertidas junto com a direção da replicação. Você precisa optar por alternâncias se 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 à troca manual.

A transição resulta na seguinte sequência de eventos:

  1. O operador do AlloyDB Omni desativa a instância de banco de dados primária.

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

  3. O operador do AlloyDB Omni muda a instância do banco de dados primário anterior para uma réplica em espera.

Realizar uma troca

Antes de fazer uma alternância, verifique se:

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

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 failover. Por exemplo, switchover-1.

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

  • STANDBY_REPLICA_NAME: o nome da instância de banco de dados que você quer promover como nova primária.

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

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

Para usar uma réplica em 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 está 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