Esta página mostra a documentação da versão 15.5.4 do AlloyDB Omni.
Consulte a última documentação do AlloyDB Omni.

Esta página foi traduzida pela API Cloud Translation.

Gerenciar alta disponibilidade no Kubernetes

Esta página mostra como ativar e testar a alta disponibilidade (HA) no cluster de banco de dados do AlloyDB Omni baseado no Kubernetes. A realização das tarefas documentadas aqui requer 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, direcione o operador AlloyDB Omni Kubernetes para criar réplicas de reserva da instância de banco de dados principal. O operador AlloyDB Omni configura seu cluster de banco de dados para atualizar continuamente os dados nessa réplica, correspondendo a todas as alterações nos dados na sua 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 define o número de esperas que você quer adicionar definindo o parâmetro numberOfStandbys.
```
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ê estiver configurando a HA e 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 conferir o status atual de HA de um cluster de banco de dados, verifique a condição HAReady do status desse cluster. Se esse valor tiver um status definido como True, a HA estará configurada e funcionando no cluster do banco de dados.

Para verificar esse valor na linha de comando, 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 mais de 90 segundos, o operador AlloyDB Omni vai fazer o failover automático da instância do banco de dados principal para a instância de espera.

Os failovers são uma boa opção quando você quer se recuperar rapidamente de uma falha inesperada e minimizar o tempo de inatividade, mesmo que isso signifique perder uma pequena quantidade de dados se o banco de dados principal ficar indisponível antes que o backup seja totalmente atualizado.

O operador 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 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 AlloyDB Omni exclui a instância do 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

Aplique o manifesto novamente.

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, os papéis da instância do banco de dados principal e da réplica de espera são invertidos junto com a direção da replicação. Você precisa optar por alternâncias se quiser ter um melhor controle sobre o processo de teste da configuração de recuperação de desastres sem perda de dados.

O operador AlloyDB Omni oferece suporte à troca manual.

A transição resulta na seguinte sequência de eventos:

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

Realizar uma alternância

Antes de realizar uma troca, verifique se:

Verifique se a instância principal do banco de dados e a réplica de espera estão em um estado saudável. 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 migração, por exemplo, switchover-1.
DB_CLUSTER_NAME: o nome da instância do banco de dados principal à qual a operação de migração se aplica.
STANBDY_REPLICA_NAME: o nome da instância do banco de dados que você quer promover como primária.

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

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:

Modifique o manifesto do cluster de banco de dados para definir o parâmetro enableStandbyAsReadReplica como true.
```
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