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