הגדרה של רפליקציה לוגית ופענוח

אתם יכולים להשתמש בתכונות של שכפול לוגי ופענוח ב-Cloud SQL ל-PostgreSQL. התכונות האלה מאפשרות תהליכי עבודה של רפליקציה לוגית ותהליכי עבודה של סימון נתונים שהשתנו (CDC).

מידע כללי על רפליקציה זמין במאמר מידע על רפליקציה ב-Cloud SQL.

מבוא

כשמבצעים שכפול לוגי ב-PostgreSQL, השינויים שמוזרמים לרפליקות מחולצים מיומני ה-WAL באמצעות פענוח לוגי. השינויים המפוענחים לא תלויים בפורמט האחסון הפיזי הבסיסי. השינויים משקפים רק את השינויים בנתונים מרמת SQL, מבחינת INSERT,‏ UPDATE ו-DELETE. העצמאות הזו משכבת האחסון מספקת גמישות רבה ומאפשרת מגוון רחב של פונקציות לצרכנים של סנכרון שינויים בזרמי נתונים.

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

בניגוד לתכונת השכפול הפיזי של PostgreSQL, שדורשת שמסדי הנתונים של המקור והיעד יהיו באותה גרסה, שכפול לוגי מאפשר שכפול בין גרסאות ראשיות של PostgreSQL. שכפול לוגי ב-Cloud SQL נתמך על ידי התוסף pglogical, שזמין בכל הגרסאות של PostgreSQL, ועל ידי שכפול לוגי מקורי של PostgreSQL, שנוסף ב-PostgreSQL 10.

אפשר להגדיר את הפורמט שבו השינויים מועברים באמצעות תוספים שונים. כך אפשר ליצור ארכיטקטורות גמישות של לכידת נתונים משתנים (CDC). לדוגמה, התוסף wal2json מאפשר להזרים את כל השינויים במסד נתונים לצרכן, בפורמט JSON. ‫Cloud SQL תומך במפענח pgoutput המובנה, במודול test_decoding של contrib וב-wal2json. בשלב הזה, Cloud SQL תומך בשני וריאנטים של פלט JSON – wal2json שמקודד את כל העסקה כאובייקט JSON יחיד, ו-format-version 1 שמוציא אובייקט JSON אחד לכל פקודה.format-version 2 התוספים האלה מאפשרים שכפול למסדי נתונים שאינם PostgreSQL.

הגדרת מכונת PostgreSQL

‫PostgreSQL תומך בפענוח לוגי על ידי כתיבת מידע נוסף ל-WAL (יומן כתיבה מראש).

ב-Cloud SQL, כדי להפעיל את התכונה הזו, מגדירים את האפשרות cloudsql.logical_decoding לערך on. ההגדרה הזו שונה מההגדרה שמשמשת ב-PostgreSQL רגיל. אם משנים מופע חיצוני של PostgreSQL, מפעילים את התכונה הזו על ידי הגדרת פרמטר התצורה wal_level לערך logical.

אם אתם מתכננים להשתמש בתוסף pglogical, אתם צריכים להוסיף את pglogical אל shared_preload_libraries. מכיוון ש-Cloud SQL לא מאפשר שינוי ישיר של הדגל הזה, כדי להפעיל את pglogical צריך להגדיר את cloudsql.enable_pglogical ל-on. (במכונה וירטואלית, מריצים את הפקודה sudo apt-get install postgresql-13-pglogical ) ומפעילים מחדש את מסד הנתונים.

אם אתם משתמשים ב-pglogical כדי לשכפל בין שני מופעי PostgreSQL, צריך להפעיל פענוח לוגי רק במופע הראשי, ולא במופע המשוכפל (אלא אם המופע הזה הוא בעצמו ראשי עבור עותקים משוכפלים אחרים). עם זאת, צריך להפעיל את התוסף pglogical בשני המקרים. דוגמאות לשימוש במונחים 'ראשי' ו'רפליקה' והמשמעויות שלהם מופיעות במאמר מידע על שכפול ב-Cloud SQL.

הפעלת קישוריות לרשת

מוודאים שהמופעים הראשיים מקבלים חיבורים ממופע ההעתקה.

קבלת כתובת ה-IP היוצאת של מופע משוכפל

אם מכונת הרפליקה היא מכונת Cloud SQL ויש לה כתובת IP ציבורית, צריך לבצע את השלבים הבאים כדי לקבל את כתובת ה-IP היוצאת שלה.

gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"

התרת חיבורים

אם המכונה הראשית היא מכונת Cloud SQL, אפשר לאפשר גישה מכתובת ה-IP היוצאת של הרפליקה על ידי הוספתה כרשת מורשית.

הפעלת חיבורי שכפול ל-PostgreSQL 9.6 ולגרסאות קודמות

אם המופע הראשי שלכם לא פועל ב-Cloud SQL, והוא פועל ב-PostgreSQL 9.6 או בגרסה קודמת, אתם צריכים לוודא שהקובץ pg_hba.conf של המופע מוגדר לקבל חיבורי שכפול. מוסיפים את השורה הבאה לקובץ, ומשתמשים ב-all all לבדיקה ראשונית בלבד. כדי לשפר את האבטחה, כדאי להגביל את המשתמשים וכתובות ה-IP רק לאלה שנדרשים, כמו בדוגמה הזו:

host replication all all md5

מידע נוסף זמין במאמר בנושא קובץ pg_hba.conf.

יצירת משתמש שכפול

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

דוגמאות

CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';

לחלופין, אפשר להגדיר את המאפיין הזה למשתמש קיים:

ALTER USER existing_user WITH REPLICATION;

משאבים של PostgreSQL

כשמשתמשים בפענוח לוגי, תהליך רקע במופע הראשי של PostgreSQL הופך שינויים ב-WAL לשינויים לוגיים, באמצעות תוסף הפענוח שנבחר, ומעביר אותם לצרכן (שיכול להיות אפילו מופע שאינו PostgreSQL). תהליך הרקע הזה נקרא WAL sender. מספר השולחים של WAL בו-זמנית שיכולים להיות פעילים במופע של PostgreSQL מוגבל על ידי הדגל max_wal_senders. ערך ברירת המחדל של הדגל הזה הוא 10, והמגבלה שלו גדלה באופן ליניארי עם הזיכרון של מופע Cloud SQL, כך שניתן להשתמש ב-8 שולחי WAL לכל GB של זיכרון.

כדי לוודא שפלחים של WAL לא יימחקו לפני שהם נשלחים לכל הצרכנים, PostgreSQL משתמש במשבצות שכפול לוגיות כדי לעקוב אחרי הנתונים שנשלחו לכל צרכן (ובמשבצות שכפול פיזיות עבור רפליקות לקריאה). מספר משבצות השכפול שאפשר ליצור עבור מכונת PostgreSQL מוגבל על ידי הדגל max_replication_slots. ערך ברירת המחדל של הדגל הזה הוא 10, והמגבלה שלו גדלה בהתאם לזיכרון של מכונת Cloud SQL, כך שאפשר להשתמש ב-2 עד 8 משבצות שכפול לכל GB של זיכרון.

בטבלה הבאה מוצג הקשר בין הזיכרון המקסימלי של מופע Cloud SQL לבין מספר משבצות השכפול המקסימלי של המופע.

בדרך כלל יש משבצת שכפול אחת ושולח WAL אחד לכל צרכן, ולכן צריך להגדיר את הערכים של הדגלים האלה כך שיהיו בערך שווים. עם זאת, ב-PostgreSQL מומלץ לספק מאגר קטן ל-max_wal_senders כדי לטפל במקרים שבהם החיבורים נסגרים באופן לא צפוי ונוצרים חיבורים חדשים. שכפול פיזי, כמו זה שמשמש את רפליקות הקריאה של Cloud SQL, משתמש גם במשבצת שכפול ובשולח WAL, לכן צריך לכלול אותם בחישוב של מספר המשאבים שאתם צריכים.

שכפול לוגי מקורי של PostgreSQL ו-pglogical דורשים הפעלה של תהליכי רקע נוספים, גם במופעים הראשיים וגם במופעים המשוכפלים. מספר התהליכים ברקע שיכולים לפעול מוגבל על ידי הדגל max_worker_processes. ברירת המחדל היא שמונה, והמגבלה גדלה באופן לינארי עם הזיכרון של מכונת Cloud SQL, כך שניתן להוסיף שני תהליכים לכל GB של זיכרון. המספר המדויק של תהליכי העובד שמשמשים בגישות האלה מוסבר בסעיפים הרלוונטיים.

אם הערך של הדגל הזה נמוך מדי, והשכפול נכשל עם הודעת השגיאה worker registration failed ביומנים, כנראה שצריך להגדיל את הערך של max_worker_processes.

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

אפשר להשתמש בפונקציה pg_ls_waldir () כדי לקבוע את השימוש בדיסק של WAL. הפונקציה הזו מוגבלת למשתמשים cloudsqlsuperuser כמו משתמש האדמין שמוגדר כברירת מחדל postgres. הפונקציה הזו זמינה רק ב-PostgreSQL מגרסה 10 ומעלה.

כדי לחשב את השימוש הכולל בדיסק של WAL:

postgres=> select * from pg_ls_waldir();

(2 שורות)

postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();

(שורה אחת)

הגדרה של רפליקציה לוגית עם עותק חיצוני

במאמר הגדרת עותקים חיצוניים יש דוגמה מלאה לשימוש ב-pglogical ובפענוח לוגי.

הגדרה של רפליקציה לוגית באמצעות pglogical

כדי להגדיר שכפול לוגי באמצעות pglogical, צריך להפעיל פענוח לוגי במופע הראשי. מגדירים את cloudsql.logical_decoding=on במכונה של Cloud SQL או את wal_level=logical במכונה חיצונית. בנוסף, צריך להפעיל את pglogical גם במופע הראשי וגם במופע המשוכפל. צריך להגדיר את cloudsql.enable_pglogical=on במופע של Cloud SQL או להוסיף את pglogical אל shared_preload_libraries במופע חיצוני. שימו לב: כדי לשנות את הדגלים האלה צריך להפעיל מחדש את המופעים הראשיים והמשוכפלים.

אם נתקלתם בבעיות בשלבים האלה, כדאי לעיין במאמר בנושא פתרון בעיות ב-pglogical.

יצירת משתמש עם הרשאות שכפול

כשמשתמשים ב-pglogical, צריך משתמש עם הרשאות שכפול ותפקיד cloudsqlsuperuser גם במופע הראשי וגם במופע המשוכפל. כל הפקודות שמתוארות בהמשך צריכות להתבצע על ידי המשתמש הזה.

התקנת התוסף pglogical

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

CREATE EXTENSION pglogical;

יצירת צומת pglogical בכל מופע

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

source-instance$ SELECT pglogical.create_node(
    node_name := 'primary',
    dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

dest-instance$ SELECT pglogical.create_node(
    node_name := 'replica',
    dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

יצירת טבלה עם נתונים לשכפול

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

CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');

הטבלה צריכה להיווצר גם במופע המשוכפל.

הוספת הטבלה לקבוצת שכפול

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

SELECT pglogical.replication_set_add_table('default', 'replica_test', true);

יצירת מינוי pglogical

יוצרים את המינוי pglogical במופע היעד על ידי הזנת פרטי החיבור למופע הראשי.

SELECT pglogical.create_subscription(
    subscription_name := 'test_sub',
    provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);

SELECT * FROM pglogical.show_subscription_status('test_sub');

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

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

הסרת המשאבים

אחרי שהבדיקה מצליחה, מבטלים את המינוי בעותק המשוכפל באמצעות הפקודה pglogical.drop_subscription('test_sub'). מוודאים שמשבצת השכפול הוסרה גם מהשרת הראשי. אחרת, פלחי ה-WAL ממשיכים להצטבר במופע המשוכפל.

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

שימוש במשאבים

התוסף pglogical מפעיל כמה תהליכים ברקע שנספרים במסגרת המגבלה של max_worker_processes.

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

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

לסיכום, ההגדרות המומלצות הן:

max_worker_processes
  >= 1 + D + 8 (on the source instance)
  >= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)

פתרון בעיות ב-pglogical

לא ניתן ליצור את התוסף pglogical

כשמנסים להתקין את התוסף pglogical, יכול להיות שתוצג השגיאה:

ERROR:  pglogical is not in shared_preload_libraries

כשמתקינים את pglogical במכונת Cloud SQL, מוודאים שהגדרתם את cloudsql.enable_pglogical=on. אם משתמשים במופע חיצוני, מוסיפים אותו ישירות לדגל shared_preload_libraries, לדוגמה, shared_preload_libraries=pg_stat_statements,pglogical. כדי שהשינויים האלה ייכנסו לתוקף, צריך להפעיל מחדש את המופע הראשי.

אי אפשר ליצור מינוי pglogical

כשיוצרים מינוי, pglogical בודק קודם שהוא יכול להשתמש בפרטי החיבור כדי להתחבר למופע. הוא מנסה קודם ליצור חיבור רגיל, ואם זה נכשל, מתרחשת שגיאה: ERROR: could not connect to the postgresql server.

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

אחרי שיוצרים חיבור רגיל, pglogical מנסה ליצור חיבור שכפול מיוחד. ב-PostgreSQL 9.6 ובגרסאות קודמות, יכול להיות שלסוג החיבור הזה יש הגדרת אימות שונה. אם מופיעה השגיאה הבאה: ERROR: could not connect to the postgresql server in replication mode, צריך לעדכן את הקובץ pg_hba.conf במופע המקור.

הקובץ pg_hba.conf שמשמש את Cloud SQL כבר כולל את השינויים הנדרשים. השגיאה הזו מתרחשת רק כשמתחברים למופע חיצוני שלא מנוהל על ידי Cloud SQL.

לחלופין, יכול להיות שהחיבור במצב השכפול ייכשל אם מופעלים יותר מדי שולחי WAL במופע המקור. אם מופיע FATAL: number of requested standby connections exceeds max_wal_senders, צריך להגדיל את max_wal_senders במופע הראשי.

המינוי ל-pglogical מושבת

יכול להיות ששכפול של מינוי pglogical ייכשל. כדי לפתור את הבעיה הזו, קודם צריך לוודא שתהליך ברקע פועל במופע המשוכפל. מריצים את השאילתה pg_stat_activity כדי לוודא שתהליך pglogical apply פועל. אם לא, בודקים את היומנים בצומת היעד. אם מופיעה ההודעה worker registration failed, אפשר להגדיל את ההגדרה max_worker_processes.

לאחר מכן, מוודאים שנוצר משבצת רפליקציה במופע הראשי. במופע המשוכפל, השורה ב-pglogical.subscription מכילה את שם המשבצת שהמינוי מנסה ליצור, ובמופע הראשי אפשר להריץ שאילתה על pg_replication_slots כדי לוודא שהמשבצת נוצרה בהצלחה.

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

שגיאה מסוג ERROR: logical decoding requires wal_level >= logical מצביעה על כך שהדגל wal_level לא הוגדר לערך logical. כדי לפתור את הבעיה, צריך להגדיר את cloudsql.logical_decoding=on במכונה הראשית אם היא מכונה של Cloud SQL.

לחלופין, אם המופע הוא מופע חיצוני, מגדירים את wal_level=logical.

אחרת, יכול להיות שיוצג ERROR: all replication slots are in use, יחד עם HINT: Free one or increase max_replication_slots.

הגדרה של שכפול לוגי מקורי של PostgreSQL

מאז PostgreSQL 10, ‏ PostgreSQL תומך בשכפול לוגי מובנה. כדי להגדיר שכפול לוגי מקורי, צריך להפעיל פענוח לוגי במופע הראשי. לשם כך, מגדירים את cloudsql.logical_decoding=on במופע של Cloud SQL או את wal_level=logical במופע חיצוני. שימו לב: כדי לשנות את הדגלים האלה צריך להפעיל מחדש את המופע הראשי.

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

יצירת טבלה עם נתונים לשכפול

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

CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');

הטבלה צריכה להיווצר גם במופע המשוכפל.

יצירת אתר חדשות במופע הראשי

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

CREATE PUBLICATION pub FOR TABLE native_test;

יצירת מינוי במופע המשוכפל

דוגמה ליצירת מינוי במופע המשוכפל:

CREATE SUBSCRIPTION sub
    CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
    PUBLICATION pub;

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

בשרת הראשי, אפשר להריץ שאילתה בטבלה pg_replication_slots כדי לראות את משבצת השכפול שנוצרה על ידי המינוי.

הסרת המשאבים

אחרי שהבדיקה תצליח, אפשר לבטל את המינוי ברפליקה באמצעות DROP SUBSCRIPTION sub;. מוודאים שמשבצת השכפול הוסרה גם בשרת הראשי. אחרת, פלחי ה-WAL ממשיכים להצטבר במופע הראשי.

מגבלות על שכפול לוגי מקורי של PostgreSQL

הגישה לעמודה subconninfo של טבלת המערכת pg_subscription לא זמינה.

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

קבלת שינויים מפוענחים ב-WAL לסימון נתונים שהשתנו (CDC)

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

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

• ‫wal2json, להזרמת שינויים בפורמט JSON, או

• ‫test_decoding, כדי להזרים שינויים בפורמט טקסט בסיסי

יצירת משבצת שכפול

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

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --create-slot \
  -P <decoder_plugin>

שינויים בזרם

בטרמינל אחד של Cloud Shell, מריצים את הפקודה:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --start \
  -f -

במסוף אחר של Cloud Shell, מתחברים למסד הנתונים ומריצים את הפקודות הבאות:

CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;

אם משתמשים בתוסף wal2json של פענוח, פלט שדומה לזה שבהמשך מוצג במסוף הראשון של Cloud Shell:

{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}

אם משתמשים בתוסף test_decoding decoder, פלט שדומה לזה שמופיע בהמשך מוצג בטרמינל הראשון של Cloud Shell:

BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464

(מזהי העסקאות עשויים להיות שונים).

הסרת המשאבים

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

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --drop-slot

הערות ומגבלות

ההערות וההגבלות שבקטע הזה רלוונטיות לתכונות של שכפול לוגי ופענוח ב-Cloud SQL ל-PostgreSQL.

• אי אפשר להשתמש במכונות שמשתמשות בזמינות גבוהה (HA) כמנויות שכפול, כי אין להן כתובת IP יוצאת עקבית.

• התוסף pglogical לא פועל במופעים שבהם מופעלת אכיפת מחבר. המגבלה הזו לא חלה על מקרים שבהם מוגדרת גישה לשירותים פרטיים.

• כשמשחזרים מופע שמופעלים בו cloudsql.logical_decoding או cloudsql.enable_pglogical, ושפועל כרגע כמוציא לאור לשכפול לוגי, צריך להשבית קודם את השכפול לכל מופעי היעד. אחרת, השחזור למופע ייכשל עם שגיאה, אבל כרגע פרטי השגיאה לא גלויים.

• כשמשחזרים גיבוי של מכונה שבה הופעלו cloudsql.logical_decoding או cloudsql.enable_pglogical (בזמן הגיבוי), ומשחזרים אותה למכונה חדשה, מצב השכפול לא משוחזר למכונה החדשה. לאחר מכן צריך להגדיר מחדש את השכפול באופן ידני.

• במכונת Cloud SQL עם רפליקות לקריאה (באמצעות שכפול פיזי), אם מפעילים את האפשרויות cloudsql.logical_decoding או cloudsql.enable_pglogical, הן מופעלות גם ברפליקה לקריאה.

  • בגרסאות 15 ומגרסאות קודמות של Cloud SQL ל-PostgreSQL, מכונות реплика לקריאה של Cloud SQL לא יכולות לשמש כמקורות לפרסום של שכפול לוגי, כי PostgreSQL לא תומך בפענוח לוגי במכונות реплика לקריאה בגרסאות הישנות האלה. עם זאת, כדי להבטיח שהמופעים יוכלו לשמש כתחליף למופע הראשי במקרה של קידום, הדגלים הלוגיים עדיין מופעלים במופעים של העתק לקריאה בגרסאות הקודמות האלה.

  • החל מגרסה 16 של Cloud SQL ל-PostgreSQL, מכונות реплика לקריאה ב-Cloud SQL יכולות לשמש כמפרסמים לשכפול לוגי, אם הדגלים הלוגיים מוגדרים במכונה הראשית. המשתמש הלוגי יכול להיות מכונה של Cloud SQL או מכונה חיצונית. עם זאת, פעולות מחיקה של שורות ופעולות vacuum בשרת הראשי עשויות למחוק טפלים שעדיין נדרשים לפענוח לוגי בעותק לקריאה. במקרים כאלה, משבצת השכפול הלוגי בעותק לקריאה נפסלת כדי למנוע חוסר עקביות.

  • הפעלת cloudsql.logical_decoding או cloudsql.enable_pglogical במופע הראשי גורמת להפעלת הדגלים בכל העותקים לקריאה בלבד, וכתוצאה מכך המופע הראשי והעותקים לקריאה בלבד מופעלים מחדש ברצף. כדי להימנע מהמצב הזה ולשלוט מתי כל מופע מופעל מחדש, אפשר (1) להגדיר את הדגלים בכל העתק לקריאה בתורו, ורק אז (2) להגדיר את הדגלים במופע הראשי.

  • השבתה של cloudsql.logical_decoding או cloudsql.enable_pglogical במופע הראשי לא גורמת להשבתת הדגלים בכל העותקים לקריאה. כדי להשבית את הדגלים בכל המופעים, צריך לבצע את הפעולות ההפוכות לאלה שמתוארות למעלה: (1) להשבית את הדגלים במופע הראשי ואז (2) להשבית את הדגלים בכל העתקים לקריאה, אחד אחרי השני.