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

בקטע הזה מופיע מידע על:

  • התנהגות של Datastream לגבי נתונים שנשלפים ממסד נתונים של PostgreSQL
  • גרסאות של מסד נתונים PostgreSQL שנתמכות ב-Datastream
  • סקירה כללית על הגדרת מסד נתונים של PostgreSQL כמקור, כדי שאפשר יהיה להזרים ממנו נתונים ליעד
  • מגבלות ידועות בשימוש במסד נתונים של PostgreSQL כמקור

התנהגות

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

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

גרסאות

‫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.

שימוש במספר זרמים כדי למנוע חסימה של ראש התור

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

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

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

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

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

בנוסף, זה יכול להאט את הפענוח הלוגי. ההאטה נגרמת מעסקאות גדולות שגורמות לשינויים להישפך לדיסק, ואז נדרשת הרכבה מחדש איטית שצורכת הרבה פעולות קלט/פלט (I/O) עם ביצוע commit, מה שחוסם את השכפול של כל העסקאות הבאות. המלצה: במסד הנתונים של המקור, מגדירים את הפרמטרים 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 משתמש בעמודות שנרשמו ביומן בתור מפתח לוגי לפעולות של BigQuery MERGE. אם הערך של 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 רק בטבלאות ללא מזהה ייחודי. אם משכפלים ל-BigQuery, חשוב להיות מודעים להשפעה על הביצועים, למגבלה של 16 עמודות ולהגבלה על סוגי הנתונים הנתמכים עבור מפתחות ראשיים.

שכפול ממופעי קריאה משוכפלים

‫Datastream תומך בשכפול ממופעים של העתק לקריאה של PostgreSQL ל-PostgreSQL בגרסה 16 ואילך.

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

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

אחת הדרכים להגדיר פעימות לב תקופתיות היא ליצור משימת 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 כמקור כוללות:

  • הסטרימינג מוגבל ל-10,000 טבלאות.
  • אי אפשר לבצע מילוי חוזר של טבלה עם יותר מ-500 מיליון שורות, אלא אם מתקיימים התנאים הבאים:
    1. לטבלה יש אינדקס ייחודי של עץ B.
    2. האינדקס לא כולל עמודות מהסוגים הבאים: DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, סוגי נתונים מורכבים או סוגי נתונים גיאומטריים.
    3. אף אחת מהעמודות של האינדקס לא יכולה להכיל ערך null.
    4. כל העמודות של האינדקס הן בסדר עולה, או שכל העמודות של האינדקס הן בסדר יורד.
    5. כל העמודות של האינדקס נכללות בזרם.
  • בטבלאות ללא מפתחות ראשיים צריך להיות REPLICA IDENTITY. אחרת, רק אירועי INSERT משוכפלים ליעד.
  • בטבלאות עם מפתחות ראשיים, אי אפשר להגדיר את REPLICA IDENTITY לערך FULL או NOTHING. הערך חייב להיות DEFAULT.
  • לא כל השינויים בסכימת המקור ניתנים לזיהוי אוטומטי, ובמקרה כזה עלול להתרחש שיבוש בנתונים. השינויים הבאים בסכימה עלולים לגרום לפגם בנתונים או לכך שהמערכת לא תעבד את האירועים בהמשך:
    • הסרת עמודות.
    • הוספת עמודות באמצע הטבלה.
    • שינוי סוג הנתונים של עמודה.
    • שינוי סדר העמודות.
    • מחיקת טבלאות (רלוונטי אם אותה טבלה נוצרת מחדש עם נתונים חדשים).
  • ב-Datastream אין תמיכה בעמודות מסוגי הנתונים geometric.
  • ב-Datastream אין תמיכה בעמודות מסוגי הנתונים range.
  • ‫Datastream לא תומך במערכים של סוגי נתונים שלא נתמכים, במערכים של סוגי נתונים מוגדרים על ידי המשתמש (כולל ENUM) או במערכים של סוגי הנתונים DATE, ‏ TIMESTAMP או TIMESTAMP WITH TIME ZONE. המערכת מתעלמת מעמודות כאלה.
  • למקורות נתונים שנוצרו לפני 17 בפברואר 2026: מקור הנתונים לא תומך בשכפול של אירועי UPDATE בשורות שכוללות ערכי TOAST בעמודות שמהוות חלק מהזהות המשוכפלת של הטבלה. אירועים כאלה נפסלים. החריג הזה לא חל על שידורים חיים שנוצרו אחרי התאריך הזה.
  • הזרמת נתונים לא תומכת בשכפול שורות שכוללות ערכים של JSON או JSONB עם יותר מ-2,950 אובייקטים מוטמעים. אירועים שמכילים ערכים כאלה של JSON או JSONB לא משוכפלים למסד הנתונים של היעד.
  • הכלי Datastream לא תומך בשכפול שורות שכוללות ערכי NaN בעמודות NUMERIC (precision, scale). הערכים בעמודות כאלה מוחלפים בערכים NULL.
  • ב-Datastream אין תמיכה בשכפול עמודות מסוג הנתונים hstore. הערכים בעמודות כאלה מוחלפים בערכים NULL.
  • ‫Datastream לא תומך בשכפול רשומות שאינן ASCII ממסד נתונים של מקור שמקודד ב-SQL_ASCII. רשומות כאלה נמחקות.
  • ‫Datastream לא תומך בשכפול טבלאות עם כללי מדיניות של אבטחה ברמת השורה (RLS). מידע על דרכים לעקוף את המגבלה הזו זמין במאמר התנהגות ומגבלות של מקור PostgreSQL.
  • השינויים שבוצעו בעמודות שנוצרו לא נרשמים ב-Datastream.
  • יכול להיות שמקור הנתונים יפסיק לפעול או שלא יתעד אירועים חדשים אם מתבצע שדרוג של גרסה ראשית של PostgreSQL במסד הנתונים. מומלץ להסיר את משבצות השכפול לפני השדרוג, לשדרג את מסד הנתונים ואז ליצור מחדש את משבצות השכפול. אם הסטרימינג נכשל, צריך לשחזר את הסטרימינג על ידי ציון השם החדש של משבצת השכפול, ולבצע מילוי חוזר אם נדרשת עקביות נתונים.
  • ‫Datastream לא תומך בשכפול של טבלאות מערכת של PostgreSQL כשמשתמשים בתהליך ההגדרה האוטומטי של הזרם. אם עורכים את הזרם שנוצר באמצעות התהליך האוטומטי ומוסיפים טבלאות מערכת, Datastream מתעלם מהטבלאות האלה ולא משכפל מהן נתונים או שינויים.

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