פתרון בעיות בשדרוג של גרסה ראשית במקום ל-MySQL 8.0

בדף הזה מתוארות בעיות ידועות ואי-תאימויות שאפשר להיתקל בהן במהלך פעולות של בדיקה מוקדמת כשמבצעים שדרוג של גרסה ראשית מ-Cloud SQL ל-MySQL 5.7 ל-Cloud SQL ל-MySQL 8.0.

מידע נוסף על שדרוג גרסה ראשית זמין במאמרים שדרוג גרסה ראשית של מסד נתונים במקום וצפייה ביומני שגיאות.

שינויים לא תואמים ב-SQL

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

מילות מפתח שמורות

השגיאה הבאה מתרחשת כשמנסים להשתמש במילת מפתח שמורה:

Warning: The following objects have names that conflict with new reserved
keywords. Ensure queries sent by your applications use `quotes` when referring
to them or they will result in errors.

השגיאה הזו מתרחשת אם מנסים להשתמש במילות מפתח שמסווגות עכשיו ככאלה ששמורות ב-MySQL בגרסה 8.0, כמו מילות המפתח הבאות:

• GROUPS
• LEAD
• RANK

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

רשימת מילות המפתח המלאה זמינה במאמר מילות מפתח ומילים שמורות.

הוסרה ASC/DESC עם פסקה GROUP BY

השגיאה הבאה מתרחשת כשמנסים להשתמש ב-ASC/DESC עם הסעיף GROUP BY:

[ERROR] [MY-013235] [Server] Error in parsing Routine db_name.routine_name during
upgrade. You may have an error in your SQL syntax; check the manual that
corresponding to your MySQL server version for the right syntax to use near
'some_text'

הנה עוד הודעת שגיאה שיכולה להופיע במקרה הזה:

[ERROR] [MY-013235] [Server] Unknown trigger has an error in its body: 'You have
an error in you SQL syntax;
[ERROR] [MY-010198] [Server] Error in parsing Triggers from trigger_name.TRG file.

השגיאה הזו מתרחשת אם מנסים למיין את השאילתה באמצעות GROUP BY.

שאילתות שהסתמכו בעבר על מיון GROUP BY יכולות להניב תוצאות שונות מגרסאות קודמות של MySQL. כדי לשמור על סדר מיון מסוים, צריך לספק פסקה של ORDER BY.

כדי לפתור את הבעיה, משתמשים בסעיף ORDER BY. לדוגמה, אם הגדרה של אירוע, טריגר או פרוצדורה מאוחסנת מכילה שאילתה שמשתמשת ב-ASC או ב-DESC עם פסקה GROUP BY, השאילתה של האובייקט הזה צריכה פסקה ORDER BY.

מידע נוסף זמין במאמר הסרת התחביר של GROUP BY ASC ו-DESC.

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

השגיאה הבאה מתרחשת כשמשתמשים במקש הקידומת הלא נכון:

[ERROR] [MY-013140] [Server] Incorrect prefix key; the used key part isn't a
string, the used length is longer than the key part, or the storage engine doesn't
support unique prefix keys
[ERROR] [MY-013140] [Server] Too many key parts specified; max 1 parts allowed

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

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

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

  SELECT
      s.TABLE_SCHEMA,
      s.TABLE_NAME,
      s.INDEX_NAME,
      s.COLUMN_NAME,
      s.INDEX_TYPE,
      c.DATA_TYPE
  FROM
      information_schema.STATISTICS s
  JOIN
      information_schema.COLUMNS c ON s.TABLE_SCHEMA = c.TABLE_SCHEMA
      AND s.TABLE_NAME = c.TABLE_NAME
      AND s.COLUMN_NAME = c.COLUMN_NAME
  WHERE
      c.DATA_TYPE IN (
          'geometry',
          'point',
          'linestring',
          'polygon',
          'multipoint',
          'multilinestring',
          'multipolygon',
          'geometrycollection'
      )
      AND s.INDEX_TYPE = 'BTREE';

תווים לא תקינים בפורמט UTF8

השגיאה הבאה מתרחשת כשמשתמשים במחרוזות של תווים לא חוקיים בקידוד UTF8:

[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s
[ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string

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

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

כדי לזהות תווים לא חוקיים ולטפל בהם, אפשר להשתמש בשאילתה דומה לזו שבהמשך:

SHOW CREATE TABLE table_name;

ALTER TABLE table_name MODIFY COLUMN column_name data_type comment='';
// removing invalid utf8 character from comment

עסקאות XA שלא בוצעו

השגיאה הבאה מתרחשת כשיש טרנזקציות XA מוכנות קיימות:

[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions

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

כדי לפתור את הבעיה, צריך להריץ את ההצהרה XA RECOVER לפני השלמת השדרוג. ההצהרה הזו בודקת עסקאות XA שלא בוצעו.

אם מוחזרת תשובה, צריך לבצע commit לעסקאות XA באמצעות הפקודה XA COMMIT או לבצע rollback לעסקאות XA באמצעות הפקודה XA ROLLBACK.

כדי לבדוק טרנזקציות XA קיימות, אפשר להריץ פקודה שדומה לזו:

  mysql> XA RECOVER CONVERT xid;
  +----------+--------------+--------------+--------------------------
  | formatID | gtrid_length | bqual_length | data |
  +----------+--------------+--------------+--------------------------
  | 787611   | 9            | 9            | 0x787887111212345678812676152F12345678 |
  +----------+--------------+--------------+--------------------------
  1 row in set (0.00 sec)
  

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

• gtrid = 0x787887111212345678
• bqual = 0x812676152F12345678

כדי לבצע (commit) או לבטל (rollback) את טרנזקציות ה-XA האלה, אפשר ליצור xid מהמידע הזה באמצעות פקודה שדומה לפקודה הבאה:

xid: gtrid [, bqual [, formatID ]]

mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;

חריגה מאורך המפתח המקסימלי

השגיאה הבאה מתרחשת כשמפתח שצוין ארוך מדי:

[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes

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

הבעיה הזו יכולה להיגרם בגלל ההגדרה של sql_mode. ב-MySQL בגרסה 5.7, היעדר מצבים קפדניים הוביל לכך שאפשר היה ליצור אינדקסים עם הגבלה על קידומת או על אורך האינדקס.

עם זאת, ב-MySQL גרסה 8.0, הוצגו מצבים מחמירים כמו STRICT_ALL_TABLES או STRICT_TRANS_TABLES שבהם הוחלו כללים מחמירים יותר על אורך האינדקס, ולכן השגיאה הזו מתרחשת.

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

חוסר התאמה בפרטי המטא-נתונים

השגיאה הבאה מתרחשת כשיש חוסר התאמה במטא-נתונים:

[ERROR] [MY-012084] [InnoDB] Num of Indexes in InnoDB doesn't match with Indexes from server
[ERROR] [MY-012069] [InnoDB] table: TABLE_NAME has xx columns but InnoDB dictionary has yy columns

הנה עוד הודעת שגיאה שיכולה להופיע במקרה הזה:

[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name

השגיאה הזו מתרחשת אם מנסים לשדרג טבלאות עם מטא-נתונים לא תואמים.

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

למידע נוסף, אפשר לעיין במאמר בנושא ניסיון לשדרג טבלאות עם מטא-נתונים לא תואמים.

כדי לבצע dump ולשחזר את הטבלאות שהושפעו, אפשר להריץ פקודה שדומה לזו:

mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql

mysql> source database_dump.sql;

שם המפתח הזר מכיל יותר מ-64 תווים

השגיאה הבאה מתרחשת כשמנסים להשתמש בשם של אילוץ מפתח זר שהוא ארוך מדי:

[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long

השגיאה הזו מתרחשת אם שם המפתח הזר ארוך מ-64 תווים.

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

SELECT CONSTRAINT_NAME, TABLE_NAME
FROM information_schema.REFERENTIAL_CONSTRAINTS
WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;

אם שם האילוץ בטבלה מכיל יותר מ-64 תווים, צריך להשתמש בפקודה ALTER TABLE כדי לשנות את שם האילוץ כך שלא יעבור את מגבלת התווים:

ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;

טבלאות יתומות

טבלאות יתומות עלולות לגרום לבעיות רבות.

לקבלת עזרה מפורטת בפתרון בעיות, אפשר לעיין במאמר בנושא טבלאות יתומות.

אי התאמה בין אותיות רישיות לאותיות קטנות בשמות של טבלאות

השגיאה הבאה מתרחשת כשלא משתמשים בשמות מדויקים של טבלאות:

[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.

השגיאה הזו מתרחשת אם יש הבדלים בין האותיות הרישיות בשמות הטבלאות.

כדי לפתור את הבעיה הזו, אם במכונות ב-MySQL גרסה 5.7 נדרש שימוש באותיות קטנות בשמות הטבלאות (lower_case_table_names=1), צריך להמיר את כל שמות הטבלאות לאותיות קטנות לפני השדרוג ל-MySQL גרסה 8.0.

לחלופין, אפשר להשבית את הדרישה (lower_case_table_names=0) ואז לשדרג את המופע. חשוב לזכור: אם משנים את הערך של השדה lower_case_table_names מ-1 ל-0, אי אפשר לשנות את הערך בחזרה ב-MySQL גרסה 8.0.

טבלאות שזוהו על ידי InnoDB ושייכות למנוע אחר

השגיאה הבאה מתרחשת כשInnoDB מזהה טבלה, אבל היא שייכת למנוע אחר:

Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removed InnoDB files manually from the disk and creates a table with same name by using different engine.

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

אם יש טבלאות במסד הנתונים שמנוע InnoDB מזהה אבל שכבת ה-SQL לא מזהה, השדרוג ייכשל.

כדי לפתור את הבעיה, צריך למצוא את כל הטבלאות במסד הנתונים שלא משתמשות במנוע האחסון InnoDB:

SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'

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

ALTER TABLE db_name.table_name ENGINE='INNODB';

מנוע אחסון לא ידוע partition

השגיאה הבאה מתרחשת כשמנסים להשתמש במנוע אחסון לא מוכר:

[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'

השגיאה הזו מתרחשת אם יש מחיצות לא נתמכות במנוע.

ב-MySQL גרסה 8.0 מותרות רק המחיצות הבאות במנוע האחסון:

• InnoDB
• ndbcluster

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

כדי לזהות את הטבלאות האלה, משתמשים בשאילתה הבאה:

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';

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

ALTER TABLE db_name.table_name ENGINE = INNODB;

פעולת MVU פועלת למשך זמן ארוך יותר

יש שני סוגים של משימות שקשורות לשדרוג גרסה ראשית:

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

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

• מספר גדול מאוד של טבלאות, תצוגות או אינדקסים
• משאבים לא מספיקים, כמו מעבד (CPU) או זיכרון
• עסקאות גדולות שמונעות את כיבוי מסדי הנתונים כדי להתחיל את תהליך השדרוג. אפשר להשתמש במסוף Cloud de Confiance by S3NS כדי לבדוק את התהליכים הנוכחיים.

יותר מדי קבצים פתוחים במערכת

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

[ERROR] [MY-012592] [InnoDB] Operating system error number 23 in a file operation
[ERROR] [MY-012596] [InnoDB] Error number 23 means 'Too many open files in system'

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

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

שגיאה של חוסר זיכרון

השגיאה הבאה מתרחשת כשנגמר הזיכרון:

Out of memory

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

כשמשדרגים מ-MySQL 5.7 ל-8.0, נדרש זיכרון נוסף כדי להמיר מטא נתונים ישנים למילון הנתונים החדש.

כדי לפתור את הבעיה, מומלץ להקצות לכל טבלה זיכרון של 100 KB לפחות.

כדי למצוא את מספר הטבלאות, משתמשים בשאילתה הבאה:

SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables

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

במקרים של ליבות משותפות (לדוגמה, ליבות micro או small, כולל db-f1-micro, db-g1-small, HA db-f1-micro, HA db-g1-small), מומלץ לשדרג לליבה ייעודית במהלך פעולת השדרוג כדי למנוע בעיות פוטנציאליות שקשורות למשאבים. אפשר לשנמך את המהדורה אחרי שהשדרוג יסתיים.

שגיאה בהשבתה של MySQL

השגיאה הבאה מתרחשת כשמנסים לשדרג אחרי קריסה:

[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.

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

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

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

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

• שדרוג של הגרסה הראשית של מסד הנתונים במקום