Resolver problemas de um pod de banco de dados em loop de falha no AlloyDB Omni para Kubernetes

Selecione uma versão da documentação:

Nesta página, descrevemos como resolver problemas com o AlloyDB Omni para Kubernetes quando você encontrar as seguintes situações:

  • Você tem um cluster de banco de dados em loop de falha no Kubernetes e sabe o nome e o namespace do banco de dados, a instância interna e o pod.
  • Você precisa acessar um arquivo no pod do banco de dados, mas o loop de falha impede o acesso.

Um pod de banco de dados em loop de falha é um pod que inicia, falha e é reiniciado automaticamente pelo Kubernetes repetidamente. Esse ciclo continua indefinidamente até que o problema seja resolvido. O banco de dados fica indisponível e instável durante esse processo.

Antes de começar

Antes de seguir as orientações de solução de problemas neste documento, tente estas soluções:

  • Se a alta disponibilidade (HA) estiver disponível, acione um failover. Com a HA, uma instância em espera síncrona está pronta para substituir a instância principal.
  • Recupere de um backup, se houver um disponível. Essa abordagem é automatizada e menos propensa a erros.

Não é possível acessar arquivos em um pod de banco de dados em loop de falha

Descrição:um pod de banco de dados no cluster do Kubernetes entra em um estado CrashLoopBackOff. Esse estado impede que você use kubectl exec para acessar o sistema de arquivos do contêiner de banco de dados para depuração.

Correção recomendada:para resolver esse problema, interrompa temporariamente o loop de falhas aplicando um patch no StatefulSet do pod para substituir o comando do contêiner. Antes de continuar, considere alternativas mais simples, como acionar um failover ou fazer a recuperação de um backup, se disponível.

Para acessar o pod, siga estas etapas:

  1. Pause todos os recursos relacionados do AlloyDB Omni voltados ao usuário para evitar que eles interfiram no processo de recuperação.

    1. Liste todas as definições de recursos personalizados do Kubernetes do AlloyDB Omni:

      kubectl get crd | grep alloydbomni.dbadmin

    2. Analise a lista de recursos do cluster de banco de dados. Mantenha uma lista dos recursos pausados para poder reativá-los depois. No mínimo, você precisa pausar o recurso dbclusters.alloydbomni.dbadmin.goog.

    3. Pause cada recurso separadamente adicionando a anotação ctrlfwk.internal.gdc.goog/pause.

      kubectl annotate RESOURCE_TYPE -n NAMESPACE RESOURCE_NAME ctrlfwk.internal.gdc.goog/pause=true

      Substitua:

      • RESOURCE_TYPE: o tipo do recurso a ser pausado, por exemplo, dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: o namespace do cluster de banco de dados.
      • RESOURCE_NAME: o nome do recurso a ser pausado.

  2. Pause a instância interna que gerencia o pod em crashlooping.

    1. Encontre o nome da instância interna.

      kubectl get instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.

    2. Pause a instância. A anotação ctrlfwk.internal.gdc.goog/pause=true informa ao controlador do AlloyDB Omni para pausar o gerenciamento do recurso. Isso impede que o controlador reconcilie ou mude automaticamente o recurso enquanto você realiza etapas manuais de solução de problemas, como correção do StatefulSet subjacente.

      kubectl annotate instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE INSTANCE_NAME ctrlfwk.internal.gdc.goog/pause=true

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.
      • INSTANCE_NAME: o nome da instância encontrada.

  3. Evite que o pod entre em crashloop.

    Adicione um patch ao StatefulSet do pod para substituir o comando do contêiner principal. Essa mudança impede que o aplicativo seja iniciado e falhe, permitindo que você acesse o pod.

    1. Confirme o nome do pod em loop de falha.

      kubectl get pod -n NAMESPACE

      Substitua NAMESPACE, que é o nome do namespace em que você tem interesse.

    2. Encontre o nome do StatefulSet proprietário do pod.

      kubectl get pod -n NAMESPACE POD_NAME -ojsonpath='{.metadata.ownerReferences[0].name}'

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.
      • POD_NAME: o nome do pod em loop de falha.

    3. Adicione um patch ao StatefulSet para substituir o comando do contêiner de banco de dados por sleep infinity:

      kubectl patch statefulset STATEFULSET_NAME -n NAMESPACE --type='strategic' -p '
{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "name": "database",
            "command": ["sleep"],
            "args": ["infinity"],
            "livenessProbe": null,
            "startupProbe": null
          }
        ]
      }
    }
  }
}
'

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.
      • STATEFULSET_NAME: o nome do StatefulSet.

    4. Exclua o pod para aplicar o patch.

      kubectl delete pod -n NAMESPACE POD_NAME

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.
      • POD_NAME: o nome do pod em loop de falha.

  4. Acesse o banco de dados no pod.

    kubectl exec -ti -n NAMESPACE POD_NAME -c database -- bash

    Substitua:

    • NAMESPACE: o nome do namespace que você quer.
    • POD_NAME: o nome do pod em loop de falha.

    Depois que o novo pod for iniciado, ele vai executar o comando sleep em vez do aplicativo de banco de dados. Agora você pode acessar o shell do pod.

  5. Retome todos os componentes.

    Depois de investigar, restaure o estado original removendo as anotações pause. Você retoma os recursos na ordem inversa da pausa. Por exemplo, retome a instância antes de retomar o DBCluster. Essa ação reconcilia os recursos e reinicia o pod do banco de dados com o comando original.

    1. Para cada recurso pausado, remova a anotação anexando um hífen ao nome dela. O exemplo a seguir remove a anotação de uma instância:

      kubectl annotate instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE INSTANCE_NAME ctrlfwk.internal.gdc.goog/pause-

      Substitua:

      • NAMESPACE: o nome do namespace que você quer.
      • INSTANCE_NAME: o nome da instância que você encontrou na etapa anterior.

    2. Repita esse processo para todos os outros recursos que você pausou na primeira etapa.