מעקב אחרי שכפול pglogical ב-AlloyDB Omni

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

• הגרסה הנוכחית (18.4.0)
• 18.4.0
• 18.3.0
• 18.1.1
• 18.1.0

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

המידע בדף הזה רלוונטי רק ל-AlloyDB Omni שמשתמש בקונטיינרים. היא לא רלוונטית ל-AlloyDB Omni שמשתמש בתזמור קונטיינרים.

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

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

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

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

בדיקת ההגדרות של pglogical, הרפליקציה והפרמטרים של AlloyDB Omni

הערה: מומלץ לבדוק את הגדרות הפרמטרים בכל הצמתים.

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

1. הצגת ההגדרה הנוכחית של פרמטרים ספציפיים ל-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;
   

2. הצגת פרמטרים אחרים שקשורים לשכפול לוגי:

   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;
   

3. הצגת פרמטרים ספציפיים ל-AlloyDB Omni:

   SELECT name,
       setting,
       source,
       short_desc
   FROM pg_catalog.pg_settings
   WHERE name LIKE '%alloydb%'
   ORDER BY category, name;
   

רשימת הצמתים בהגדרות האישיות

1. מציגים את הצמתים המקומיים והמרוחקים בהגדרת הרפליקציה של 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, זהו הצומת המקומי.

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

בדיקת סטטוס המינוי ונקודת הרפליקציה של הטבלה

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

1. רשימת המינויים הנוכחיים של מסד הנתונים, סטטוס המינוי וההגדרות.

   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=#
   

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

3. כדי לבדוק את סטטוס הרפליקציה של טבלה ספציפית:

   SELECT * FROM pglogical.show_subscription_table('test_sub_1','test_table_1');
   

אימות הפרטים של קבוצת הרפליקציה אצל הספק

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;
   

2. מציגים את הטבלאות והרצפים שמשוכפלים:

   -- 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;
   

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

1. כדי לבדוק את הסטטוס של כל מנוי, יוצרים את התצוגה 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=#
   

   זהירות: חשוב לבדוק רק את הרשומות של pglogical. מתאימים בין העמודה application_name לשם המינוי ממסד הנתונים של המנויים.

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

3. צריך לעקוב אחרי השהיית השכפול של משבצת השכפול אצל הספק, כי 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=#
   

   חשוב: כלים ותוספים אחרים יכולים ליצור משבצות רפליקציה. צריך לוודא שמשבצת הרפליקציה שנבדקת תואמת לpglogical קבוצת רפליקציה. הפעולה הזו מכוסה על ידי הפלאגין, למשל '%pglogical%' query predicate.

פתרון בעיות בשכפול מינויים

המינוי שנבדק במסד הנתונים של המנויים צריך להיות בסטטוס replicating או initializing אם המינוי נוצר לאחרונה. אם הסטטוס הוא down, סימן שיש בעיה.

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

כדי לקבל מידע נוסף שיכול להצביע על הגורם לבעיה, אפשר להשתמש ב-Logs Explorer ולבדוק את קובצי היומן של PostgreSQL ב- Google Cloud כש- Google Cloud AlloyDB היא אחת מנקודות הקצה. קובצי היומן מספקים פרטים על הבעיה, כולל פרטים ספציפיים על הרשאות חסרות.

בודקים את היומן של PostgreSQL בשרת AlloyDB Omni:

   sudo journalctl -u alloydbomni18

1. פותרים את הבעיה בהגדרה dsn ומוודאים שהבעיה לא נובעת מהקישוריות לרשת:

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

     • בעיה ברשת.
     • כתובת IP, שם משתמש או סיסמה שגויים.
     • חומת אש חוסמת.
     • הקובץ pg_hba.conf של האשכול השני לא מוגדר כמו שצריך.

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

   • כדי לסנכרן מחדש טבלה בלי לבטל את המינוי:

     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 למסדי נתונים אחרים