Fehlerbehebung bei einem Datenbank-Pod mit Crashloop in AlloyDB Omni mit dem Container-Orchestrator

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie Probleme mit AlloyDB Omni für Kubernetes beheben, wenn die folgenden Situationen auftreten:

  • Sie haben einen Datenbankcluster in Kubernetes, der sich in einer Crashloop befindet, und Sie kennen den Namen und Namespace der Datenbank, ihre interne Instanz und den Pod.
  • Sie müssen auf eine Datei im Datenbank-Pod zugreifen, aber die Crashloop verhindert den Zugriff.

Ein Datenbank-Pod in einer Crashloop ist ein Pod, der wiederholt gestartet wird, abstürzt und dann automatisch von Kubernetes neu gestartet wird. Dieser Zyklus wird unbegrenzt fortgesetzt, bis das zugrunde liegende Problem behoben ist. Die Datenbank ist während dieses Vorgangs nicht verfügbar und instabil.

Hinweis

Bevor Sie die Anleitung zur Fehlerbehebung in diesem Dokument befolgen, versuchen Sie es mit diesen Lösungen:

  • Wenn Hochverfügbarkeit (HA) verfügbar ist, lösen Sie ein Failover aus. Bei HA ist eine synchrone Standby-Instanz bereit, die primäre Instanz zu ersetzen.
  • Stellen Sie die Daten aus einer Sicherung wieder her, falls eine verfügbar ist. Dieser Ansatz ist automatisiert und weniger fehleranfällig.

Kein Zugriff auf Dateien in einem Datenbank-Pod in einer Crashloop

Beschreibung:Ein Datenbank-Pod in Ihrem Kubernetes-Cluster wechselt in den Status CrashLoopBackOff. In diesem Status können Sie kubectl exec nicht verwenden, um auf das Dateisystem des Datenbankcontainers zuzugreifen und Fehler zu beheben.

Empfohlene Lösung:Um dieses Problem zu beheben, beenden Sie die Crashloop vorübergehend, indem Sie das StatefulSet des Pods patchen, um den Befehl des Containers zu überschreiben. Bevor Sie fortfahren, sollten Sie einfachere Alternativen in Betracht ziehen, z. B. ein Failover auslösen oder die Daten aus einer Sicherung wiederherstellen, falls verfügbar.

So greifen Sie auf den Pod zu:

  1. Pausieren Sie alle zugehörigen für Nutzer sichtbaren AlloyDB Omni-Ressourcen, damit sie den Wiederherstellungsprozess nicht beeinträchtigen.

    1. Listen Sie alle benutzerdefinierten Ressourcendefinitionen von AlloyDB Omni Kubernetes auf:

      kubectl get crd | grep alloydbomni.dbadmin

    2. Prüfen Sie die Liste der Ressourcen für Ihren Datenbankcluster. Führen Sie eine Liste der Ressourcen, die Sie pausieren, damit Sie sie später wieder aktivieren können. Sie müssen mindestens die Ressource dbclusters.alloydbomni.dbadmin.goog pausieren.

    3. Pausieren Sie jede Ressource einzeln, indem Sie die Annotation ctrlfwk.internal.gdc.goog/pause hinzufügen.

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

      Ersetzen Sie Folgendes:

      • RESOURCE_TYPE: der Typ der zu pausierenden Ressource, z. B. dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: der Namespace des Datenbankclusters.
      • RESOURCE_NAME: der Name der zu pausierenden Ressource.

  2. Pausieren Sie die interne Instanz, die den Pod in der Crashloop verwaltet.

    1. Suchen Sie den Namen der internen Instanz.

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

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.

    2. Pausieren Sie die Instanz. Die Annotation ctrlfwk.internal.gdc.goog/pause=true weist den AlloyDB Omni-Controller an, die Verwaltung der Ressource zu pausieren. Dadurch wird verhindert, dass der Controller die Ressource automatisch abgleicht oder ändert, während Sie manuell Schritte zur Fehlerbehebung ausführen, z. B. das zugrunde liegende StatefulSet patchen.

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

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.
      • INSTANCE_NAME: der Name der Instanz, die Sie gefunden haben.

  3. Verhindern Sie, dass der Pod in eine Crashloop gerät.

    Patchen Sie das StatefulSet des Pods, um den Befehl des Hauptcontainers zu überschreiben. Durch diese Änderung wird verhindert, dass die Anwendung gestartet wird und abstürzt, sodass Sie auf den Pod zugreifen können.

    1. Bestätigen Sie den Namen des Pods in der Crashloop.

      kubectl get pod -n NAMESPACE

      Ersetzen Sie NAMESPACE durch den Namen des Namespace, der Sie interessiert.

    2. Suchen Sie den Namen des StatefulSet, zu dem der Pod gehört.

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

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.
      • POD_NAME: der Name des Pods in der Crashloop.

    3. Patchen Sie das StatefulSet, um den Befehl des Datenbankcontainers durch sleep infinity zu ersetzen:

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

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.
      • STATEFULSET_NAME: der Name des StatefulSet.

    4. Löschen Sie den Pod, um den Patch anzuwenden.

      kubectl delete pod -n NAMESPACE POD_NAME

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.
      • POD_NAME: der Name des Pods in der Crashloop.

  4. Greifen Sie auf die Datenbank im Pod zu.

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

    Ersetzen Sie Folgendes:

    • NAMESPACE: der Name des Namespace, der Sie interessiert.
    • POD_NAME: der Name des Pods in der Crashloop.

    Nach dem Start des neuen Pods wird der Befehl sleep anstelle der Datenbankanwendung ausgeführt. Sie können jetzt auf die Shell des Pods zugreifen.

  5. Aktivieren Sie alle Komponenten wieder.

    Nach der Untersuchung stellen Sie den ursprünglichen Zustand wieder her, indem Sie die pause-Annotationen entfernen. Sie aktivieren die Ressourcen in umgekehrter Reihenfolge ihrer Pausierung wieder. Aktivieren Sie beispielsweise die Instanz wieder, bevor Sie den DB-Cluster wieder aktivieren. Dadurch werden die Ressourcen abgeglichen und der Datenbank-Pod mit seinem ursprünglichen Befehl neu gestartet.

    1. Entfernen Sie für jede pausierte Ressource die Annotation, indem Sie dem Annotationsnamen einen Bindestrich anhängen. Im folgenden Beispiel wird die Annotation aus einer Instanz entfernt:

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

      Ersetzen Sie Folgendes:

      • NAMESPACE: der Name des Namespace, der Sie interessiert.
      • INSTANCE_NAME: der Name der Instanz, die Sie im vorherigen Schritt gefunden haben.

    2. Wiederholen Sie diesen Vorgang für alle anderen Ressourcen, die Sie im ersten Schritt pausiert haben.