MySQL (Percona सर्व्हर) 5.7 ते 8.0 पर्यंत अपडेट करत आहे

प्रगती स्थिर नाही, त्यामुळे MySQL च्या नवीनतम आवृत्त्यांमध्ये अपग्रेड करण्याची कारणे अधिकाधिक आकर्षक होत आहेत. काही काळापूर्वी, आमच्या एका प्रकल्पात, आरामदायक पर्कोना सर्व्हर 5.7 क्लस्टर्स आवृत्ती 8 वर अद्यतनित करण्याची वेळ आली होती. हे सर्व उबंटू लिनक्स 16.04 प्लॅटफॉर्मवर घडले. कमीतकमी डाउनटाइमसह असे ऑपरेशन कसे करावे आणि अद्यतनादरम्यान आम्हाला कोणत्या समस्या आल्या - या लेखात वाचा.

प्रशिक्षण

डेटाबेस सर्व्हरचे कोणतेही अद्यतन बहुधा डेटाबेस पुनर्संरचनाशी संबंधित असते: सिस्टम संसाधनावरील मर्यादा आणि डेटाबेस कॉन्फिगच्या सुधारणेसाठी आवश्यकतांमध्ये बदल ज्यांना कालबाह्य निर्देशांपासून मुक्त करणे आवश्यक आहे.

अद्ययावत करण्यापूर्वी, आम्ही निश्चितपणे अधिकृत कागदपत्रांचा संदर्भ घेऊ:

• MySQL 8 रिलीझ नोट्स;
• MySQL अपग्रेड मार्गदर्शक;
• Percona अद्यतन मार्गदर्शक;
• प्रतिकृती आणि मास्टर्स अद्यतनित करण्यासाठी MySQL मार्गदर्शक.

आणि एक कृती योजना तयार करूया:

1. कालबाह्य निर्देश काढून कॉन्फिगरेशन फाइल्स दुरुस्त करा.
2. उपयुक्तता सह सुसंगतता तपासा.
3. पॅकेज स्थापित करून स्लेव्ह डेटाबेस अद्यतनित करा percona-server-server.
4. त्याच पॅकेजसह मास्टर अद्यतनित करा.

चला योजनेच्या प्रत्येक बिंदूकडे पाहू आणि काय चूक होऊ शकते ते पाहू.

महत्वाचे! Galera वर आधारित MySQL क्लस्टर अद्यतनित करण्याच्या प्रक्रियेची स्वतःची सूक्ष्मता आहे ज्याचे लेखात वर्णन केलेले नाही. आपण या प्रकरणात ही सूचना वापरू नये.

भाग 1: कॉन्फिगरेशन तपासत आहे

MySQL आवृत्ती 8 मध्ये काढून टाकण्यात आले query_cache. प्रत्यक्षात तो होता अप्रचलित घोषित केले आवृत्ती 5.7 मध्ये परत, पण आता पूर्णपणे हटवले. त्यानुसार, संबंधित निर्देश काढून टाकणे आवश्यक आहे. आणि विनंत्या कॅशे करण्यासाठी तुम्ही आता बाह्य साधने वापरू शकता - उदाहरणार्थ, प्रॉक्सीएसक्यूएल.

तसेच कॉन्फिगरेशनमध्ये कालबाह्य निर्देश होते innodb_file_format. जर MySQL 5.7 मध्ये InnoDB फॉरमॅट निवडणे शक्य असेल, तर 8 वी आवृत्ती आधीपासूनच कार्य करते फक्त बॅराकुडा फॉरमॅटसह.

खालील निर्देश काढून टाकणे हा आमचा परिणाम आहे:

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

तपासण्यासाठी, आम्ही Percona सर्व्हरची डॉकर प्रतिमा वापरू. आम्ही डिरेक्टरीमध्ये सर्व्हर कॉन्फिगरेशन ठेवू 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

तळ ओळ: एकतर डॉकर लॉगमध्ये किंवा लॉगसह निर्देशिकेत - तुमच्या कॉन्फिगरेशनवर अवलंबून - एक फाइल दिसेल ज्यामध्ये समस्याग्रस्त निर्देशांचे वर्णन केले जाईल.

आमच्याकडे जे होते ते येथे आहे:

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 उपयुक्तता आहेत. त्यांचा वापर प्रशासकास विद्यमान डेटा संरचनेची सुसंगतता तपासण्यास मदत करतो.

चला क्लासिक mysqlcheck युटिलिटीसह प्रारंभ करूया. फक्त चालवा:

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

कोणतीही समस्या न आढळल्यास, युटिलिटी कोड 0 सह बाहेर पडेल:

याव्यतिरिक्त, MySQL च्या आधुनिक आवृत्त्यांमध्ये एक उपयुक्तता उपलब्ध आहे mysql-शेल (पर्कोनाच्या बाबतीत हे पॅकेज आहे 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

आम्हाला मिळालेल्या टिप्पण्या येथे आहेत:

सर्वसाधारणपणे, काहीही गंभीर नाही - फक्त एन्कोडिंगबद्दल चेतावणी (खाली पहा). एकूण अंमलबजावणी परिणाम:

आम्ही ठरवले की अद्यतन समस्यांशिवाय जावे.

एन्कोडिंगमधील समस्या दर्शविणारी वरील इशाऱ्यांबद्दलची एक टीप. वस्तुस्थिती अशी आहे की अलीकडे पर्यंत MySQL मध्ये UTF-8 UTF-8 "सत्य" नव्हते, कारण ते 3 ऐवजी फक्त 4 बाइट संचयित करते. MySQL 8 मध्ये हे शेवटी आहे निराकरण करण्याचा निर्णय घेतला: उर्फ utf8 लवकरच कोडिंगकडे नेईल utf8mb4, आणि टेबलमधील जुने स्तंभ बनतील utf8mb3. पुढील एन्कोडिंग utf8mb3 काढले जाईल, परंतु या प्रकाशनात नाही. म्हणून, आम्ही चालू असलेल्या डीबीएमएस इंस्टॉलेशनवर आधीपासूनच अपडेट केल्यानंतर, एन्कोडिंग दुरुस्त करण्याचा निर्णय घेतला.

भाग 3: सर्व्हर अद्यतने

अशी स्मार्ट योजना असताना काय चूक होऊ शकते?.. बारकावे नेहमी घडतात हे पूर्णपणे समजून घेऊन, आम्ही MySQL डेव्ह क्लस्टरवर पहिला प्रयोग केला.

आधीच नमूद केल्याप्रमाणे, अधिकृत दस्तऐवजीकरण प्रतिकृतीसह MySQL सर्व्हर अद्यतनित करण्याच्या समस्येचा समावेश आहे. सर्वात महत्त्वाची ओळ अशी आहे की तुम्ही प्रथम सर्व प्रतिकृती (स्लेव्ह) अद्यतनित केल्या पाहिजेत, कारण MySQL 8 मास्टर आवृत्ती 5.7 वरून प्रतिकृती बनवू शकते. आम्ही मोड वापरतो या वस्तुस्थितीत काही अडचण आहे मास्टर <-> मास्टर, जेव्हा रिमोट मास्टर मोडमध्ये असतो फक्त वाचा. म्हणजेच, खरं तर, लढाऊ रहदारी एका डेटा सेंटरकडे जाते आणि दुसरा बॅकअप असतो.

टोपोलॉजी असे दिसते:

अद्यतन प्रतिकृतींसह सुरू होणे आवश्यक आहे mysql प्रतिकृती dc 2, mysql मास्टर 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 आणि ऍप्लिकेशन डेटाबेसमधील काउंटरसह टेबल अपडेट केलेले पहा.

हे सर्व अगदी सोपे दिसते: dev अद्यतन यशस्वी झाले. ठीक आहे, तुम्ही उत्पादनासाठी रात्रीचे अपडेट सुरक्षितपणे शेड्यूल करू शकता.

कोणतेही दुःख नव्हते - आम्ही उत्पादन अद्यतनित केले

तथापि, यशस्वी देव अनुभवाचे उत्पादनात हस्तांतरण आश्चर्यकारक नव्हते.

सुदैवाने, अद्यतन प्रक्रिया स्वतःच प्रतिकृतींपासून सुरू होते, म्हणून जेव्हा आम्हाला अडचणी आल्या तेव्हा आम्ही काम थांबवले आणि स्नॅपशॉटमधून प्रतिकृती पुनर्संचयित केली. समस्यांची तपासणी दुसऱ्या दिवशी सकाळपर्यंत पुढे ढकलण्यात आली. लॉगमध्ये खालील नोंदी होत्या:

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

Google वरील विविध मेलिंग लिस्टच्या संग्रहणांचे संशोधन केल्याने ही समस्या उद्भवते हे समजू शकले 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 स्क्रिप्ट.

देवावर अशी समस्या का आली नाही? डेटाबेस वेळोवेळी उत्पादनातून कॉपी केला जातो - अशा प्रकारे, टेबल पुन्हा तयार केले जातात.

दुर्दैवाने, खरोखर कार्यरत असलेल्या मोठ्या डेटाबेसवर, आपण फक्त एक सार्वत्रिक घेऊ आणि कार्यान्वित करू शकणार नाही 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 वर अपग्रेड करताना तयार केल्या होत्या आणि काढलेल्या पॅकेजच्या आहेत. फायली हटविणे आणि अॅपर्मर सेवा रीस्टार्ट केल्याने समस्येचे निराकरण झाले:

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

शेवटी

कोणतीही, अगदी सोपी ऑपरेशनमुळे अनपेक्षित समस्या उद्भवू शकतात. आणि सुविचारित योजना असल्‍यानेही नेहमी अपेक्षित परिणामाची हमी मिळत नाही. आता, आमच्या कार्यसंघाच्या कोणत्याही अद्ययावत योजनांमध्ये अलीकडील कृतींच्या परिणामी दिसू शकणाऱ्या अनावश्यक फाइल्सची अनिवार्य साफसफाईचा देखील समावेश आहे.

आणि या अतिशय व्यावसायिक ग्राफिक सर्जनशीलतेसह, मी पर्कोनाला त्यांच्या उत्कृष्ट उत्पादनांसाठी खूप खूप धन्यवाद म्हणू इच्छितो!

PS

आमच्या ब्लॉगवर देखील वाचा:

• «डेटाबेस आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «Kubernetes टिपा आणि युक्त्या: मोठ्या डेटाबेससाठी बूटस्ट्रॅपचा वेग वाढवणे";
• «आमच्या SRE दैनंदिन जीवनातील 6 व्यावहारिक कथा";
• «K8s मधील Redis ऑपरेटरसह एक कथा आणि या डेटाबेसमधील डेटाचे विश्लेषण करण्यासाठी उपयुक्ततेचे एक लहान-पुनरावलोकन";
• «मोंगोडीबीचे कुबर्नेट्समध्ये अखंड स्थलांतर».

स्त्रोत: www.habr.com