Fehlerbehebung bei einem Datenbank-Pod mit Crashloop in AlloyDB Omni für Kubernetes

Wählen Sie eine Dokumentationsversion aus: 16.9.0

• Aktuell (17.5.0)
• 17.5.0
• 16.9.0
• 15.13.0

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

• Sie haben einen Datenbankcluster in Kubernetes, der in einer Schleife abstürzt, und Sie kennen den Namen und Namespace der Datenbank, ihrer internen Instanz und des Pods.
• Sie müssen auf eine Datei im Datenbank-Pod zugreifen, aber der Crash-Loop verhindert den Zugriff.

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

Hinweise

Bevor Sie die Anleitung zur Fehlerbehebung in diesem Dokument befolgen, probieren Sie Folgendes aus:

• 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.

Auf Dateien in einem Datenbank-Pod, der in einer Schleife abstürzt, kann nicht zugegriffen werden

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 den Absturzzyklus vorübergehend, indem Sie den StatefulSet des Pods patchen, um den Befehl des Containers zu überschreiben. Bevor Sie fortfahren, sollten Sie einfachere Alternativen in Betracht ziehen, z. B. das Auslösen eines Failovers oder die Wiederherstellung aus einem Backup, sofern verfügbar.

So greifen Sie auf den Pod zu:

1. Pausieren Sie alle zugehörigen nutzerorientierten AlloyDB Omni-Ressourcen, damit sie den Wiederherstellungsprozess nicht beeinträchtigen.

   1. Alle benutzerdefinierten Ressourcendefinitionen von AlloyDB Omni Kubernetes auflisten:

      kubectl get crd | grep alloydbomni.dbadmin
      

   2. Sehen Sie sich die Liste der Ressourcen für Ihren Datenbankcluster an. Führen Sie eine Liste der pausierten Ressourcen, damit Sie sie später wieder aktivieren können. Sie müssen mindestens die dbclusters.alloydbomni.dbadmin.goog-Ressource 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 Ressource, die pausiert werden soll, z. B. dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: Der Namespace des Datenbankclusters.
      • RESOURCE_NAME: der Name der Ressource, die pausiert werden soll.

2. Pausieren Sie die interne Instanz, die den Pod mit Crashlooping 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. Halten Sie die Instanz an. 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 Fehlerbehebungsschritte 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 einer Crash-Schleife hängen bleibt.

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

   1. Bestätigen Sie den Namen des Pods, der in einer Schleife abstürzt.

      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, der in einer Schleife abstürzt.

   3. Patchen Sie 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, der in einer Schleife abstürzt.

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, der in einer Schleife abstürzt.

   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. Pausierung aller Komponenten aufheben

   Nachdem Sie die Ursache ermittelt haben, stellen Sie den ursprünglichen Zustand wieder her, indem Sie die pause-Anmerkungen entfernen. Sie heben die Pausierung der Ressourcen in umgekehrter Reihenfolge auf, in der Sie sie pausiert haben. Heben Sie beispielsweise die Pausierung der Instanz auf, bevor Sie die Pausierung des DB-Clusters aufheben. Dadurch werden die Ressourcen abgeglichen und der Datenbank-Pod wird 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 Anmerkung 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.