pglogical ולפתור בעיות שקשורות אליהן, באמצעות בדיקה ואימות של מסדי הנתונים של הספק והמנוי.
לפני שמתחילים
לפני שמתחילים לעקוב אחרי הטמעות של pglogical ולפתור בהן בעיות, צריך לבדוק את מסדי הנתונים של הספק והמנוי, להבין את ההטמעה של pglogical ולאמת את ההגדרה שלה.
מידע נוסף על התוסף pglogical זמין במאמר מידע על pglogical.
למידע על שכפול נתונים באמצעות pglogical, אפשר לעיין במאמרים שכפול נתונים בין AlloyDB ל-PostgreSQL לבין AlloyDB Omni ושכפול נתונים בין AlloyDB Omni לבין מסדי נתונים אחרים.
בדיקת ההגדרות של pglogical, השכפול והפרמטרים של AlloyDB Omni
יש כמה פרמטרים של הגדרה שמשפיעים על הפעולה של התוסף pglogical, ואפשר לבדוק את זה במסדי הנתונים של הספק והמנוי. שימו לב: ערכי הפרמטרים עשויים להשתנות.
הצגת ההגדרה הנוכחית של פרמטרים ספציפיים ל-
pglogical:SELECT name, setting, source, short_desc FROM pg_catalog.pg_settings WHERE name LIKE '%pglogical%' AND name NOT LIKE '%alloydb%' ORDER BY category, name;הצגת פרמטרים אחרים שקשורים לשכפול לוגי:
SELECT name, setting, source, short_desc FROM pg_catalog.pg_settings WHERE name IN ('wal_level', 'max_worker_processes', 'max_replication_slots', 'max_wal_senders', 'shared_preload_libraries', 'track_commit_timestamp') ORDER BY name;הצגת פרמטרים ספציפיים ל-AlloyDB Omni:
SELECT name, setting, source, short_desc FROM pg_catalog.pg_settings WHERE name LIKE '%alloydb%' ORDER BY category, name;
רשימת הצמתים בהגדרה
מציגים את הצמתים המקומיים והמרוחקים בהגדרת הרפליקציה של pglogical:
SELECT node_id, if_nodeid AS node_id, if_name AS node_name, if_dsn AS dsn FROM pglogical.node_interface LEFT JOIN pglogical.local_node ON (node_id = if_nodeid AND node_local_interface = if_id) ORDER BY node_name;אם העמודה
node_idהיאNOT NULL, זהו הצומת המקומי.בודקים את המידע ב
dsn. אם מחרוזת החיבור מכילה מידע שגוי או לא עדכני, יכול להיות שיהיה כשל ברפליקציה. למידע על פתרון בעיות ב-dsn, קראו את המאמר פתרון בעיות ברפליקציה של מינויים.
בדיקת סטטוס המינוי ונקודת הרפליקציה של הטבלה
סטטוס המינוי תמיד מאומת מול מסד הנתונים של המנויים. המינוי מופיע בסטטוס initializing או replicating, וגם בסטטוס down.
מידע נוסף על הסטטוס down זמין במאמר פתרון בעיות ברפליקציה של מינויים.
מציגים את המינויים, הסטטוס הנוכחי וההגדרות שלהם במסד הנתונים הנוכחי:
SELECT s.sub_name AS subscription_name, n1.node_name AS origin_name, n2.node_name AS target_name, x.status, sub_slot_name, sub_replication_sets, sub_forward_origins, sub_apply_delay, sub_force_text_transfer, sub_enabled AS enabled FROM pglogical.subscription s, (SELECT subscription_name, status FROM pglogical.show_subscription_status()) AS x, pglogical.node n1, pglogical.node n2 WHERE s.sub_origin = n1.node_id AND s.sub_target = n2.node_id AND s.sub_name = x.subscription_name ORDER BY s.sub_name;הפלט אמור להיראות כך:
-[ RECORD 1 ]-----------+-------------------------------------- subscription_id | 3072625608 subscription_name | test_sub_1 origin_name | provider target_name | subscriber status | replicating sub_slot_name | pgl_my_test_db_provider_test_sub_1 sub_replication_sets | {default,default_insert_only,ddl_sql} sub_forward_origins | {all} sub_apply_delay | 00:00:00 sub_force_text_transfer | f enabled | t my_test_db=#רשימה של הטבלאות שמשוכפלות כרגע ומספר רצף היומן (LSN) הנוכחי שלהן לפי המינוי:
SELECT sync_nspname||'.'||sync_relname AS table_name, sync_status, sync_statuslsn FROM pglogical.local_sync_status WHERE sync_relname IS NOT NULL ORDER BY table_name;הפלט אמור להיראות כך:
table_name | sync_status | sync_statuslsn ---------------------+-------------+---------------- public.test_table_1 | r | 0/B891BC0 (1 row) my_test_db=#בעמודה
sync_statuslsnמוצג מספר ה-LSN שאליו הטבלה מסונכרנת. אפשר להשוות את הערך הזה ל-LSN במסד הנתונים של הספק כדי למדוד את זמן האחזור של השכפול.כדי לבדוק את סטטוס הרפליקציה של טבלה ספציפית:
SELECT * FROM pglogical.show_subscription_table('test_sub_1','test_table_1');
אימות הפרטים של קבוצת הרפליקציה אצל הספק
מציגים ברשימה את קבוצות השכפול הנוכחיות במסד הנתונים של הספק ובודקים את הפריטים שמשוכפלים:
SELECT set_name, node_name, replicate_insert, replicate_update, replicate_delete, replicate_truncate FROM pglogical.replication_set JOIN pglogical.node ON set_nodeid = node_id ORDER BY set_name, node_name;מציגים את הטבלאות והרצפים שמשוכפלים:
-- Table details: SELECT set_name, set_reloid AS table_name, set_att_list, set_row_filter FROM pglogical.replication_set NATURAL JOIN pglogical.replication_set_table ORDER BY set_name, table_name; -- Sequence details: SELECT set_name, set_seqoid AS sequence_name FROM pglogical.replication_set NATURAL JOIN pglogical.replication_set_seq ORDER BY set_name, sequence_name;
בודקים את פרטי הרפליקציה ואת הפיגור במשבצת אצל הספק
כדי לבדוק את הסטטוס של כל מנוי, יוצרים את התצוגה
pg_stat_replicationבמסד הנתונים של הספק: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 my_test_db=#שימו לב לעמודה
reply_delayשבה מוצג הזמן שבו התקבל העדכון האחרון ממסד הנתונים של המנויים.צריך לעקוב אחרי השהיית השכפול של משבצת השכפול אצל הספק, כי
pglogicalיוצר משבצות שכפול במסד הנתונים של הספק:SELECT slot_name, slot_type, database, active, COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn),0) AS restart_lag, COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),confirmed_flush_lsn),0) AS confirmed_flush_lag FROM pg_replication_slots WHERE plugin like '%pglogical%' ORDER BY slot_name;הפלט אמור להיראות כך:
-[ RECORD 1 ]-------+----------------------------------- slot_name | pgl_my_test_db_provider_test_sub_1 slot_type | logical database | my_test_db active | t restart_lag | 56 confirmed_flush_lag | 0 my_test_db=#
פתרון בעיות בשכפול מינויים
המינוי שנבדק במסד הנתונים של המנויים צריך להיות בסטטוס replicating או initializing אם המינוי נוצר לאחרונה.
אם הסטטוס הוא down, סימן שהתרחשה בעיה.
הסטטוס down מוצג בדרך כלל אחרי שהמערכת ניסתה להתחיל שכפול, אבל הניסיון נכשל. הסיבה לכך היא בעיות בקישוריות שנובעות מההגדרה של dsn, או מהרשאות חסרות במסד הנתונים, אצל הספק או המנוי.
כדי לקבל מידע נוסף שיכול להצביע על הגורם לבעיה, השתמשו ב-Log Explorer ובדקו את קובצי היומן של PostgreSQL ב- Google Cloud כש-Google Cloud AlloyDB הוא אחת מנקודות הקצה. קבצי היומן מספקים פרטים על הבעיה, כולל פרטים ספציפיים על הרשאות חסרות.
בודקים את יומן הרישום של PostgreSQL בשרת AlloyDB Omni:
Docker
docker logs CONTAINER_NAMEמחליפים את
CONTAINER_NAMEבשם שהקציתם לקונטיינר של AlloyDB Omni כשהתקנתם אותו.Podman
podman logs CONTAINER_NAMEמחליפים את
CONTAINER_NAMEבשם שהקציתם לקונטיינר של AlloyDB Omni כשהתקנתם אותו.כדאי לפתור בעיות בהגדרה
dsnולוודא שהבעיה לא נובעת מקישוריות לרשת:- מעתיקים את מחרוזת החיבור של
dsnומנסים להתחבר ידנית באמצעותpsqlואותה מחרוזת. אם אי אפשר להתחבר לסשןpsql, מוצגות ההודעות הבאות:- בעיה ברשת.
- כתובת IP, שם משתמש או סיסמה שגויים.
- חומת אש חוסמת.
- הקובץ
pg_hba.confשל האשכול השני לא מוגדר כמו שצריך.
- מעתיקים את מחרוזת החיבור של
אם לא רוצים להסיר את המינוי וליצור אותו מחדש אחרי ביצוע פעולות לתיקון, אפשר לסנכרן מחדש את הטבלה:
SELECT pglogical.alter_subscription_resynchronize_table(subscription_name := 'test_sub_1',relation := 'table_name');אפשר גם לבטל את המינוי וליצור אותו מחדש:
SELECT pglogical.drop_subscription(subscription_name := 'test_sub_1');
המאמרים הבאים
- מעבר לגיבוי ויתירות כשל עם רפליקציה של
pglogical - שכפול נתונים בין Google Cloud AlloyDB ל-AlloyDB Omni
- שכפול נתונים בין AlloyDB Omni למסדי נתונים אחרים