עבודה עם שכפול בין אזורים

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

סקירה כללית על שכפול בין אזורים

לפני שמתחילים

• Google Cloud לפרויקט שבו אתם משתמשים צריכה להיות גישה ל-AlloyDB.
• בפרויקט ב- Google Cloud שבו אתם משתמשים, צריך להיות לכם אחד מתפקידי ה-IAM הבאים:
  • ‫roles/alloydb.admin (תפקיד IAM מוגדר מראש של אדמין ב-AlloyDB)
  • ‫roles/owner (תפקיד ה-IAM הבסיסי "בעלים")
  • ‫roles/editor (תפקיד העריכה הבסיסי ב-IAM)

  אם לא הוקצו לכם התפקידים האלה, פנו לאדמין הארגוני כדי לבקש גישה.

יצירת אשכול משני

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

אם מעדכנים את הגדרות האשכול הראשי אחרי שיוצרים את האשכול המשני, השינויים לא זמינים באשכול המשני. עם זאת, אתם יכולים לעדכן ידנית את האשכול המשני כדי שתהיה לו את התצורה העדכנית ביותר שזמינה באשכול הראשי.

אפשר ליצור עד חמישה אשכולות משניים לאשכול ראשי. כל האשכולות המשניים משוכפלים ממכונה ראשית אחת. אם מקדמים אשכול משני, הוא הופך לאשכול ראשי עצמאי.

הערה: כשיוצרים כמה אשכולות משניים, מומלץ להמתין עד שהיצירה של כל אשכול משני תסתיים לפני שיוצרים את האשכולות המשניים הנוספים.

בתרשים הבא אפשר לראות איך לקדם את האשכול המשני שנקרא cluster-2 ב-us-east4:

איור 1. דוגמה לקידום של אשכול משני.

כדי ליצור אשכול משני ומכונה משנית ב-AlloyDB:

הערה: אי אפשר להפעיל תכונות מתקדמות של תובנות לגבי שאילתות באשכולות משניים.

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

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

המסוף

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. לוחצים על אשכול בעמודה Resource Name.

3. בדף Overview, לוחצים על Create secondary cluster.

4. מגדירים את האשכול המשני:

   1. בשדה Cluster ID, מזינים מזהה משאב לאשכול המשני.
   2. בוחרים אזור לאשכול המשני ששונה מהאזור של האשכול הראשי.
   3. בוחרים את שיטת ההצפנה של האשכול המשני: הצפנה בניהול Google כברירת מחדל או מפתח בניהול הלקוח (CMEK).

   כדי להצפין את האשכול באמצעות מפתח CMEK:

   1. לוחצים על אפשרויות הצפנה מתקדמות.
   2. בוחרים באפשרות Customer-managed encryption key (CMEK).

   3. בוחרים מפתח בניהול הלקוח מהתפריט שמופיע.

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

      כדי להשתמש במפתח שלא מופיע ברשימה הזו:

      1. לוחצים על לא רואה את המפתח שלך? מזינים את שם המשאב העיקרי.
      2. מזינים את שם המשאב בשדה Key resource name.
      3. לוחצים על Save.
      4. לוחצים על Continue.

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

   אם המכונה הראשית המשויכת מוצפנת באמצעות מפתח CMEK, צריך להצפין גם את האשכול המשני שלה באמצעות מפתח CMEK.

5. מגדירים את המכונה המשנית. בשדה Instance ID, מזינים מזהה משאב למכונה המשנית. מזהה המשאב חייב להיות ייחודי באשכול.

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

6. לוחצים על Create cluster.

gcloud

כדי להשתמש ב-CLI של gcloud, אתם יכולים להתקין ולהפעיל את Google Cloud CLI או להשתמש ב-Cloud Shell.

משתמשים בפקודה gcloud alloydb clusters create-secondary.

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

 gcloud alloydb clusters create-secondary SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --primary-cluster=projects/PROJECT_ID/locations/LOCATION_ID/clusters/PRIMARY_CLUSTER_ID
 gcloud alloydb instances create-secondary SECONDARY_INSTANCE_ID \
 --cluster=SECONDARY_CLUSTER_ID \
 --region=REGION_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫SECONDARY_CLUSTER_ID: המזהה של האשכול המשני שרוצים ליצור ולשייך אליו את המכונה המשנית.
• ‫SECONDARY_INSTANCE_ID: המזהה של המכונה המשנית שרוצים ליצור.
• ‫REGION_ID: המזהה של האזור של האשכול המשני, לדוגמה us-central1.
• ‫PROJECT_ID: מזהה הפרויקט של האשכול הראשי.
• ‫LOCATION_ID: המיקום של האשכול הראשי, לדוגמה us-central1.
• ‫PRIMARY_CLUSTER_ID: המזהה של האשכול הראשי שאליו משויך האשכול המשני.

כדי להשבית את היצירה של גיבויים אוטומטיים באשכול המשני, מעבירים את הדגל --no-enable-automated-backup לפקודה gcloud alloydb clusters create-secondary.

כדי ליצור מכונה משנית עם Private Service Connect, מוסיפים את הדגל --allowed-psc-projects כדי להגדיר רשימה מופרדת בפסיקים של מזהי פרויקטים או מספרי פרויקטים שרוצים לאפשר להם גישה למכונה – לדוגמה, my-project-1,‏ 12345 ו-my-project-n.

 gcloud alloydb clusters create-secondary SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --primary-cluster=projects/PROJECT_ID/locations/LOCATION_ID/clusters/PRIMARY_CLUSTER_ID
 gcloud alloydb instances create-secondary SECONDARY_INSTANCE_ID \
 --cluster=SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --allowed-psc-projects=ALLOWED_PSC_PROJECTS

מחליפים את מה שכתוב בשדות הבאים:

• ‫ALLOWED_PSC_PROJECTS (אופציונלי): רשימה מופרדת בפסיקים של מזהי פרויקטים או מספרי פרויקטים שרוצים לאפשר להם גישה למכונה. לדוגמה: my-project-1,‏ 12345 ו-my-project-n. אם האשכול משתמש ב-Private Service Connect כשיטה להתחברות למכונה, צריך להגדיר רשימה של פרויקטים או מספרים מותרים.

כדי ליצור מכונה משנית לאשכול עם כתובת IP ציבורית, מוסיפים את הפרמטר --assign-inbound-public-ip=ASSIGN_IPV4.

 gcloud alloydb instances create-secondary SECONDARY_INSTANCE_ID \
 --cluster=SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
  --assign-inbound-public-ip=ASSIGN_IPV4

אפשר להעביר את הרשימה המופרדת בפסיקים של בלוקי CIDR, כמו 64.233.160.0/16, לפרמטר --authorized-external-networks כדי להגדיר רשתות חיצוניות מורשות במכונה.

הצגת אשכול משני

כדי לראות מידע מפורט על אשכול משני ב-AlloyDB:

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. לוחצים על אשכול משני בעמודה Resource Name.

3. בדף Overview, בודקים את כל הפרטים של האשכול המשני.

עדכון של מכונה משנית

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

הגדרת דגלים לניהול מסד נתונים במכונה משנית

כדי להוסיף, לשנות או למחוק דגלים לניהול מסדי נתונים:

המסוף

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. בעמודה Resource Name, לוחצים על האשכול המשני שרוצים לשנות.

3. בדף Overview, עוברים לקטע Instances in your cluster, בוחרים את המכונה המשנית ולוחצים על Edit secondary.

4. הוספה, שינוי או מחיקה של דגל לניהול מסד נתונים מהמכונה:

   הוספת דגל

   1. כדי להוסיף דגל לניהול מסד נתונים למכונה, לוחצים על Add flag.
   2. בוחרים דגל לניהול מסד נתונים מהרשימה New database flag.
   3. צריך לספק ערך לדגל.
   4. לוחצים על סיום.

   שינוי דגל

   1. כדי לשנות דגל לניהול מסד נתונים שקיים במכונה, מרחיבים את הדגל ומשנים את הערך שלו בקטע Edit database flag.
   2. לוחצים על סיום.

   מחיקת סימון

   1. כדי למחוק דגל לניהול מסד נתונים מהמכונה, בוחרים דגל ולוחצים על סמל המחיקה.
   2. לוחצים על סיום.

5. לוחצים על עדכון הדומיין המשני.

gcloud

משתמשים בפקודה gcloud alloydb instances update כדי לשנות את הדגלים לניהול מסד הנתונים של מכונה משנית.

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

 gcloud alloydb instances update SECONDARY_INSTANCE_ID \
  --database-flags FLAGS_LIST \
  --region=REGION_ID \
  --cluster=CLUSTER_ID \
  --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫SECONDARY_INSTANCE_ID: המזהה של המכונה המשנית.
• ‫FLAGS_LIST: רשימה מופרדת בפסיקים של מפרט אחד או יותר של דגלים לניהול מסד נתונים. כל מפרט מורכב משם הדגל, סימן שוויון (=) והערך שרוצים להקצות לדגלים. בדגלים לניהול מסדי נתונים שלא מקבלים ערכים, צריך לציין את שם הדגל ואחריו סימן שוויון (=).
• ‫REGION_ID: האזור שבו נמצא המכונה המשנית, לדוגמה us-central1.
• ‫CLUSTER_ID: המזהה של האשכול שבו נמצא המכונה המשנית.
• ‫PROJECT_ID: מזהה הפרויקט שבו נמצא האשכול המשני.

שינוי קנה המידה של סוג המכונה של המכונה המשנית

כדי לשנות את סוג המכונה של המכונה המשנית:

המסוף

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. בעמודה Resource Name, לוחצים על האשכול המשני שרוצים לשנות.

3. בדף Overview, עוברים לקטע Instances in your cluster ולוחצים על Edit secondary.

   שימו לב שהפעולה הזו לא זמינה אם בדף מדווח על סטטוס תחזוקה של האשכול. הפעולה תהיה זמינה שוב אחרי שהערך של Status ישתנה ל-Ready.

4. בוחרים סוג מכונה.

5. לוחצים על עדכון הדומיין המשני.

gcloud

משתמשים בפקודה gcloud alloydb instances update כדי לשנות את סוג המכונה של המכונה המשנית.

 gcloud alloydb instances update SECONDARY_INSTANCE_ID \
  --cpu-count=CPU_COUNT \
  --region=REGION_ID \
  --cluster=CLUSTER_ID \
  --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫SECONDARY_INSTANCE_ID: המזהה של המכונה המשנית שמעדכנים.

• ‫CPU_COUNT: מספר המעבדים הווירטואליים שרוצים להקצות למכונה. הערכים התקינים כוללים:

  • ‫2 (2 vCPUs, 16 GB RAM)
  • 4 (4 vCPUs, 32 GB RAM)
  • ‫8 (8 מעבדי vCPU, זיכרון RAM בנפח 64GB)
  • ‫16 (16 vCPUs, 128 GB RAM)
  • 32 (32 vCPUs, 256 GB RAM)
  • ‫64 (64 מעבדי vCPU, זיכרון RAM בנפח 512GB)
  • ‫96 (96 vCPUs, 768 GB RAM)
  • ‫128 (128 מעבדי vCPU, ‏864GB RAM)

• ‫REGION_ID: האזור שבו נמצאת המכונה.

• ‫CLUSTER_ID: המזהה של האשכול שבו נמצא המכונה.

• ‫PROJECT_ID: מזהה הפרויקט שבו נמצא האשכול.

אם הפקודה מחזירה הודעת שגיאה שכוללת את הביטוי invalid cluster state MAINTENANCE, סימן שהאשכול עובר תחזוקה שוטפת. הפעולה הזו משביתה באופן זמני את האפשרות להגדיר מחדש את המכונה. מריצים שוב את הפקודה אחרי שהאשכול חוזר למצב READY.

כדי לבדוק את סטטוס האשכול, קראו את המאמר הצגת פרטי האשכול.

הוספת מופעים של מאגר קריאה לאשכול משני

כדי להוסיף מאגר לקריאה בלבד לאשכול משני:

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. בעמודה Resource Name, לוחצים על אשכול משני שרוצים להוסיף לו מכונה של מאגר לקריאה בלבד.

3. בדף Overview, עוברים לקטע Instances in your cluster ולוחצים על Add read pool.

4. מגדירים את המכונה של מאגר הקריאה:

   1. בשדה Read pool instance ID, מזינים מזהה למכונה של מאגר הקריאה.
   2. בשדה Node count, מזינים את מספר הצמתים. מספר הצמתים במכונה של מאגר קריאה קובע את קיבולת המחשוב הכוללת של המכונה. בכל מאגרי הקריאה באשכול יכולים להיות עד 20 צמתים.
   3. בוחרים סוג מכונה.

   4. אופציונלי: מגדירים דגלים בהתאמה אישית למכונה. לכל דגל, מבצעים את הפעולות הבאות:

      1. לוחצים על הוספת סימון.
      2. בוחרים דגל לניהול מסד נתונים מהרשימה New database flag.
      3. צריך לספק ערך לדגל.
      4. לוחצים על סיום.

5. לוחצים על Add read pool.

תוכנית התאוששות מאסון (DR) מתקדמת

בתרחישים מתקדמים של תוכנית התאוששות מאסון (DR),‏ AlloyDB תומך במעבר וביתירות כשל בין אזורים:

ביצוע מעבר

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

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

אם מבצעים מעבר כשיש כמה אשכולות משניים, מתרחשים השינויים הבאים:

• האשכול המשני שמקבל את פקודת המעבר הופך לאשכול ראשי.
• האשכול הראשי הקודם הופך לאשכול משני, שמשכפל מהאשכול הראשי החדש.
• כל שאר האשכולות המשניים עוברים לשכפול מהאשכול הראשי החדש.

בתרשים הבא מוצג מעבר מ-cluster-1 ב-us-central1 ל-cluster-2 ב-us-east4:

איור 2. דוגמה לביצוע מעבר לאחד משני אשכולות משניים.

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

הערה: אימות סטטוס הרפליקציה לפני המעבר הוא שלב אופציונלי שעוזר להשלים את הפעולה במהירות. מידע נוסף מופיע במאמר אימות סטטוס הרפליקציה.

כדי לבצע מעבר, פועלים לפי השלבים הבאים:

המסוף

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. בעמודה Resource Name, לוחצים על האשכול המשני שרוצים להעביר לאשכול הראשי.

3. בדף Overview, לוחצים על Switchover.

4. בתיבת הדו-שיח שמופיעה, מזינים את המזהה של האשכול המשני כדי לאשר שרוצים להעביר את האשכול.

5. לוחצים על Switchover.

אחרי שהאשכול מועבר, Type: Secondary cluster בדף Overview מתעדכן ל-
Cluster Type: Primary Cluster ול-Cluster Type: Secondary Cluster.

gcloud

משתמשים בפקודה gcloud alloydb clusters switchover:

 gcloud alloydb clusters switchover SECONDARY_CLUSTER_ID \
   --region=REGION_ID \
   --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫SECONDARY_CLUSTER_ID: המזהה של האשכול המשני שרוצים להעביר אליו את הניהול.
• ‫REGION_ID: המזהה של האזור של האשכול המשני, לדוגמה us-central1.
• ‫PROJECT_ID: מזהה הפרויקט של האשכול המשני.

הערה: כדי להמשיך להשתמש בתובנות מתקדמות לגבי שאילתות אחרי ביצוע מעבר, צריך להפעיל מחדש את התובנות המתקדמות לגבי שאילתות באשכול הראשי החדש.

אופציונלי: אימות סטטוס הרפליקציה

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

1. מפסיקים את כל פעולות הכתיבה באשכול הראשי.

2. כדי לבדוק את סטטוס הרפליקציה של האשכול המשני, מבצעים את השלבים הבאים:

   1. נכנסים לדף Clusters במסוף Google Cloud .

      כניסה לדף Clusters

   2. ברשימת האשכולות, לוחצים על השם של האשכול המשני שרוצים להעביר אליו את הנתונים.

   3. בדף הפרטים של האשכול, לוחצים על Monitoring.

   4. ברשימה Monitoring, בוחרים את המכונה המשנית. הוא מופיע ברשימה בתור משני: INSTANCE_NAME.

   5. ברשימת המדדים, מאתרים את התרשים Replication lag from primary instance.

   6. מוודאים שהתרשים מציג השהיה מינימלית.

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

   7. ברשימת המדדים, מאתרים את התרשים Replication status.

   8. מוודאים שלכל הצמתים שמוצגים בתרשים יש ערך של streaming.

קידום אשכול משני

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

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

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

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

המסוף

1. נכנסים לדף Clusters במסוף Google Cloud .

   כניסה לדף Clusters

2. בעמודה Resource Name, לוחצים על אשכול משני שרוצים לקדם לאשכול ראשי.

3. בדף Overview, לוחצים על Promote cluster.

4. בתיבת הדו-שיח שמופיעה, מזינים את המזהה של האשכול המשני כדי לאשר שרוצים לקדם את האשכול.

5. לוחצים על קידום.

   אחרי שהאשכול קודם, השדה Type: Secondary cluster (highly available) בדף Overview מתעדכן ל-Type: Highly available with read pools.

gcloud

כדי לקדם אשכול משני לאשכול ראשי עצמאי, משתמשים בפקודה gcloud alloydb clusters promote:

 gcloud alloydb clusters promote SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --project=PROJECT_ID

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

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

 gcloud beta alloydb clusters promote SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --project=PROJECT_ID \
 --failover

מחליפים את מה שכתוב בשדות הבאים:

• ‫SECONDARY_CLUSTER_ID: המזהה של האשכול המשני שרוצים לקדם.
• ‫REGION_ID: המזהה של אזור האשכול המשני,לדוגמה us-central1.
• ‫PROJECT_ID: מזהה הפרויקט של האשכול המשני.

שימוש בנקודות קצה לכתיבה כדי למנוע מצב של פיצול מוח (split-brain)

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

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

כשמבצעים מעבר בין אזורים במקרה של יתירות כשל, AlloyDB מעדכן באופן אוטומטי את רשומת ה-DNS של נקודת הקצה לכתיבה כך שתצביע על אשכול ה-primary החדש. כך אפשר לוודא שתנועת הכתיבה החדשה מופנית מהמכונה הראשית המקורית למכונה הראשית החדשה.

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

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

שחזור נתונים במהלך מעבר לגיבוי בעת כשל בין אזורים שונים

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

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

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

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

• הצגת פרטי האשכול.
• לצפייה ברשימת האשכולות