עבודה עם רפליקציה בין מרכזי נתונים

בחירה של גרסת המסמך: 16.3.0

• 16.3.0
• 15.7.1
• 15.7.0
• 15.5.5

בדף הזה מוסבר איך להשתמש ברפליקציה בין מרכזי נתונים על ידי יצירה ועבודה עם אשכולות משניים של מסדי נתונים ב-Kubernetes. סקירה כללית של שכפול בין מרכזי נתונים מופיעה במאמר [About cross-data-center replication](/alloydb/omni/containers/16.3.0/docs/cross-data-center-replication/about-cross-data-center-replication). ## לפני שמתחילים {: #before-you-begin } - חשוב לוודא שיש לכם קישוריות רשת אמינה עם זמן אחזור נמוך בין מרכזי הנתונים הראשיים והמשניים. זה חיוני כדי שהשכפול בין מרכזי הנתונים יפעל בצורה יעילה. ‫– [Install](/alloydb/omni/containers/16.3.0/docs/deploy-kubernetes) the latest version of AlloyDB Omni operator to deploy AlloyDB Omni on a Kubernetes cluster in the primary data center and a Kubernetes cluster in the secondary data center. שכפול בין מרכזי נתונים נתמך בגרסה 1.5.0 ואילך של AlloyDB Omni operator. ‫– [יצירת אשכול מסד נתונים של AlloyDB Omni](/alloydb/omni/containers/16.3.0/docs/deploy-kubernetes#create) באשכול Kubernetes במרכז הנתונים הראשי. – מוודאים שלשרתי מסד הנתונים הראשיים ושרתי הגיבוי באשכול מסד הנתונים הראשי יש מספיק מקום לרישום מראש (WAL) שיכול להכיל את קובצי ה-WAL שנדרשים לשכפול לאשכול המשני. כל הנתונים שעדיין לא שוכפלו לאשכול המשני מאוחסנים באשכול הראשי כקבצי WAL, ולכן יכול להיות שתצטרכו נפח אחסון נוסף למטרה הזו, בהתאם למהירות החיבור בין האשכול הראשי למשני. ## יצירת אשכול משני של מסד נתונים {: #secondary-db-cluster-instance } כדי ליצור אשכול משני של מסד נתונים ב-AlloyDB Omni ולהפעיל שכפול מאשכול מסד הנתונים הראשי, פועלים לפי השלבים הבאים:

1. מוודאים שהקישוריות החיצונית מופעלת באשכול מסד הנתונים הראשי של AlloyDB Omni. אם הקישוריות החיצונית לא מופעלת, מוסיפים את הקוד הבא לקטע spec במניפסט של אשכול מסד הנתונים:

   ...
   spec:
     ...
     allowExternalIncomingTraffic: true
    

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

   ...
   spec:
     ...
     availability:
       ...
       replayReplicationSlotsOnStandbys: true
    

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

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

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

   apiVersion: v1
   kind: Secret
   metadata:
     name: ha-rep-pw-DB_CLUSTER_NAME
     namespace: DB_CLUSTER_NAMESPACE
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
     name: REPLICATION_NAME
     namespace: DB_CLUSTER_NAMESPACE
   spec:
     dbcluster:
       name: DB_CLUSTER_NAME
     upstream:
       password:
         name: ha-rep-pw-DB_CLUSTER_NAME
       logReplicationSlot: true

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

   • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים, למשל dbc-1.
   • ‫ENCODED_PASSWORD: הסיסמה של משתמש מסד הנתונים שתשמש לשכפול ממסדי נתונים משניים, מקודדת כמחרוזת base64 – לדוגמה, Q2hhbmdlTWUxMjM= for ChangeMe123. ערך ברירת המחדל הוא alloydbreplica.
   • ‫REPLICATION_NAME: השם של השכפול, לדוגמה replication-1.
   • ‫LOG_REPLICATION_SLOT: רישום נתונים של משבצת שכפול ביומנים בקובצי WAL. כדי להפעיל את האפשרות הזו, צריך להגדיר את הערך שלה ל-true. ערך ברירת המחדל הוא false.

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

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

   מחכים שהסטטוס של השכפול יהיה מוכן.

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

4. כדי לקבל את פרטי החיבור של ה-upstream שמשמשים להגדרת השכפול באשכול מסד הנתונים המשני, מריצים את הפקודה הבאה:

   kubectl get replication REPLICATION_NAME
   kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

   פלט לדוגמה:

     {
       "host": "35.230.32.36",
       "password": {
         "name": "ha-rep-pw-dbc-1"
       },
       "port": 5432,
       "replicationSlotName": "dbc_1_replication_1",
       "username": "alloydbreplica"
     }
     

5. חשוב לשים לב לפלט, כי תצטרכו אותו כדי להפעיל שכפול באשכול מסדי הנתונים המשני בשלב הבא.
6. יוצרים אשכול AlloyDB Omni באשכול Kubernetes במרכז הנתונים המשני עם הגדרה זהה לזו של אשכול מסד הנתונים הראשי.
7. מוודאים שהקישוריות החיצונית מופעלת באשכול מסד הנתונים המשני של AlloyDB Omni

8. אם הקישוריות החיצונית לא מופעלת, מוסיפים את השורה הבאה לקטע spec במניפסט:

   ...
   spec:
     ...
     allowExternalIncomingTraffic: true

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

   apiVersion: v1
   kind: Secret
   metadata:
     name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
     namespace: SECONDARY_DB_CLUSTER_NAMESPACE
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
     name: SECONDARY_REPLICATION_NAME
     namespace: SECONDARY_DB_CLUSTER_NAMESPACE
   spec:
     dbcluster:
       name: SECONDARY_DB_CLUSTER_NAME
     downstream:
       host: PRIMARY_HOST
       port: PRIMARY_PORT
       username: alloydbreplica
       password:
         name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
       replicationSlotName: PRIMARY_REPLICATION_SLOT
       control: setup

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

   • ‫SECONDARY_DB_CLUSTER_NAME: השם של אשכול מסד הנתונים המשני, לדוגמה dbc-2.
   • ‫ENCODED_PASSWORD: הסיסמה של משתמש מסד הנתונים שתשמש לשכפול של אשכול מסד הנתונים הראשי, מקודדת כמחרוזת base64 – לדוגמה, Q2hhbmdlTWUxMjM= for ChangeMe123. ערך ברירת המחדל הוא alloydbreplica.
   • ‫SECONDARY_REPLICATION_NAME: השם של השכפול, לדוגמה, `replication-2`.
   • ‫PRIMARY_HOST: נקודת הקצה של החיבור של אשכול מסד הנתונים הראשי מהפלט בשלב 3, שאליו מסד הנתונים המשני יכול לגשת לצורך שכפול.
   • ‫PRIMARY_PORT: יציאת החיבור של אשכול מסד הנתונים הראשי מהפלט בשלב 3, שמסד הנתונים המשני יכול לגשת אליה לצורך שכפול.
   • ‫PRIMARY_REPLICATION_SLOT: השם של משבצת השכפול באשכול מסד הנתונים הראשי מהפלט בשלב 3, שמשמש את מסד הנתונים המשני לשכפול.

הצגת השכפול באשכול מסדי הנתונים המשני

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

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

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

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

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

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

  kubectl get replication SECONDARY_REPLICATION_NAME

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

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

  psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

כדי לקדם אשכול משני של מסדי נתונים לאשכול ראשי של מסדי נתונים, מעדכנים את השדה control במניפסט השכפול של האשכול המשני של מסדי הנתונים לערך promote, ומחילים את השינוי הזה באשכול Kubernetes במרכז הנתונים המשני.

apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  downstream:
    host: PRIMARY_HOST
    port: PRIMARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    replicationSlotName: PRIMARY_REPLICATION_SLOT
    control: promote

ביצוע מעבר לגיבוי (failover)

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

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

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

  kubectl get replication SECONDARY_REPLICATION_NAME

• מפסיקים את כל פעולות הכתיבה לאשכול מסד הנתונים הראשי. מריצים את השאילתה הבאה באשכול מסד הנתונים הראשי כדי לבדוק את השהיית השכפול של מסד הנתונים המשני. מוודאים שערך ההשהיה שמוצג בתוצאה הוא 0.

  psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

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

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

   apiVersion: v1
   kind: Secret
   metadata:
     name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
     namespace: SECONDARY_DB_CLUSTER_NAMESPACE
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
     name: SECONDARY_REPLICATION_NAME
     namespace: SECONDARY_DB_CLUSTER_NAMESPACE
   spec:
     dbcluster:
       name: SECONDARY_DB_CLUSTER_NAME
     upstream:
       password:
         name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

   מחכים שהסטטוס של השכפול יהיה מוכן.

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

   kubectl get replication SECONDARY_REPLICATION_NAME
   kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

   פלט לדוגמה:

     {
       "host": "34.23.207.137",
       "password": {
         "name": "ha-rep-pw-dbc-2"
       },
       "port": 5432,
       "replicationSlotName": "dbc_2_replication_2",
       "username": "alloydbreplica"
     }
   

3. כדי להמיר את אשכול מסד הנתונים הראשי שלכם ב-AlloyDB Omni לאשכול מסד נתונים משני, מעדכנים את מניפסט השכפול שלו באשכול Kubernetes במרכז הנתונים הראשי באופן דומה לזה:

   apiVersion: v1
   kind: Secret
   metadata:
     name: ha-rep-pw-DB_CLUSTER_NAME
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
     name: REPLICATION_NAME
   spec:
     dbcluster:
       name: DB_CLUSTER_NAME
     downstream:
       host: SECONDARY_HOST
       port: SECONDARY_PORT
       username: alloydbreplica
       password:
         name: ha-rep-pw-DB_CLUSTER_NAME
       replicationSlotName: SECONDARY_REPLICATION_SLOT
       control: rewind

   ממתינים עד שהסטטוס של השכפול יהיה מוכן ותקין.

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

   kubectl get replication REPLICATION_NAME