כדי להבטיח את המשכיות העסקית ולמזער את אובדן הנתונים, זמינות גבוהה (HA) והתאוששות מאסון (DR) הן אסטרטגיות חיוניות להגנה על נתונים ב-AlloyDB Omni. הזמינות הגבוהה מתמקדת בשמירה על זמינות מסד הנתונים ובמזעור היעד להתאוששות מאסון (RTO), בעוד שהתאוששות מאסון (DR) מתמקדת בהתאוששות מאירועים קטסטרופליים ובמזעור היעד להתאוששות מאסון (RPO).
ה-RTO וה-RPO מותאמים לדרישות העסקיות ומוגדרים באופן הבא:
- RTO הוא משך הזמן המקסימלי שבו מסד הנתונים יכול להיות מושבת או לא זמין לפני שהעסק יחווה השלכות בלתי קבילות, כמו אובדן הכנסות או פרודוקטיביות.
- RPO הוא הכמות המקסימלית של נתונים שאובדים לעסק לפני שהדבר משפיע על הדרישות העסקיות. לדוגמה, במערכות מלאי שדורשות נתיב ביקורת מלא, יכול להיות שתהיה דרישה לאובדן נתונים אפסי.
AlloyDB Omni מציע את הארכיטקטורות הבאות של זמינות, שמספקות רמות הולכות וגדלות של זמינות:
- זמינות רגילה: הגנה על הנתונים באמצעות גיבויים.
- זמינות משופרת: הגנה על הנתונים באמצעות שכפול אזורי באזור (HA).
- זמינות בגרסת Premium: הגנה על הנתונים באמצעות שכפול אזורי ואזורי משנה (זמינות גבוהה והתאוששות מאסון).
מנגנוני זמינות
אלה המנגנונים העיקריים שמבטיחים זמינות:
- גיבויים של מסדי נתונים
- שכפול מסד נתונים
גיבויים של מסדי נתונים
גיבויים של מסדי נתונים הם היבט בסיסי של הגנה על נתונים, והם כוללים יצירת עותקים פיזיים של קובצי נתונים של מסדי נתונים. סוגי גיבוי שונים – מלא, מצטבר ודיפרנציאלי – מציעים איזונים שונים בין יעד נקודת השחזור (RPO), גודל הגיבוי ומשך הזמן שלו, וזמן השחזור.
כדי להבטיח התאוששות יעילה ולמזער את אובדן הנתונים במקרה של כשלים במערכת, אסטרטגיית גיבוי חזקה חייבת לכלול גיבויים של מסד הנתונים ושל קובץ יומן הרישום (WAL). חשוב מאוד לגבות את קובצי הנתונים באופן קבוע (בדרך כלל מדי יום). צריך גם לגבות קובצי WAL, שמתעדים שינויים במסד הנתונים והם קריטיים לשחזור מערכת מנקודה מסוימת בזמן (PITR) ולשמירה על תקינות הנתונים במהלך השחזור.
שכפול מסד נתונים
PostgreSQL מציע שרתי העתקה (replica) כדי לשפר את המהימנות. העותקים האלה מסווגים כגיבויים פעילים, שלא מקבלים חיבורים לאפליקציות, או כגיבויים חמים, שפועלים במצב קריאה בלבד. השינויים ממסד הנתונים הראשי מוחלים באופן רציף על הרפליקה כדי שהנתונים ברפליקה יהיו עדכניים. אם מסד הנתונים הראשי נכשל, הרפליקה מקודמת לסטטוס ראשי ומקבלת את תחומי האחריות של מסד הנתונים הראשי.
אפשר למקם עותקים של מסד נתונים באותו אזור או מרכז נתונים כמו המופע הראשי, באזור אחר, באזור אחר או בשילוב של המיקומים האלה. ככל שהרפליקה ממוקמת רחוק יותר ממסד הנתונים הראשי, כך זמן האחזור גדול יותר כששולחים שינויים כדי לעדכן את הרפליקות. בפריסות במיקומים מרוחקים, כדי לצמצם כשלים בקנה מידה גדול כמו תקלה אזורית, בדרך כלל רפליקציית הנתונים מתבצעת באופן אסינכרוני. הגישה הזו מונעת את הירידה בביצועים שיכולה להתרחש בהגדרות כאלה.
בפריסות עם זמינות גבוהה, בדרך כלל הרפליקות נפרסות בקרבה למסד הנתונים הראשי. לדוגמה, עותקים משוכפלים שנפרסים באזור אחר באותו מרכז נתונים מציעים RTO נמוך ו-RPO קרוב לאפס. לעומת זאת, בהגדרות של תוכנית התאוששות מאסון (DR), רפליקות נפרסות במרכזי נתונים או באזורים נפרדים, בהתאם לרמת ההגנה הנדרשת מפני הפסקות חשמל. הגישה הזו מובילה ל-RPO גבוה יותר (כי השכפול עשוי להיות אסינכרוני) ול-RTO משתנה.
בטבלה הבאה מפורטים המנגנונים שמשמשים לארכיטקטורות הייחוס של הזמינות ב-AlloyDB Omni:
| התכונה | רגילה | Enhanced | Premium |
|---|---|---|---|
| גיבוי | ✔ | ✔ | ✔ |
| Zonal Replica | ❌ | ✔ | ✔ |
| רפליקה בין אזורים | ❌ | ✔ | ✔ |
| עותק אזורי | ❌ | ❌ | ✔ |
טבלה 1. מנגנוני הזמינות הנתמכים ב-AlloyDB Omni
תרחישים של כשלים במסד הנתונים ושחזור
כשל במסד הנתונים יכול להתרחש ברמות הבאות:
- כשל במכונה (צומת או שרת): כשל במסד הנתונים עצמו.
- כשל בשרת: השרת שמארח את מסד הנתונים נכשל.
- כשל אזורי: כל מרכז הנתונים שבו נמצא השרת נכשל.
- כשל באזור: כל האזור שמכיל כמה מרכזי נתונים (אזורי זמינות) לא זמין, למשל בגלל שיטפון או רעידת אדמה חזקה.
הסבירות והסיכון לאסון פוחתים כשיש פחות אירועים, והעלות של מניעת האירועים האלה עולה. עסקים צריכים לקבוע את רמת הסיכון שהם מוכנים לקחת, ולהחליט אם הם מוכנים לקבל שיבושים פוטנציאליים או להשקיע בארכיטקטורות עמידות יותר כדי למזער את הסיכונים.
בטבלה הבאה מפורטים תרחישי השחזור שנתמכים בארכיטקטורות לדוגמה של AlloyDB Omni:
| סוג האסון | רגילה | Enhanced | Premium |
|---|---|---|---|
| כשל במכונה וירטואלית או במופע | ✔ | ✔ | ✔ |
| כשל בצומת או בשרת | ✔ | ✔ | ✔ |
| כשל באזור | ❌ | ✔ | ✔ |
| כשל אזורי | ❌ | ❌ | ✔ |
טבלה 2. תרחישי שחזור נתמכים
חשבו על היעדים העסקיים של מסד הנתונים ב-AlloyDB Omni, כמו הצורך הקריטי בזמינות של 99.99% ובאפס אובדן נתונים בזמן שחזור של אפליקציות חיוניות. המטרה של ארכיטקטורות ההפניה לזמינות היא לתת מענה לדרישות של RTO ו-RPO.
ב-AlloyDB Omni יש ארכיטקטורות זמינות רגילות, משופרות ומתקדמות כדי להגן על מסדי נתונים מפני הפסקות מתוכננות ולא מתוכננות, בהתאם לצרכים העסקיים השונים. לדוגמה, בסביבות פיתוח אפשר להשתמש בהגנה בסיסית עם גיבויים, ובאפליקציות קריטיות אפשר להשתמש בהגדרות של זמינות גבוהה ותוכנית התאוששות מאסון (DR).
המאמרים הבאים
מידע נוסף על ארכיטקטורות הפניה של AlloyDB Omni:
- הגנה על הנתונים באמצעות גיבויים (זמינות רגילה).
- הגנה על הנתונים באמצעות שכפול אזורי באזור (זמינות משופרת).
- הגנה על הנתונים באמצעות שכפול אזורי (זמינות פרימיום).