שאילתות לאופטימיזציה ודיבוג של שכפול PostgreSQL

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

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

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

ניטור מצב שכפול לוגי של Postgres

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

SELECT 

    subname AS subscription_name,

    pid AS process_id,

    usename AS user_name,

    application_name,

    client_addr AS client_address,

    state,

    sync_state,

    sent_lsn,

    write_lsn,

    flush_lsn,

    replay_lsn,

    clock_timestamp() - write_lsn_timestamp AS replication_delay

FROM 

    pg_stat_subscription

ORDER BY 

    subscription_name;

​

​

subscription_name | process_id | user_name | application_name | client_address |    state    | sync_state |   sent_lsn   |  write_lsn   |  flush_lsn   |  replay_lsn  | replication_delay

-------------------+------------+-----------+------------------+----------------+-------------+------------+--------------+--------------+--------------+--------------+-------------------

 sub1              |      23456 | postgres  | logical_rep_sub   | 192.168.1.10   | streaming   | synced     | 0/3000128    | 0/3000128    | 0/3000128    | 0/3000128    | 00:00:00.12345

 sub2              |      23478 | postgres  | logical_rep_sub   | 192.168.1.11   | catchup     | async      | 0/4000238    | 0/4000200    | 0/40001F8    | 0/40001E0    | 00:00:02.67890

• subname – שם המנוי.
• state – מצב תהליך המנוי (למשל, סטרימינג, השגה, אתחול).
• sync_state – מצב הסנכרון של המנוי.
• sent_lsn, write_lsn, flush_lsn, replay_lsn – עמודות אלו מייצגות מספרי רצף של קבוצת פעולות (LSNs) המציינות את התקדמות השקיפות.
• replication_delay – ההשהייה בין כתיבת ה-LSN והיישום שלו במנוי היא חיונית לזיהוי עיכוב בשקיפות.

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

ניתוח עיכוב השקיפות ב־Postgres

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

SELECT 

    s.slot_name,

    s.active,

    s.restart_lsn,

    pg_wal_lsn_diff(pg_current_wal_lsn(), s.restart_lsn) AS replication_lag_bytes,

    clock_timestamp() - pg_last_xact_replay_timestamp() AS replication_lag_time

FROM 

    pg_replication_slots s

WHERE 

    s.active = true

AND 

    s.plugin = 'pgoutput';

​

​

slot_name | active | restart_lsn | replication_lag_bytes | replication_lag_time 

-----------+--------+-------------+-----------------------+-----------------------

 slot1     | t      | 0/3000128   |                 65536 | 00:00:00.12345

 slot2     | t      | 0/4000238   |                131072 | 00:00:02.67890

• slot_name – שם חריץ השקיפות המשמש.
• replication_lag_bytes – ההבדל בבתים בין עמדת ה-WAL הנוכחית במפרסם ועמדת ה-WAL האחרונה שהוכרזה על ידי המנוי.
• replication_lag_time – ההבדל הזמני בין העסקאות האחרונות שנשדרו במנוי והזמן הנוכחי.

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

ניטור שימוש במקום השילוש

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

SELECT

    slot_name,

    plugin,

    slot_type,

    active,

    confirmed_flush_lsn,

    pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS slot_lag_bytes

FROM 

    pg_replication_slots

WHERE 

    slot_type = 'logical';

​

​

slot_name | plugin  | slot_type | active | confirmed_flush_lsn | slot_lag_bytes 

-----------+---------+-----------+--------+---------------------+----------------

 slot1     | pgoutput| logical   | t      | 0/3000128           |           65536

 slot2     | pgoutput| logical   | t      | 0/4000238           |          131072

• slot_name – שם מקום השילוש.
• slot_lag_bytes – העיכוב בבתים בין המיקום הנוכחי של WAL והמיקום האחרון שאושר כי הושף על ידי המקום.

ניטור שימוש במקומות השילוש חיוני למניעת בעיות הקשורות לשמירת קטעי WAL, שעלולות להוביל למילוי של מקום בדיסק במפרסם.

השלכת מקומות השילוש שאינם בשימוש

במהלך הזמן, תוכל לאסוף מקומות שילוש שאינם בשימוש, במיוחד לאחר הסרת מנויים או שינוי תצורת שילוש. מקומות השילוש שאינם בשימוש יכולים לגרום לשמירה מיותרת של קטעי WAL, עלולה להוביל למשאב של יקום בדיסק מיותר. השאילתה הבאה זוהי מזהה ומשחררת מקומות שילוש שאינם בשימוש:

DO $$

DECLARE

    slot_record RECORD;

BEGIN

    FOR slot_record IN

        SELECT slot_name FROM pg_replication_slots WHERE active = false

    LOOP

        EXECUTE format('SELECT pg_drop_replication_slot(%L)', slot_record.slot_name);

    END LOOP;

END $$;

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

יצירת סלוטי שקיעה

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

SELECT * FROM pg_create_logical_replication_slot('my_slot', 'pgoutput');

​

slot_name | xlog_position 

-----------+---------------

 my_slot   | 0/3000128

השאילתה הזו משתמשת בפונקציית pg_create_logical_replication_slot כדי ליצור סלוט שקיעה לוגי חדש עם השם ופלאגין הפלט המצויין (pgoutput בדוגמתנו). השאילתה היא שימושית בעת הגדרת הגדרות חדשות לשקיעה לוגית; ניתן להשתמש בה כדי לאשר שהנרשם יכול להתחיל לקבל שינויים מנקודת התחלה הנכונה ברשומות WAL.

אופטימיזציה של שקיעה לוגית עם pglogical

אם אתה משתמש בסיומת pglogical ליכולות שקיעה לוגיות מתקדמות יותר, השאילתה הבאה יכולה לעזור לך לבדוק את מצב כל המינויים של pglogical:

SELECT 

    subscription_name,

    status,

    received_lsn,

    replay_lag,

    last_received_change,

    pending_changes

FROM 

    pglogical.show_subscription_status();

​

​

subscription_name | status   | received_lsn | replay_lag | last_received_change | pending_changes 

-------------------+----------+--------------+------------+---------------------+-----------------

 sub_pglogical1    | replicating | 0/3000128 | 00:00:01.234 | 2024-08-22 10:30:00 | 5

 sub_pglogical2    | idle      | 0/4000238 | 00:00:00.000 | 2024-08-22 10:29:30 | 0

• subscription_name – שם המינוי של pglogical.

• replay_lag – ההמהות בין השינוי האחרון שהתקבל והזמן הנוכחי.
• pending_changes – מספר השינויים הממתינים ליישום במנוי.

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

מסקנה

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

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