הזרמת נתונים ממסדי נתונים של PostgreSQL

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

כדי להתכונן לרפליקציה של PostgreSQL ב-Datastream, כדאי לעיין בהתנהגות הרפליקציה, בגרסאות ובסוגי מסדי הנתונים הנתמכים, בשיטות המומלצות, בדרישות לרפליקות לקריאה בלבד ובמגבלות הידועות.

התנהגות

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

• אפשר לבחור את כל הסכימות או סכימות ספציפיות ממקור PostgreSQL נתון, וגם את כל הטבלאות מהסכימה או טבלאות ספציפיות.
• כל הנתונים ההיסטוריים משוכפלים.
• כל השינויים בשפת הטיפול בנתונים (DML), כמו הוספות, עדכונים ומחיקות ממסדי הנתונים ומהטבלאות שצוינו, משוכפלים.
• רק שינויים שבוצעו משוכפלים.
• אם מגדירים REPLICA IDENTITY בטבלה, Datastream מתייחס לעמודות שצוינו כמפתחות ראשיים.
• כשהוא מחובר למכונה ראשית, Datastream שולח מדי פעם הודעות איתות למסד הנתונים של המקור. כתוצאה מכך, אירועי הודעות של פענוח לוגי (op:"m") מוכנסים ישירות לקובץ ה-WAL. ההודעות האלה נדרשות ל-Datastream כדי לוודא את זמינות המקור ולחשב את העדכניות. כשמשתמשים בעותק לקריאה בלבד כמקור, צריך להגדיר הודעות פעימה (heartbeat) באופן חיצוני. מידע נוסף זמין במאמר רפליקציה מרפליקות לקריאה בלבד. מומלץ להביא את זה בחשבון אם הגדרות אחרות של שכפול קוראות מאותו מסד נתונים של מקור.

גרסאות

‫Datastream תומך ב-PostgreSQL מגרסה 10 ואילך.

‫Datastream תומך בסוגים הבאים של מסדי נתונים ב-PostgreSQL:

• ‫PostgreSQL באירוח עצמי
• Cloud SQL ל-PostgreSQL
• ‫AlloyDB ל-PostgreSQL
• AlloyDB Omni
• Amazon RDS ל-PostgreSQL
• Amazon Aurora PostgreSQL

תוכנית בחינם

באמצעות Datastream אתם יכולים להעביר נתונים בסטרימינג מ-AlloyDB ל-PostgreSQL אל BigQuery, במסגרת התוכנית בחינם, ולקבל עד 100GiB של נתוני CDC בחינם מדי חודש. למידע נוסף, ראו התמחור של Datastream.

שיטות מומלצות

בקטע הזה מתוארות השיטות המומלצות להגדרת מקור PostgreSQL לשימוש עם Datastream.

שימוש בכמה סטרימים כדי למנוע חסימה של ראש התור (head-of-line blocking)

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

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

המלצה: זהו טבלאות עם שיעורי כתיבה (INSERT/UPDATE/DELETE) גבוהים במיוחד, והציבו אותן בסטרימינג ייעודי משלהן ב-Datastream עם משבצת שכפול נפרדת.

הימנעות מעסקאות ארוכות

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

בנוסף, זה עלול להאט את הפענוח הלוגי. ההאטה נגרמת בגלל טרנזקציות גדולות שמעבירות שינויים לדיסק, ואז נדרשת הרכבה מחדש איטית ועתירת קלט/פלט בזמן האישור, שחוסמת את הרפליקציה של כל הטרנזקציות הבאות. המלצה: במסד הנתונים של המקור, מגדירים את הפרמטרים statement_timeout ו-idle_in_transaction_session_timeout כדי להימנע מטרנזקציות שנמשכות זמן רב. מידע נוסף זמין במאמרי העזרה של PostgreSQL.

שימוש בסינון טבלאות כשיוצרים פרסומים

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

ניהול יזום של מיקומי רפליקציה

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

המלצה: הגדירו התראות יעילות ועקבו אחרי השימוש בדיסק WAL בשרת המקור של PostgreSQL.

הגדרת זהות הרפליקה בצורה נכונה

ההגדרה REPLICA IDENTITY מציינת ל-PostgreSQL אילו נתונים לכתוב ב-WAL לאירועים מסוג UPDATE ו-DELETE, וכך Datastream יכול לזהות אילו שורות השתנו.

אם אתם משתמשים ב-BigQuery כיעד, אל תגדירו את REPLICA IDENTITY ל-FULL. ‫Datastream משתמש בעמודות שנרשמו ביומן כמפתח לוגי לפעולות MERGE ב-BigQuery. אם REPLICA IDENTITY מוגדר ל-FULL ובטבלה יש יותר מ-16 עמודות, היא חורגת מהמגבלה של BigQuery של 16 עמודות למפתחות ראשיים בפעולות MERGE והסטרימינג נשבר.

המלצות (לפי סדר העדיפות):

1. הכי טוב: להשתמש במפתח ראשי. הגדרת ברירת המחדל של REPLICA IDENTITY DEFAULT משתמשת באופן אוטומטי ויעיל במפתח הראשי הקיים.
2. טוב: אם אין מפתח ראשי, יוצרים אינדקס UNIQUE NOT NULL ומגדירים את REPLICA IDENTITY USING INDEX INDEX_NAME.
3. הכי פחות מומלץ: להשתמש בהגדרה REPLICA IDENTITY FULL רק בטבלאות שאין בהן מזהה ייחודי. חשוב להיות מודעים להשפעה על הביצועים, למגבלה של 16 עמודות ולהגבלה על סוגי הנתונים הנתמכים למפתחות ראשיים, אם משכפלים ל-BigQuery.

רפליקציה מרפליקות לקריאה בלבד

‫Datastream תומך בשכפול ממכונות של רפליקות לקריאה בלבד של PostgreSQL, מגרסה 16 ואילך.

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

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

אחת מהדרכים להגדיר אותות heartbeat תקופתיים היא ליצור משימת cron ב-PostgreSQL באמצעות התוסף pg_cron:

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

מחליפים את מה שכתוב בשדות הבאים:

• ‫DATABASE_NAME: שם מסד הנתונים שרוצים ליצור בשבילו פעימות לב.
• ‫USERNAME: שם המשתמש שהמשימה תופעל בשמו. בדרך כלל postgres.

מגבלות ידועות

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

המגבלות הידועות בשימוש ב-Datastream עם מסד נתונים של PostgreSQL כמקור כוללות:

• הסטרימינג מוגבל ל-10,000 טבלאות.
• ‫PostgreSQL דוחה באופן מוחלט בייטים מסוג NULL‏ (0x00) בעמודות של מחרוזות UTF-8. ‫Datastream לא מסיר בייטים מסוג NULL. אם מחרוזת מקור מכילה 0x00 בייטים מסוג null, הוספת האצווה נכשלת והשכפול נפסק. מומלץ לנקות או להחליף תווים מסוג CHAR(0) במסד הנתונים של המקור לפני הרפליקציה.
• אי אפשר להגדיר את מקורות הנתונים של PostgreSQL כך שיתחילו מהמיקום האחרון.
• אי אפשר למלא מילוי חסר בטבלה שיש בה יותר מ-500 מיליון שורות, אלא אם מתקיימים התנאים הבאים:
  1. לטבלה יש אינדקס B-tree ייחודי.
  2. האינדקס לא כולל עמודות מהסוגים הבאים: DOUBLE, ‏ FLOAT, ‏ MONEY, ‏ REAL, ‏ JSON, ‏ JSONB, ‏ BYTEA, ‏ TXID, ‏ XML, סוגי נתונים מורכבים או סוגי נתונים גיאומטריים.
  3. אף אחת מהעמודות של האינדקס לא יכולה להיות ריקה.
  4. כל העמודות של האינדקס הן בסדר עולה, או שכל העמודות של האינדקס הן בסדר יורד.
  5. כל העמודות של האינדקס נכללות בסטרימינג.
• בטבלאות ללא מפתחות ראשיים צריך להיות REPLICA IDENTITY. אחרת, רק אירועים מסוג INSERT משוכפלים ליעד.
• בטבלאות עם מפתחות ראשיים, אי אפשר להגדיר את REPLICA IDENTITY לערך FULL או NOTHING. הערך חייב להיות DEFAULT.
• לא כל השינויים בסכימת המקור ניתנים לזיהוי באופן אוטומטי, ובמקרים כאלה עלול להתרחש נזק לנתונים. השינויים הבאים בסכימה עלולים לגרום לפגיעה בנתונים או לכשל בעיבוד האירועים בהמשך:
  • הסרת עמודות.
  • הוספת עמודות באמצע הטבלה.
  • שינוי סוג הנתונים של עמודה.
  • שינוי הסדר של העמודות.
  • הסרת טבלאות (רלוונטי אם אותה טבלה נוצרת מחדש עם נתונים חדשים).
• ‫Datastream לא תומך בעמודות מסוגי הנתונים geometric, כמו BOX,‏ CIRCLE,‏ LINE,‏ LSEG,‏ PATH,‏ POINT ו-POLYGON. עמודות כאלה משוכפלות בתור NULL.
• ב-Datastream אין תמיכה בעמודות מסוגי הנתונים range.
• ‫Datastream לא תומך במערכים של סוגי נתונים שלא נתמכים (כמו סוגים מרחביים), במערכים של LTREE, במערכים של סוגי נתונים שמוגדרים על ידי המשתמש (כולל ENUM) או במערכים של DATE,‏ TIMESTAMP או TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream מתעלם מעמודות כאלה במהלך הרפליקציה.
• במקורות נתונים שנוצרו לפני 17 בפברואר 2026: Datastream לא תומך בשכפול של אירועי UPDATE בשורות שכוללות ערכי TOAST בעמודות שהן חלק מהזהות של הרפליקה של הטבלה. אירועים כאלה נמחקים. החריגה הזו לא חלה על שידורים שנוצרו אחרי התאריך הזה.
• ‫Datastream לא תומך בשכפול שורות שכוללות ערכי JSON או JSONB עם יותר מ-2,950 אובייקטים בתצוגת עץ. אירועים שמכילים ערכים כאלה של JSON או JSONB לא משוכפלים למסד הנתונים של היעד.
• ‫Datastream לא תומך בשכפול שורות שכוללות ערכי NaN בעמודות NUMERIC (precision, scale). הערכים בעמודות האלה מוחלפים בערכים של NULL.
• ב-Datastream אין תמיכה בשכפול עמודות מסוג הנתונים hstore. הערכים בעמודות האלה מוחלפים בערכים של NULL.
• ‫Datastream לא תומך בשכפול רשומות שאינן ב-ASCII ממסד נתונים מקודד ב-SQL_ASCII. רשומות כאלה נמחקות.
• ב-Datastream אין תמיכה בשכפול טבלאות שמוגדרת בהן מדיניות אבטחה ברמת השורה (RLS). במאמר התנהגות ומגבלות של מקור PostgreSQL מוסבר איך לעקוף את המגבלה הזו.
• בעמודות סטרימינג עם סוגי נתונים באורך משתנה שמשתמשים ב-Oversized-Attribute Storage Technique‏ (TOAST): אם ערך TOAST שלא השתנה נמחק מיומן ה-WAL במהלך פעולת UPDATE, Datastream מבצע חיפוש פעיל במסד הנתונים של המקור כדי לנסות לשחזר את הערך החסר. לכן, יכול להיות ששינויי ביניים לא יתועדו בתרחישים שכוללים עדכונים מהירים ורציפים, או מחיקה מהירה אחרי הוספה. חשוב לזכור שפעולות DELETE לא מפעילות את פעולת החיפוש הפעיל הזו. המגבלה הזו על עמודות באורך משתנה שמשתמשות ב-TOAST רלוונטית במיוחד כשמשתמשים במצב הכתיבה "הוספה בלבד", שבו כל השינויים שמתרחשים באמצע אמורים להישמר.
• ‫Datastream לא מתעד שינויים שבוצעו בעמודות שנוצרו.
• יכול להיות ש-Datastream יפסיק לפעול או לא יתעד אירועים חדשים כשמתבצע שדרוג של גרסה ראשית של PostgreSQL במסד הנתונים. מומלץ להסיר את משבצות השכפול לפני השדרוג, לשדרג את מסד הנתונים ואז ליצור מחדש את משבצות השכפול. אם הסטרימינג נכשל, משחזרים את הסטרימינג על ידי ציון השם החדש של משבצת הרפליקציה, ומבצעים מילוי חוסרים אם נדרשת עקביות בנתונים.
• כשמשתמשים בתהליך האוטומטי להגדרת סטרימינג, Datastream לא תומך בשכפול של טבלאות מערכת של PostgreSQL. אם תערכו את ה-stream שיצרתם באמצעות התהליך האוטומטי ותוסיפו טבלאות מערכת, Datastream יתעלם מהטבלאות האלה בלי להציג הודעה, ולא ישכפל נתונים או שינויים מהן.

המאמרים הבאים

• איך מגדירים מקור PostgreSQL לשימוש עם Datastream