בדף הזה מתועדת גרסה 18.4.0 של AlloyDB Omni באמצעות אפשרות הפריסה של קונטיינרים. בוחרים אפשרות פריסה אחרת.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מעבר לגיבוי כשל עם שכפול pglogical

בחירת גרסת תיעוד:

בדף הזה מוסבר איך לבצע מעבר ידני (switchover) ומעבר אוטומטי (failover) עם רפליקציה של pglogical.

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

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

מידע נוסף על התוסף pglogical זמין במאמר מידע על pglogical.

למידע על שכפול נתונים באמצעות pglogical, אפשר לעיין במאמרים שכפול נתונים בין AlloyDB ל-PostgreSQL לבין AlloyDB Omni ושכפול נתונים בין AlloyDB Omni לבין מסדי נתונים אחרים.

מעבר עם רפליקציה של pglogical

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

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

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

יצירת ההגדרה החדשה של הספק או המנוי

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

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

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

הפלט אמור להיראות כך:

-[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

המרת מסד הנתונים של המנויים למסד נתונים של ספק:
1. מפסיקים את המינוי הקיים של המנוי.
2. מוסיפים את קבוצת הרפליקציה, אם צריך.
3. מוסיפים את הטבלאות הנדרשות לקבוצת השכפול.
4. יוצרים מינוי חדש במסד הנתונים החדש של המינויים.
5. מפנים את האפליקציות לספק החדש.
מפסיקים את המינוי במסד הנתונים הקיים של המנויים, שהופך לספק החדש:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(אופציונלי) יוצרים קבוצת רפליקציה שתואמת להגדרה של מסד הנתונים המקורי של הספק. אם אתם משתמשים בקבוצות ברירת המחדל של הרפליקציות, אתם לא צריכים לעשות את זה:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
מוסיפים טבלאות לקבוצת הרפליקציה:
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPLICATION_SET_NAME: השם של קבוצת השכפול.
- ‫TABLE_NAME: שם הטבלה של בעלי סכימה. לדוגמה, ARRAY['public'].`

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

SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

בודקים אם המינוי פועל בצומת של הספק:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

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

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

הסרת הספק והמינוי הישנים

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

הסרת המינוי הישן אצל הספק החדש:

SELECT pglogical.drop_subscription('<subscription name>')

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

SELECT pglogical.drop_replication_set('<replication set name>')

SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

רפליקציה דו-כיוונית

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

כדי להגדיר את פתרון ההתנגשויות, אפשר להשתמש בהגדרות הבאות של pglogical.conflict_resolution:

‫error: המנוי מפסיק כשהמערכת מזהה התנגשות.
‫apply_remote: תמיד להחיל את השינויים הנכנסים, בלי קשר לנתונים במסד הנתונים של המנוי. זוהי הגדרת ברירת המחדל.
‫keep_local: תמיד מתעלמים מהנתונים הנכנסים שמתנגשים עם השינוי ומבטלים את השינוי שמתנגש.
‫last_update_wins: גרסת הנתונים עם חותמת הזמן של ה-commit האחרון היא הנתונים שבוצע להם commit
‫first_update_wins: גרסת הנתונים עם חותמת הזמן הישנה ביותר היא הגרסה שמועברת.

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

אצל הספק המקורי, צריך להוסיף מנוי חדש. כדי ליצור מנוי חדש, פועלים לפי ההוראות במאמר יצירת צומת ומנוי במסד הנתונים של המנויים ב-AlloyDB Omni, ומוודאים שהפרמטר synchronize_data של הפקודה pglogical.create_subscription מוגדר לערך false. כך נמנעת העתקה ראשונית של הנתונים מהטבלה.

מעבר לגיבוי בעת כשל עם רפליקציה של pglogical

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

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

עוצרים את המנוי, test_sub_1:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

בודקים שהסטטוס הוא disabled:

SELECT pglogical.show_subscription_status('test_sub_1');