נפח האחסון בתוכנית וגודל ה-PVC

בחירת גרסה של מאמר העזרה:

כדי למנוע השבתה של מסד הנתונים ואובדן נתונים שנגרמים כתוצאה ממיצוי נפח האחסון, צריך לתכנן בצורה מתאימה את נפח האחסון ואת נפח התביעה של Persistent Volume (PVC) עבור אשכולות מסד הנתונים של AlloyDB Omni ‏ (DBCluster). אפשר להשתמש בהמלצות לגבי גודל כדי להגדיר את נפחי האחסון כשמבצעים פריסה ב-Kubernetes באמצעות AlloyDB Omni Kubernetes operator.

כשיוצרים DBCluster משאב בהתאמה אישית, האופרטור של AlloyDB Omni מקצה PVCs של Kubernetes על סמך הדיסקים שמגדירים בשדות הבאים:

  • מופעי המתנה הראשיים ומופעי המתנה של זמינות גבוהה (HA): מוגדרים בשדה spec.primarySpec.resources.disks במשאב המותאם אישית DBCluster. אם מפעילים זמינות גבוהה על ידי הגדרת השדה spec.availability.numberOfStandbys, כל העתקים למצב המתנה משתמשים באותה הגדרת דיסק כמו המופע הראשי.
  • מופעים של מאגר קריאה: מוגדרים ב-spec.resources.disks בכל DBInstance משאב בהתאמה אישית שבו הערך של instanceType מוגדר כ-ReadPool. אם משמיטים את הקטע spec.resources במשאב DBInstance, מופע מאגר הקריאה מקבל בירושה את הגדרת הדיסק מהשדה spec.primarySpec.resources של משאב האב DBCluster.

נפחי PVC נתמכים

האופרטור AlloyDB Omni לא מקצה את כל נפחי ה-PVC בו-זמנית:

  • הקצאה תמיד: האופרטור תמיד מקצה את DataDisk, ObsDisk, BackupDisk ו-LogDisk לכל הפודים של מכונות מסד הנתונים המרכזיות, של מכונות ההמתנה עם זמינות גבוהה ושל מאגר הקריאה. צריך לציין במפורש את DataDisk ואת הגודל שלו במניפסט. הגדרת הערכים ObsDisk, BackupDisk ו-LogDisk במניפסט היא אופציונלית. אם לא מציינים אותם, כמו שמוצג במניפסט ההתקנה הבסיסי, האופרטור עדיין מקצה את ה-PVC האלה באמצעות הגדלים שמוגדרים כברירת מחדל.
  • לא מוקצה כברירת מחדל: האופרטור לא מקצה את נפח האחסון BackupRepoDisk כשיוצרים משאב עצמאי DBCluster או כשמאחסנים גיבויים ב-Cloud Storage או ב-Amazon S3. הוא מקצה את ה-Pod של מאגר הגיבוי ואת ה-PVCBackupRepoDisk שלו רק כשיוצרים משאב BackupPlan לאחסון גיבויים באופן מקומי באשכול Kubernetes (כלומר, משאב BackupPlan ללא שדה backupLocation מרוחק).

בטבלה הבאה מתוארים הכרכים הקבועים שמנוהלים על ידי אופרטור AlloyDB Omni:

שם הדיסק נתיב ההרכבה יעד הפוד הגדרת המניפסט התנהגות הקצאת ההרשאות מטרה
DataDisk /mnt/disks/pgsql Database Pod חובה תמיד מוקצה לכל Pod של מסד נתונים. מאחסן את ספריית האשכול של מסד נתוני PostgreSQL‏ (PGDATA), טבלאות, אינדקסים, קבצים זמניים וקטעים פעילים של יומן WAL.
ObsDisk /obs Database Pod אופציונלי (ברירת מחדל: 2Gi) תמיד מוקצה לכל Pod של מסד נתונים. אחסון נתוני יכולת צפייה, כולל יומני שרת PostgreSQL‏ (postgresql.log), יומני pgAudit‏ (postgresql.audit), יומנים פנימיים (postgresql.internal) וארכיונים של יומני .gz שהוחלפו.
BackupDisk /backup Database Pod אופציונלי (ברירת מחדל: 10Gi) תמיד מוקצה לכל Pod של מסד נתונים. מספק ספריית הכנה מקומית לפעולות גיבוי ב-Pod של מסד הנתונים.
LogDisk /archive Database Pod אופציונלי (ברירת מחדל: 2Gi) תמיד מוקצה לכל Pod של מסד נתונים. מספק יעד ייעודי לארכיון WAL עבור קבצי sidecar של גיבוי בהתאמה אישית או של צד שלישי. אם לא משתמשים ב-sidecar מותאם אישית לארכיון WAL, אפשר להשמיט את הדיסק הזה מהמניפסט ולהשאיר את הגודל שלו כברירת המחדל 2Gi.
BackupRepoDisk /backup ‫Pod של מאגר הגיבויים אופציונלי (ברירת מחדל: 10Gi) לא מוקצה כברירת מחדל. מוקצה רק כשמשאב BackupPlan שומר גיבויים באופן מקומי (לא מוקצה כשלא מוגדר משאב BackupPlan או כשגיבויים משתמשים ב-Cloud Storage או ב-Amazon S3). מספק נפח אחסון ייעודי שבו מאוחסנים גיבויים פיזיים של מסד הנתונים, גיבויים מצטברים ודיפרנציאליים וקבצי WAL בארכיון כשמשתמשים בגיבויים של אחסון מקומי.

המלצות לגבי גודל ה-PVC

כדי לקבוע את הגודל של כל נפח PVC בהתאם לעומס העבודה, להגדרות הרישום ולאסטרטגיית הגיבוי, אפשר להיעזר בהנחיות הבאות.

נפח DataDisk לאחסון מסד נתונים ראשי

האופרטור AlloyDB Omni תמיד מקצה את נפח האחסון DataDisk לכל Pod של מסד נתונים, ואתם צריכים לציין את הגודל שלו באופן מפורש במניפסט. כדי להעריך את הקיבולת המינימלית של DataDisk, משתמשים בנוסחה הבאה:

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

כשקובעים את הגודל של נפח DataDisk, חשוב להתייחס לגורמים הבאים:

  • תקורה של אינדקסים: אינדקסים של PostgreSQL וטבלאות של קטלוג המערכת בדרך כלל דורשים עוד 20% עד 50% של נפח אחסון מעבר לנתוני הטבלה הגולמיים.
  • מרווח ביטחון פעיל של WAL: עסקאות כתיבה עם תפוקה גבוהה צוברות קובצי WAL בספרייה pg_wal עד להשלמת נקודות הבדיקה. צריך להקצות מספיק נפח אחסון כדי להתאים לפרמטר של מסד הנתונים שהגדרתם max_wal_size (בדרך כלל כמה גיגה-בייט עד עשרות גיגה-בייט, בהתאם לעומס העבודה). כדי להציג או לשנות פרמטרים של מסד נתונים כמו max_wal_size, אפשר לעיין במאמר הגדרת פרמטרים של מסד נתונים.
  • קבצים זמניים ופעולות vacuum: מיון שאילתות, יצירת אינדקס, יצירת אינדקס מחדש ופעולות autovacuum דורשים נפח אחסון זמני נוסף בדיסק.
  • כלל כללי לגבי גודל: צריך להקצות נפח אחסון שגדול פי 1.5 עד פי 2 מגודל מסד הנתונים הגולמי, כולל לפחות 30% של מאגר בטיחות.

ObsDisk נפח ליומני אבחון וביקורת

אופרטור AlloyDB Omni תמיד מקצה את נפח האחסון ObsDisk לכל Pod של מסד נתונים (עם גודל ברירת המחדל 2Gi אם לא מציינים אותו במניפסט). אם נפח ObsDisk מתמלא, מערכת PostgreSQL לא יכולה לכתוב רשומות חדשות ביומן, והחלפת יומן יכולה להיעצר. מידע על הגדרת רוטציה של יומנים והגדרות שמירה של נפח ObsDisk זמין במאמר הגדרת רוטציה של יומנים.

כשקובעים את הגודל של נפח האחסון ObsDisk, כדאי לפעול לפי ההנחיות הבאות:

  • רישום סטנדרטי ביומן: נפח של 4GB עד 10GB מספיק לרישום סטנדרטי ביומן הפעולות בהגדרות ברירת המחדל של רוטציית היומן (סף רוטציה של 200MB ושמירה של 7 ימים).
  • רישום ביומן ביקורת (pgAudit): כשמפעילים רישום ביומן ביקורת באמצעות pgAudit, נפח היומן שנוצר גבוה משמעותית. מקצים 20GiB עד 50GiB או יותר, בהתאם לקצב השאילתות ולרמת הפירוט של כללי הביקורת.

נפח אחסון של BackupRepoDisk למאגר גיבויים מקומי

בניגוד לדיסקים של Pod של מסד הנתונים, BackupRepoDisk לא מוקצה כברירת מחדל. האופרטור AlloyDB Omni מקצה את ה-Pod של מאגר הגיבוי ואת ה-PVC שלו BackupRepoDisk רק כשיוצרים משאב BackupPlan לאחסון גיבויים באופן מקומי ב-Kubernetes cluster בלי שדה backupLocation מרוחק. אם לא תציינו את הדיסק הזה במניפסט DBCluster, הוא ישתמש בגודל ברירת המחדל 10Gi. אם לא מגדירים BackupPlan, או אם משתמשים ב-Cloud Storage עם סוג GCS או ב-Amazon S3 עם סוג S3, האופרטור לא יקצה BackupRepoDisk.BackupPlan מידע נוסף על הגדרת תוכניות גיבוי ושינוי הגודל של אחסון הגיבוי זמין במאמרים גיבוי ושחזור ב-Kubernetes ושינוי הגודל של דיסק גיבוי.

כשמאחסנים גיבויים באופן מקומי, נפח האחסון BackupRepoDisk מאחסן גיבויים מלאים, דיפרנציאליים ואינקרמנטליים דחוסים, יחד עם קובצי WAL בארכיון. הנפח הכולל של האחסון שנדרש תלוי בגודל מסד הנתונים, בקצב השינוי היומי של הנתונים, בלוח הזמנים של הגיבוי שמוגדר ב-backupSchedules ובתקופת השמירה שמוגדרת ב-backupRetainDays:

  • דחיסת גיבויים: גיבויים דחוסים בדרך כלל תופסים 37% עד 38% מגודל מסד הנתונים הלא דחוס, כלומר יש צמצום של 62% עד 63% בגודל. לדוגמה, מסד נתונים של 50GiB נדחס לכ-18.5GiB.
  • תזמון הגיבויים ומשך השמירה: שילוב של גיבויים מלאים שבועיים עם גיבויים מצטברים או גיבויים דיפרנציאליים יומיים דורש נפח אחסון קטן בהרבה מגיבויים מלאים יומיים.

בטבלה הבאה מוצג נפח אחסון נדרש מקסימלי לפי מדד השוואה וגודל BackupRepoDisk מומלץ (כולל מאגר נתונים זמני של 20%), בתוכניות גיבוי שונות למסד נתונים של 100GiB עם קצב שינוי נתונים יומי של 10% ותקופת שמירה שמוגדרת כברירת מחדל של 14 ימים (backupRetainDays: 14):

לוח זמנים לגיבוי (backupSchedules) גיבויים מלאים בשיא גיבויים דיפרנציאליים גיבויים מצטברים קבצי WAL בארכיון נפח האחסון המקסימלי בשימוש גודל מומלץ של BackupRepoDisk (+20% ‎ מאגר)
גיבוי מלא שבועי + גיבוי מצטבר יומי ‫148.0 GiB ‫0 GiB ‫66.6 GiB ‫‎155.4 GiB ‫370.0 GiB ‫444GiB (בערך פי 4.4 מגודל מסד הנתונים)
שבועי מלא + הפרש באמצע השבוע + יומי מצטבר ‫148.0 GiB ‫22.2 GiB ‫44.4GiB ‫‎155.4 GiB ‫370.0 GiB ‫444GiB (בערך פי 4.4 מגודל מסד הנתונים)
ייבוא שבועי מלא + ייבוא יומי של נתונים מצטברים ‫148.0 GiB ‫‎155.4 GiB ‫0 GiB ‫‎155.4 GiB ‫458.8 GiB ‫551GiB (בערך פי 5.5 מגודל מסד הנתונים)
יומי מלא בלבד (לוח זמנים שמוגדר כברירת מחדל) ‫592.0 GiB ‫0 GiB ‫0 GiB ‫111.0 GiB ‫703.0 GiB ‫844GiB (בערך פי 8.4 מגודל מסד הנתונים)

BackupDisk נפח לאחסון זמני של גיבויים של Pods של מסדי נתונים

אופרטור AlloyDB Omni תמיד מקצה את נפח האחסון BackupDisk לכל Pod של מסד נתונים, עם גודל ברירת מחדל של 10GiB‏ (10Gi).‏ AlloyDB Omni משתמש בנפח האחסון BackupDisk כספריית הכנה מקומית במהלך פעולות גיבוי. גודל ברירת המחדל של 10GiB מספיק לפעולות רגילות, ולכן אפשר להשמיט את BackupDisk מהמניפסט DBCluster כדי להשתמש בגודל ברירת המחדל.

LogDisk נפח לארכיון WAL מותאם אישית

אופרטור AlloyDB Omni תמיד מקצה נפח אחסון של LogDisk לכל Pod של מסד נתונים, עם גודל ברירת מחדל של 2GB ‏ (2Gi). צריך לציין גודל מותאם אישית לנפח האחסון של LogDisk רק אם פורסים קונטיינר מותאם אישית או קונטיינר sidecar של צד שלישי שמאחסן בארכיון קובצי WAL בספרייה /archive. בפריסות רגילות של אופרטור AlloyDB Omni שמשתמשות בגיבויים מובנים, אפשר להשמיט את LogDisk מהמניפסט DBCluster ולהשאיר אותו בגודל ברירת המחדל 2Gi.

הפניה לגודל לפי גודל מערך הנתונים

בטבלה הבאה מפורטים גדלים מומלצים של PVC לגדלים נפוצים של מערכי נתונים גולמיים:

גודל הנתונים הגולמיים גודל מומלץ DataDisk גודל מומלץ ObsDisk גודל מומלץ של BackupRepoDisk (מוקצה לגיבויים מקומיים בלבד) גודל מומלץ BackupDisk גודל מומלץ LogDisk
‫50 GiB ‫‎100 GiB ‫4GiB (10 עד 20GiB עם pgAudit) ‫150 GiB ‫‎10 GiB (ברירת מחדל) ‫2 GiB (ברירת מחדל)
‫200 GiB ‫400 GiB ‫10GiB (20 עד 50GiB עם pgAudit) ‫600 GiB ‫‎10 GiB (ברירת מחדל) ‫2 GiB (ברירת מחדל)
‫500 GiB ‫1,000 GiB‏ (1 TiB) ‫15GiB‏ (30 עד 60GiB עם pgAudit) ‫1,500 GiB ‏ (1.5 TiB) ‫‎10 GiB (ברירת מחדל) ‫2 GiB (ברירת מחדל)
‫1 TiB ‫2,000 GiB‏ (2 TiB) ‫20GiB (50 עד 100GiB עם pgAudit) ‫3,000 GiB‏ (3 TiB) ‫‎10 GiB (ברירת מחדל) ‫2 GiB (ברירת מחדל)

מעקב אחרי השימוש בדיסק ומדדי קלט/פלט

אתם יכולים לעקוב אחרי השימוש בדיסק בזמן אמת ישירות ב-Pods של מאגרי הנתונים והגיבויים באמצעות kubectl או באמצעות איסוף מדדי Prometheus שמיוצאים על ידי AlloyDB Omni.

בדיקת השימוש בדיסק באמצעות kubectl

כדי לבדוק את השימוש הנוכחי בנפח האחסון של הכרכים של ה-PVC המצורפים בתוך ה-Pod של מסד הנתונים ובתוך ה-Pod של מאגר הגיבוי, מריצים את הפקודות הבאות:

  1. מקבלים את השם של ה-Pod של מסד הנתונים עבור משאב DBCluster:

    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}')

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE: מרחב השמות של Kubernetes שבו פריסת אשכול מסד הנתונים.
    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים.

  2. מריצים את הפקודה df -h בתוך מאגר מסדי הנתונים כדי לראות את הקיבולת והשימוש של אמצעי האחסון DataDisk (/mnt/disks/pgsql),‏ ObsDisk (/obs),‏ BackupDisk (/backup) ו-LogDisk (/archive):

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

  3. אם הגדרתם משאב BackupPlan לאחסון גיבויים באופן מקומי, צריך לקבל את השם של מאגר הגיבויים של ה-Pod ולהריץ את הפקודה df -h כדי לראות את הקיבולת והשימוש של נפח האחסון BackupRepoDisk (/backup):

    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

מעקב אחרי מדדי האחסון באמצעות Prometheus

‫AlloyDB Omni מייצא מדדים של אחסון ושל קלט/פלט בדיסק בשירות al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (יציאה 9187). כדי ללמוד איך לגרד את המדדים האלה ולשאול עליהם שאילתות, אפשר לעיין במאמר מעקב אחרי AlloyDB Omni. כאן אפשר לראות רשימה מלאה של המדדים הזמינים ב-AlloyDB Omni.

אפשר לעקוב אחרי מדדי הדיסק הבאים:

  • נפח אחסון נדרש וקיבולת: אפשר לעקוב אחרי המדדים alloydb_omni_node_storage_usage_per_disk_byte ו-alloydb_omni_node_storage_limit_per_disk_byte, שמציגים את נפח האחסון בשימוש ואת הקיבולת הכוללת בבייט לכל אמצעי אחסון באמצעות התווית disk (לדוגמה, DataDisk, ‏ ObsDisk או BackupDisk). אפשר להגדיר התראות כשניצול הדיסק מגיע ל-80% ול-90% מהקיבולת, כדי שתוכלו להרחיב את אמצעי האחסון לפני שייגמר בהם המקום.
  • קצב העברת נתונים בדיסק ופעולות קלט/פלט: כדאי לעקוב אחרי המדדים alloydb_omni_node_storage_read_bytes_count_total ו-alloydb_omni_node_storage_write_bytes_count_total כדי לראות את קצב העברת הנתונים של קריאה וכתיבה בדיסק, ואחרי המדדים alloydb_omni_node_storage_read_ops_count_total ו-alloydb_omni_node_storage_write_ops_count_total כדי לראות את פעולות הקלט/פלט של קריאה וכתיבה.

שינוי הגודל של PVCs עבור DBCluster קיים

אם כבר יצרתם משאב DBCluster לפי השלבים במאמר יצירת אשכול מסדי נתונים, סביר להניח שבמניפסט הראשוני צוין רק נפח האחסון DataDisk (לדוגמה, 10Gi), בזמן שאופרטור AlloyDB Omni הקצה את נפחי האחסון ObsDisk (2Gi), ‏BackupDisk (10Gi) ו-LogDisk (2Gi) עם הגדלים שמוגדרים כברירת מחדל. כדי להרחיב את כל ה-PVC האלה, צריך לעדכן את המניפסט DBCluster.

לפני שמשנים את הגודל של PVC, חשוב לעיין בדרישות ובמגבלות הבאות:

  • הרחבת נפח האחסון של StorageClass: אפשר להגדיל את גודל הדיסק רק אם allowVolumeExpansion: true מוגדר במשאב StorageClass של Kubernetes. מידע נוסף זמין במאמר בנושא הרחבת תביעות של נפחים קבועים.
  • אין אפשרות להקטין את הגודל או לשנות את StorageClass: אי אפשר להקטין את הגודל של דיסק, ואי אפשר לשנות את השדה storageClass של PVC קיים אחרי שהוא הוקצה.
  • שינוי הגודל של דיסקים בגודל ברירת המחדל: כדי להרחיב דיסק שהשמטתם בעבר מהמניפסט (כמו נפח ObsDisk או נפח BackupRepoDisk), מוסיפים רשומה לדיסק הזה בשדה spec.primarySpec.resources.disks עם שדה size גדול יותר מקיבולת ברירת המחדל הנוכחית שלו. כשמעדכנים את קובץ המניפסט, תמיד צריך להשאיר את DataDisk ואת כל הערכים הקיימים האחרים של הדיסק ברשימה disks.
  • התנהגות של הפעלה מחדש של Pod: כשמשנים את השדה resources.disks, אופרטור AlloyDB Omni מעדכן את ה-PVC הבסיסי ומפעיל מחדש את ה-Pod של מופע מסד הנתונים כדי להחיל את מפרט המשאבים החדש. כדי לצמצם את זמן ההשבתה, אפשר להרחיב את נפח האחסון במהלך חלון זמן מתוכנן לתחזוקה או להגדיר זמינות גבוהה.

כדי לבדוק ולשנות את הגודל של ה-PVC ב-DBCluster, פועלים לפי השלבים הבאים:

  1. מציגים את ה-PVC במרחב השמות של אשכול מסד הנתונים כדי לבדוק את הקיבולות הנוכחיות שלהם ואת StorageClass המשאב:

    kubectl get pvc -n NAMESPACE

    מחליפים את NAMESPACE במרחב השמות שבו פרסתם את DBCluster (לדוגמה, default).

    הפלט של אשכול בשם my-db-cluster אמור להיראות כך:

    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. מוודאים שהמשאב StorageClass שבו נעשה שימוש ב-PVC תומך בהרחבת נפח:

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

    מחליפים את STORAGE_CLASS_NAME בשם סוג האחסון מהעמודה STORAGECLASS של הפלט הקודם (לדוגמה, standard-rwo). מוודאים שהפקודה מחזירה true.

  3. מעדכנים את השדה spec.primarySpec.resources.disks במניפסט DBCluster כדי להגדיל את הערך size של נפח DataDisk, ומוסיפים דיסקים בגודל ברירת המחדל שצריך להרחיב (כמו נפח ObsDisk או נפח BackupRepoDisk).

    במניפסט לדוגמה הבא, נפח DataDisk מורחב ל-400Gi, נפח ObsDisk מורחב מברירת המחדל 2Gi ל-10Gi, ונפח BackupRepoDisk מוגדר ל-600Gi עבור עומס עבודה של 200GiB:

    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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים, לדוגמה my-db-cluster.
    • ‫NAMESPACE: מרחב השמות של אשכול מסד הנתונים.
    • ‫STORAGE_CLASS_NAME: השם של משאב StorageClass Kubernetes שמשמש את נפחי האחסון המתמיד, לדוגמה, standard-rwo. אם השמטתם את השדה storageClass כשיצרתם את האשכול, אתם יכולים להמשיך להשמיט אותו כדי שהאופרטור ישתמש ב-StorageClass שמוגדר כברירת מחדל באשכול.

  4. החלת המניפסט המעודכן של DBCluster:

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    מחליפים את DB_CLUSTER_MANIFEST בנתיב אל DBCluster קובץ המניפסט.

  5. מוודאים שהגדלים המורחבים משתקפים ב-PVC ובסטטוס DBCluster:

    kubectl get pvc -n NAMESPACE

    אפשר גם לבדוק את השדה allocatedResources.disks status במשאב DBCluster:

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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE: מרחב השמות של אשכול מסד הנתונים.
    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים.

מידע נוסף על שינוי הגודל של משאבי מחשוב ואחסון זמין במאמר שינוי הגודל של אשכול מסד נתונים מבוסס Kubernetes.

המאמרים הבאים