אבחון בעיות

יכול להיות שיתרחשו שגיאות בשידור במהלך זמן הריצה.

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

כדי לפתור שגיאה, עוברים לזרם כדי לראות את השגיאה ופועלים לפי השלבים שמפורטים בהודעת השגיאה.

בדף הזה מופיע מידע על שגיאות בהגדרות, בקישוריות, ב-Oracle וב-MySQL, וגם שלבים לפתרון הבעיות.

שגיאות בהגדרות ובקישוריות

שגיאה	שלבים לפתרון בעיות
החיבור למסד הנתונים של המקור נכשל (כללי).	יכולות להיות לכך כמה סיבות. כדי לפתור את השגיאה: מוודאים שמסד הנתונים של המקור פועל ושאפשר לגשת אליו. עוברים לפרופיל של חיבור המקור מהדפים Streams או Connection profiles. מוודאים שפרטי הקישוריות בפרופיל החיבור נכונים. מוודאים ששם המשתמש והסיסמה תואמים. מוודאים ששם המשתמש קיים במסד הנתונים ושיש לו את ההרשאות הנדרשות. שומרים את השינויים שביצעתם בדף פרופילי חיבור. השידור יתחדש באופן אוטומטי.
החיבור למסד הנתונים של המקור נכשל (רשימת כתובות IP שאפשר להשתמש בהן).	זה יכול לקרות אם שיטת הקישור שנבחרה היא רשימת כתובות IP להיתר, אבל כתובת IP יוצאת אחת או יותר של Datastream לא נוספה בצורה תקינה למסד הנתונים של המקור. מוודאים שכתובות ה-IP היוצאות שמוצגות בפרופיל החיבור של Datastream מוגדרות בחומת האש של הרשת, כדי ששרת מסד הנתונים של המקור יוכל לקבל חיבורים מכתובות ה-IP האלה. אחרי שהבעיה תיפתר, השידור יתחדש אוטומטית.
החיבור למסד הנתונים של המקור נכשל (מנהרת SSH קדימה).	זה יכול לקרות אם יש בעיה במנהרת ה-SSH להעברת נתונים. בודקים את הסטטוס של המנהרה. אם המנהרה הופסקה, צריך להפעיל אותה. אחרי שהבעיה תיפתר, השידור יתחדש אוטומטית.
‫Datastream לא יכול להתחבר ליעד מבוצר (bastion host) דרך מנהרת SSH להעברת נתונים.	מוודאים שהגדרת מנהרת ה-SSH להעברה מוגדרת בצורה נכונה בפרופיל החיבור של המקור, ושהיציאה פתוחה בשרת מנהרת ה-SSH.
החיבור למסד הנתונים של המקור נכשל בגלל אישורים לא תקינים.	זה יכול לקרות אם יש בעיה באישורים שסופקו כשמגדירים את פרופיל חיבור המקור. עוברים לדף פרופילי חיבור ובוחרים את פרופיל החיבור הרצוי. מוודאים שהאישורים מוגדרים בצורה נכונה. אחרי שמבצעים את השינויים, שומרים את פרופיל החיבור והשידור מתחדש באופן אוטומטי.
החיבור למסד הנתונים של המקור נכשל בגלל בעיה בקישוריות הפרטית.	השגיאה הזו קשורה לשיטת הקישוריות הפרטית של קישור בין רשתות VPC שכנות (peering). חשוב לוודא שהשלמתם את כל התנאים המוקדמים תנאים מוקדמים ל-VPC peering. אחרי יצירת ההגדרה של הקישוריות הפרטית, מוודאים שהנתיב שמכיל את כתובת ה-IP הפנימית של מסד הנתונים מופיע בכרטיסייה Exported routes בדף VPC Network Peering. כדי לעשות את זה, עוברים לדף VPC Network Peering ומחפשים את ה-peering שנוסף (השם הוא peering-[UUID]). אפשר למצוא את המסלול בכרטיסייה Exported routes. אם המסלול הזה לא קיים, צריך להוסיף אותו ידנית. ב-Datastream לא מתבצעת בדיקה של חפיפה עם מסלולי ניתוב דינמיים של שירותי Peering. אספקת רשת משנה שחופפת לנתיב דינמי עלולה לגרום לבעיות בקישוריות. לכן, לא מומלץ להשתמש ברשת משנה שהיא חלק מניתוב דינמי. מוודאים שהמסלולים המותאמים אישית לטווחים של כתובות ה-IP של מקור הנתונים מפורסמים בצורה נכונה. אם המסלולים המותאמים אישית לא מופיעים, אפשר לעיין במאמר בנושא מסלולים מותאמים אישית שפורסמו. אם עדיין יש בעיות בחיבור למסד הנתונים של המקור, כדאי לעיין במאמר בנושא הגדרת פרוקסי הפוך.
החיבור למסד הנתונים של המקור נכשל באמצעות ממשק Private Service Connect.	חשוב לוודא שכל הדרישות המוקדמות הושלמו. מוודאים שכללי חומת האש מאפשרים לרשת המשנה של קובץ הרשת המצורף להתחבר למסד הנתונים של המקור. מוודאים שהמסלולים המותאמים אישית לטווחים של כתובות ה-IP של מקור הנתונים מפורסמים בצורה נכונה. אם המסלולים המותאמים אישית לא מופיעים, אפשר לעיין במאמר בנושא מסלולים מותאמים אישית שפורסמו.
סוג הקישוריות STATIC_SERVICE_IP_CONNECTIVITY לא מותר כשהאילוצים של מדיניות הארגון או datastream.disablePublicConnectivity מופעלים.	בחרתם בשיטות הציבוריות לרשימת כתובות ה-IP המותרות או למנהור SSH להעברה לקישוריות לרשת עבור פרופיל החיבור שאתם יוצרים. עם זאת, מדיניות הארגון Block Public Connectivity Methods (חסימת שיטות קישוריות ציבוריות) מופעלת ב-Datastream. לכן, אי אפשר לבחור שיטות קישוריות ציבוריות לפרופיל החיבור. כדי לפתור את הבעיה הזו, צריך לבחור את שיטת הקישוריות לרשת VPC peering או ממשקי Private Service Connect, או להשבית את מדיניות הארגון. כדי להשבית את מדיניות הארגון: עוברים לדף מדיניות הארגון במסוף Google Cloud . בוחרים את מדיניות הארגון Datastream - Block Public Connectivity Methods. לוחצים על עריכה. אם הלחצן עריכה מושבת, סימן שאין לכם את ההרשאות orgpolicy.policy.get ו-orgpolicy.policy.set לשנות את מדיניות הארגון הזו. מידע נוסף על קבלת ההרשאות האלה זמין במאמר הפניה להרשאות IAM . בקטע חל על בדף, בוחרים באפשרות התאמה אישית. בקטע Enforcement, בוחרים באפשרות Off. אם בוחרים באפשרות Off, אוסרים על אכיפת ההגבלה שמשויכת למדיניות הארגון הזו. אפשר להשתמש בשיטות קישוריות ציבוריות לפרופיל החיבור. לוחצים על SAVE. חוזרים לפרופיל החיבור של Oracle שיוצרים ולוחצים על יצירה. יכול להיות שיחלפו כמה דקות עד שהשינויים שביצעתם במדיניות הארגון ייכנסו לתוקף. בנוסף, למידע נוסף על מדיניות הארגון, אפשר לעיין במאמר מבוא לשירות של מדיניות הארגון.
כשמגדירים את מסד הנתונים של המקור לסטרימינג, אי אפשר למצוא ברשימת האובייקטים את הטבלאות והסכימות שרוצים להעביר.	זה יכול לקרות אם במסד הנתונים יש אלפי טבלאות וסכימות. יכול להיות שחלק מהם לא ייכללו ברשימת האובייקטים למשיכה כשמגדירים את המקור לזרם ב Google Cloud מסוף. במקום לבחור באפשרות סכימות וטבלאות ספציפיות בקטע בחירת אובייקטים להכללה, בוחרים באפשרות בהתאמה אישית. בשדה קריטריונים להתאמת אובייקטים, מזינים את הסכימות והטבלאות שרוצים ש-Datastream ישלוף.
הוספתי כמה טבלאות לשידור שלי באמצעות התפריט אובייקטים להוספה. עם זאת, כשמעיינים בכרטיסייה Objects בStream details, אפשר לראות שחסרות כמה טבלאות.	חשוב לוודא שיש לפחות עדכון CDC אחד לכל אחת מהטבלאות האלה, כדי ש-Datastream יוכל לזהות את השינויים ולכלול את הטבלאות בזרם באופן אוטומטי.
הטעינה של רשימת האובייקטים נכשלת כשמשתמשים בתפריט Objects to include במסוף Google Cloud .	זה יכול לקרות אם במסד הנתונים יש יותר מ-5,000 סכימות וטבלאות. אפשר להשתמש בשיטה אחרת כדי לציין אילו אובייקטים לכלול, או להשתמש ב-Datastream API. מידע נוסף זמין במאמר בנושא הגדרת מסדי נתונים של מקורות.
אירועים שהושמטו במהלך הסטרימינג ולא שוכפלו ביעד.	יכול להיות שאירועים שלא נתמכים יושמטו ממקור הנתונים במהלך העיבוד בסטרימינג. כדי לפתור את הבעיה, אפשר לבצע את הפעולות הבאות: מפעילים ידנית מילוי חוסרים של כל הטבלה. האפשרות הזו פועלת רק אם האירועים שהושלכו הם אירועים מסוג UPSERT. אם האירועים שהושמטו כוללים אירועי DELETE, צריך לחתוך את הטבלה ב-BigQuery לפני שמבצעים מילוי חוסרים. במאמר הפעלת מילוי חוסרים מוסבר איך לבצע מילוי חוסרים. פנו לתמיכה של Google ובקשו לבצע מילוי חלקי של שטחי הפרסום. אפשר לעשות את זה רק אם אתם יכולים לזהות את האירועים שהושמטו באמצעות פסקה של SQL‏ WHERE, ואם אף אחד מהאירועים לא מסוג DELETE. אפשר להתעלם מהבעיה אם מספר האירועים שהמערכת פסלה נמוך או אם האירועים האלה לא משמעותיים.
הזמן הקצוב פג במהלך הניסיון להתחבר למקור הנתונים. צריך לוודא שההגדרה של שם המארח והיציאה מדויקת ושיש גישה למקור הנתונים.	כשמשתמשים ב-VPC Peering, אי אפשר ליצור קישור ישיר בין רשת Datastream לבין רשת שירותים פרטיים (למשל, מופע Cloud SQL), ולכן צריך להשתמש במכונה וירטואלית (VM) של תרגום כתובות רשת (NAT) כדי ליצור קישוריות בין Datastream לבין המשאב. מידע נוסף על הגדרת מכונה וירטואלית של NAT זמין במאמר הגדרת קישור בין רשתות VPC.
הסכימה של האובייקט OBJECT_NAME גדולה מדי לעיבוד על ידי Datastream.	‫Datastream לא תומך בשכפול אירועים עם סכימות מקור תואמות שגדולות מ-2,621,440 תווים ב-Unicode. האירועים האלה מושמטים עם קוד הסיבה הבא: UNSUPPORTED_LARGE_SCHEMA. אולי תרצו להחריג חלק מהעמודות או לשנות את השמות שלהן. אפשרות אחרת היא להחריג את האובייקט עם הסכימה הגדולה.
מצב הסטרימינג השתנה.	יכולות להיות כמה סיבות לשגיאה הזו, אבל בעיה נפוצה שגורמת לה היא הגדרת מקור לא תקינה. אם השידור לא מתחיל ומוצגת הודעת השגיאה הזו, צריך לבדוק את הגדרות המקור כדי לוודא שאין מפתחות או שמות טבלאות כפולים, חוסר עקביות בנתונים או סכמות שמתנגשות. אפשר לפתור הרבה מהבעיות האלה על ידי עריכת ההגדרות של הזרם שנכשל ישירות במסוף Google Cloud והתאמת הערכים של האובייקטים שנכללים והאובייקטים שמוחרגים. מידע נוסף מופיע במאמר בנושא שינוי פרטי ההגדרה של מסד הנתונים של המקור.

שגיאות ב-Oracle

שגיאה	שלבים לפתרון בעיות
הגדרת הרישום המשני בבסיס הנתונים של המקור שגויה.	שגיאה באחזור נתונים שוטפים של תיעוד שינויים בנתונים (CDC) יכולה לקרות אם ההגדרה של תיעוד משלים לא נכונה במסד הנתונים של המקור. מוודאים שהרישום המשלים מוגדר בצורה נכונה. בפרט, צריך לוודא שהרישום המשלים ביומן מופעל עבור טבלאות מסד הנתונים שמוזרמות מהמקור ליעד. השידור יתחדש באופן אוטומטי.
אי אפשר להמשיך את השכפול כי מיקום היומן אבד.	השגיאה הזו יכולה להתרחש אם תהליך השכפול מושהה למשך זמן רב, מה שגורם לאובדן המיקום ביומן. אסור להשהות את הסטרימינג למשך תקופות שמתקרבות לתקופת השמירה של היומנים. יוצרים מחדש את מקור הנתונים.
חסרים קובצי יומן, באופן חלקי או מלא.	יכול להיות שקבצי היומן נמחקו. ‫Oracle מוחקת קובצי יומן ברגע שאפשר, אלא אם מציינים תקופת רוטציה מינימלית כדי לשמור אותם. בשרת Oracle, מגדירים את משך הזמן לשמירת קובצי היומן. לדוגמה, אפשר להשתמש בפקודה CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; כדי לשמור את קובצי היומן למשך 4 ימים לפחות. בפריסת RDS, משתמשים ב-exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);
רשימת ההחרגות כוללת את רשימת ההכללות.	רשימת ההכללה נכללת במלואה ברשימת ההחרגה, ולכן רשימת האובייקטים ש-Datastream שולף מהמקור ריקה. משנים את הבחירה באובייקט ומנסים שוב.
מצב הרישום ביומן של מסד הנתונים של Oracle לא מוגדר ל-ARCHIVELOG.	משנים את מצב הרישום ביומן ומנסים שוב.
‫Datastream מחזיר הודעת שגיאה ORA-00942: table or view does not exist, אבל הכול מוגדר בצורה תקינה.	יכול להיות שהבעיה נובעת משמירת נתונים במטמון בשרת Oracle. יצירה מחדש של משתמש מסד הנתונים אמורה לפתור את בעיית השמירה במטמון.
שינויים במקור Oracle לא משתקפים ביעד כשהזרם כבר פועל.	אם משתמשים ב-LogMiner כשיטת ה-CDC, ‏ Datastream קורא מקבצים של יומני Redo שנשמרו בארכיון. במקרה כזה, השינויים שתבצעו במקור לא ישתקפו ביעד עד שהיומן יועבר לארכיון. כדי לראות את השינויים ביעד, צריך לשנות את שיטת ה-CDC ל-binary log reader, לשנות את מדיניות הארכיון של היומן או להפעיל ידנית החלפת יומן. מידע נוסף זמין במאמר בנושא עבודה עם קובצי יומן Redo של מסד נתונים של Oracle.
אימות ההגדרות של Oracle CDC נכשל.	בחרתם שיטת CDC שלא הוגדרה עבור מסד הנתונים של המקור. בוחרים שיטה אחרת או משלימים את ההגדרה של שיטת ה-CDC. פרטים נוספים זמינים במאמר בנושא הגדרת מסד נתונים של Oracle כמקור.
אירעה שגיאה פנימית לא צפויה.	לפרטים נוספים, אפשר לפנות לתמיכה של Google.

שגיאות ב-MySQL

שגיאה	שלבים לפתרון בעיות
ההגדרה של Binlog במסד הנתונים של המקור שגויה.	זה יכול לקרות לזרמי MySQL רציפים אם ההגדרה של binlog במסד הנתונים של המקור שגויה. כדי לפתור את השגיאה, מבצעים את הפעולות הבאות: מוודאים שקובץ ה-binlog מוגדר בצורה נכונה. מוודאים שפורמט היומן הבינארי של מסד הנתונים MySQL מוגדר ל-ROW. מפעילים מחדש את השידור.
אי אפשר להמשיך את השכפול כי מיקום ה-binlog אבד.	השגיאה הזו יכולה להתרחש אם תהליך השכפול מושהה למשך זמן רב, מה שגורם לאובדן המיקום ב-binlog. אסור להשהות את הסטרימינג לתקופות שמתקרבות לתקופת השמירה של קובץ ה-binlog. יוצרים מחדש את מקור הנתונים.
הפעלת הזרם נכשלה בגלל גרסאות לא תואמות של מסד הנתונים של המקור ומסד הנתונים של היעד.	זה יכול לקרות אם מסד הנתונים של המקור לא תואם לטבלת התמיכה בגרסאות. כדי לפתור את השגיאה, מבצעים את הפעולות הבאות: מוודאים שמסד הנתונים של המקור עומד בדרישות של המטריצה. יוצרים מחדש את הזרם עם מסד הנתונים המעודכן של המקור.
קובצי ה-binlog של מקור AWS RDS MySQL חסרים, באופן חלקי או מלא.	יכול להיות שקבצי ה-binlog נמחקו. מערכת AWS RDS מוחקת את קובצי ה-binlog ברגע שאפשר, אלא אם מציינים תקופת רוטציה מינימלית כדי לשמור אותם. במופע המקור של AWS RDS MySQL, מגדירים את משך הזמן בשעות שבו צריך לשמור את קובצי ה-binlog. לדוגמה, אפשר להשתמש בערך mysql.rds_set_configuration('binlog retention hours', 168); כדי לשמור את קובצי ה-binlog למשך 7 ימים לפחות.
רשימת ההחרגות כוללת את רשימת ההכללות.	רשימת ההכללה נכללת במלואה ברשימת ההחרגה, ולכן רשימת האובייקטים ש-Datastream שולף מהמקור ריקה. משנים את הבחירה באובייקט ומנסים שוב.
אי אפשר לשכפל מסד נתונים של MySQL באמצעות Datastream.	מוודאים של-Datastream יש הרשאות לשכפל את מסד הנתונים.
כשיוצרים פרופיל חיבור למקור MySQL, אי אפשר להזין כמה אישורי SSL עם קידוד PEM בתפריט סוג ההצפנה.	‫Datastream לא תומך בשרשראות של אישורי SSL בפרופילים של חיבורים ל-MySQL. יש תמיכה רק באישורים יחידים בקידוד PEM מסוג x509.
זמן טעינה גבוה כשמבצעים סטרימינג ממקור MySQL.	להגדיל את היכולת של Datastream לקרוא ממסד הנתונים של המקור: מצמצמים את הגודל המקסימלי של קובץ יומן בינארי (binlog) במסד נתוני המקור. הקטנת הגודל מגדילה את מספר קובצי ה-binlog. אם יש כמה קובצי binlog, צריך להגדיר את המספר של משימות ה-CDC המקבילות המקסימליות לזרם בהתאם. אם יש כמה קובצי binlog,‏ Datastream יכול לקרוא אירועים ממסד הנתונים של המקור במקביל, עד למספר שמוגדר בשדה maxConcurrentCdcTasks.
האימות של הגדרת ה-CDC של MySQL נכשל.	מסד הנתונים של המקור לא הוגדר לשיטת ה-CDC שבחרתם. בוחרים שיטה אחרת או משלימים את ההגדרה של שיטת ה-CDC. מידע נוסף על הגדרת מסד נתונים של MySQL כמקור
אירעה שגיאה פנימית לא צפויה.	לפרטים נוספים, אפשר לפנות לתמיכה של Google.

שגיאות ב-PostgreSQL

שגיאה	שלבים לפתרון בעיות
הפענוח הלוגי מוגדר בצורה שגויה במסד הנתונים של המקור.	מוודאים שהפענוח הלוגי מוגדר בצורה נכונה. איך מגדירים מסד נתונים של PostgreSQL כמקור
משבצת השכפול לא קיימת.	שגיאה באחזור נתונים שוטפים של סימון נתונים שהשתנו (CDC) יכולה לקרות אם משבצת השכפול לא קיימת במסד הנתונים. מוודאים שמשבצת השכפול מוגדרת בצורה נכונה. איך מגדירים מסד נתונים של PostgreSQL כמקור
משבצת השכפול מוגדרת עם תוסף שגוי.	השגיאה הזו יכולה להתרחש אם משבצת השכפול מוגדרת עם פלאגין ששונה מ-pgoutput. מוודאים שמשבצת השכפול מוגדרת בצורה נכונה. מידע נוסף זמין במאמר בנושא מסד נתונים של PostgreSQL כמקור.
משבצת השכפול פעילה בתהליך אחר.	השגיאה הזו יכולה להתרחש אם משתמשים במשבצת השכפול בתהליך אחר. אפשר להשתמש במשבצות שכפול רק בתהליך אחד בכל פעם. חשוב לוודא שלא משתמשים באותו משבצת שכפול בשום תהליך אחר מלבד Datastream.
יש בעיה בהגדרה של אתר החדשות.	השגיאה הזו יכולה להתרחש כשהפרסום לא מוגדר לחשיפת הטבלאות שכלולות בהגדרת הסטרים. מוודאים שהגדרתם את אתר החדשות בצורה נכונה. איך מגדירים מידע על מסד הנתונים של המקור עבור הזרם
אתר החדשות לא קיים.	השגיאה הזו יכולה להתרחש אם אתר החדשות לא קיים במסד הנתונים. מוודאים שהגדרתם את אתר החדשות בצורה נכונה. איך מגדירים מסד נתונים של PostgreSQL כמקור
אי אפשר להמשיך את השכפול כי קובצי ה-WAL אבדו.	השגיאה הזו יכולה להתרחש כשתהליך השכפול מושהה למשך זמן רב, מה שגורם לאובדן של קובצי WAL. אין להשהות את הסטרימינג לתקופות שמתקרבות לתקופת השמירה של קובצי ה-WAL. יוצרים מחדש את מקור הנתונים.
רשימת ההחרגות כוללת את רשימת ההכללות.	רשימת ההכללה נכללת במלואה ברשימת ההחרגה, ולכן רשימת האובייקטים ש-Datastream שולף מהמקור ריקה. משנים את הבחירה באובייקט ומנסים שוב.
‫Datastream לא יכול לשכפל סכימה של PostgreSQL.	מוודאים של-Datastream יש הרשאות לשכפל את הסכימה.
עסקאות גדולות במסד הנתונים של המקור גורמות לבעיות בשכפול ובסנכרון של הנתונים.	אם מוסיפים, מעדכנים או מוחקים מספר משמעותי של רשומות במסד הנתונים של המקור, יכול להיות שמשבצת השכפול תהיה עמוסה מדי באירועים המתאימים. למקור הנתונים לוקח זמן לקרוא ולעבד את האירועים האלה. מכיוון שמשבצות רפליקציה של PostgreSQL הן בעלות תהליך יחיד, העיבוד של שינויים אחרים במשבצת הרפליקציה, כולל שינויים בנתונים בטבלאות אחרות, מתעכב עד ש-Datastream ישלים את כל השינויים במשבצת הרפליקציה.
עסקאות גדולות במסד הנתונים של המקור גורמות לתפוקה נמוכה של CDC.	‫Datastream לא תומך ב-CDC מרובה-הליכי משנה ב-PostgreSQL. כדי לעקוף את המגבלה הזו ולהגדיל את קצב העברת הנתונים של ה-CDC, אפשר לפצל את המקור לכמה זרמים, שלכל אחד מהם יש חריץ פרסום ושכפול משלו. לדוגמה, אפשר ליצור מקור נתונים אחד לטבלה הגדולה ביותר במסד הנתונים ומקור נתונים אחר לכל שאר הטבלאות, או מקור נתונים אחד לטבלאות בעדיפות הגבוהה ביותר ומקור נתונים אחר לכל שאר הטבלאות. תרחישי השימוש עשויים להיות שונים, ולכן צריך לשקול מה הכי הגיוני בתרחיש ה-CDC הספציפי שלכם. מידע על יצירת פרסום זמין במאמר הגדרת מסד נתונים של PostgreSQL כמקור.
אירועים לא נתמכים הוסרו עם קוד הסיבה: BIGQUERY_TOO_MANY_PRIMARY_KEYS.	כשהזהות של העותק המשוכפל של PostgreSQL עבור טבלה מוגדרת ל-FULL, ‏ Datastream מתייחס לכל העמודות בטבלה הזו כמפתחות ראשיים. אם יש יותר מ-16 עמודות בטבלה, זה מפר את המגבלה של BigQuery CDC וגורם לשגיאה. כדי לפתור את הבעיה, מבצעים את השלבים הבאים: משנים את זהות הרפליקה ל-DEFAULT: ‫ ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT מחליפים את TABLE_NAME בשם הטבלה שרוצים לשנות את זהות העותק שלה. מסירים את הטבלה מרשימת האובייקטים של הזרם שרוצים לכלול. מידע נוסף מופיע במאמר בנושא שינוי פרטי ההגדרה של מסד הנתונים של המקור. מוחקים את הטבלה מ-BigQuery. מידע נוסף מופיע במאמר מחיקת טבלאות. ב-Datastream, מוסיפים שוב את הטבלה למקור הנתונים על ידי עריכת הגדרת המקור.
אירעה שגיאה פנימית לא צפויה.	לפרטים נוספים, אפשר לפנות לתמיכה של Google.

שגיאות ב-SQL Server

שגיאה	שלבים לפתרון בעיות
התכונה CDC מושבתת במסד הנתונים DATABASE_NAME.	צריך להפעיל את התכונה 'לכידת שינויי נתונים' (CDC) במסד הנתונים. ל-Datastream צריכה להיות גישת קריאה ישירה ליומני העסקאות כדי לשכפל שינויים בזמן אמת במסד הנתונים של המקור, וכדי לקבל מידע מלא על היומנים. צריך להפעיל את CDC במסד הנתונים ולנסות שוב. מידע על הפעלת CDC במסד נתונים זמין במאמר הגדרת מסד נתונים של SQL Server כמקור.
טבלאות שבהן ה-CDC מושבת.	צריך להפעיל את התכונה 'לכידת שינויי נתונים' (CDC) בכל הטבלאות שכלולות בזרם. כדי לשכפל שינויים בזמן אמת בטבלאות המקוריות וכדי לקבל מידע מלא על היומנים, ל-Datastream צריכה להיות גישת קריאה ישירה ליומני העסקאות. מפעילים את CDC עבור הטבלאות שכלולות בזרם ומנסים שוב. במאמר הגדרת מסד נתונים של SQL Server כמקור מוסבר איך מפעילים את ה-CDC בטבלאות המקור.
חסרות הרשאות.	ל-Datastream חסרות ההרשאות הנדרשות לקריאה מהמקור. צריך להעניק את ההרשאות המתאימות לחשבון המשתמש שמשמש לחיבור למסד הנתונים, ולנסות שוב.
אין תמיכה במהדורת SQL Server EDITION_NAME.	‫Datastream לא תומך במהדורה הזו של SQL Server. מידע נוסף על מהדורות נתמכות של SQL Server זמין במאמר סקירה כללית על SQL Server כמקור.
אין תמיכה בגרסה VERSION_NAME של SQL Server במהדורת Standard.	‫Datastream לא תומך בגרסה הזו של מהדורת SQL Server Standard. מידע נוסף על גרסאות נתמכות של SQL Server זמין במאמר סקירה כללית של SQL Server כמקור.
הזרם לא יכול לקרוא את האירוע ב-LSN ‏ "YOUR_LSN" כי נראה שיומן העסקאות נחתך.	הבעיה הזו יכולה להתרחש אם יומני העסקאות כבר לא קיימים במסד הנתונים של המקור. כשמשכפלים נתונים ממקור SQL Server באמצעות שיטת ה-CDC של יומני העסקאות, יכול להיות שהיומנים ייחתכו לפני ש-Datastream יקרא אותם. במקרה כזה, Datastream לא יכול לשכפל את מסד הנתונים של המקור ליעד בצורה מהימנה. כדי לפתור את הבעיה, צריך לשחזר את הזרם או להשתמש בשיטת ה-CDC של טבלאות השינויים במקום זאת. מידע נוסף על ההבדלים בין שתי השיטות זמין במאמר סקירה כללית של SQL Server כמקור.
ההגדרה של SQL Server CDC נכשלה.	שיטת ה-CDC שבחרתם לא תואמת להגדרת מסד הנתונים. צריך לשנות את שיטת ה-CDC ולנסות שוב.

שגיאות ב-Salesforce

שגיאה	שלבים לפתרון בעיות
אין מספיק הרשאות.	למשתמש באפליקציה המקושרת או באפליקציית הלקוח החיצונית שהגדרתם לאימות החיבור בין הארגון שלכם ב-Salesforce לבין Datastream אין הרשאות מספיקות לגישה לנתונים שאתם רוצים לשכפל. מוודאים שהגדרתם את מקור Salesforce בצורה נכונה. מידע נוסף זמין במאמר הגדרת מקור Salesforce.
‫Bulk API 2.0 מושבת.	‫Bulk API 2.0 מופעל כברירת מחדל במהדורות Performance, ‏ Unlimited, ‏ Enterprise ו-Developer. הודעת השגיאה הזו מציינת שה-API מושבת במהדורה שלכם, או שאין לפרטי הכניסה שבהם אתם משתמשים הרשאות מספיקות. מוודאים שלפרופיל המשתמש שבו אתם משתמשים יש הרשאה API Enabled.
יש חריגה מהמגבלה.	חרגתם ממגבלת השאילתות של Salesforce API. ההודעה הזו מוצגת כשמגיעים ל-90% ממכסת השימוש ב-API. במקרה כזה, Datastream ינסה שוב לבצע את הפעולה במועד מאוחר יותר. מומלץ להגדיל את מכסת Salesforce API.
חריגה ממגבלת המחיקה.	כשמבצעים שאילתה לגבי רשומות שנמחקו, Salesforce מגבילה את התגובה ל-600,000 מזהי רשומות. הגרנולריות הכי נמוכה של שאילתות ב-Salesforce היא דקה אחת, ואם מוחקים יותר מ-600,000 רשומות בתוך דקה, Salesforce מחזירה את השגיאה הזו.
שגיאת אימות.	ל-Datastream אין הרשאת אימות ב-Salesforce. כנראה שהשתמשתם בפרטי הכניסה או בשם הדומיין הלא נכונים.

שגיאות ב-MongoDB

שגיאה	שלבים לפתרון בעיות
האימות נכשל.	צריך לבדוק אם המשתמש של Datastream הוא authSource.admin צריך ליצור את המשתמש ב-Datastream במסד הנתונים admin. מסד הנתונים הזה הוא מסד נתונים עם הרשאות מיוחדות שמאפשר למשתמשים להריץ פקודות ניהול מסוימות.
הכניסה למסד הנתונים נכשלה.	צריך לבדוק את שם המשתמש והסיסמה ולנסות שוב. בנוסף, צריך לוודא שחשבון המשתמש שלכם נוצר במסד הנתונים של admin. אם הבעיה נמשכת, יכול להיות שחשבון המשתמש שלכם נמחק או נוצר בצורה שגויה.
רשימת האובייקטים שהוחרגו לא תקינה: {exclude_list}.	מציינים את האובייקטים שרוצים להחריג בפורמט הבא: DATABASE_NAME.COLLECTION_NAME.FIELD_NAME.NESTED_FIELD_NAME עם תווים כלליים אופציונליים. דוגמאות לערכים תקינים: db.*, ‏ database.collection.*, ‏ database.*.field.*.
חסרות לנו ההרשאות הנדרשות לקריאה מהמקור.	מקצים למשתמש את התפקיד readAnyDatabase ומנסים שוב.
אין תמיכה בגרסה VERSION_NAME של MongoDB.	צריך להשתמש בגרסה 5.0 ואילך.
מקור הנתונים לא הצליח להריץ את הפקודה buildinfo כדי לקבוע את הגרסה של MongoDB.	צריך לוודא שלמשתמש יש את ההרשאות הנדרשות להפעלת הפקודה buildinfo ולנסות שוב. מידע נוסף על ההרשאות הנדרשות זמין במאמר הגדרת מסד נתונים של MongoDB.
פג הזמן הקצוב של החיבור לאשכול MongoDB.	צריך לוודא שהזנתם את שם המארח ואת פרטי הכניסה הנכונים ולנסות שוב.
אין לנו אפשרות לקרוא את הנתונים הנדרשים כי ההרשאות לא מספיקות.	מקצים את התפקיד readAnyDatabase לחשבון שמשמש לחיבור לאשכול MongoDB, ומנסים שוב.
חשבון המשתמש שמשמש לחיבור לאשכול MongoDB לא קיים.	צריך ליצור את חשבון המשתמש ולנסות שוב.
לא הצלחנו להתחבר באמצעות הפרטים שסיפקת.	צריך לוודא שנעשה שימוש בפורמט החיבור הנכון (SRV או Standard) ושהמידע הנדרש (כמו שמות של קבוצות שכפול למחרוזת חיבור של קבוצת שכפול) כלול. מידע נוסף זמין במאמר יצירת פרופיל חיבור למסד נתונים של MongoDB.
נתקלנו בחריגה ב-MongoDB. הודעת השגיאה במקור: {source_error}.	אם הודעת השגיאה במקור לא ברורה, אפשר לפנות לתמיכה של Google.

שגיאות ב-Spanner

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

שגיאות ב-BigQuery

שגיאה	שלבים לפתרון בעיות
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported.	אם המפתח הראשי משתנה במקור, צריך להסיר את הטבלה ב-BigQuery ולהפעיל שוב מילוי נתונים חסרים. זו מגבלה של BigQuery, כי אין דרך להבטיח מיזוג נכון של אירועים חדשים עם שורות קיימות אם המפתח הראשי שונה. מידע נוסף זמין במאמר בנושא הגדרת יעד ב-BigQuery.
בטבלה ב-BigQuery של היעד יש הרבה יותר רשומות מאשר בטבלת המקור.	מצב כזה יכול לקרות אם בטבלת המקור אין מפתח ראשי. במקרה כזה, Datastream מעבד את הטבלה במצב כתיבה של הוספה בלבד, וכל אירוע בשורה נתונה מופיע כשורה נפרדת ב-BigQuery.
הנתונים משוכפלים כשמבצעים מילוי חוסרים במצב כתיבה Append-only.	כשבוחרים במצב הכתיבה Append-only (הוספה בלבד) לזרם, הנתונים מתווספים ב-BigQuery כזרם של אירועים מסוג INSERT, UPDATE-INSERT, UPDATE-DELETE ו-DELETE, ללא איחוד. יכול להיות שבמקרים כאלה, כשמבצעים מילוי חוזר או כשמתרחשת בעיה והכלי לכתיבה ב-BigQuery מנסה שוב את פעולות הכתיבה, שורות כפולות ייכתבו ב-BigQuery. כדי לפתור את הבעיה, מומלץ להריץ באופן קבוע שאילתת ביטול כפילויות שדומה לשאילתה הבאה: SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
הכלי Datastream מוגדר למצב כתיבה של מיזוג, אבל השינויים לא ממוזגים ב-BigQuery.	מוודאים שיש מפתח ראשי בטבלת המקור. הוא נדרש ל-BigQuery כדי למזג את השינויים בטבלת היעד. אילוץ UNIQUE לא עומד בדרישה PRIMARY KEY למיזוג אירועים. אם אין מפתח ראשי, כדאי להוסיף אחד בטבלת המקור או בטבלת היעד. כדי להוסיף מפתח ראשי לטבלת היעד ב-BigQuery, פועלים לפי השלבים הבאים: משהים את השידור. מבצעים חיתוך של הטבלה ב-BigQuery. מוסיפים את המפתח הראשי להגדרת הטבלה. המשך השידור. הפעלת מילוי חוסרים בטבלה.
אי אפשר להוסיף מפתח ראשי, להסיר מפתח ראשי או לשנות את ההגדרה של מפתח ראשי בטבלה שכבר משוכפלת ל-BigQuery.	כברירת מחדל, Datastream לא תומך בהוספת מפתח ראשי לטבלה שכבר משוכפלת ל-BigQuery ללא מפתח ראשי, או בהסרת מפתח ראשי מטבלה שמשוכפלת ל-BigQuery עם מפתח ראשי. עם זאת, אפשר לשנות את ההגדרה של המפתח הראשי בטבלת מקור שמשוכפלת ל-BigQuery וכבר יש לה מפתח ראשי: בודקים את מדד ההשהיה הכוללת של הסטרימינג וממתינים לפחות למשך ההשהיה הנוכחית כדי לוודא שכל האירועים שנמצאים בתהליך ייכתבו ליעד. כך אפשר להזרים בהצלחה את כל האירועים עם המפתח הראשי המקורי. להשהות את השידור. מעתיקים את הפקודה CREATE TABLE של שפת הגדרת הנתונים (DDL) לטבלה ב-BigQuery: SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES WHERE table_name='TABLE_NAME'; מחליפים את מה שכתוב בשדות הבאים: ‫PROJECT_ID: המזהה של הפרויקט ב- Google Cloud . ‫DATASET_ID: המזהה של מערך הנתונים ב-BigQuery. ‫TABLE_NAME: השם של הטבלה שרוצים להעתיק את פקודת ה-DDL שלה. מחיקת הטבלה ב-BigQuery. משנים את פקודת ה-DDL‏ CREATE TABLE עם המפתחות הראשיים החדשים. צריך לכלול את מפתחות המחיצה והאשכול, ואת max_staleness OPTION: CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]` ( product_id INT64 NOT NULL, product_name STRING, datastream_metadata STRUCT, PRIMARY KEY (product_id) NOT ENFORCED ) CLUSTER BY dept_no OPTIONS( max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND ); ; מחליפים את מה שכתוב בשדות הבאים: ‫PROJECT_ID: המזהה של הפרויקט ב- Google Cloud . ‫DATASET_ID: המזהה של מערך הנתונים ב-BigQuery. ‫TABLE_NAME: השם של הטבלה שהעתקתם את פקודת ה-DDL שלה. ‫MINS: מספר הדקות שרוצים להגדיר לאפשרות max_staleness, לדוגמה 15. מריצים את השאילתה המותאמת כדי ליצור מחדש את הטבלה ב-BigQuery. המשך השידור. הפעלת מילוי חוסרים בטבלה.

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

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