אבחון בעיות

אם מתרחשת שגיאת זמן ריצה ב-Datastream, אפשר לראות את הפרטים בדף Streams או בדף Stream details במסוף Google Cloud . אפשר גם לאחזר מידע על אבחון באמצעות Datastream API. חלק מהבעיות, כמו סיסמה לא חוקית, ניתנות לשחזור, והשכפול ממשיך באופן אוטומטי אחרי שמתקנים אותן. שגיאות אחרות משפיעות על אובייקט אחד, כמו סוג נתונים שלא נתמך, או מפסיקות את הסטרימינג כש-Datastream לא מצליח להתחבר למקור.

כדי לפתור בעיה, בודקים את הודעת השגיאה ופועלים לפי השלבים לפתרון שגיאות שקשורות להגדרות, לקישוריות, למקור או ליעד ב-BigQuery.

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

שגיאה	שלבים לפתרון בעיות
החיבור למסד הנתונים של המקור נכשל (כללי).	יכולות להיות לכך כמה סיבות. כדי לפתור את השגיאה: מוודאים שמסד הנתונים של המקור פועל ונגיש. עוברים לפרופיל החיבור של המקור מהדפים Streams או Connection profiles. מוודאים שפרטי הקישוריות של פרופיל החיבור נכונים. מוודאים ששם המשתמש והסיסמה תואמים. מוודאים ששם המשתמש קיים במסד הנתונים ושיש לו את ההרשאות הנדרשות. שומרים את השינויים שבוצעו בדף Connection profiles. השידור יתחדש באופן אוטומטי.
החיבור למסד הנתונים של המקור נכשל (הוספת כתובות IP לרשימת ההיתרים).	זה יכול לקרות אם שיטת הקישור שנבחרה היא רשימת היתרים של כתובות IP, אבל אחת או יותר מכתובות ה-IP היוצאות של Datastream לא נוספו כמו שצריך למסד הנתונים של המקור. מוודאים שכתובות ה-IP היוצאות שמוצגות בפרופיל החיבור של Datastream מוגדרות בחומת האש של הרשת, כדי ששרת מסד הנתונים של המקור יוכל לקבל חיבורים מכתובות ה-IP האלה. אחרי שהבעיה תתוקן, השידור יתחדש באופן אוטומטי.
החיבור למסד הנתונים של המקור נכשל (מנהרת SSH להעברה).	זה יכול לקרות אם יש בעיה במנהרת ה-SSH להעברה. בודקים את הסטטוס של המנהרה. אם המנהרה נעצרה, צריך להפעיל אותה. אחרי שהבעיה תתוקן, השידור יתחדש באופן אוטומטי.
‫Datastream לא יכול להתחבר ליעד מבוצר באמצעות מנהרת SSH להעברה.	מוודאים שההגדרה של מנהרת ה-SSH להעברה מוגדרת בצורה נכונה בפרופיל החיבור של המקור, ושהיציאה פתוחה בשרת של מנהרת ה-SSH.
החיבור למסד הנתונים של המקור נכשל בגלל אישורים לא תקינים.	זה יכול לקרות אם יש בעיה באישורים שסופקו כשפרופיל החיבור של המקור הוגדר. עוברים לדף Connection profiles ובוחרים את פרופיל החיבור הרצוי. מוודאים שהאישורים מוגדרים בצורה נכונה. אחרי שמבצעים את השינויים, שומרים את פרופיל החיבור והשידור ממשיך באופן אוטומטי.
החיבור למסד הנתונים של המקור באמצעות קישוריות פרטית נכשל.	השגיאה הזו קשורה לשיטת הקישוריות הפרטית של קישור בין רשתות VPC שכנות (peering). מוודאים שהשלמתם את כל הדרישות המוקדמות של קישור VPC בין רשתות שכנות (peering). אחרי שיוצרים את הגדרת הקישוריות הפרטית, מוודאים שהמסלול שמכיל את כתובת ה-IP הפנימית של מסד הנתונים מופיע בכרטיסייה Exported routes בדף VPC Network Peering. כדי לעשות את זה, נכנסים לדף VPC Network Peering ומחפשים את הקישור שנוסף (השם שלו הוא peering-[UUID]). הנתיב נמצא בכרטיסייה Exported routes. אם הנתיב הזה לא קיים, צריך להוסיף אותו ידנית. ‫Datastream לא בודק אם יש חפיפה עם נתיבי קישור דינמיים. אם תספקו רשת משנה שחופפת למסלול דינמי, עלולות להיווצר בעיות בקישוריות. לכן, לא מומלץ להשתמש ברשת משנה שהיא חלק מנתיב דינמי. חשוב לוודא שהנתיבים בהתאמה אישית של טווחי כתובות ה-IP של Datastream מפורסמים בצורה נכונה. אם חסרים נתיבים בהתאמה אישית, קראו את המאמר נתיבים מפורסמים בהתאמה אישית. אם עדיין יש בעיות בחיבור למסד הנתונים של המקור, עיינו במאמר הגדרת שרת proxy הפוך.
לא הצלחנו להתחבר למסד הנתונים של המקור באמצעות ממשק Private Service Connect.	מוודאים שכל הדרישות המוקדמות הושלמו. חשוב לוודא שהכללים של חומת האש מאפשרים לרשת המשנה של מחבר הרשת שצוין להתחבר למסד הנתונים של המקור. חשוב לוודא שהנתיבים בהתאמה אישית של טווחי כתובות ה-IP של Datastream מפורסמים בצורה נכונה. אם חסרים נתיבים בהתאמה אישית, קראו את המאמר נתיבים מפורסמים בהתאמה אישית.
אי אפשר להשתמש בסוג הקישוריות STATIC_SERVICE_IP_CONNECTIVITY כשהאילוץ datastream.disablePublicConnectivity של מדיניות הארגון מופעל.	בחרתם בשיטות הקישוריות לרשת רשימת היתרים של כתובות IP ציבוריות או מנהרת SSH להעברה לפרופיל החיבור שאתם יוצרים. עם זאת, מדיניות הארגון Block Public Connectivity Methods של Datastream מופעלת. לכן, אי אפשר לבחור שיטות קישוריות ציבוריות לפרופיל החיבור. כדי לפתור את הבעיה, צריך לבחור בשיטת הקישוריות לרשת קישור בין רשתות VPC שכנות (peering) או ממשקי Private Service Connect, או להשבית את מדיניות הארגון. כדי להשבית את מדיניות הארגון: נכנסים לדף Organization policies במסוף Google Cloud . בוחרים את מדיניות הארגון Datastream - Block Public Connectivity Methods. לוחצים על עריכה. אם הלחצן EDIT מושבת, אין לכם את ההרשאות orgpolicy.policy.get ו-orgpolicy.policy.set שנדרשות כדי לשנות את מדיניות הארגון הזו. למידע נוסף על קבלת ההרשאות האלה, ראו הפניה להרשאות IAM . בקטע חל על בדף, לוחצים על התאמה אישית. בקטע אכיפה, לוחצים על השבתה. אם בוחרים באפשרות Off, משביתים את אכיפת האילוץ שמשויך למדיניות הארגון הזו. אפשר להשתמש בשיטות קישוריות ציבוריות לפרופיל החיבור. לוחצים על SAVE. חוזרים לפרופיל החיבור של Oracle שאתם יוצרים ולוחצים על CREATE. יכול להיות שיעברו כמה דקות עד שהשינויים שביצעתם במדיניות הארגון ייכנסו לתוקף. למידע נוסף על מדיניות הארגון, קראו את המאמר מבוא לשירות מדיניות הארגון.
כשאני מגדיר את מסד הנתונים של המקור לסטרימינג, אני לא מוצא את הטבלאות והסכימות שאני רוצה להעביר ברשימת האובייקטים שצריך לכלול.	זה יכול לקרות אם במסד הנתונים יש אלפי טבלאות וסכימות. יכול להיות שחלק מהם לא ייכללו ברשימת האובייקטים שצריך לשלוף כשמגדירים את המקור של הסטרימינג במסוף Google Cloud . במקום לבחור באפשרות Specific schemas and tables בקטע Select objects to include, בוחרים באפשרות Custom. בשדה Object matching criteria, מזינים את הסכימות והטבלאות שרוצים ש-Datastream ישלוף.
הוספתי כמה טבלאות לסטרימינג באמצעות התפריט Objects to include. עם זאת, כשאני מסתכל בכרטיסייה Objects בקטע Stream details, אני רואה שחלק מהטבלאות חסרות.	חשוב לוודא שיש לפחות עדכון CDC אחד לכל אחת מהטבלאות האלה, כדי ש-Datastream יוכל לזהות את השינויים ולכלול את הטבלאות בסטרים באופן אוטומטי.
רשימת האובייקטים לא נטענת כשמשתמשים בתפריט Objects to include במסוף Google Cloud .	זה יכול לקרות אם במסד הנתונים יש יותר מ-5,000 סכימות וטבלאות. צריך להשתמש בשיטה אחרת כדי לציין אילו אובייקטים לכלול, או להשתמש ב-Datastream API. מידע נוסף זמין במאמר הגדרת מסדי נתונים של מקורות.
אירועים שהושמטו במהלך הסטרימינג ולא שוכפלו ביעד.	יכול להיות ש-Datastream יסיר אירועים לא נתמכים במהלך הסטרימינג. כדי לפתור את הבעיה, אתם יכולים לבצע את הפעולות הבאות: להפעיל באופן ידני מילוי חוסרים של כל הטבלה. זה עובד אם האירועים שנמחקו הם אירועי UPSERT בלבד. אם האירועים שהושמטו כוללים אירועים מסוג DELETE, צריך לחתוך את הטבלה ב-BigQuery לפני שמבצעים את מילוי החוסרים. במאמר התחלת מילוי חוסרים מוסבר איך לבצע מילוי חוסרים. פונים לתמיכה של Google ומבקשים לבצע מילוי חלקי. זה אפשרי רק אם אתם יכולים לזהות את האירועים שהושמטו באמצעות משפט WHERE ב-SQL, ואם אף אחד מהאירועים הוא לא אירוע DELETE. אם מספר האירועים שנמחקו נמוך או אם האירועים שנמחקו לא משמעותיים, אפשר להתעלם מהבעיה.
הזמן הקצוב פג במהלך הניסיון להתחבר למקור הנתונים. צריך לוודא שהגדרת שם המארח והיציאה מדויקת, ושאפשר לגשת למקור הנתונים.	כשמשתמשים בקישור בין רשתות VPC שכנות (peering), אי אפשר לקשר ישירות בין רשת Datastream לבין רשת שירותים פרטית (לדוגמה, מכונה של Cloud SQL). לכן צריך להשתמש במכונה וירטואלית של תרגום כתובת רשת (NAT) כדי ליצור קישוריות בין Datastream לבין המשאב. מידע נוסף על הגדרת מכונה וירטואלית של NAT זמין במאמר הגדרת קישור VPC בין רשתות שכנות (peering).
הסכימה של האובייקט 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 לקורא יומנים בינאריים, לשנות את מדיניות ארכיון היומנים או לאלץ החלפת יומן באופן ידני. מידע נוסף זמין במאמר עבודה עם קובצי יומן 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 במקור, מגדירים את משך הזמן בשעות שבו צריך לשמור את ה-binlogs. לדוגמה, אפשר להשתמש ב-mysql.rds_set_configuration('binlog retention hours', 168); כדי לשמור את יומני ה-binlog למשך 7 ימים לפחות.
רשימת ההחרגות כוללת את רשימת ההכללות.	רשימת ההכללה נמצאת כולה בתוך רשימת ההחרגה, ולכן רשימת האובייקטים ש-Datastream שולף מהמקור ריקה. משנים את בחירת האובייקטים ומנסים שוב.
‫Datastream לא יכול לשכפל מסד נתונים של MySQL.	מוודאים של-Datastream יש הרשאות לשכפל את מסד הנתונים.
כשיוצרים פרופיל חיבור למקור MySQL, אי אפשר להזין כמה אישורי SSL בקידוד PEM בתפריט Encryption type.	‫Datastream לא תומך בשרשראות של אישורי SSL בפרופילים של חיבורי MySQL. יש תמיכה רק באישור יחיד בקידוד x509 PEM.
זמן אחזור ארוך בסטרימינג ממקור MySQL.	מגדילים את היכולת של Datastream לקרוא ממסד הנתונים של המקור: מקטינים את הגודל המקסימלי של קובץ היומן הבינארי (binlog) במסד הנתונים של המקור. הקטנת הגודל מגדילה את מספר קובצי ה-binlog. אם יש כמה קובצי binlog, מגדירים בהתאם את המספר המקסימלי של משימות CDC מקבילות לסטרימינג. כשיש כמה קובצי binlog, ‏Datastream יכול לקרוא אירועים ממסד הנתונים של המקור בו-זמנית, עד למספר שמוגדר בשדה maxConcurrentCdcTasks.
אימות ההגדרות של MySQL CDC נכשל.	מסד הנתונים של המקור לא הוגדר לשיטת ה-CDC שבחרתם. בוחרים שיטה אחרת או משלימים את ההגדרה של שיטת ה-CDC. פרטים נוספים זמינים במאמר הגדרת מסד נתונים של MySQL כמקור.
יש שגיאה פנימית לא צפויה.	לפרטים נוספים, אפשר לפנות לתמיכה של Google.

שגיאות ב-PostgreSQL

שגיאה	שלבים לפתרון בעיות
הפענוח הלוגי מוגדר באופן שגוי במסד הנתונים של המקור.	מוודאים שהפענוח הלוגי מוגדר בצורה נכונה. הגדרת מסד נתונים של PostgreSQL כמקור
משבצת הרפליקציה לא קיימת.	אם משבצת הרפליקציה לא קיימת במסד הנתונים, יכולה להתרחש שגיאה באחזור נתונים שוטפים של סימון נתונים שהשתנו (CDC). מוודאים שמשבצת השכפול מוגדרת בצורה נכונה. הגדרת מסד נתונים של PostgreSQL כמקור
משבצת השכפול מוגדרת עם פלאגין שגוי.	השגיאה הזו יכולה להתרחש אם משבצת הרפליקציה מוגדרת עם פלאגין שונה מ-pgoutput. מוודאים שמשבצת השכפול מוגדרת בצורה נכונה. מידע נוסף זמין במאמר מסד נתונים של PostgreSQL במקור.
משבצת השכפול פעילה בתהליך אחר.	השגיאה הזו יכולה להתרחש כשמשבצת הרפליקציה נמצאת בשימוש בתהליך אחר. רק תהליך אחד יכול להשתמש במשבצת רפליקציה בכל פעם. חשוב לוודא שלא משתמשים באותו מיקום רפליקציה באף תהליך אחר מלבד Datastream.
אתר החדשות לא מוגדר כמו שצריך.	השגיאה הזו יכולה לקרות כשהפרסום לא מוגדר לחשוף את הטבלאות שנכללות בהגדרת הסטרימינג. מוודאים שאתר החדשות מוגדר בצורה נכונה. הגדרת מידע על מסד הנתונים של המקור ל-stream
אתר החדשות לא קיים.	השגיאה הזו יכולה לקרות אם אתר החדשות לא קיים במסד הנתונים. מוודאים שאתר החדשות מוגדר בצורה נכונה. הגדרת מסד נתונים של PostgreSQL כמקור
אי אפשר להמשיך את הרפליקציה כי קובצי ה-WAL אבדו.	השגיאה הזו יכולה להתרחש כשמשהים את תהליך השכפול למשך זמן רב, מה שגורם לאובדן של קובצי ה-WAL. לא כדאי להשהות את השידורים לפרקי זמן שמתקרבים לתקופת השמירה של קובצי ה-WAL. יוצרים מחדש את השידור.
רשימת ההחרגות כוללת את רשימת ההכללות.	רשימת ההכללה נמצאת כולה בתוך רשימת ההחרגה, ולכן רשימת האובייקטים ש-Datastream שולף מהמקור ריקה. משנים את בחירת האובייקטים ומנסים שוב.
‫Datastream לא יכול לשכפל סכימה של PostgreSQL.	חשוב לוודא של-Datastream יש הרשאות לשכפל את הסכימה.
טרנזקציות גדולות במסד הנתונים של המקור גורמות לבעיות ברפליקציה ובסנכרון של הנתונים.	אם מוסיפים, מעדכנים או מוחקים מספר משמעותי של רשומות במסד הנתונים של המקור, יכול להיות שמשבצת הרפליקציה תהיה עמוסה מדי באירועים התואמים. ל-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 בשם הטבלה שבה רוצים לשנות את זהות הרפליקה. מסירים את הטבלה מרשימת האובייקטים שצריך לכלול ב-stream. מידע נוסף זמין במאמר שינוי פרטי ההגדרות של מסד הנתונים של המקור. מוחקים את הטבלה מ-BigQuery. מידע נוסף זמין במאמר מחיקת טבלאות. ב-Datastream, מוסיפים שוב את הטבלה למקור הנתונים על ידי עריכת ההגדרות של המקור.
יש שגיאה פנימית לא צפויה.	לפרטים נוספים, אפשר לפנות לתמיכה של Google.

שגיאות בשרת SQL

שגיאה	שלבים לפתרון בעיות
התכונה CDC מושבתת במסד הנתונים DATABASE_NAME.	צריך להפעיל את סימון הנתונים שהשתנו (CDC) במסד הנתונים. כדי לשכפל שינויים בזמן אמת במסד הנתונים של המקור ולקבל מידע מלא על היומנים, Datastream צריך גישת קריאה ישירה ליומני העסקאות. מפעילים את CDC במסד הנתונים ומנסים שוב. מידע נוסף על הפעלת CDC במסד נתונים זמין במאמר הגדרת מסד נתונים של SQL Server כמקור.
טבלאות עם CDC מושבת.	צריך להפעיל את התכונה "סימון נתונים שהשתנו" (CDC) בכל הטבלאות שנכללות בסטרימינג. כדי לשכפל שינויים בזמן אמת בטבלאות המקור ולקבל מידע מלא על היומנים, Datastream צריך גישת קריאה ישירה ליומני העסקאות. מפעילים את CDC בטבלאות שנכללות בסטרימינג ומנסים שוב. מידע נוסף על הפעלת CDC לטבלאות מקור זמין במאמר הגדרת מסד נתונים של SQL Server כמקור.
חסרות הרשאות.	ל-Datastream אין את ההרשאות הנדרשות לקריאה מהמקור. נותנים את ההרשאות המתאימות לחשבון המשתמש שמשמש לחיבור למסד הנתונים, ומנסים שוב.
אין תמיכה במהדורת SQL Server EDITION_NAME.	‫Datastream לא תומך במהדורה הזו של SQL Server. מידע נוסף על הגרסאות הנתמכות של SQL Server זמין במאמר סקירה כללית על SQL Server כמקור.
גרסת SQL Server‏ VERSION_NAME של מהדורת Standard לא נתמכת.	‫Datastream לא תומך בגרסה הזו של SQL Server Standard. מידע נוסף על הגרסאות הנתמכות של SQL Server זמין במאמר סקירה כללית של SQL Server כמקור.
הסטרימינג לא יכול לקרוא את האירוע ב-LSN "YOUR_LSN" כי נראה שיומן העסקאות נקטע.	הבעיה הזו יכולה לקרות כשיומני העסקאות כבר לא קיימים במסד הנתונים של המקור. כשמשכפלים נתונים ממקור SQL Server באמצעות שיטת ה-CDC של יומני העסקאות, יכול להיות שהיומנים ייחתכו לפני ש-Datastream יקרא אותם. במצב כזה, Datastream לא יכול לשכפל באופן מהימן את מסד הנתונים של המקור ליעד. כדי לפתור את הבעיה, צריך לשחזר את הסטרימינג או להשתמש בשיטת ה-CDC של טבלאות השינויים. למידע נוסף על ההבדלים בין שתי השיטות, ראו סקירה כללית של SQL Server כמקור.
הגדרת CDC ב-SQL Server: נכשלה.	שיטת ה-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 מנסה שוב לבצע את הפעולה במועד מאוחר יותר. מומלץ להגדיל את מכסת ה-API של Salesforce.
חרגת ממגבלת המחיקות.	כששולחים שאילתה לגבי רשומות שנמחקו, Salesforce מגבילה את התגובה ל-600,000 מזהי רשומות. רמת הפירוט הנמוכה ביותר של שאילתות ב-Salesforce היא דקה אחת. אם מוחקים יותר מ-600,000 רשומות בתוך דקה, Salesforce מחזירה את השגיאה הזו.
שגיאת אימות.	Datastream לא יכול לבצע אימות באמצעות Salesforce. כנראה שהשתמשתם בפרטי כניסה או בשם דומיין שגויים.

שגיאות ב-MongoDB

שגיאה	שלבים לפתרון בעיות
האימות נכשל.	צריך לבדוק אם הערך של authSource למשתמש Datastream הוא 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 ואילך.
ל-Datastream לא הייתה אפשרות להריץ את הפקודה 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 לסטרימינג, הנתונים מתווספים ב-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 וכבר יש לה מפתח ראשי: בודקים את מדד זמן האחזור הכולל של הסטרימינג וממתינים לפחות למשך זמן האחזור הנוכחי כדי לוודא שכל האירועים שבתהליך נכתבים ביעד. כך אפשר להעביר בהצלחה את כל האירועים עם המפתח הראשי המקורי. להשהות את השידור. מעתיקים את פקודת שפת הגדרת הנתונים (DDL) של CREATE TABLE לטבלה ב-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.