שדרוגי גרסה ראשיים של MySQL – מדריך מלא

• RANK
• GROUPS
• VALUE
• SYSTEM

MySQL 8.0 → 8.4:

• תוסף mysql_native_password מושבת כברירת מחדל.
• מספר משתני מערכת הוסרו או שונו שמם.

למה בדיקת תאימות חשובה?

לפני השדרוג, אנחנו תמיד מריצים mysqlcheck ו-MySQL Shell Upgrade Checker – כלי המומלץ על ידי Oracle לאיתור בעיות לפני הגירה. כפי שצוין בתיעוד MySQL: "לפני השדרוג, תמיד הריצו את MySQL Shell Upgrade Checker".

mysqlcheck --all-databases --user=root --password --check-upgrade
mysqlsh root@localhost -e "util.checkForServerUpgrade('root@localhost:3306', {targetVersion: '8.0'})"

Shell Upgrade Checker מוצא:

• טבלאות עם סוגי נתונים לא תואמים
• שימוש בפונקציות SQL שהוסרו או שונו
• פרמטרי תצורה שהשתנו
• שמות בעייתיים (מילים שמורות)
• טבלאות בפורמט ROW_FORMAT מיושן

פלט אופייני למסד נתונים בעייתי:

1) Usage of old temporal type - table mydb.events: column event_time is using old temporal type
2) Usage of reserved keywords - table mydb.rank: 'rank' is a reserved keyword in MySQL 8.0
3) Tables with non-native partitioning - table mydb.logs uses MySQL 5.1 style partitioning (upgrade required)

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

שדרוג גרסה מרכזית של MySQL: איזו אסטרטגיה לבחור?

שדרוג במקום (In-place) – מתאים לסביבות לא קריטיות, מסדי נתונים קטנים. עצרו את MySQL 5.7, התקינו את MySQL 8.0 מעל, והתחילו. זה מהיר פי 5 מ-dump/restore, אבל מסוכן יותר – אין חזרה לאחור.

הגירה לוגית באמצעות dump – אמינה, אבל דורשת זמן השבתה יחסי לגודל מסד הנתונים. עבור מסדי נתונים גדולים (500+ GB), זמן ההשבתה יכול להגיע ליום, ולכן מועדפת רפליקציה.

רפליקציה לזמן השבתה אפסי – הקימו MySQL 8.0 כ-replica ל-MySQL 5.7 הקיים. MySQL 8.0 יכול להיות replica של 5.7 (ההפך אינו אפשרי). סנכרנו נתונים באמצעות רפליקציה, העבירו את היישום לשרת החדש, ואז הסירו את הישן. שיטה זו מצמצמת את זמן ההשבתה לשניות – פי 100 טוב יותר מאשר במקום.

# Пример: настройка репликации на MySQL 8.0
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.1',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='password',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

אסטרטגיה זו דורשת ש-MySQL 5.7 יהיה עם GTID מופעל. אם לא, השתמשו ב-SOURCE_LOG_FILE/POS.

מה לבדוק לאחר השדרוג?

ודאו שכל הטבלאות הומרו: הריצו mysqlcheck --all-databases --user=root --password --check-upgrade mysqlsh root@localhost -e "util.checkForServerUpgrade('root@localhost:3306', {targetVersion: '8.0'})"

בדקו תוספי אימות: 1) Usage of old temporal type - table mydb.events: column event_time is using old temporal type 2) Usage of reserved keywords - table mydb.rank: 'rank' is a reserved keyword in MySQL 8.0 3) Tables with non-native partitioning - table mydb.logs uses MySQL 5.1 style partitioning (upgrade required)

עדכנו משתמשים ל-caching_sha2_password (אם הלקוחות תומכים): # Пример: настройка репликации на MySQL 8.0 CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.1', SOURCE_USER='repl', SOURCE_PASSWORD='password', SOURCE_AUTO_POSITION=1; START REPLICA; או השאירו mysql_native_password ללקוחות legacy.

אילו פרמטרי תצורה צריך לעדכן?

חלק מהפרמטרים שעבדו ב-5.7 גורמים לשגיאות או מתעלמים מהם ב-8.0. הסירו מ-my.cnf:

• SELECT table_schema, table_name, row_format FROM information_schema.tables WHERE engine='InnoDB' AND row_format NOT IN ('Dynamic', 'Compressed') AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys'); (תמיד פעיל)
• SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password'; (הוסר)
• ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'password';, innodb_log_checksums (מטמון השאילתות הוסר ב-8.0)
• innodb_locks_unsafe_for_binlog → הוחלף ב-query_cache_size

MySQL 8.0 לא יתחיל אם my.cnf מכיל משתנים לא ידועים. Shell Upgrade Checker מוצא אותם מראש.

כיצד אנו מבצעים את ההגירה

התהליך שלנו מבוסס על שנים של ניסיון – יותר מ-50 פרויקטי הגירת MySQL. שלבים אופייניים:

1. ביקורת תאימות: הרצת Upgrade Checker, בדיקת סכמה, תצורה, ספריות לקוח.
2. בחירת אסטרטגיה: קביעה אם במקום, dump/restore או רפליקציה מתאימים ל-SLA שלכם.
3. יצירת סביבת בדיקה: הקמת עותק של מסד הנתונים, ביצוע הגירת בדיקה, בדיקת שגיאות.
4. הכנת חזרה לאחור: הגדרת גיבוי, שמירת תצורה.
5. הגירה בייצור: ביצוע לפי התוכנית, ניטור מדדים.
6. בדיקות לאחר הגירה: בדיקת ביצועים, פונקציונליות, שגיאות.
7. תיעוד: רישום שינויים, עדכון runbook, הדרכת הצוות שלכם.

מה כלול בשירות – שדרוג גרסה מרכזית של MySQL

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

לוחות זמנים ועלות

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

חזרה לאחור חירום

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

צרו קשר לייעוץ – נעריך את הפרויקט שלכם תוך יום. קבלו הצעה מסחרית עם תוכנית מפורטת.