יכול להיות שבתהליך של משימת ההעברה יתרחשו שגיאות בזמן הריצה.
- יש שגיאות שאפשר לתקן, כמו סיסמה שגויה במסד הנתונים של המקור. במקרים כאלה, אחרי שמתקנים את השגיאה, משימת ההעברה ממשיכה באופן אוטומטי.
- חלק מהשגיאות לא ניתנות לשחזור, כמו מיקום binlog שאבד, מה שאומר שצריך להפעיל מחדש את משימת ההעברה מההתחלה.
אם מתרחשת שגיאה, סטטוס משימת ההעברה משתנה ל-Failed, וסטטוס המשנה משקף את הסטטוס האחרון לפני הכישלון.
כדי לפתור שגיאה, עוברים למשימת ההעברה שנכשלה, בודקים את השגיאה ופועלים לפי השלבים שמפורטים בהודעת השגיאה.
כדי לראות פרטים נוספים על השגיאה, עוברים אל Cloud Monitoring באמצעות הקישור במשימת ההעברה. היומנים מסוננים לפי משימת ההעברה הספציפית.
בטבלה הבאה מפורטות כמה דוגמאות לבעיות ודרכים לפתור אותן:
| בבעיה הזו… | יכול להיות שהבעיה היא... | אפשר לנסות את זה… |
|---|---|---|
| הגדרות מסד הנתונים של היעד שונות מהגדרות Terraform ששימשו להקצאת מסד הנתונים. (הבעיה הזו נקראת לפעמים גם סטייה מההגדרות). | כשמעבירים נתונים למסד נתונים קיים ביעד, השירות Database Migration Service משנה הגדרות מסוימות במסד הנתונים ביעד כדי להריץ את משימת ההעברה. | אחרי שמקדמים את משימת ההעברה, צריך להחיל מחדש את ההגדרות שבהן אתם משתמשים בקובץ התצורה של Terraform. מידע נוסף על שינויים בהגדרות של Terraform |
הודעת שגיאה: Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
בטבלאות שמשתמשות בעמודות VARCHAR יכולות להיות שורות שחורגות מהגודל המקסימלי שמותר ב-InnoDB (מנוע האחסון שמוגדר כברירת מחדל ב-MySQL). |
כדי לבטל את החסימה של משימת ההעברה, אתם יכולים להמיר עמודות ל-BLOB או ל-TEXT, או להגדיר באופן זמני את הדגל innodb_strict_mode לערך off.
שגיאה 1118: גודל השורה גדול מדי. |
משימת ההעברה נכשלה בשלב ה-dump הראשוני, והוצגה הודעת השגיאה הבאה:ERROR 1064 (42000) at {line_number}: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near {reserved_word} at {line_number}.
|
הבעיה הזו מתרחשת כשמעבירים נתונים בין גרסאות של MySQL.
יכול להיות שישויות בגרסת המקור של MySQL משתמשות במילים שאסורות בגרסת MySQL שאליה אתם רוצים לעבור.
לדוגמה, ב-MySQL 5.7 אפשר להשתמש במילה |
משנים את השם של האובייקטים במסד הנתונים של המקור שמופיעים בהודעת השגיאה, או שמים אותם בגרש הפוך (``) כדי להחריג אותם מהתחביר. בסיום, מנסים שוב להפעיל את משימת ההעברה.
|
הודעת שגיאה: ERROR 1109 (42S02): Unknown table in <schema name here> |
Database Migration Service לא מעביר את הסכימות של המערכות mysql, performance_schema, information_schema, ndbinfo או sys.
משימת ההעברה עלולה להיכשל אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות מאחת מהסכימות האלה. |
בודקים אם במסד הנתונים של המקור יש אובייקטים שמפנים לטבלאות שכלולות בסכימות המערכת שלא הועברו. ERROR 1109 (42S02): Unknown table in <schema name here>. |
הודעת שגיאה: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
רלוונטי רק לתרחישים של העברה ידנית של מסד נתונים באמצעות mysqldump.במסדי נתונים של MySQL בגרסאות שקודמות ל-8 אין את הטבלה COLUMN_STATISTICS. כלי השירות |
משתמשים בדגל --column-statistics=0 כשמשתמשים ב-mysqldump. |
הודעת שגיאה: Specified key was too long; max key length is 767 bytes. |
יכול להיות שהמשתנה innodb_large_prefix מוגדר במכונה של מסד הנתונים במקור. |
מגדירים את הדגל innodb_large_prefix לערך ON כשיוצרים את מכונת היעד, או מעדכנים את מכונת היעד הקיימת באמצעות הדגל. |
הודעת שגיאה: Table definition has changed. |
היו שינויים בשפת הגדרת הנתונים (DDL) במהלך תהליך ה-dump. | הימנעו משינויים ב-DDL במהלך תהליך ה-dump. |
הודעת שגיאה: While 'Loading data': Dump timeout. |
יכול להיות שבעיה בקישוריות גורמת לזמן קצוב לתפוגה. | מוודאים שיש חיבור לרשת עם מסד הנתונים של המקור. לדוגמה, ראו ניפוי באגים בקישוריות. |
| אם בוצעו שינויים בשפת הגדרת הנתונים (DDL) במהלך תהליך ה-dump, יכול להיות ש-Database Migration Service נתקע בגלל נעילת מטא-נתונים. | בודקים את מסד הנתונים של המקור כדי לראות אם יש תהליכים שנתקעו במצב Waiting for table metadata lock. אם אתם מוצאים תהליכים עם הסטטוס הזה, מומלץ להפעיל מחדש את משימת ההעברה. אל תבצעו שינויים ב-DDL במהלך שלב ה-dump המלא אחרי ההפעלה מחדש.
אתם יכולים להשתמש בסקריפט לדוגמה כדי לוודא שפעולות ה-DDL הופסקו.
|
|
MySQL Error 2013: (HY000): Lost connection to MySQL server during query |
יכול להיות שבעיה בקישוריות גורמת לזמן קצוב לתפוגה. | מוודאים שיש חיבור לרשת עם מסד הנתונים של המקור. לדוגמה, ראו ניפוי באגים בקישוריות. |
| אם בוצעו שינויים בשפת הגדרת הנתונים (DDL) במהלך תהליך ה-dump, יכול להיות ש-Database Migration Service נתקע בנעילת מטא-נתונים. | בודקים את מסד הנתונים של המקור כדי לראות אם יש תהליכים שנתקעו במצב Waiting for table metadata lock. אם אתם מוצאים תהליכים עם הסטטוס הזה, מומלץ להפעיל מחדש את משימת ההעברה. אל תבצעו שינויים ב-DDL במהלך שלב ה-dump המלא אחרי ההפעלה מחדש.
אתם יכולים להשתמש בסקריפט לדוגמה כדי לוודא שפעולות ה-DDL הופסקו.
|
|
הודעת שגיאה: Timeout waiting for no write traffic on source: context deadline exceeded. |
יכול להיות שבעיה בקישוריות גורמת לזמן קצוב לתפוגה. | מוודאים שיש חיבור לרשת עם מסד הנתונים של המקור. לדוגמה, ראו ניפוי באגים בקישוריות. |
| אם בוצעו שינויים בשפת הגדרת הנתונים (DDL) במהלך תהליך ה-dump, יכול להיות ש-Database Migration Service נתקע בנעילת מטא-נתונים. | בודקים את מסד הנתונים של המקור כדי לראות אם יש תהליכים שנתקעו במצב Waiting for table metadata lock. אם אתם מוצאים תהליכים עם הסטטוס הזה, מומלץ להפעיל מחדש את משימת ההעברה. אל תבצעו שינויים ב-DDL במהלך שלב ה-dump המלא אחרי ההפעלה מחדש.
אתם יכולים להשתמש בסקריפט לדוגמה כדי לוודא שפעולות ה-DDL הופסקו.
|
|
הודעת שגיאה: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. |
יכול להיות שיש אירוע, תצוגה, פונקציה או פרוצדורה במסד הנתונים של המקור שמשתמשים ב-super user@localhost (כמו root@localhost). האפשרות הזו לא נתמכת ב-Cloud SQL. | מידע נוסף על השימוש ב-DEFINER ב-Cloud SQL. |
הודעת שגיאה: Definer user 'x' does not exist. Please create the user on the replica.
|
המשתמש לא קיים ברפליקה. | מידע נוסף על השימוש ב-DEFINER ב-Cloud SQL. |
הודעת שגיאה: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost. |
יש DEFINER במסד הנתונים של המקור שלא קיים ברפליקה. |
מידע נוסף על השימוש ב-DEFINER ב-Cloud SQL. |
הודעת שגיאה: Lost connection to MySQL server during query when dumping table. |
יכול להיות שלא ניתן לגשת למסד הנתונים של המקור, או שה-dump הכיל חבילות גדולות מדי. | כדאי לנסות את ההצעות האלה. |
הודעת שגיאה: Got packet bigger than 'max_allowed_packet' bytes when dumping table. |
החבילה הייתה גדולה מהמותר בהגדרות. | שימוש ב-Manual dump עם האפשרות max_allowed_packet. |
| העברת הנתונים הראשונית הצליחה, אבל לא מתבצעת שכפול של נתונים. | יכול להיות שיש דגלי שכפול מתנגשים. | בודקים את הגדרות הדגלים האלה. |
| העברת הנתונים הראשונית הצליחה, אבל שכפול הנתונים הפסיק לפעול אחרי זמן מה. | יכולות להיות לכך הרבה סיבות. | כדאי לנסות את ההצעות האלה. |
הודעת שגיאה: mysqld check failed: data disk is full. |
דיסק הנתונים של מכונת היעד מלא. | מגדילים את נפח הדיסק של מכונת היעד. אתם יכולים להגדיל את נפח הדיסק באופן ידני או להפעיל את ההגדלה האוטומטית של נפח האחסון. |
| החיבור למכונה של מסד הנתונים במקור נכשל. | הייתה בעיית קישוריות בין המכונה של מסד הנתונים במקור לבין המכונה ביעד. | פועלים לפי השלבים במאמר ניפוי באגים בקישוריות. |
| ההעברה ממסד נתונים מנוהל (Amazon RDS/Aurora) לא מתחילה. | כדי להעביר ממסד נתונים מנוהל של מקור בלי הרשאות SUPERUSER, נדרש זמן השבתה קצר בתחילת ההעברה. | פועלים לפי השלבים שמפורטים במאמר הזה. |
| ה-Binlog מוגדר באופן שגוי במסד הנתונים של המקור. | ההגדרות של Binlog שגויות. | במשימות העברה רציפות של MySQL, חשוב לפעול לפי ההגדרות הנדרשות של binlog. |
| לא נמצא קובץ ה-dump. | שירות DMS לא מצליח למצוא את קובץ ה-dump שסופק. | זה יכול לקרות אם משימת ההעברה לא מוצאת את קובץ ה-dump במיקום שצוין.
|
| אי אפשר להמשיך את הרפליקציה כי המיקום של binlog אבד. | המיקום של binlog אבד ואי אפשר היה להמשיך את משימת ההעברה. | השגיאה הזו יכולה להתרחש כשתהליך השכפול מושהה למשך זמן רב, מה שגורם לאובדן המיקום של binlog. אל תשהו את משימות ההעברה לפרקי זמן שמתקרבים לתקופת השמירה של binlog. מפעילים מחדש את משימת ההעברה. |
כשמעבירים למופע יעד קיים, מקבלים את הודעת השגיאה הבאה:
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
|
מכונת היעד ב-Cloud SQL מכילה נתונים נוספים. אפשר להעביר רק למכונות קיימות ריקות. מגבלות ידועות | מקַדמים את מכונת היעד כדי להפוך אותה למכונה לקריאה/כתיבה, מסירים את הנתונים הנוספים ומנסים שוב את משימת ההעברה. איך מוחקים נתונים מיותרים מהמופע הקיים של היעד |
| הפעלת משימת ההעברה נכשלה כי הגרסאות של מסד הנתונים של המקור והיעד לא תואמות. | גרסת מסד הנתונים של המקור שצוינה לא תואמת לגרסת מסד הנתונים של היעד. | מוודאים שגרסת מסד הנתונים של היעד זהה לגרסת מסד הנתונים של המקור או שהיא גרסה ראשית אחת מעליה, ואז יוצרים משימת העברה חדשה. |
הודעת השגיאה: Unable to connect to source database server.
|
Database Migration Service לא מצליח להתחבר לשרת של מסד הנתונים במקור. | מוודאים שיש תקשורת בין מכונות מסד הנתונים של המקור והיעד, ושהשלמתם את כל הדרישות המוקדמות שמופיעות כשמגדירים את משימת ההעברה. |
הודעת השגיאה: Timeout waiting for no write traffic on source.
|
אם מעבירים ממסד נתונים מנוהל במקור בלי הרשאות SUPERUSER, תהיה השבתה קצרה בתחילת ההעברה. |
מבצעים את השלבים שמפורטים במאמר העברה מ-RDS MySQL בלי הרשאות SUPERUSER. |
הודעת השגיאה: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
יכול להיות שיש חוסר התאמה בין הערך של הדגל lower_case_table_names במסד הנתונים של המקור לבין הערך של הדגל במכונה של Cloud SQL ביעד. |
מגדירים את הערך של הדגל של מכונת Cloud SQL כך שיתאים לערך של הדגל של מסד הנתונים במקור. |
הודעת השגיאה: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.
|
אובייקטים מסוימים במסד הנתונים של המקור, כמו תצוגות, פונקציות, פרוצדורות מאוחסנות או טריגרים, מפנים לטבלה שכבר לא קיימת במסד הנתונים. | בודקים אם האובייקטים האלה קיימים. אם כן, צריך להסיר את האובייקטים ממסד הנתונים של המקור או להוסיף למסד הנתונים של המקור את הטבלה שהאובייקטים מפנים אליה. |
הודעת השגיאה: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. |
הזנתם סיסמה שגויה למכונה המקורית. או שהמכונה של המקור מאלצת חיבור SSL, אבל משימת ההעברה לא מוגדרת לשימוש באישורי SSL. | באמצעות הלקוח של אם מכונת המקור היא Cloud SQL, עיינו במאמר דרישת SSL/TLS כדי לבדוק אם נדרש SSL/TLS לחיבורי TCP. |
| הפיגור בשכפול גבוה באופן עקבי. | עומס הכתיבה גבוה מדי והרפליקה לא יכולה לטפל בו. השהיית הרפליקציה מתרחשת כשהשרשור של Cloud SQL ל-MySQL ברפליקה לא עומד בקצב של שרשור הקלט/פלט. סוגים מסוימים של שאילתות או עומסי עבודה יכולים לגרום לעיכוב זמני או קבוע בשכפול של סכימה מסוימת. הנה כמה סיבות נפוצות להשהיה ברפליקציה:
|
פתרונות אפשריים:
|
הודעת השגיאה: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. |
יכול להיות שמסד הנתונים של המקור משתמש בקבוצות תווים או באוספי תווים שלא נתמכים ברפליקה שנבחרה ב-Cloud SQL. דוגמה אחת היא AWS Aurora בגרסה 2.x, שתואמת ל-MySQL 5.7. עם זאת, הגרסה הזו תומכת ב-collation utf8mb4_0900_as_ci, שלא נתמך ב-Cloud SQL ל-MySQL 5.7. |
|
שגיאה 1108: גודל השורה גדול מדי
בטבלאות עם עמודות שמאחסנות מחרוזות באורך משתנה, יכולות להיות שורות שחורגות מגודל השורה המקסימלי שמוגדר כברירת מחדל ב-InnoDB.דברים שכדאי לנסות
שינוי הסכימה של טבלת המקור
הבעיה הזו יכולה לחזור על עצמה בכל פעם שמבצעים הצהרות INSERT בטבלאות שחורגות ממגבלת הגודל המקסימלי של השורות. כדי למנוע בעיות בעתיד, מומלץ לשנות את הטבלאות לפני שמנסים שוב לבצע את ההעברה:
- משנים את הטבלה
ROW_FORMATל-DYNAMICאו ל-COMPRESSEDבאמצעות הרצת השאילתה הבאה:ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
- TABLE_NAME הוא שם הטבלה שהשורות שלה חורגות מהגודל המקסימלי המותר לשורה.
- FORMAT_NAME הוא
DYNAMICאוCOMPRESSED
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- המרת נתוני שורות ל-BLOB או ל-TEXT. אחת הדרכים לבצע את הפעולה הזו היא באמצעות הפונקציה
CONVERT().
השבתת המצב הקפדני של InnoDB
אם אתם לא יכולים לשנות את הסכימה של טבלת המקור, אתם יכולים להשבית זמנית את האימות של InnoDB כדי להשלים את משימת ההעברה. חשוב לזכור שהבעיה יכולה לחזור על עצמה בניסיונות עתידיים של כתיבה במסד הנתונים, ולכן מומלץ לשנות את סכימת הטבלה כשאפשר.
כדי להשבית זמנית את האימות של InnoDB לצורך השלמת משימת ההעברה, פועלים לפי השלבים הבאים:
| אם... | ואז… |
|---|---|
| אם אתם עוברים למופע יעד חדש |
|
| אם אתם מעבירים את הנתונים למופע יעד קיים |
|
מחיקת נתונים מיותרים מהמכונה הקיימת של היעד
כשמעבירים למכונה קיימת ביעד, מופיעה הודעת השגיאה הבאה:
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
הבעיה הזו יכולה לקרות אם המכונה של היעד מכילה נתונים נוספים. אפשר להעביר רק למכונות קיימות ריקות. מגבלות ידועות
דברים שכדאי לנסות
כדי למחוק נתונים מיותרים ממכונת היעד ולהפעיל מחדש את משימת ההעברה:
- עצירת משימת ההעברה.
- בשלב הזה, המכונה של Cloud SQL ביעד נמצאת במצב
read-only. מקַדמים את המכונה ביעד כדי לקבל גישת כתיבה. - מתחברים למכונה של Cloud SQL ביעד.
- מסירים נתונים מיותרים ממסדי הנתונים של המכונה המיועדת. היעד יכול להכיל רק נתוני הגדרות מערכת. מסדי נתונים של יעדים לא יכולים להכיל נתוני משתמשים (כמו טבלאות). יש הצהרות SQL שונות שאפשר להריץ במסדי הנתונים כדי למצוא נתונים שאינם נתוני מערכת, לדוגמה:
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- מתחילים את משימת ההעברה.
שינויים בהגדרות של Terraform
כשמעבירים נתונים למסד נתונים קיים ביעד, השירות Database Migration Service משנה הגדרות מסוימות במסד הנתונים ביעד כדי להריץ את משימת ההעברה. במסדי נתונים שנוצרו באמצעות Terraform, האינטראקציה הזו עלולה לגרום לשינוי בהגדרות, כך שההגדרות בפועל של מסד הנתונים ביעד יהיו שונות מההגדרות שנקבעו בקובצי Terraform.דברים שכדאי לנסות
אל תנסו להחיל מחדש את ההגדרות של Terraform בזמן שמשימת ההעברה פועלת. אחרי קידום מסד הנתונים של היעד, אפשר לשנות את ההגדרות הנדרשות בלי חשש. Database Migration Service מבצע את השינויים הבאים במכונה של Cloud SQL ביעד:- הגדרת הגיבוי נקבעת לערכי ברירת המחדל.
- ההגדרה שחזור מערכת מנקודה מסוימת בזמן (PITR) מאופסת לערכי ברירת המחדל.
ERROR 1109 (42S02): Unknown table in <schema name here>
משימות ההעברה נכשלות ומופיעה ההודעה הבאה:
ERROR 1109 (42S02): Unknown table in <schema name here>
, לדוגמה: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema.
יכול להיות שהבעיה היא
Database Migration Service לא מעביר את הסכימות של המערכות mysql, performance_schema, information_schema, ndbinfo או sys (ראו מגבלות ידועות).
יכול להיות שמשימת ההעברה תיכשל אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות מאחת מהסכימות האלה.
דברים שכדאי לנסות
בודקים אם במסד הנתונים של המקור יש אובייקטים שמפנים לטבלאות מהסכימות של המערכת. מריצים את השאילתות הבאות במסד הנתונים של המקור:# Query to check routines or functions definitions. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check view definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check trigger definitions. SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE' # Query to check constraint definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
טבלה לא ידועה COLUMN_STATISTICS ב-information_schema
כשמריצים את כלי השירות mysqldump בגרסה 8 ואילך כדי לייצא מסד נתונים של MySQL בגרסה שקודמת ל-8, נתקלים בשגיאה הבאה: Unknown table 'COLUMN_STATISTICS' in information_schema (1109).
יכול להיות שהבעיה היא
במסדי נתונים של MySQL בגרסאות שקודמות ל-8 אין את הטבלה COLUMN_STATISTICS. כלי השירות mysqldump בגרסאות 8 ואילך מנסה לייצא את הטבלה הזו כברירת מחדל. הייצוא נכשל כי העמודה לא קיימת.
דברים שכדאי לנסות
מוסיפים את הדגל --column-statistics=0 לפקודה mysqldump כדי להסיר את הטבלה COLUMN_STATISTICS מהייצוא. מידע נוסף זמין במאמר ייצוא מסד נתונים של MySQL באמצעות mysqldump.
המפתח שצוין ארוך מדי. האורך המקסימלי של מפתח הוא 767 בייטים
מוצגת השגיאה Specified key was too long; max key length is 767 bytes.
יכול להיות שהבעיה היא
יכול להיות שבמסד הנתונים של המקור מוגדר המשתנה innodb_large_prefix. כך אפשר להשתמש בתחיליות של מפתחות אינדקס שארוכות מ-767 בייטים. ערך ברירת המחדל הוא OFF ל-MySQL 5.6.
דברים שכדאי לנסות
מגדירים את הדגל innodb_large_prefix לערך ON כשיוצרים את מסד הנתונים של היעד, או מעדכנים את מסד הנתונים הקיים של היעד באמצעות הדגל.
הגדרת הטבלה השתנתה
מוצגת השגיאה Table definition has changed.
יכול להיות שהבעיה היא
היו שינויים ב-DDL במהלך תהליך ה-dump.
דברים שכדאי לנסות
אל תשנו טבלאות ואל תבצעו שינויים אחרים ב-DDL במהלך תהליך ה-dump.אתם יכולים להשתמש בסקריפט כדי לוודא שפעולות ה-DDL הופסקו.
הגישה נדחתה; נדרשת (לפחות אחת) מהרשאות ה-SUPER לפעולה הזו
מוצגת השגיאה Access denied; you need (at least one of) the SUPER privilege(s) for this operation.
יכול להיות שהבעיה היא
יכול להיות שיש אירוע, תצוגה, פונקציה או פרוצדורה במסד הנתונים של המקור שמשתמשים ב-super user@localhost (כמו root@localhost). האפשרות הזו לא נתמכת ב-Cloud SQL.
דברים שכדאי לנסות
במסמך הזה מוסבר איך להעביר מסד נתונים עם משפטי DEFINER.
הודעת שגיאה: Definer user 'x' does not exist. Please create the user on the replica.
מוצגת השגיאה Definer user 'x' does not exist. Please create the user on the replica.
יכול להיות שהבעיה היא
שורש הבעיה הוא שמשתמש במסד הנתונים של המקור עם הסעיף DEFINER לא קיים במסד הנתונים של הרפליקה.
דברים שכדאי לנסות
במסמך הזה מוסבר איך להעביר מסד נתונים עם משפטי DEFINER. יכול להיות שתצטרכו ליצור את המשתמש במסד הנתונים של הרפליקה.
הודעת שגיאה: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost
מוצגת השגיאה ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost.
יכול להיות שהבעיה היא
שורש הבעיה הוא שמשתמש במסד הנתונים של המקור עם הפסוקית DEFINER לא קיים במסד הנתונים של הרפליקה, ויש הצלבת נתונים למשתמש הזה בהגדרות האובייקט במסד הנתונים של המקור.
דברים שכדאי לנסות
במסמך הזה מוסבר איך להעביר מסד נתונים עם משפטי DEFINER. יכול להיות שתצטרכו ליצור משתמש אחד או יותר במסד הנתונים של הרפליקה.
החיבור לשרת MySQL אבד במהלך שאילתה בזמן העברת טבלה
מוצגת השגיאה Lost connection to MySQL server during query when dumping table.
יכול להיות שהבעיה היא
- יכול להיות שאי אפשר להגיע למכונה של מסד הנתונים במקור מהמכונה ביעד.
- יכול להיות שבמסד הנתונים של המקור יש טבלאות עם אובייקטים בינאריים גדולים (BLOB) או מחרוזות ארוכות, שדורשות הגדרה של
max_allowed_packetלמספר גדול יותר במסד הנתונים של המקור.
דברים שכדאי לנסות
- מוודאים שהמופע של מסד הנתונים במקור פועל ונגיש.
- מגדירים את הדגל
max-allowed-packetבמשימת ההעברה, ואז מפעילים מחדש את משימת ההעברה. אפשר גם ליצור קובץ dump ידני באמצעות האפשרותmax_allowed_packetכדי ליצור קובץ dump של הנתונים ולהעביר אותם באמצעות קובץ ה-dump. - כדי להגדיל את
max_allowed_packet, סביר להניח שצריך לשנות את ההגדרות שלnet_read_timeoutו-net_write_timeoutבמסד הנתונים של המקור (בדרך כלל צריך להגדיל את הערך עד ששגיאת החיבור מפסיקה).
התקבלה חבילה גדולה יותר מ-'max_allowed_packet' בייטים בזמן ה-dump של הטבלה
מוצגת השגיאה Got packet bigger than 'max_allowed_packet' bytes when dumping table.
יכול להיות שהבעיה היא
החבילה הייתה גדולה מהמותר בהגדרות.
דברים שכדאי לנסות
יוצרים משימת העברה באמצעות הורדה ידנית עם האפשרות max_allowed_packet כדי להוריד את הנתונים ולהעביר אותם באמצעות קובץ dump.
לא מתבצעת שכפול של נתונים
העברת הנתונים הראשונית הצליחה, אבל לא מתבצעת שכפול של נתונים.
יכול להיות שהבעיה היא
שורש הבעיה האפשרי יכול להיות שבמסד הנתונים של המקור יש דגלי רפליקציה שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים.
דברים שכדאי לנסות
חשוב לוודא שדגלי הרפליקציה, כמו binlog-do-db, binlog-ignore-db, replicate-do-db או replicate-ignore-db, לא מוגדרים באופן שיוצר התנגשות.
מריצים את הפקודה show master status במסד הנתונים של המקור כדי לראות את ההגדרות הנוכחיות.
העברת הנתונים הראשונית הצליחה, אבל שכפול הנתונים הפסיק לפעול אחרי זמן מה
העברת הנתונים הראשונית הצליחה, אבל שכפול הנתונים הפסיק לפעול אחרי זמן מה.
יכול להיות שהבעיה היא
יכולות להיות הרבה שורשי בעיה לבעיה הזו.
דברים שכדאי לנסות
- בודקים את מדדי הרפליקציה של מכונת היעד ב-Cloud Monitoring.
- השגיאות משרשור ה-IO של MySQL או משרשור ה-SQL מופיעות ב-Cloud Logging בקובצי היומן mysql.err.
- השגיאה יכולה להופיע גם כשמתחברים למכונה ביעד. מריצים את הפקודה
SHOW REPLICA STATUSובודקים אם השדות הבאים מופיעים בפלט:- Replica_IO_Running
- Replica_SQL_Running
- Last_IO_Error
- Last_SQL_Error
הערה:
SHOW REPLICA STATUSהוא שם חלופי שהוצג ב-MySQL 8.0.22. בגרסאות קודמות (MySQL 5.7, MySQL 8.0), צריך להשתמש בשם הסודי הישן של פקודת הסטטוס. מידע נוסף זמין בקטע Status statement במסמכי התיעוד של MySQL.אם קיבלתם את השגיאה
fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error, יכול להיות שהסיבה לכך היא הגדרה לא מספיקה של שמירת binlog במכונה המקורית.אם קיבלתם את השגיאה
error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES, יכול להיות שהסיבה לכך היא שהמכונה ביעד לא הצליחה להתחבר מחדש למקור בגלל בעיית קישוריות או אימות.
בדיקת mysqld נכשלה: דיסק הנתונים מלא
מוצגת השגיאה mysqld check failed: data disk is full.
יכול להיות שהבעיה היא
כנראה שדיסק הנתונים של מכונת היעד מלא.
דברים שכדאי לנסות
מגדילים את נפח הדיסק של מכונת היעד.
החיבור למסד הנתונים של המקור נכשל
החיבור למסד הנתונים של המקור נכשל.
יכול להיות שהבעיה היא
הייתה בעיית קישוריות בין המכונה של מסד הנתונים במקור לבין המכונה ביעד.
דברים שכדאי לנסות
פועלים לפי השלבים שמפורטים במאמר ניפוי באגים בקישוריות.
ההעברה ממסד נתונים מנוהל (Amazon RDS/Aurora) לא מתחילה
משימת ההעברה לא מתחילה.
יכול להיות שהבעיה היא
כדי להעביר ממסד נתונים מנוהל של מקור בלי הרשאות SUPERUSER, צריך זמן השבתה קצר בתחילת ההעברה.
דברים שכדאי לנסות
- ב-Amazon RDS, פועלים לפי השלבים שמפורטים במאמר הזה.
- ב-Amazon Aurora, פועלים לפי השלבים שמפורטים במאמר הזה.
ה-Binlog לא מוגדר נכון במסד הנתונים של המקור
מוצגת שגיאה שמצביעה על בעיה ביומנים הבינאריים.
יכול להיות שהבעיה היא
זה יכול לקרות במשימות העברה רציפות של MySQL אם ההגדרה של binlog לא נכונה במסד הנתונים של המקור.
דברים שכדאי לנסות
חשוב לפעול לפי השלבים שמפורטים כאן.
לא ניתן לקרוא את קובץ ה-dump שסופק
מוצגת שגיאה שמציינת שיש בעיה בקובץ ה-dump.
יכול להיות שהבעיה היא
שירות DMS לא מצליח למצוא את קובץ ה-dump שסופק.
דברים שכדאי לנסות
- צריך לבדוק את נתיב ה-dump כדי לוודא שיש שם קובץ תקין, או לשנות את הנתיב
- אם משנים את הנתיב, צריך להשתמש בבקשת
PATCHכדי לוודא שהמשימה משתמשת בו. - מפעילים מחדש את משימת ההעברה.
אי אפשר להמשיך את הרפליקציה כי המיקום של binlog אבד
המיקום של binlog אבד.
יכול להיות שהבעיה היא
השגיאה הזו יכולה להתרחש כשמשהים את תהליך השכפול למשך זמן רב, מה שגורם לאובדן המיקום של binlog. לא כדאי להשהות משימות העברה לפרקי זמן שמתקרבים לתקופת השמירה של binlog.
דברים שכדאי לנסות
מפעילים מחדש את משימת ההעברה.
הפעלת משימת ההעברה נכשלה כי גרסאות מסד הנתונים של המקור והיעד לא תואמות
השילוב בין הגרסאות של מסד הנתונים במקור וביעד לא נתמך.
יכול להיות שהבעיה היא
גרסת מסד הנתונים של המקור שצוינה לא תואמת לגרסת מסד הנתונים של היעד.
דברים שכדאי לנסות
מוודאים שגרסת מסד הנתונים של היעד זהה לגרסת מסד הנתונים של המקור או שהיא גרסה ראשית אחת מעליה, ואז יוצרים משימת העברה חדשה.
לא ניתן להתחבר לשרת של מסד הנתונים המקורי
מוצגת השגיאה Unable to connect to source database server.
יכול להיות שהבעיה היא
Database Migration Service לא מצליח להתחבר לשרת של מסד הנתונים במקור.
דברים שכדאי לנסות
מוודאים שמופעי מסד הנתונים של המקור והיעד יכולים לתקשר זה עם זה. לאחר מכן, ודאו שהשלמתם את כל הדרישות המוקדמות שמופיעות כשמגדירים את משימת ההעברה.
השימוש בדיסק של מכונת היעד ב-Cloud SQL יורד לאפס
השימוש בדיסק יורד פתאום לאפס במהלך ההעברה.
יכול להיות שהבעיה היא
יכול להיות שתהיה שגיאה בייבוא הנתונים הראשוניים. במקרים כאלה, תהליך ההעברה מנסה לטעון שוב את הנתונים. בתהליך הזה, קודם כל נמחקים הנתונים הקיימים במכונה של היעד (לכן השימוש בדיסק יורד לאפס), ואז המערכת מנסה לטעון מחדש את הנתונים.
דברים שכדאי לנסות
נכנסים ל-Logs Explorer ובוחרים את המכונה של היעד מרשימת המשאבים.
מחפשים הודעת יומן דומה:
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
מוצאים את ההודעה אחרי הטקסט import failed: ומנסים לפתור את הבעיה הבסיסית.