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 principal do banco de dados. 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 um período configurável, o operador do AlloyDB Omni fará o failover automático da instância principal do banco de dados 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 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 principal do banco de dados off-line.

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

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

  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 acionador 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 do acionador de failover automático, o operador do AlloyDB Omni vai acionar um failover automático.

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

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

Substitua:

  • TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas para a verificação de integridade antes que um failover seja 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 principal do banco de dados estiver pronta para uso. Para monitorar o status da nova instância de espera, consulte a próxima seção.

Fazer a troca para uma instância de espera

A troca é realizada quando você quer testar a configuração de recuperação de desastres ou outras atividades planejadas que exigem a troca das funções do banco de dados principal e da réplica de espera.

Após a conclusão da troca, as funções da instância principal do banco de dados e da réplica de espera são invertidas, assim como a direção da replicação. É necessário optar por trocas 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 à troca manual.

A troca resulta na seguinte sequência de eventos:

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

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

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

.

Realizar uma troca

Antes de realizar uma troca, verifique o seguinte:

Para realizar uma troca, crie e aplique um manifesto para um novo recurso de troca:

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

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

  • STANDBY_REPLICA_NAME: o nome da instância do banco de dados que você quer promover como nova 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