Esta página mostra a documentação da versão 15.7.0 do AlloyDB Omni.
Acesse Versões da documentação do AlloyDB Omni para escolher uma versão diferente.

Esta página foi traduzida pela API Cloud Translation.

Gerenciar alta disponibilidade no Kubernetes

Neste documento, mostramos como ativar e testar a alta disponibilidade (HA) no cluster de banco de dados 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 Kubernetes para criar réplicas de espera da instância principal do banco de dados. O operador AlloyDB Omni configura seu 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 do 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 o HA, siga estas etapas:

Modifique o manifesto do cluster do 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 esperas a serem adicionadas.
```
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 esperas necessárias, comece definindo o valor como 1 ou 2.
Aplique o manifesto novamente.

Desativar HA

Para desativar a HA, siga estas etapas:

Defina numberOfStandbys como 0 no manifesto do cluster:

spec:
  availability:
    numberOfStandbys: 0

Aplique o manifesto novamente.

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, o recurso está 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 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 do banco de dados.
NAMESPACE: o namespace do cluster do banco de dados.

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 vai fazer 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 uma failover automática:

O tempo entre as verificações de integridade (padrão: 30 segundos)
O número de verificações de integridade com falhas consecutivas (o padrão é 3)

Um failover automático começa depois que o número especificado de verificações de integridade falharam consecutivamente, 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 a cada 30 segundos.

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. A failover automática é ativada por padrão.

O failover resulta na seguinte sequência de eventos:

O operador do AlloyDB Omni tira a instância do banco de dados principal da rede.
O operador AlloyDB Omni promove a réplica de reserva para ser a nova instância principal do banco de dados.
O operador do AlloyDB Omni exclui a instância de banco de dados principal anterior.
O operador AlloyDB Omni cria uma nova réplica reserva.

Desativar o failover automático

As failovers automáticas são ativadas por padrão nos clusters de banco de dados.

Para desativar uma failover, siga estas etapas:

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 na instância do banco de dados principal e em 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 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 na 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 de espera 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 da 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 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 ao qual ele se aplica.
DB_CLUSTER_NAME: o nome do cluster de banco de dados que vai falhar.

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 quando o criou.
NAMESPACE: o namespace do cluster do 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 reserva, consulte a próxima seção.

Alternar 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 é concluída, 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 revertidas. Use as 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 à conversão manual. Uma transição resulta na seguinte sequência de eventos:

O operador do AlloyDB Omni tira a instância do banco de dados principal da rede.
O operador AlloyDB Omni promove a réplica de reserva para ser a nova instância principal do banco de dados.
O operador do AlloyDB Omni muda a instância do banco de dados principal anterior para ser uma réplica de espera.

Realizar uma alternância

Antes de iniciar uma troca, faça o seguinte:

Verifique se a instância principal do banco de dados e a réplica de espera estão em um estado íntegro. Para mais informações, consulte Gerenciar e monitorar o AlloyDB Omni.
Verifique se o status atual de HA está na condição HAReady. Para mais informações, consulte Verificar HA em um cluster de banco de dados.

Para realizar uma conversão, crie e aplique um manifesto para um novo recurso de conversão:

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

Substitua:

SWITCHOVER_NAME: um nome para esse recurso de mudança, por exemplo, switchover-1.
DB_CLUSTER_NAME: o nome da instância do banco de dados principal a que a operação de migração se aplica.
STANBDY_REPLICA_NAME: o nome da instância do banco de dados que você quer promover para ser a nova principal.

Para identificar o nome da réplica reserva, execute o seguinte comando:
```
kubectl get instances.alloydbomni.internal.dbadmin.goog
```

Recuperar uma instância de reserva automaticamente

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

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

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

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

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

No manifesto do cluster, defina enableAutoHeal como false:

spec:
  availability:
    enableAutoHeal: false

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

Para cada cluster de banco de dados, é possível usar as configurações para ajustar as correçõ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 em espera atingir o limite de acionamento da 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 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 da verificação de integridade antes que uma correção seja acionada. O valor padrão é 3. O valor mínimo é 2 devido a possíveis erros temporários e únicos nas verificações de integridade em 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, será possível (embora improvável) sobrecarregar a recuperação automática. 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 de conexão, tente mitigar o erro fazendo o seguinte:

Reduza o número de clusters de banco de dados que você gerencia no cluster do Kubernetes.
Aumente o valor do limite healthcheckPeriodSeconds para que as verificações de integridade ocorram com menos frequência. Para mais informações, consulte Ajustar as configurações do acionador de failover automático.
Aumente o limite de CPU, o limite de memória ou ambos para o operador AlloyDB Omni. Para mais informações, consulte Sobre o gerenciamento automático de memória e Analisar o uso de heap de memória do operador do AlloyDB Omni.

Confira a seguir exemplos de erros que podem ser causados por uma correçã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 reserva como uma instância somente leitura

Para usar uma réplica reserva como uma instância somente leitura, siga estas etapas:

Defina enableStandbyAsReadReplica como true no manifesto do cluster do banco de dados:
```
spec:
  availability:
    enableStandbyAsReadReplica: true
```
Aplique o manifesto novamente.

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