Speicher- und PVC-Größen planen

Wählen Sie eine Dokumentationsversion aus:

Um Datenbankausfallzeiten und Datenverlust aufgrund von Speichermangel zu vermeiden, müssen Sie die Speicher- und PersistentVolumeClaim-Kapazitäten (PVC) für Ihre AlloyDB Omni-Datenbankcluster (DBCluster) entsprechend planen. Verwenden Sie diese Empfehlungen zur Größenanpassung, um Ihre Volumes zu konfigurieren, wenn Sie die Bereitstellung in Kubernetes mit dem AlloyDB Omni Kubernetes-Operator vornehmen.

Wenn Sie eine benutzerdefinierte DBCluster-Ressource erstellen, stellt der AlloyDB Omni-Operator Kubernetes-PVCs basierend auf den Festplatten bereit, die Sie in den folgenden Feldern definieren:

  • Primäre Instanzen und HA-Stand-by-Instanzen (Hochverfügbarkeit): werden im Feld spec.primarySpec.resources.disks Ihrer benutzerdefinierten Ressource DBCluster konfiguriert. Wenn Sie Hochverfügbarkeit aktivieren, indem Sie das Feld spec.availability.numberOfStandbys konfigurieren, verwendet jedes Stand-by-Replikat dieselbe Laufwerkskonfiguration wie die primäre Instanz.
  • Lese-Pool-Instanzen: In spec.resources.disks für jede benutzerdefinierte DBInstance-Ressource konfiguriert, in der instanceType auf ReadPool festgelegt ist. Wenn Sie den Abschnitt spec.resources für eine DBInstance-Ressource weglassen, übernimmt die Lesepoolinstanz die Laufwerkskonfiguration aus dem Feld spec.primarySpec.resources der übergeordneten DBCluster-Ressource.

Unterstützte PVC-Volumes

Der AlloyDB Omni-Operator stellt nicht alle PVC-Volumes gleichzeitig bereit:

  • Immer bereitgestellt: Der Operator stellt DataDisk, ObsDisk, BackupDisk und LogDisk immer für alle Pods von primären Datenbankinstanzen, HA-Stand-by-Instanzen und Lesepoolinstanzen bereit. Sie müssen DataDisk und seine Größe explizit in Ihrem Manifest angeben. Die Angabe von ObsDisk, BackupDisk und LogDisk in Ihrem Manifest ist optional. Wenn Sie sie weglassen, wie im einfachen Installationsmanifest gezeigt, stellt der Operator diese PVCs weiterhin mit ihren Standardgrößen bereit.
  • Nicht standardmäßig bereitgestellt: Der Operator stellt das BackupRepoDisk-Volume nicht bereit, wenn Sie eine eigenständige DBCluster-Ressource erstellen oder Back-ups in Cloud Storage oder Amazon S3 speichern. Der Pod für das Backup-Repository und der zugehörige BackupRepoDisk-PVC werden nur bereitgestellt, wenn Sie eine BackupPlan-Ressource erstellen, um Backups lokal in Ihrem Kubernetes-Cluster zu speichern, d. h. eine BackupPlan-Ressource ohne das Feld „remote“ backupLocation.

In der folgenden Tabelle werden die persistenten Volumes beschrieben, die vom AlloyDB Omni-Operator verwaltet werden:

Laufwerksname Bereitstellungspfad Ziel-Pod Manifestkonfiguration Bereitstellungsverhalten Zweck
DataDisk /mnt/disks/pgsql Datenbank-Pod Erforderlich Wird immer für jeden Datenbank-Pod bereitgestellt. Speichert das PostgreSQL-Datenbankclusterverzeichnis (PGDATA), Tabellen, Indexe, temporäre Dateien und aktive WAL-Segmente (Write-Ahead Log).
ObsDisk /obs Datenbank-Pod Optional (Standard: 2Gi) Wird immer für jeden Datenbank-Pod bereitgestellt. Speichert Observability-Daten, einschließlich PostgreSQL-Serverlogs (postgresql.log), pgAudit-Logs (postgresql.audit), interne Logs (postgresql.internal) und rotierte .gz-Logarchive.
BackupDisk /backup Datenbank-Pod Optional (Standard: 10Gi) Wird immer für jeden Datenbank-Pod bereitgestellt. Bietet ein lokales Staging-Verzeichnis für Sicherungsvorgänge im Datenbank-Pod.
LogDisk /archive Datenbank-Pod Optional (Standard: 2Gi) Wird immer für jeden Datenbank-Pod bereitgestellt. Bietet ein dediziertes WAL-Archivziel für benutzerdefinierte oder Drittanbieter-Backup-Sidecars. Wenn Sie keinen benutzerdefinierten Sidecar für die WAL-Archivierung verwenden, können Sie dieses Laufwerk aus Ihrem Manifest entfernen und die Standardgröße von 2Gi beibehalten.
BackupRepoDisk /backup Pod für Backup-Repository Optional (Standard: 10Gi) Nicht standardmäßig bereitgestellt. Wird nur bereitgestellt, wenn eine BackupPlan-Ressource Back-ups lokal speichert (nicht bereitgestellt, wenn keine BackupPlan konfiguriert ist oder wenn Back-ups Cloud Storage oder Amazon S3 verwenden). Bietet ein dediziertes Volume, in dem physische Datenbanksicherungen, inkrementelle und differenzielle Backups sowie archivierte WAL-Dateien gespeichert werden, wenn Sie lokale Speichersicherungen verwenden.

Empfehlungen zur Größenanpassung von PVCs

Anhand der folgenden Richtlinien können Sie die Größe der einzelnen PVC-Volumes basierend auf Ihrer Arbeitslast, Protokollierungskonfiguration und Sicherungsstrategie festlegen.

DataDisk-Volume für den primären Datenbankspeicher

Der AlloyDB Omni-Operator stellt das DataDisk-Volume immer für jeden Datenbank-Pod bereit und Sie müssen seine Größe explizit in Ihrem Manifest angeben. Um die Mindestkapazität für DataDisk zu schätzen, verwenden Sie die folgende Formel:

DataDisk capacity = (initial_dataset_size + projected_growth + max_wal_size) * 1.30

Berücksichtigen Sie bei der Festlegung der Größe des DataDisk-Volumes die folgenden Faktoren:

  • Index-Overhead: PostgreSQL-Indizes und Systemkatalogtabellen benötigen in der Regel 20% bis 50% mehr Speicherplatz als die Rohdaten der Tabelle.
  • Aktiver WAL-Puffer: Bei Schreibtransaktionen mit hohem Durchsatz werden WAL-Dateien im Verzeichnis pg_wal angesammelt, bis die Checkpoints abgeschlossen sind. Weisen Sie genügend Speicherplatz zu, um den konfigurierten Datenbankparameter max_wal_size aufzunehmen (in der Regel mehrere Gigabyte bis zu zehn Gigabyte, je nach Arbeitslast). Informationen zum Aufrufen oder Ändern von Datenbankparametern wie max_wal_size finden Sie unter Datenbankparameter konfigurieren.
  • Temporäre Dateien und Vacuum-Vorgänge: Für das Sortieren von Abfragen, das Erstellen von Indexen, das Neuindexieren und Autovacuum-Vorgänge ist zusätzlicher temporärer Speicherplatz auf der Festplatte erforderlich.
  • Allgemeine Regel für die Dimensionierung: Weisen Sie das 1,5- bis 2-Fache der Größe Ihrer Rohdatenbank zu, einschließlich eines Sicherheitsbuffers von mindestens 30 %.

ObsDisk-Volumen für Diagnose- und Audit-Logs

Der AlloyDB Omni-Operator stellt immer das ObsDisk-Volume für jeden Datenbank-Pod bereit (mit der Standardgröße 2Gi, wenn Sie es in Ihrem Manifest weglassen). Wenn das ObsDisk-Volume voll ist, kann PostgreSQL keine neuen Logeinträge schreiben und die Logrotation kann ins Stocken geraten. Informationen zum Konfigurieren der Einstellungen für den Logwechsel und die Aufbewahrung für das ObsDisk-Volume finden Sie unter Logwechsel konfigurieren.

Beachten Sie beim Festlegen der Größe des ObsDisk-Volumes die folgenden Richtlinien:

  • Standard-Logging: Für das Standard-Betriebs-Logging mit den Standardeinstellungen für die Logrotation (Rotationsgrenzwert von 200 MB und Aufbewahrungsdauer von 7 Tagen) reicht ein Volumen von 4 bis 10 GiB aus.
  • Audit-Logging (pgAudit): Wenn Sie Audit-Logging mit pgAudit aktivieren, wird durch das Audit-Logging ein deutlich höheres Logvolumen generiert. Weisen Sie je nach Abfragerate und Ausführlichkeit der Auditregel 20 GiB oder mehr zu.

BackupRepoDisk-Volume für das lokale Backup-Repository

Im Gegensatz zu den Festplatten für Datenbank-Pods wird BackupRepoDisk nicht standardmäßig bereitgestellt. Der AlloyDB Omni-Operator stellt den Pod für das Sicherungs-Repository und den zugehörigen BackupRepoDisk-PVC nur bereit, wenn Sie eine BackupPlan-Ressource zum lokalen Speichern von Sicherungen in Ihrem Kubernetes-Cluster ohne ein backupLocation-Feld erstellen. Wenn Sie dieses Laufwerk aus Ihrem DBCluster-Manifest weglassen, wird die Standardgröße von 10Gi verwendet. Wenn Sie keine BackupPlan-Ressource konfigurieren oder Ihre BackupPlan-Ressource Cloud Storage mit dem Typ GCS oder Amazon S3 mit dem Typ S3 verwendet, stellt der Operator keine BackupRepoDisk bereit. Weitere Informationen zum Konfigurieren von Sicherungsplänen und zum Ändern der Größe des Sicherungsspeichers finden Sie unter Sichern und Wiederherstellen in Kubernetes und Größe einer Sicherungsdisk ändern.

Wenn Sie Sicherungen lokal speichern, werden auf dem BackupRepoDisk-Volume komprimierte vollständige, differenzielle und inkrementelle Sicherungen zusammen mit archivierten WAL-Dateien gespeichert. Der insgesamt benötigte Speicherplatz hängt von der Größe Ihrer Datenbank, der täglichen Änderungsrate der Daten, dem in backupSchedules definierten Sicherungszeitplan und dem von backupRetainDays festgelegten Aufbewahrungszeitraum ab:

  • Sicherungskomprimierung: Komprimierte Sicherungen benötigen in der Regel 37% bis 38% der Größe der unkomprimierten Datenbank, was einer Größenreduzierung von 62% bis 63% entspricht. Eine 50 GiB große Datenbank wird beispielsweise auf etwa 18, 5 GiB komprimiert.
  • Sicherungszeitplan und Aufbewahrung: Wenn Sie wöchentliche Vollsicherungen mit täglichen inkrementellen oder differenziellen Backups kombinieren, benötigen Sie deutlich weniger Speicherplatz als bei täglichen Vollsicherungen.

In der folgenden Tabelle sehen Sie die gemessene maximale Speichernutzung und die empfohlene Größe von BackupRepoDisk (einschließlich eines Puffers von 20 %) für verschiedene Sicherungszeitpläne für eine 100-GiB-Datenbank mit einer täglichen Datenänderungsrate von 10% und dem standardmäßigen Aufbewahrungszeitraum von 14 Tagen (backupRetainDays: 14):

Sicherungszeitplan (backupSchedules) Spitzenwerte bei Vollsicherungen Differenzielle Backups Inkrementelle Sicherungen Archivierte WAL-Dateien Spitzenauslastung des Speichers Empfohlene Größe von BackupRepoDisk (+20% Puffer)
Wöchentlich vollständig + täglich inkrementell 148,0 GiB 0 GiB 66,6 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4-fache Datenbankgröße)
Wöchentlich: vollständig + differenziell (Mitte der Woche) + täglich inkrementell 148,0 GiB 22,2 GiB 44,4 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4-fache Datenbankgröße)
Wöchentlich vollständig + täglich differenziell 148,0 GiB 155,4 GiB 0 GiB 155,4 GiB 458,8 GiB 551 GiB (~5,5-fache Datenbankgröße)
Nur täglich vollständig (Standardzeitplan) 592,0 GiB 0 GiB 0 GiB 111,0 GiB 703,0 GiB 844 GiB (~8,4-fache Datenbankgröße)

BackupDisk-Volume für das Staging von Datenbank-Pod-Sicherungen

Der AlloyDB Omni-Operator stellt das BackupDisk-Volume immer für jeden Datenbank-Pod mit einer Standardgröße von 10 GiB (10Gi) bereit. AlloyDB Omni verwendet das BackupDisk-Volume als lokales Staging-Verzeichnis während der Sicherungsvorgänge. Da die Standardgröße von 10 GiB für Standardvorgänge ausreicht, können Sie BackupDisk aus Ihrem DBCluster-Manifest weglassen, um die Standardgröße zu verwenden.

LogDisk Volumen für die benutzerdefinierte WAL-Archivierung

Der AlloyDB Omni-Operator stellt das LogDisk-Volume immer für jeden Datenbank-Pod mit einer Standardgröße von 2 GiB (2Gi) bereit. Sie müssen nur dann eine benutzerdefinierte Größe für das LogDisk-Volume angeben, wenn Sie einen benutzerdefinierten oder Drittanbieter-Sidecar-Container bereitstellen, der WAL-Dateien im Verzeichnis /archive archiviert. Bei Standardbereitstellungen des AlloyDB Omni-Operators, die integrierte Sicherungen verwenden, können Sie LogDisk aus Ihrem DBCluster-Manifest weglassen und die Standardgröße 2Gi beibehalten.

Referenz für die Größenanpassung nach Dataset-Größe

In der folgenden Tabelle finden Sie empfohlene PVC-Größen für gängige Rohdatensatzgrößen:

Größe der Rohdaten Empfohlene Größe für DataDisk Empfohlene Größe für ObsDisk Empfohlene Größe für BackupRepoDisk (nur für lokale Sicherungen bereitgestellt) Empfohlene Größe für BackupDisk Empfohlene Größe für LogDisk
50 GiB 100 GiB 4 GiB (10 bis 20 GiB mit pgAudit) 150 GiB 10 GiB (Standard) 2 GiB (Standard)
200 GiB 400 GiB 10 GiB (20 bis 50 GiB mit pgAudit) 600 GiB 10 GiB (Standard) 2 GiB (Standard)
500 GiB 1.000 GiB (1 TiB) 15 GiB (30 bis 60 GiB mit pgAudit) 1.500 GiB (1,5 TiB) 10 GiB (Standard) 2 GiB (Standard)
1 TiB 2.000 GiB (2 TiB) 20 GiB (50 bis 100 GiB mit pgAudit) 3.000 GiB (3 TiB) 10 GiB (Standard) 2 GiB (Standard)

Laufwerkauslastung und E/A-Messwerte überwachen

Sie können die aktuelle Festplattennutzung direkt in Ihren Datenbank- und Sicherungs-Repository-Pods mit kubectl überwachen oder Prometheus-Messwerte erfassen, die von AlloyDB Omni exportiert werden.

Laufwerksnutzung mit kubectl prüfen

Führen Sie die folgenden Befehle aus, um die aktuelle Speicherplatznutzung der bereitgestellten PVC-Volumes in Ihrem Datenbank-Pod und Backup-Repository-Pod zu prüfen:

  1. Rufen Sie den Namen des Datenbank-Pods für Ihre DBCluster-Ressource ab:

    export DB_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')

    Ersetzen Sie Folgendes:

    • NAMESPACE: Der Kubernetes-Namespace, in dem Ihr Datenbankcluster bereitgestellt wird.
    • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters.

  2. Führen Sie df -h im Datenbankcontainer aus, um die Kapazität und Nutzung der Volumes DataDisk (/mnt/disks/pgsql), ObsDisk (/obs), BackupDisk (/backup) und LogDisk (/archive) aufzurufen:

    kubectl exec -n NAMESPACE "${DB_POD}" -c database -- df -h /mnt/disks/pgsql /obs /backup /archive

  3. Wenn Sie eine BackupPlan-Ressource für die lokale Speicherung von Sicherungen konfiguriert haben, rufen Sie den Namen des Pods des Backup-Repositorys ab und führen Sie df -h aus, um die Kapazität und Nutzung des BackupRepoDisk-Volumes (/backup) aufzurufen:

    export BACKUP_REPO_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/backup-repository -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n NAMESPACE "${BACKUP_REPO_POD}" -c backuprepo -- df -h /backup

Speichermesswerte mit Prometheus überwachen

AlloyDB Omni exportiert Speicher- und Laufwerk-I/O-Messwerte für den Dienst al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (Port 9187). Informationen zum Erfassen und Abfragen dieser Messwerte finden Sie unter AlloyDB Omni überwachen. Eine vollständige Liste der verfügbaren Messwerte finden Sie unter AlloyDB Omni-Messwerte.

Behalten Sie die folgenden Laufwerksmesswerte im Blick:

  • Speicherplatznutzung und ‑kapazität: Beobachten Sie die Messwerte alloydb_omni_node_storage_usage_per_disk_byte und alloydb_omni_node_storage_limit_per_disk_byte, die den verwendeten Speicherplatz und die Gesamtkapazität in Byte für jedes Volume mit dem Label disk (z. B. DataDisk, ObsDisk oder BackupDisk) angeben. Konfigurieren Sie Benachrichtigungen, wenn die Festplattennutzung 80% und 90% der Kapazität erreicht, damit Sie Volumes erweitern können, bevor der Speicherplatz aufgebraucht ist.
  • Laufwerkdurchsatz und E/A-Vorgänge: Beobachten Sie die Messwerte alloydb_omni_node_storage_read_bytes_count_total und alloydb_omni_node_storage_write_bytes_count_total für den Lese- und Schreibdurchsatz des Laufwerks sowie die Messwerte alloydb_omni_node_storage_read_ops_count_total und alloydb_omni_node_storage_write_ops_count_total für Lese- und Schreib-E/A-Vorgänge.

Größe von PVCs für eine vorhandene DBCluster ändern

Wenn Sie bereits eine DBCluster-Ressource gemäß Datenbankcluster erstellen erstellt haben, wurde in Ihrem ursprünglichen Manifest wahrscheinlich nur das DataDisk-Volume angegeben (z. B. 10Gi), während der AlloyDB Omni-Operator die Volumes ObsDisk (2Gi), BackupDisk (10Gi) und LogDisk (2Gi) mit ihren Standardgrößen bereitgestellt hat. Sie können diese PVCs erweitern, indem Sie Ihr DBCluster-Manifest aktualisieren.

Bevor Sie die Größe eines PVC ändern, sollten Sie die folgenden Anforderungen und Einschränkungen beachten:

  • StorageClass-Volumenerweiterung: Sie können die Größe eines Laufwerks nur erhöhen, wenn in der zugehörigen Kubernetes-Ressource StorageClass allowVolumeExpansion: true festgelegt ist. Weitere Informationen finden Sie unter Ansprüche auf nichtflüchtige Volumes erweitern.
  • Kein Verkleinern oder Ändern der StorageClass: Sie können die Größe eines Laufwerks nicht verringern und das Feld storageClass einer vorhandenen PVC nicht ändern, nachdem sie bereitgestellt wurde.
  • Größe von Laufwerken mit Standardgröße ändern: Wenn Sie ein Laufwerk erweitern möchten, das Sie zuvor aus Ihrem Manifest entfernt haben (z. B. das ObsDisk- oder BackupRepoDisk-Volume), fügen Sie dem Feld spec.primarySpec.resources.disks einen Eintrag für dieses Laufwerk mit einem Feld size hinzu, das größer als die aktuelle Standardkapazität ist. Behalten Sie beim Aktualisieren des Manifests immer DataDisk und alle anderen vorhandenen Laufwerkseinträge in der Liste disks bei.
  • Verhalten beim Neustart von Pods: Wenn Sie das Feld resources.disks ändern, aktualisiert der AlloyDB Omni-Operator den zugrunde liegenden PVC und startet den Pod der Datenbankinstanz neu, um die neue Ressourcenspezifikation anzuwenden. Führen Sie die Speichererweiterung während eines geplanten Wartungsfensters durch oder konfigurieren Sie Hochverfügbarkeit, um Ausfallzeiten zu minimieren.

So prüfen und ändern Sie die Größe der PVCs für Ihre DBCluster:

  1. Listen Sie die PVCs im Namespace Ihres Datenbankclusters auf, um die aktuelle Kapazität und die StorageClass-Ressource zu prüfen:

    kubectl get pvc -n NAMESPACE

    Ersetzen Sie NAMESPACE durch den Namespace, in dem Sie DBCluster bereitgestellt haben (z. B. default).

    Die Ausgabe für einen Cluster mit dem Namen my-db-cluster sieht in etwa so aus:

    NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
backupdisk-al-1060-my-db-cluster-0  Bound    pvc-45a28be2-a111-40ed-9641-61b9d25f313b   10Gi       RWO            standard-rwo   10m
datadisk-al-1060-my-db-cluster-0    Bound    pvc-c23a1ab8-f97c-4449-9072-502b6d9ba869   10Gi       RWO            standard-rwo   10m
logdisk-al-1060-my-db-cluster-0     Bound    pvc-f0c41d15-bb13-4d28-b94b-01a28dc67ef6   2Gi        RWO            standard-rwo   10m
obsdisk-al-1060-my-db-cluster-0     Bound    pvc-69ea1ca7-a868-4dc9-a9f8-503d5e5f2387   2Gi        RWO            standard-rwo   10m

  2. Prüfen Sie, ob die von Ihren PVCs verwendete StorageClass-Ressource die Volume-Erweiterung unterstützt:

    kubectl get storageclass STORAGE_CLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'

    Ersetzen Sie STORAGE_CLASS_NAME durch den Namen der Speicherklasse aus der Spalte STORAGECLASS der vorherigen Ausgabe (z. B. standard-rwo). Prüfen Sie, ob der Befehl true zurückgibt.

  3. Aktualisieren Sie das Feld spec.primarySpec.resources.disks in Ihrem DBCluster-Manifest, um den size-Wert des DataDisk-Volumes zu erhöhen, und fügen Sie alle Standardgrößen-Festplatten hinzu, die Sie erweitern müssen (z. B. das ObsDisk-Volume oder das BackupRepoDisk-Volume).

    Im folgenden Beispielmanifest wird das Volume DataDisk auf 400Gi erweitert, das Volume ObsDisk von seinem Standardwert 2Gi auf 10Gi erweitert und das Volume BackupRepoDisk mit 600Gi für eine Arbeitslast von 200 GiB konfiguriert:

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  namespace: NAMESPACE
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: 4
      memory: 32Gi
      disks:
      - name: DataDisk
        size: 400Gi
        storageClass: STORAGE_CLASS_NAME
      - name: ObsDisk
        size: 10Gi
        storageClass: STORAGE_CLASS_NAME
      - name: BackupRepoDisk
        size: 600Gi
        storageClass: STORAGE_CLASS_NAME

    Ersetzen Sie Folgendes:

    • DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters, z. B. my-db-cluster.
    • NAMESPACE: der Namespace Ihres Datenbankclusters.
    • STORAGE_CLASS_NAME: Der Name der Kubernetes-StorageClass-Ressource, die von Ihren persistenten Volumes verwendet wird, z. B. standard-rwo. Wenn Sie das Feld storageClass beim Erstellen des Clusters weggelassen haben, können Sie es weiterhin weglassen, damit der Operator die Standard-StorageClass Ihres Clusters verwendet.

  4. Wenden Sie das aktualisierte DBCluster-Manifest an:

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    Ersetzen Sie DB_CLUSTER_MANIFEST durch den Pfad zu Ihrer DBCluster-Manifestdatei.

  5. Prüfen Sie, ob die PVCs und der Status DBCluster die erweiterten Größen widerspiegeln:

    kubectl get pvc -n NAMESPACE

    Sie können auch das Statusfeld allocatedResources.disks in der DBCluster-Ressource prüfen:

    kubectl get dbcluster DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.allocatedResources.disks}{"\n"}'

    Ersetzen Sie Folgendes:

    • NAMESPACE: der Namespace Ihres Datenbankclusters.
    • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters.

Weitere Informationen zum Ändern der Größe von Compute- und Speicherressourcen finden Sie unter Größe des Kubernetes-basierten Datenbankclusters ändern.

Nächste Schritte