Gerenciar alta disponibilidade no Kubernetes

Selecione uma versão da documentação:

Nesta página, descrevemos como ativar e testar a alta disponibilidade (HA) no cluster de banco de dados do AlloyDB Omni baseado no Kubernetes. Este documento pressupõe conhecimento básico sobre como aplicar arquivos de manifesto do Kubernetes e usar a ferramenta de linha de comando kubectl.

Visão geral

Para ativar a HA no cluster de banco de dados, configure o operador do AlloyDB Omni no Kubernetes 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 e corresponde a todas as mudanças de dados na 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 usa o parâmetro numberOfStandbys para especificar o número de instâncias de espera a serem adicionadas.

    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ê 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 verificar o status da HA em um cluster de banco de dados, verifique o status HAReady. Se o status de HAReady for True, a HA estará ativada e funcionando no cluster. Se for False, ela estará ativada, mas não pronta porque está em processo de configuração.

Para verificar o status HAReady usando a linha de comando kubectl, 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 do banco de dados principal para a instância de espera. Os parâmetros a seguir determinam quando iniciar um failover automático:

  • O tempo entre as verificações de integridade (o padrão é 30 segundos)

  • O número de verificações de integridade com falha consecutivas (o padrão é 3)

Um failover automático é iniciado após a ocorrência do número especificado de verificações de integridade com falha consecutivas, com o tempo especificado entre cada verificação de integridade com falha. Se os valores padrão forem mantidos, um failover automático ocorrerá após três falhas consecutivas de verificação de integridade, cada uma com 30 segundos de intervalo.

A execução de um failover manual é uma boa opção quando você quer se recuperar rapidamente de uma falha inesperada e minimizar o tempo de inatividade.

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 o failover automático, siga estas etapas:

  1. Defina enableAutoFailover como false no manifesto do cluster:

    spec:
  availability:
    enableAutoFailover: false

Ajustar as configurações do 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 para a instância do banco de dados principal e para todas as réplicas de espera. A frequência padrão para verificações de integridade é de 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 de limite é o número de falhas consecutivas para a verificação de integridade antes que um failover seja acionado. Para mudar o período de verificação de integridade ou o valor de limite, defina os campos healthcheckPeriodSeconds e autoFailoverTriggerThreshold como valores inteiros no manifesto do cluster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Substitua:

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

  • AUTOFAILOVER_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. O valor mínimo é 0. Não há valor máximo. Se esse campo estiver definido como 0, o valor padrão de 3 será usado.

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.

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, a direção da replicação e as funções da instância do banco de dados principal e da réplica de espera são invertidas. Use as trocas para ter mais controle sobre o teste da configuração de recuperação de desastres sem perda de dados.

O operador do AlloyDB Omni oferece suporte à troca manual. Uma troca 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 muda a instância do banco de dados principal anterior para ser uma réplica de espera.

Realizar uma troca

Antes de iniciar uma troca, faça 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 do banco de dados principal 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 para ser a nova instância principal.

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

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Recuperar uma instância de espera automaticamente

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

A recuperação automática do cluster de banco de dados ajuda a manter a replicação contínua e íntegra do banco de dados principal.

Desativar a recuperação automática da instância

Por padrão, a recuperação automática de uma instância de espera está ativada nos clusters de banco de dados.

Para desativar as recuperações automáticas, siga estas etapas:

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

    spec:
  availability:
    enableAutoHeal: false

Ajustar as configurações do acionador de recuperação automática

Para cada cluster de banco de dados, é possível usar as configurações para ajustar as recuperações automáticas.

O operador do AlloyDB Omni emite verificações de integridade regulares que podem ser configuradas. Para mais informações, consulte Ajustar as configurações do acionador de failover automático. Se uma réplica de espera atingir o limite do acionador de recuperação automática, o operador do AlloyDB Omni vai acionar uma recuperação automática.

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

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Substitua:

  • AUTOHEAL_TRIGGER_THRESHOLD: um valor inteiro para o número de falhas consecutivas para a verificação de integridade antes que uma recuperação seja acionada. O valor padrão é 5. O valor mínimo é 2 devido a possíveis erros transitórios e únicos nas verificações de integridade de espera.

Resolver problemas de recuperação de instâncias

Se você usar um grande número de clusters de banco de dados em um único cluster do Kubernetes ou se tiver clusters de banco de dados com provisionamento insuficiente, a recuperação automática poderá causar indisponibilidade para o operador do AlloyDB Omni ou para os clusters de banco de dados. Se você receber um erro que começa com HealthCheckProber: health check for instance failed e o erro se referir a um tempo limite ou falha na conexão, tente as seguintes correções recomendadas:

Confira a seguir exemplos de erros que podem ser causados pela recuperação automática excessiva. Esses 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...

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

    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