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