כדי להבטיח את המשכיות העסקית ולמזער את אובדן הנתונים, זמינות גבוהה (HA) ותוכנית התאוששות מאסון (DR) הן אסטרטגיות חיוניות להגנה על נתונים ב-AlloyDB Omni. זמינות גבוהה מתמקדת בשמירה על זמינות מסד הנתונים ובמזעור של יעד זמן ההתאוששות (RTO), בעוד שתוכנית התאוששות מאסון מתמקדת בהתאוששות מאירועים קטסטרופליים ובמזעור של יעד נקודת ההתאוששות (RPO).
ה-RTO וה-RPO מותאמים לדרישות העסקיות ומוגדרים באופן הבא:
- RTO הוא הזמן המקסימלי שבו מסד נתונים יכול להיות מושבת או לא זמין לפני שהעסק חווה השלכות בלתי קבילות, כמו אובדן הכנסות או ירידה בפריון.
- RPO הוא כמות הנתונים המקסימלית שאפשר לאבד לפני שזה ישפיע על הדרישות העסקיות. לדוגמה, יכול להיות שבמערכות מלאי שנדרש בהן נתיב ביקורת מלא, לא תהיה אפשרות לאבד נתונים.
AlloyDB Omni מציע את ארכיטקטורות ההפניה הבאות לזמינות, שמספקות רמות הולכות וגדלות של זמינות:
- זמינות רגילה: הגנה על הנתונים באמצעות גיבויים.
- זמינות משופרת: הגנה על הנתונים באמצעות שכפול אזורי באזור (HA).
- זמינות בגרסת Premium: הגנה על הנתונים באמצעות שכפול אזורי ואזורי משנה (זמינות גבוהה והתאוששות מאסון).
מנגנוני זמינות
אלה המנגנונים העיקריים שמבטיחים זמינות:
- גיבויים של מסדי נתונים
- שכפול מסד נתונים
גיבויים של מסדי נתונים
גיבויים של מסדי נתונים הם היבט בסיסי של הגנה על נתונים. הם כוללים יצירה של עותקים פיזיים של קובצי נתונים של מסד הנתונים. יש סוגים שונים של גיבויים – מלא, מצטבר ודיפרנציאלי – שמציעים איזון שונה בין יעד נקודת השחזור (RPO), גודל הגיבוי ומשך הגיבוי, וזמן השחזור.
כדי להבטיח שחזור יעיל ולמזער את אובדן הנתונים במקרה של כשלים במערכת, אסטרטגיית גיבוי חזקה חייבת לכלול גיבויים של מסד הנתונים ושל קובץ יומן הרישום (WAL). גיבויים קבועים (בדרך כלל יומיים) של קובצי נתונים הם חיוניים. אתם צריכים גם לגבות קובצי WAL, שמתעדים שינויים במסד הנתונים והם קריטיים לשחזור מערכת מנקודה מסוימת בזמן (PITR) ולשמירה על תקינות נתונים במהלך השחזור.
שכפול מסד נתונים
PostgreSQL מציע שרתי העתקה (replica) כדי לשפר את המהימנות. העותקים המשוכפלים האלה מסווגים כגיבויים פעילים שלא מקבלים חיבורים לאפליקציות, או כגיבויים חמים שפועלים במצב קריאה בלבד. השינויים ממסד הנתונים הראשי מוחלים באופן רציף על העותק כדי שהנתונים בעותק יהיו עדכניים. אם מסד הנתונים הראשי נכשל, העותק המשוכפל מקודם לסטטוס ראשי ומקבל את האחריות של מסד הנתונים הראשי.
אפשר למקם רפליקות של מסדי נתונים באותו אזור או מרכז נתונים כמו המופע הראשי, באזור אחר, באזור אחר או בשילוב של המיקומים האלה. ככל שהרפליקה ממוקמת רחוק יותר ממסד הנתונים הראשי, כך זמן האחזור גדול יותר כששולחים שינויים כדי לעדכן את הרפליקות. כדי לצמצם את הסיכון לכשלים בקנה מידה גדול, כמו תקלות אזוריות, בפריסות במיקומים מרוחקים, בדרך כלל מתבצעת רפליקציה של נתונים באופן אסינכרוני. הגישה הזו מונעת ירידה בביצועים שיכולה להתרחש בהגדרות כאלה.
בפריסות של זמינות גבוהה, רפליקות נפרסות בדרך כלל בקרבה למסד הנתונים הראשי. לדוגמה, רפליקות שנפרסות בתחום (zone) אחר באותו מרכז נתונים מציעות 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 מציע ארכיטקטורות זמינות רגילות, משופרות ופרימיום כדי להגן על מסדי נתונים מפני הפסקות מתוכננות ולא מתוכננות, בהתאם לצרכים העסקיים השונים. לדוגמה, בסביבות פיתוח אפשר להשתמש בהגנה בסיסית עם גיבויים, ואילו באפליקציות קריטיות אפשר להשתמש בהגדרות של זמינות גבוהה ותוכנית התאוששות מאסון (DR).
המאמרים הבאים
מידע נוסף על ארכיטקטורות הפניה של AlloyDB Omni:
- הגנה על הנתונים באמצעות גיבויים (זמינות רגילה).
- הגנה על הנתונים באמצעות שכפול אזורי באזור (זמינות משופרת).
- הגנה על הנתונים באמצעות שכפול אזורי ואזורי (זמינות פרימיום).