Resolva problemas de um pod de base de dados em ciclo de falhas no AlloyDB Omni para Kubernetes

Selecione uma versão da documentação: 15.13.0

• Atual (17.5.0)
• 17.5.0
• 16.9.0
• 15.13.0

Esta página descreve como resolver problemas com o AlloyDB Omni para Kubernetes quando se deparar com as seguintes situações:

• Tem um cluster de base de dados em ciclo infinito no Kubernetes e sabe o nome e o espaço de nomes da base de dados, a respetiva instância interna e o pod.
• Tem de aceder a um ficheiro no pod da base de dados, mas o ciclo de falhas impede o acesso.

Um pod de base de dados em crashlooping é um pod que é iniciado repetidamente, falha e, em seguida, é reiniciado automaticamente pelo Kubernetes. Este ciclo continua indefinidamente até o problema subjacente ser resolvido. A base de dados fica indisponível e instável durante este processo.

Antes de começar

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

• Se a alta disponibilidade (HA) estiver disponível, acione uma comutação por falha. Com a HA, uma instância de espera assíncrona está pronta para substituir a instância principal.
• Recuperar a partir de uma cópia de segurança, se estiver disponível. Esta abordagem é automática e menos propensa a erros.

Não é possível aceder aos ficheiros num pod de base de dados em ciclo de falhas

Descrição: um pod de base de dados no seu cluster do Kubernetes entra num estado CrashLoopBackOff. Este estado impede que use o kubectl exec para aceder ao sistema de ficheiros do contentor da base de dados para depuração.

Correção recomendada: para resolver este problema, pare temporariamente o ciclo de falhas aplicando uma correção ao StatefulSet do pod para substituir o comando do contentor. Antes de continuar, considere alternativas mais simples, como acionar uma comutação por falha ou recuperar a partir de uma cópia de segurança, se estiverem disponíveis.

Para aceder ao pod, siga estes passos:

1. Pausar todos os recursos do AlloyDB Omni orientados para o utilizador relacionados para impedir que interfiram com o 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. Reveja a lista de recursos do cluster de base de dados. Mantenha uma lista dos recursos que pausar para que os possa reativar mais tarde. No mínimo, tem de pausar o recurso dbclusters.alloydbomni.dbadmin.goog.

   3. Pausar 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 o seguinte:

      • RESOURCE_TYPE: o tipo de recurso a pausar, por exemplo, dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: o espaço de nomes do cluster da base de dados.
      • RESOURCE_NAME: o nome do recurso a pausar.

2. Pause a instância interna que gere o pod em ciclo de falhas.

   1. Encontre o nome da instância interna.

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

      Substitua o seguinte:

      • NAMESPACE: o nome do espaço de nomes no qual tem interesse.

   2. Pause a instância. A anotação ctrlfwk.internal.gdc.goog/pause=true indica ao controlador do AlloyDB Omni que pause a respetiva gestão do recurso. Isto impede que o controlador reconcilie automaticamente ou altere o recurso enquanto executa manualmente os passos de resolução de problemas, como aplicar patches ao StatefulSet subjacente.

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

      Substitua o seguinte:

      • NAMESPACE: o nome do espaço de nomes que lhe interessa.
      • INSTANCE_NAME: o nome da instância que encontrou.

3. Impedir que o pod entre num ciclo de falhas.

   Aplique uma correção ao StatefulSet do pod para substituir o comando do contentor principal. Esta alteração impede que a aplicação seja iniciada e falhe, o que lhe permite aceder ao pod.

   1. Confirme o nome do pod crashlooping.

      kubectl get pod -n NAMESPACE
      

      Substitua NAMESPACE, que é o nome do espaço de nomes que lhe interessa.

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

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

      Substitua o seguinte:

      • NAMESPACE: o nome do espaço de nomes que lhe interessa.
      • POD_NAME: o nome do pod em crashlooping.

   3. Aplique uma correção ao StatefulSet para substituir o comando do contentor da base 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 o seguinte:

      • NAMESPACE: o nome do espaço de nomes que lhe interessa.
      • STATEFULSET_NAME: o nome do StatefulSet.

   4. Elimine o pod para aplicar a correção.

      kubectl delete pod -n NAMESPACE POD_NAME
      

      Substitua o seguinte:

      • NAMESPACE: o nome do espaço de nomes que lhe interessa.
      • POD_NAME: o nome do pod em crashlooping.

4. Aceder à base de dados no pod.

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

   Substitua o seguinte:

   • NAMESPACE: o nome do espaço de nomes que lhe interessa.
   • POD_NAME: o nome do pod em crashlooping.

   Após o início do novo pod, este executa o comando sleep em vez da aplicação de base de dados. Já pode aceder ao shell do pod.

5. Retome todos os componentes.

   Após a investigação, restaure o estado original removendo as anotações pause. Desativar a pausa dos recursos pela ordem inversa da pausa; por exemplo, desative a pausa da instância antes de desativar a pausa do DBCluster. Esta ação reconcilia os recursos e reinicia o pod da base de dados com o respetivo comando original.

   1. Para cada recurso que pausou, remova a anotação acrescentando um hífen ao nome da anotação. O exemplo seguinte 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 o seguinte:

      • NAMESPACE: o nome do espaço de nomes que lhe interessa.
      • INSTANCE_NAME: o nome da instância que encontrou no passo anterior.

   2. Repita este processo para todos os outros recursos que pausou no primeiro passo.