עדכון MySQL (שרת פרקונה) מ-5.7 ל-8.0

ההתקדמות אינה עומדת במקום, כך שהסיבות לשדרוג לגרסאות האחרונות של MySQL הופכות למשכנעות יותר ויותר. לא מזמן, באחד הפרויקטים שלנו, הגיע הזמן לעדכן את האשכולות הנעים של Percona Server 5.7 לגרסה 8. כל זה קרה בפלטפורמת Ubuntu Linux 16.04. כיצד לבצע פעולה כזו במינימום זמן השבתה ובאילו בעיות נתקלנו במהלך העדכון - קראו במאמר זה.

הדרכה

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

לפני העדכון, בהחלט נפנה לתיעוד הרשמי:

• הערות שחרור של MySQL 8;
• מדריך לשדרוג MySQL;
• מדריך עדכון של Percona;
• מדריך MySQL לעדכון העתקים ומאסטרים.

ובואו נערוך תוכנית פעולה:

1. תקן קבצי תצורה על ידי הסרת הנחיות מיושנות.
2. בדוק תאימות עם כלי עזר.
3. עדכן מסדי נתונים של עבדים על ידי התקנת החבילה percona-server-server.
4. עדכן את המאסטר עם אותה חבילה.

בואו נסתכל על כל נקודה בתוכנית ונראה מה יכול להשתבש.

חשוב! להליך עדכון אשכול MySQL המבוסס על Galera יש דקויות משלו שאינן מתוארות במאמר. אין להשתמש בהוראה זו במקרה זה.

חלק 1: בדיקת הגדרות

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

גם בתצורה היו הנחיות מיושנות לגבי innodb_file_format. אם ב-MySQL 5.7 היה אפשר לבחור בפורמט InnoDB, אז הגרסה ה-8 כבר עובדת רק עם פורמט ברקודה.

התוצאה שלנו היא הסרת ההנחיות הבאות:

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

כדי לבדוק, נשתמש בתמונת Docker של Percona Server. אנו נמקם את תצורת השרת בספרייה mysql_config_test, ולצדו ניצור ספריות לנתונים וליומנים. דוגמה לבדיקת תצורת שרת Percona:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

בשורה התחתונה: או ב-Docker logs או בספריה עם ה-logs - תלוי בהגדרות שלך - יופיע קובץ שבו יתוארו ההנחיות הבעייתיות.

הנה מה שהיה לנו:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

לפיכך, עדיין היינו צריכים להבין את הקידודים ולהחליף את ההנחיה המיושנת expire-logs-days.

חלק 2: בדיקת התקנות תקינות

תיעוד העדכון מכיל 2 כלי עזר לבדיקת תאימות למסד הנתונים. השימוש בהם עוזר למנהל לבדוק את התאימות של מבנה הנתונים הקיים.

נתחיל עם כלי השירות הקלאסי mysqlcheck. פשוט הפעל:

mysqlcheck -u root -p --all-databases --check-upgrade

אם לא נמצאו בעיות, כלי השירות ייצא עם קוד 0:

בנוסף, כלי עזר זמין בגרסאות מודרניות של MySQL mysql-shell (במקרה של Percona זו החבילה percona-mysql-shell). הוא מהווה תחליף ללקוח mysql הקלאסי ומשלב את הפונקציות של לקוח, עורך קוד SQL וכלי ניהול MySQL. כדי לבדוק את השרת לפני העדכון, אתה יכול להפעיל את הפקודות הבאות דרכו:

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

להלן התגובות שקיבלנו:

באופן כללי, שום דבר קריטי - רק אזהרות לגבי קידודים (ראה למטה). תוצאת ביצוע כוללת:

החלטנו שהעדכון יעבור ללא בעיות.

הערה לגבי האזהרות לעיל המציינת בעיות עם קידודים. העובדה היא כי UTF-8 ב-MySQL עד לאחרונה לא היה UTF-8 "אמיתי"., מכיוון שהוא אחסן רק 3 בתים במקום 4. ב-MySQL 8 זה סוף סוף אפשרי החליט לתקן את זה: כינוי utf8 בקרוב יוביל לקידוד utf8mb4, והעמודות הישנות בטבלאות יהפכו utf8mb3. קידוד נוסף utf8mb3 יוסר, אך לא במהדורה זו. לכן, החלטנו לתקן את הקידודים כבר בהתקנת ה-DBMS הפועלת, לאחר שעדכנו אותה.

חלק 3: עדכוני שרת

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

כאמור, תיעוד רשמי מכסה את הנושא של עדכון שרתי MySQL עם העתקים. השורה התחתונה היא שתחילה עליך לעדכן את כל ההעתקים (עבדים), שכן MySQL 8 יכול לשכפל מגרסה מאסטר 5.7. קושי מסוים טמון בעובדה שאנו משתמשים במצב מאסטר <-> מאסטר, כאשר המאסטר המרוחק במצב לקריאה בלבד. כלומר, למעשה, תעבורת קרב עוברת למרכז נתונים אחד, והשני הוא גיבוי.

הטופולוגיה נראית כך:

העדכון חייב להתחיל עם העתקים mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, ולסיים בשרת mysql master dc 1. כדי להיות יותר אמין, עצרנו את המכונות הווירטואליות, צילמנו אותן ומיד לפני העדכון הפסקנו את השכפול עם הפקודה STOP SLAVE. שאר העדכון נראה כך:

1. אנו מפעילים מחדש כל עותק על ידי הוספת 3 אפשרויות להגדרות: skip-networking, skip-slave-start, skip-log-bin. העובדה היא שעדכון מסד הנתונים יוצר יומנים בינאריים עם עדכונים לטבלאות המערכת. הנחיות אלו מבטיחות שלא יהיו שינויים בנתוני האפליקציה במסד הנתונים, ומידע על עדכון טבלאות מערכת לא ייכלל ביומנים הבינאריים. זה ימנע בעיות בעת חידוש השכפול.
2. התקנת החבילה percona-server-server. חשוב לציין שב-MySQL גרסה 8 לא אתה צריך להפעיל את הפקודה mysqlupgrade לאחר עדכון השרת.
3. לאחר התחלה מוצלחת, אנו מפעילים מחדש את השרת מחדש - ללא הפרמטרים שנוספו בפסקה הראשונה.
4. אנו מוודאים שהשכפול עובד בהצלחה: בדוק SHOW SLAVE STATUS ולראות שהטבלאות עם מונים במסד הנתונים של האפליקציות מעודכנות.

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

לא היה עצב - עדכנו את הפרוד

עם זאת, העברת חוויית הפיתוח המוצלחת לייצור לא הייתה נטולת הפתעות.

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

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

מחקר בארכיונים של רשימות תפוצה שונות בגוגל הוביל להבנה כי בעיה זו מתרחשת עקב באג MySQL. למרות שסביר יותר שזה באג שירות mysqlcheck и mysqlsh.

מסתבר ש-MySQL שינתה את האופן שבו הם מייצגים נתונים עבור שדות עשרוניים (int, tinyint וכו'), אז mysql-server משתמש בדרך אחרת לאחסון אותם. אם מסד הנתונים שלך בתחילה היה בגרסה 5.5 או 5.1, ולאחר מכן עדכנת ל-5.7, אז אולי תצטרך לעשות OPTIMIZE עבור כמה שולחנות. אז MySQL תעדכן את קבצי הנתונים, תעביר אותם לפורמט האחסון הנוכחי.

אתה יכול גם לבדוק זאת עם כלי השירות mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

אם field_type אם יש לך אותו שווה 0, אז הסוג הישן משמש בטבלה - אתה צריך לבצע OPTIMIZE. עם זאת, אם הערך הוא 246, כבר יש לך סוג חדש. מידע נוסף על הסוגים ניתן למצוא ב קוד.

יתר על כן, ב הבאג הזה אנו שוקלים את הסיבה האפשרית השנייה, שעקפה אותנו: היעדר טבלאות InnoDB בטבלת המערכת INNODB_SYS_TABLESPACES, אם הם, טבלאות, נוצרו בגרסה 5.1. כדי למנוע בעיות בעת עדכון, אתה יכול להשתמש סקריפט SQL מצורף.

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

למרבה הצער, במסד נתונים גדול שעובד באמת, לא תוכל פשוט לקחת ולבצע אוניברסלי OPTIMIZE. percona-toolkit יעזור כאן: כלי השירות pt-online-schema-change מצוין לפעולת OPTIMIZE המקוונת.

התוכנית המעודכנת נראתה כך:

1. בצע אופטימיזציה של כל הטבלאות.
2. עדכן את מסדי הנתונים.

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

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

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

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

לאחר ביצוע האופטימיזציה, העדכון הצליח.

... אבל לא לגמרי!

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

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

[PDOException] SQLSTATE[HY000] [2002] Connection refused

בדיקה מהירה של היומנים גילתה שהדמון mysqld לא יכול להשיג את המשאבים הנדרשים ממערכת ההפעלה. תוך כדי מיון שגיאות, גילינו במערכת קבצי מדיניות לבוש "יתומים".:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

קבצים אלו נוצרו בעת שדרוג ל-MySQL 5.7 לפני מספר שנים ושייכים לחבילה שהוסרה. מחיקת הקבצים והפעלה מחדש של שירות apparmor פתרו את הבעיה:

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

לסיכום

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

ועם היצירתיות הגרפית הלא כל כך מקצועית הזו, אני רוצה להגיד תודה ענקית לפרקונה על המוצרים המעולים שלהם!

נ.ב.

קרא גם בבלוג שלנו:

• «מסדי נתונים ו-Kubernetes (סקירה ודוח וידאו)";
• «עצות וטריקים של Kubernetes: זירוז אתחול עבור מסדי נתונים גדולים";
• «6 סיפורים מעשיים מחיי היומיום שלנו ב-SRE";
• «סיפור אחד עם מפעיל Redis ב-K8s ומיני סקירה של כלי עזר לניתוח נתונים ממסד נתונים זה";
• «העברה חלקה של MongoDB ל-Kubernetes".

מקור: www.habr.com