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

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

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

מבוא

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

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

בניגוד לתכונת השכפול הפיזי של 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 תהליכים כאלה). עם זאת, התוסף עשוי ליצור תהליכי עובד נוספים במהלך סנכרון ראשוני, והוא אכן יוצר תהליכי 'ניהול' עבור כל מסד נתונים במופע, אבל אם התוסף לא מותקן במסד הנתונים, הוא יוצא באופן מיידי.

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

הקובץ 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 decoder, פלט שדומה לזה שבהמשך מוצג במסוף הראשון של 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.

• התוסף 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) להשבית את הדגלים בכל העתקים לקריאה, אחד אחרי השני.