הגנה על הנתונים באמצעות גיבויים

בחירת גרסת תיעוד:

בדף הזה מתוארת ארכיטקטורת ההפניה של AlloyDB Omni Standard Availability, שמספקת הגנה על נתונים באמצעות גיבויים.

תרחישים לדוגמה

ארכיטקטורת ההפניה הזו תומכת בתרחישים הבאים:

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

איך פועלת ארכיטקטורת ההפניה

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

זמינות רגילה היא הטמעה בסיסית שמצמצמת את הצורך בחומרה או בשירותים נוספים, אבל יעד זמן השחזור (RTO) מתארך ככל שמסד הנתונים גדל. ככל שיש יותר נתונים לגיבוי, כך יידרש יותר זמן לשחזור ולשחזור מסד הנתונים. אובדן הנתונים תלוי בסוג הגיבוי. אם רק קובצי הנתונים מגובים באופן תקופתי, כשמשחזרים את הנתונים, חלק מהם אובדים כי הם לא גובו מאז הגיבוי האחרון.

צמצום RPO

התכונה continuous archiving של PostgreSQL מאפשרת להשיג יעד נמוך להתאוששות מאסון (RPO) ולהפעיל שחזור מערכת מנקודה מסוימת בזמן (PITR) באמצעות גיבויים. התהליך הזה כולל ארכיון של קובצי Write-Ahead Logging ‏ (WAL) וסטרימינג של נתוני WAL, יכול להיות למיקום אחסון מרוחק.

אם קובצי WAL מאוחסנים בארכיון רק כשהם מלאים או במרווחי זמן ספציפיים, אובדן מלא של מסד הנתונים (כולל קובצי WAL הנוכחיים) מגביל את השחזור לקובץ WAL האחרון שאוחסן בארכיון. המשמעות היא שצריך לקחת בחשבון את אובדן הנתונים הפוטנציאלי בנקודת היעד לשחזור (RPO). לעומת זאת, העברה רציפה של נתוני WAL ממזערת את הסיכון לאובדן נתונים.

כשמבצעים גיבויים רציפים, אפשר לבצע שחזור לנקודת זמן ספציפית. שחזור מערכת מנקודה מסוימת בזמן (PITR) מאפשר שחזור למצב שהיה לפני שגיאה, כמו מחיקה של טבלה בטעות או עדכונים שגויים של חבילת עדכונים. עם זאת, שיטת השחזור הזו משפיעה על היעד להתאוששות מאסון (RPO) אלא אם נעשה שימוש במסד נתונים זמני עזר.

שיטות גיבוי

אתם יכולים להגדיר גיבויים ברמת Postgres ב-AlloyDB Omni כך שהם יישמרו באחסון מקומי או באחסון מרוחק. אחסון מקומי עשוי להיות מהיר יותר לגיבוי ולשחזור, אבל אחסון מרחוק בדרך כלל חזק יותר לטיפול בכשלים כשמארח שלם או מכונה וירטואלית נכשלים.

גיבויים ב-non-Kubernetes

בפריסות שאינן Kubernetes, אפשר לתזמן גיבויים באמצעות הכלים הבאים של PostgreSQL:

לחלופין, במסדי נתונים קטנים, אפשר לבצע גיבוי לוגי של מסד הנתונים (באמצעות pg_dump למסד נתונים יחיד או pg_dumpall לאשכול כולו). אפשר לשחזר באמצעות pg_restore.

גיבויים ב-Kubernetes באמצעות אופרטור AlloyDB Omni

ב-AlloyDB Omni שנפרס באשכול Kubernetes, אפשר להגדיר גיבויים רציפים באמצעות תוכנית גיבוי לכל אשכול מסדי נתונים. מידע נוסף זמין במאמר בנושא גיבוי ושחזור ב-Kubernetes.

אתם יכולים לאחסן גיבויים של AlloyDB Omni באופן מקומי או מרחוק ב-Cloud Storage, כולל אפשרויות שסופקו על ידי ספקי ענן. מידע נוסף מופיע באיור 1, שבו מוצגים יעדי גיבוי פוטנציאליים.

‫AlloyDB Omni עם אפשרויות גיבוי

איור 1. ‫AlloyDB Omni עם אפשרויות גיבוי.

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

אפשר גם לפצל גיבויים מקומיים לאחסון מקומי או לאחסון משותף. אפשרויות האחסון המקומי מושפעות מהיעדר תוכנית התאוששות מאסון (DR) כשמארח מסד הנתונים נכשל, אבל אחסון משותף מאפשר להעביר את האחסון לשרת אחר ואז להשתמש בו לשחזור. המשמעות היא שאחסון משותף יכול להציע RTO מהיר יותר.

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

  • גיבויים מלאים: גיבויים מלאים של כל קובצי מסד הנתונים שנדרשים לשחזור נתונים.
  • גיבויים דיפרנציאליים: גיבויים של השינויים בקבצים מאז הגיבוי המלא האחרון.
  • גיבויים מצטברים: גיבויים של שינויים בקבצים מאז הגיבוי האחרון מכל סוג.

שחזור מערכת מנקודה מסוימת בזמן (PITR)

גיבויים רציפים של קובצי ה-WAL (רישום מראש של פעולות כתיבה) של PostgreSQL תומכים בשחזור מערכת מנקודה מסוימת בזמן (PITR). אם אחרי אירוע כשל, קובצי ה-WAL שלמים וניתן להשתמש בהם, אפשר להשתמש בקבצים האלה כדי לשחזר את הנתונים בלי לאבד אותם.

כדי לשלוט בכתיבה של קובצי ה-WAL, אפשר להגדיר את הפרמטרים הבאים:

פרמטר תיאור

wal_writer_delay

ההגדרה קובעת באיזו תדירות כלי הכתיבה של WAL מבצע flush של WAL לדיסק, אלא אם הכתיבה מופעלת מוקדם יותר על ידי טרנזקציה שמבצעת commit באופן אסינכרוני. ערך ברירת המחדל הוא 200ms. הגדלת הערך הזה מפחיתה את תדירות הכתיבה, אבל עלולה להגדיל את כמות הנתונים שאובדים אם השרת קורס.

wal_writer_flush_after

ההגדרה קובעת כמה נתוני WAL יכולים להצטבר לפני שכותב ה-WAL יבצע פעולת ניקוי לדיסק. ערך ברירת המחדל הוא 1MB. אם הערך הוא אפס, נתוני ה-WAL תמיד מועברים לכונן באופן מיידי.

synchronous_commit

ההגדרה קובעת אם הפעולה commit מחזירה תגובה למשתמש לפני שנתוני ה-WAL נמחקים מהדיסק. הגדרת ברירת המחדל היא on, שמבטיחה שהעסקה תהיה עמידה. במילים אחרות, הפעולה commit נכתבה בדיסק לפני שהוחזר קוד הצלחה למשתמש. אם הערך מוגדר ל-off, אז יש עד שלוש פעמים wal_writer_delay לפני שהטרנזקציה נכתבת בדיסק.

מעקב אחר השימוש ב-WAL

אפשר להשתמש בשיטות הבאות כדי לבדוק את השימוש ב-WAL:

שיטת התצפית תיאור

pg_stat_wal

בתצוגה הרגילה הזו יש את העמודות wal_write ו-wal_sync, שבהן מאוחסנים הנתונים של מספר הכתיבות ב-WAL ומספר הסנכרונים ב-WAL. כשהפרמטר להגדרה track_wal_io_timing מופעל, גם הפרמטרים wal_write_time ו-wal_sync_time נשמרים. תמונות מצב קבועות של התצוגה הזו יכולות לעזור להציג את פעילות הכתיבה והסנכרון של WAL לאורך זמן.
pg_current_wal_lsn() הפונקציה הזו מחזירה את המיקום הנוכחי של מספר רצף הלוג (lsn) שמקושר לחותמת זמן ונאסף כצילומי מצב לאורך זמן, ויכול לספק את הערך של בייט לשנייה של WAL שנוצר באמצעות הפונקציה pg_wal_lsn_diff(lsn1, lsn2). הפונקציה הזו היא מדד שימושי להבנת קצב העסקאות והביצועים של קובצי ה-WAL.

הזרמת נתוני WAL למיקום מרוחק

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

לוחות זמנים לגיבויים

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

  • יום ראשון: גיבוי מלא
  • יום שני, יום שלישי: גיבוי
  • יום רביעי: גיבוי דיפרנציאלי
  • יום חמישי, יום שישי: גיבוי מצטבר
  • שבת: גיבוי דיפרנציאלי

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

כדי למזער את זמן ההשבתה עם פוטנציאל לזמן שחזור ארוך יותר, אפשר להפעיל מסדי נתונים נוספים במצב שחזור רציף. התהליך כולל הפעלה מחדש של גיבויים ועדכון רציף של הסביבה המשנית על ידי ארכיון והפעלה מחדש של קובצי WAL חדשים. ה-RPO בפועל, שמשקף אובדן נתונים פוטנציאלי, תלוי בתדירות העסקאות, בגודל קובץ ה-WAL ובשימוש בסטרימינג של WAL.

שחזור בסביבה שאינה Kubernetes

בפריסות שאינן Kubernetes, שחזור של מסד נתונים של AlloyDB Omni כולל עצירה של קונטיינר Docker ואז שחזור של הנתונים, או שחזור של הנתונים למיקום אחר והפעלת מופע חדש של Docker באמצעות הנתונים המשוחזרים. אחרי שהקונטיינר מופעל מחדש, אפשר לגשת למסד הנתונים עם הנתונים המשוחזרים.

מידע נוסף על אפשרויות השחזור זמין במאמרים שחזור אשכול AlloyDB Omni באמצעות pgBackRest ושחזור אשכול AlloyDB Omni באמצעות Barman.

שחזור ב-Kubernetes באמצעות Operator

כדי לשחזר מסד נתונים ב-Kubernetes, האופרטור מציע שחזור לאותו אשכול ולמרחב שמות של Kubernetes, מגיבוי עם שם או משיבוט מנקודת זמן (PIT). כדי לשכפל מסד נתונים לאשכול Kubernetes אחר, משתמשים ב-pgBackRest. מידע נוסף זמין במאמרים בנושא גיבוי ושחזור ב-Kubernetes וסקירה כללית על שיבוט של אשכול מסדי נתונים מגיבוי ב-Kubernetes.

הטמעה

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

יתרונות

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

מגבלות

  • דרישות אחסון שעשויות להיות גדולות יותר ממסד הנתונים עצמו, בהתאם לדרישות השמירה.
  • ההתאוששות יכולה להיות איטית, וזמן ההתאוששות (RTO) עשוי להיות ארוך יותר.
  • יכולה לגרום לאובדן נתונים מסוים, בהתאם לזמינות של נתוני ה-WAL הנוכחיים אחרי כשל במסד הנתונים, מה שעשוי להשפיע לרעה על RPO.

חלופות

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

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