Faça a gestão da elevada disponibilidade no Kubernetes

Selecione uma versão da documentação:

Esta página mostra como ativar e testar a alta disponibilidade (AD) no cluster de base de dados AlloyDB Omni baseado no Kubernetes. A execução das tarefas documentadas aqui requer conhecimentos básicos sobre a aplicação de ficheiros de manifesto do Kubernetes e a utilização da kubectl ferramenta de linha de comandos.

Vista geral

Pode ativar a HA no cluster da base de dados direcionando o operador do Kubernetes do AlloyDB Omni para criar réplicas em espera da instância da base de dados principal. O operador AlloyDB Omni configura o cluster da base de dados para atualizar continuamente os dados nesta réplica, fazendo corresponder todas as alterações aos dados na sua instância principal.

Ative a HA

Antes de ativar a HA no cluster de base de dados, certifique-se de que 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 base de dados em execução em paralelo

Para ativar a HA, siga estes passos:

  1. Modifique o manifesto do cluster da base de dados para incluir uma secção availability na secção spec. Esta secção define o número de suplentes que quer adicionar definindo o parâmetro numberOfStandbys.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Substitua NUMBER_OF_STANDBYS pelo número de suplentes que quer adicionar. O valor máximo é 5. Se estiver a configurar a HA e não tiver a certeza do número de standbys de que precisa, comece por definir o valor como 1 ou 2.

  2. Volte a aplicar o manifesto.

Desative a HA

Para desativar a HA, siga estes passos:

  1. Defina numberOfStandbys como 0 no manifesto do cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Volte a aplicar o manifesto.

Valide a HA num cluster de base de dados

Para ver o estado de HA atual de um cluster de base de dados, verifique a HAReadycondição do estado desse cluster. Se este valor tiver um status definido como True, então a HA está configurada e a funcionar no cluster da base de dados.

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

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

Substitua o seguinte:

  • DB_CLUSTER_NAME: o nome do cluster da base de dados.

  • NAMESPACE: o espaço de nomes do cluster da base de dados.

Ative a instância em espera

Se a sua instância principal ficar indisponível durante um período configurável, o operador do AlloyDB Omni faz automaticamente a comutação por falha da instância da base de dados principal para a instância de reserva. O tempo predefinido para acionar a comutação por falha automática é de 90 segundos.

As comutações por falha são uma boa opção quando quer recuperar rapidamente de uma falha inesperada e minimizar o tempo de inatividade, mesmo que isso signifique perder potencialmente uma pequena quantidade de dados, se a base de dados principal ficar indisponível antes de a cópia de segurança ser totalmente atualizada.

O operador do AlloyDB Omni suporta a comutação por falha automática e manual. A comutação por falha automática está ativada por predefinição.

A comutação por falha resulta na seguinte sequência de eventos:

  1. O operador do AlloyDB Omni coloca a instância da base de dados principal offline.

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

  3. O operador AlloyDB Omni elimina a instância da base de dados principal anterior.

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

Desative a comutação por falha automática

As comutações por falha automáticas estão ativadas por predefinição nos clusters de bases de dados.

Para desativar uma alternativa, siga estes passos:

  1. Defina enableAutoFailover como false no manifesto do cluster:

    spec:
  availability:
    enableAutoFailover: false

Ajuste as definições do acionador de comutação por falha automática

Pode usar as definições para ajustar as comutações automáticas por falha para cada cluster de base de dados.

O operador do AlloyDB Omni emite verificações de estado regulares a cada 30 segundos. Se uma instância tiver atingido o limite do acionador de comutação por falha automática, o operador do AlloyDB Omni aciona uma comutação por falha automática.

O valor predefinido para o limite do acionador de comutação por falha automática é 3. O valor do limite é o número de falhas consecutivas na verificação de estado antes de ser acionada uma comutação por falha. Para alterar o valor limite, defina autoFailoverTriggerThreshold para um valor inteiro no manifesto do cluster:

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

Substitua o seguinte:

  • TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas para a verificação de estado antes de ser acionada uma comutação por falha. O valor predefinido é 3.

Acione uma comutação por falha manual

Para acionar uma comutação por falha manual, crie e aplique um manifesto para um novo recurso de comutação por falha:

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

Substitua o seguinte:

  • FAILOVER_NAME: um nome para este recurso, por exemplo, failover-1.

  • NAMESPACE: o espaço de nomes deste recurso de comutação por falha, que tem de corresponder ao espaço de nomes do cluster de base de dados ao qual se aplica.

  • DB_CLUSTER_NAME: o nome do cluster da base de dados para o qual a comutação por falha vai ser feita.

Para monitorizar a comutação por falha, execute o seguinte comando:

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

Substitua o seguinte:

  • FAILOVER_NAME: o nome que atribuiu ao recurso de failover quando o criou.

  • NAMESPACE: o espaço de nomes do cluster da base de dados.

O comando devolve Success após a nova instância da base de dados principal estar pronta para utilização. Para monitorizar o estado da nova instância em espera, consulte a secção seguinte.

Comutação para uma instância de espera

A comutação é realizada quando quer testar a configuração de recuperação de desastres ou quaisquer outras atividades planeadas que exijam a comutação das funções da base de dados principal e da réplica em espera.

Após a conclusão da comutação, as funções da instância da base de dados principal e da réplica em espera são invertidas, juntamente com a direção da replicação. Tem de optar por comutações se quiser ter um melhor controlo sobre o processo de teste da configuração de recuperação de desastres sem perda de dados.

O operador AlloyDB Omni suporta a comutação manual.

A mudança resulta na seguinte sequência de eventos:

  1. O operador do AlloyDB Omni coloca a instância da base de dados principal offline.

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

  3. O operador do AlloyDB Omni muda a instância da base de dados principal anterior para uma réplica em espera.

Faça uma comutação

Antes de fazer uma comutação, certifique-se de que:

Para fazer uma comutação, crie e aplique um manifesto para um novo recurso de comutação:

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

Substitua o seguinte:

  • SWITCHOVER_NAME: um nome para este recurso de comutação, por exemplo, switchover-1.

  • DB_CLUSTER_NAME: o nome da instância da base de dados principal à qual a operação de comutação se aplica.

  • STANDBY_REPLICA_NAME: o nome da instância da base de dados que quer promover como nova instância principal.

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

Use a réplica em espera como uma instância só de leitura

Para usar uma réplica em espera como uma instância só de leitura, conclua os seguintes passos:

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

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Volte a aplicar o manifesto.

  3. Verifique se o ponto final só de leitura é comunicado no campo status do objeto DBCluster:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    A seguinte resposta de exemplo mostra o ponto final da instância só de leitura:

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