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 alta disponibilidade no cluster de banco de dados, configure o operador do Kubernetes do AlloyDB Omni para criar réplicas de 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 e corresponde a todas as mudanças de dados na sua 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 usa o parâmetro numberOfStandbys para especificar o número de substitutos a serem adicionados.

    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ê não tiver certeza sobre o número de standbys 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 verificar o status da alta disponibilidade em um cluster de banco de dados, confira o status HAReady dele. Se o status de HAReady for True, a alta disponibilidade estará ativada e funcionando no cluster. Se for False, ele estará ativado, mas não pronto, porque está em processo de configuração.

Para verificar o status do HAReady usando a linha de comando kubectl, execute o comando a seguir:

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 de 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 consecutivas com falha (o padrão é 3)

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

Executar 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 é 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 o failover automático, 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 para a instância de banco de dados primária e para todas as réplicas em espera. A frequência padrão para verificações de integridade é de 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 do limite é o número de falhas consecutivas da 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 na verificação de integridade antes de um failover ser acionado. O valor padrão é 3. O valor mínimo é 0. Não há valor máximo. Se este campo for 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 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, a direção da replicação e as funções da instância de banco de dados principal e da réplica em espera serão invertidas. Use alternâncias 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 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 iniciar uma alternância, faça o seguinte:

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 do 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 a nova primária.

    Para identificar o nome da réplica em 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 corrigirá a instância excluindo a réplica de espera antiga e criando uma nova réplica de espera para substituí-la. 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 íntegra e contínua 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 em espera está ativada nos clusters de banco de dados.

Para desativar os reparos automáticos, siga estas etapas:

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

    spec:
  availability:
    enableAutoHeal: false

Ajustar as configurações de acionamento da autocorreção automática

Para cada cluster de banco de dados, é possível usar configurações para ajustar os reparos automáticos.

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

O valor do limite é o número de falhas consecutivas para a verificação de integridade antes que uma recuperação seja acionada. Para mudar o valor do 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 na verificação de integridade antes de uma recuperação ser 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 em espera.

Resolver problemas de recuperação de instâncias

Se você usa um grande número de clusters de banco de dados em um único cluster do Kubernetes ou se tem clusters de banco de dados com provisionamento insuficiente, a recuperação automática pode causar indisponibilidade para o operador do AlloyDB Omni ou os clusters de banco de dados. Se você receber um erro que começa com HealthCheckProber: health check for instance failed e faz referência 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 por um excesso de correção automática. 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 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. 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 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