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

אתם יכולים להשתמש בתכונות שכפול לוגי ופענוח ב-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 וב-wal2json. ב-Cloud SQL יש כרגע תמיכה בשני הווריאנטים של wal2json לפלט JSON: ‏format-version 1 שמקודד את כל הטרנזקציה כאובייקט JSON יחיד, ו-format-version 2 שמוציא אובייקט JSON אחד לכל פקודה. הפלאגינים האלה מאפשרים רפליקציה למסדי נתונים שהם לא 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, ופועלת בה גרסה 9.6 או גרסה קודמת של PostgreSQL, צריך לוודא שהקובץ 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 שמשמשים בגישות האלה מוסבר בסעיפים הרלוונטיים.

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

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

אם הסטטוס שמופיע הוא "replicating", סימן שההגדרה הושלמה בלי שגיאות. שולחים שאילתה לטבלה 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 ובגרסאות קודמות, יכול להיות שלסוג החיבור הזה תהיה הגדרת אימות שונה. אם מופיעה השגיאה 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

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

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

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