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

Selecione uma versão da documentação:

Esta página descreve como ativar e testar a alta disponibilidade (AD) no cluster de base de dados AlloyDB Omni baseado no Kubernetes. Este documento pressupõe conhecimentos básicos sobre a aplicação de ficheiros de manifesto do Kubernetes e a utilização da ferramenta de linha de comandos kubectl.

Vista geral

Ativa a HA no cluster da base de dados configurando o operador do Kubernetes do AlloyDB Omni para criar réplicas em espera da instância da base de dados principal. O operador do AlloyDB Omni configura o cluster da base de dados para atualizar continuamente os dados nesta réplica e corresponde a todas as alterações de 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 usa o parâmetro numberOfStandbys para especificar o número de substituições a adicionar.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Substitua NUMBER_OF_STANDBYS pelo número de suplentes que quer adicionar. O valor máximo é 5. Se não tiver a certeza do número de suplentes 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 verificar o estado da HA num cluster de base de dados, verifique o respetivo estado HAReady. Se o estado de HAReady for True, a HA está ativada e a funcionar no cluster. Se for False, significa que está ativada, mas não está pronta porque está em processo de configuração.

Para verificar o estado do HAReady através da linha de comandos kubectl, 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 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. Os seguintes parâmetros determinam quando iniciar uma comutação por falha automática:

  • O tempo entre as verificações de funcionamento (a predefinição são 30 segundos)

  • O número de verificações de estado com falhas consecutivas (o valor predefinido é 3)

Uma comutação por falha automática é iniciada após o número especificado de verificações de estado com falhas consecutivas, com o tempo especificado entre cada verificação de estado com falha. Se os valores predefinidos forem mantidos, ocorre uma comutação por falha automática após 3 falhas consecutivas na verificação do estado, com um intervalo de 30 segundos entre cada uma.

A realização de uma comutação por falha manual é uma boa opção quando quer recuperar rapidamente de uma falha inesperada e minimizar o tempo de inatividade.

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 a comutação por falha automática, 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 funcionamento regulares para a instância da base de dados principal, bem como para todas as réplicas em espera. A frequência predefinida das verificações de estado é de 30 segundos. Se uma instância atingir 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 do limite é o número de falhas consecutivas para a verificação do estado antes de ser acionado um failover. Para alterar o período de verificação do estado ou o valor limite, defina os campos healthcheckPeriodSeconds e autoFailoverTriggerThreshold como valores inteiros no manifesto do cluster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Substitua o seguinte:

  • HEALTHCHECK_PERIOD: um valor inteiro que indica o número de segundos a aguardar entre cada verificação do estado. O valor predefinido é 30. O valor mínimo é 1 e o valor máximo é 86400 (equivalente a um dia).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas na verificação de estado antes de ser acionado um failover. O valor predefinido é 3. O valor mínimo é 0. Não existe um valor máximo. Se este campo estiver definido como 0, é usado o valor predefinido de 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, a direção da replicação e as funções da instância da base de dados principal e da réplica em espera são invertidas. Use as transferências para ter mais controlo sobre os testes da configuração de recuperação de desastres sem perda de dados.

O operador AlloyDB Omni suporta a comutação manual. Uma comutação 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 iniciar uma comutação, faça o seguinte:

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 para ser a nova instância principal.

    Para identificar o nome da réplica em espera, execute o seguinte comando:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Recuperar automaticamente uma instância em espera

Se uma instância em espera ficar indisponível, o operador do AlloyDB Omni corrige a instância eliminando a réplica em espera antiga e criando uma nova réplica em espera que a substitui. O tempo predefinido para acionar uma recuperação automática é de 90 segundos.

A reparação automática do cluster de base de dados ajuda a manter uma replicação contínua e saudável da base de dados principal.

Desative a reparação automática da instância

Por predefinição, a recuperação automática de uma instância em espera está ativada em clusters de bases de dados.

Para desativar as correções automáticas, siga estes passos:

  1. No manifesto do cluster, defina enableAutoHeal como false:

    spec:
  availability:
    enableAutoHeal: false

Ajuste as definições do acionador de reparação automática

Para cada cluster de base de dados, pode usar definições para ajustar as reparações automáticas.

O operador do AlloyDB Omni emite verificações de estado regulares que pode configurar. Para mais informações, consulte o artigo Ajuste as definições do acionador de comutação por falha automática. Se uma réplica em espera atingir o limite do acionador de reparação automática, o operador do AlloyDB Omni aciona uma reparação automática.

O valor do limite é o número de falhas consecutivas para a verificação de estado antes de ser acionada uma recuperação. Para alterar o valor do limite, defina autoHealTriggerThreshold no manifesto do cluster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Substitua o seguinte:

  • AUTOHEAL_TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas na verificação de estado antes de ser acionada uma recuperação. O valor predefinido é 5. O valor mínimo é 2 devido a possíveis erros temporários e únicos nas verificações de estado de espera.

Resolva problemas de recuperação de instâncias

Se usar um grande número de clusters de base de dados num único cluster do Kubernetes ou tiver clusters de base de dados com aprovisionamento insuficiente, a recuperação automática pode causar indisponibilidade para o operador do AlloyDB Omni ou os clusters de base de dados. Se receber um erro que comece por HealthCheckProber: health check for instance failed e o erro fizer referência a um tempo limite ou a uma falha de ligação, experimente as seguintes correções recomendadas:

Seguem-se exemplos de erros que podem ser causados pela correção automática excessiva. Estes exemplos omitem detalhes do ambiente que ajudam a identificar a origem do erro, como o nome de um cluster ou um endereço IP.

  • HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

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. Defina enableStandbyAsReadReplica como true no manifesto do cluster da base de dados:

    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