פתרון בעיות במקרה של שגיאות
יכול להיות שיתרחשו שגיאות במהלך זמן הריצה של תהליך העברת המשימות.
- אפשר לתקן שגיאות מסוימות, כמו סיסמה שגויה במסד הנתונים של המקור, והעברת הנתונים תתחדש באופן אוטומטי.
- חלק מהשגיאות לא ניתנות לתיקון, כמו מיקום יומן בינארי שאבד, מה שאומר שצריך להפעיל מחדש את משימת ההעברה מההתחלה.
כשמתרחשת שגיאה, סטטוס משימת ההעברה משתנה ל-Failed, וסטטוס המשנה משקף את הסטטוס האחרון לפני הכשל.
כדי לפתור שגיאה, עוברים אל משימת ההעברה שנכשלה כדי לראות את השגיאה ופועלים לפי השלבים שמפורטים בהודעת השגיאה.
כדי לראות פרטים נוספים על השגיאה, עוברים אל Cloud Monitoring באמצעות הקישור למשימת ההעברה. היומנים מסוננים לפי משימת ההעברה הספציפית.
בטבלה הבאה מפורטות כמה דוגמאות לבעיות ופתרונות אפשריים:
| לבעיה הזו... | יכול להיות שהבעיה היא... | אפשר לנסות את הפעולות הבאות… |
|---|---|---|
| ההגדרות של מסד הנתונים של היעד שונות מההגדרות של Terraform שמשמשות להקצאת מסד הנתונים. (הבעיה הזו נקראת לפעמים גם סחף תצורה). | כשמעבירים נתונים אל מסד נתונים קיים של יעד, שירות Database Migration Service משנה הגדרות מסוימות במסד הנתונים של היעד כדי להפעיל את משימת ההעברה. | אחרי שמקדמים את עבודת ההעברה, צריך להחיל מחדש את ההגדרות שבהן משתמשים בהגדרות של Terraform. מידע נוסף זמין במאמר בנושא שינויים בהגדרות של Terraform. |
הודעת שגיאה: ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824} |
הגיבוי הראשוני נכשל כי מסדי הנתונים שנבחרו מכילים אובייקטים שמפנים לנתונים במסדי נתונים שלא נבחרו להעברה. | בודקים את הודעת השגיאה הבאה כדי לזהות את האובייקט החסר שאליו יש הפניה. אם רוצים לנסות שוב את ההעברה, צריך קודם להוסיף את מסד הנתונים שמכיל את האובייקט למשימת ההעברה, או להסיר את מסד הנתונים שמכיל את ההפניה. |
| השכפול נכשל עם קוד השגיאה 1049, 1146 או 1824 במהלך שלב ה-CDC. | זה יכול לקרות אם מופעלת הצהרת DDL על:
|
בודקים את הודעת השגיאה הבאה כדי לזהות את האובייקט החסר שאליו יש הפניה. אם רוצים לנסות שוב את ההעברה, צריך קודם להוסיף את מסד הנתונים שמכיל את האובייקט למשימת ההעברה, או להסיר את מסד הנתונים שמכיל את ההפניה. |
הודעת שגיאה: Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
יכול להיות שבטבלאות שמשתמשות ב-VARCHAR עמודות יש שורות שגדולות מהגודל המקסימלי שמותר לפי InnoDB (מנוע האחסון שמוגדר כברירת מחדל ב-MySQL). |
כדי לבטל את החסימה של עבודת ההעברה, אפשר להמיר את העמודות ל-BLOB או ל-TEXT, או להגדיר באופן זמני את הדגל
innodb_strict_mode ל-off.
שגיאה 1118: גודל השורה גדול מדי |
משימת ההעברה נכשלה במהלך השלב של הגיבוי המלא עם הודעת השגיאה הבאה: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) במהלך תהליך הגיבוי. | אל תבצעו שינויים ב-DDL במהלך תהליך הגיבוי. |
הודעת שגיאה: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. |
יכול להיות שיש אירוע, תצוגה, פונקציה או פרוצדורה במסד הנתונים של המקור באמצעות משתמש סופר 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. |
החבילה הייתה גדולה יותר מהמותר בהגדרות. | משתמשים באפשרות 'יצירת קובץ 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. | כדי לוודא ששם המשתמש, הסיסמה והגדרות ה-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. עם זאת, הגרסה הזו תומכת ב-utf8mb4_0900_as_ci collation, שלא נתמך ב-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 בזמן שהעברת העבודה פועלת. אחרי שמקדמים את מסד הנתונים של היעד, אפשר לשנות את ההגדרה הנדרשת בצורה בטוחה. שירות העברת מסדי נתונים מבצע את השינויים הבאים במכונת היעד של Cloud SQL:- גיבוי ההגדרות מוגדר לערכי ברירת מחדל.
- שחזור מערכת מנקודה מסוימת בזמן מאופס לערכי ברירת המחדל.
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 מהייצוא, מוסיפים את הדגל --column-statistics=0 לפקודה mysqldump. מידע נוסף זמין במאמר ייצוא מסד נתונים של 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 במהלך תהליך הגיבוי.
פעולות שכדאי לנסות
אל תשנו טבלאות או תבצעו שינויים אחרים ב-DDL במהלך תהליך הגיבוי.אתם יכולים להשתמש בסקריפט כדי לוודא שפעולות ה-DDL הופסקו.
הגישה נדחתה. נדרשת הרשאת SUPER (לפחות אחת) כדי לבצע את הפעולה הזו
מוצגת השגיאה Access denied; you need (at least one of) the SUPER privilege(s) for this operation.
יכול להיות שהבעיה היא
יכול להיות שיש אירוע, תצוגה, פונקציה או פרוצדורה במסד הנתונים של המקור באמצעות משתמש סופר 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 נותק במהלך שאילתה בזמן יצירת dump של טבלה
מוצגת השגיאה Lost connection to MySQL server during query when dumping table.
יכול להיות שהבעיה היא
- יכול להיות שאי אפשר להגיע למופע של מסד הנתונים של המקור מהמופע של מסד הנתונים של היעד.
- יכול להיות שבמסד הנתונים של המקור יש טבלאות עם כתובות BLOB גדולות או מחרוזות ארוכות, ולכן צריך להגדיר את
max_allowed_packetלמספר גדול יותר במסד הנתונים של המקור.
פעולות שכדאי לנסות
- מוודאים שמופע מסד הנתונים של המקור פועל וניתן לגשת אליו.
- מגדירים את הדגל
max-allowed-packetבעבודת ההעברה, ואז מפעילים מחדש את עבודת ההעברה. אפשר גם ליצור גיבוי ידני באמצעות האפשרותmax_allowed_packetכדי לגבות את הנתונים ולבצע העברה באמצעות קובץ dump. - הגדלת
max_allowed_packetתדרוש כנראה שינוי של ההגדרותnet_read_timeoutו-net_write_timeoutבמסד הנתונים של המקור (בדרך כלל צריך להגדיל את הערך עד שהשגיאה בחיבור תיפסק).
Got packet bigger than 'max_allowed_packet' bytes when dumping table
מוצגת השגיאה 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.
- השגיאות משרשור הקלט/פלט או משרשור ה-SQL של MySQL מופיעות ב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 יורד לאפס
השימוש בדיסק יורד פתאום לאפס במהלך ההעברה.
יכול להיות שהבעיה היא
יכול להיות שיהיה כשל בייבוא של נתוני ה-dump המלאים. במקרה כזה, תהליך ההעברה ינסה לבצע טעינה נוספת של הנתונים. במהלך התהליך הזה, קודם נמחקים הנתונים הקיימים במופע היעד (לכן השימוש בדיסק יורד לאפס), ואז המערכת מנסה לטעון מחדש את הנתונים.
פעולות שכדאי לנסות
עוברים אל Logs Explorer ובוחרים את מופע היעד מהרשימה של המשאבים.
מחפשים הודעת יומן דומה:
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
מאתרים את ההודעה אחרי הטקסט import failed: ומנסים לפתור את הבעיה הבסיסית.