👩🏼‍🎨 🐈 💅🏽 MySQL (Percona Server) को 5.7 से 8.0 तक अपग्रेड करना 👨🏽‍🍳 ↗️ ◀️

प्रगति अभी भी स्थिर नहीं है, इसलिए MySQL के नवीनतम संस्करणों में अपग्रेड करने के कारण तेजी से महत्वपूर्ण होते जा रहे हैं। बहुत समय पहले नहीं, हमारी एक परियोजना में, आरामदायक पर्कोना सर्वर 5.7 क्लस्टर को संस्करण 8 में अपग्रेड करने का समय था। यह सब उबंटू लिनक्स 16.04 प्लेटफॉर्म पर हुआ। न्यूनतम डाउनटाइम के साथ एक समान ऑपरेशन कैसे करें और अपग्रेड के दौरान हमें क्या समस्याएं आईं - इस लेख को पढ़ें।

प्रशिक्षण

डेटाबेस सर्वर का कोई भी अपडेट डेटाबेस के माइग्रेशन से सबसे अधिक जुड़ा होता है: सिस्टम संसाधनों पर सीमा की आवश्यकताओं में बदलाव और डेटाबेस कॉन्फ़िगरेशन के सुधार, जो पुराने निर्देशों को साफ करना चाहिए।

अपडेट करने से पहले, हम निश्चित रूप से आधिकारिक दस्तावेज की ओर रुख करेंगे:

और एक कार्य योजना बनाएं:

अप्रचलित निर्देशों को हटाकर कॉन्फ़िगरेशन फ़ाइलों को ठीक करें।
उपयोगिताओं के साथ संगतता की जांच करें।
पैकेज स्थापित करके दास डेटाबेस अपडेट करें percona-server-server।
उसी पैकेज को लगाकर विज़ार्ड को अपडेट करें।

हम योजना में प्रत्येक आइटम का विश्लेषण करेंगे और देखेंगे कि क्या गलत हो सकता है।

जरूरी! गैलेरा आधारित MySQL क्लस्टर अपग्रेड प्रक्रिया की अपनी सूक्ष्मताएं हैं जो कि लेख में वर्णित नहीं हैं। आपको इस मामले में इस निर्देश का उपयोग नहीं करना चाहिए।

भाग 1: कन्फ़िगल्स की जाँच

संस्करण 8 में, MySQL को हटा दिया गया था 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।

सत्यापन के लिए हम 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: चल रहे प्रतिष्ठानों को सत्यापित करना

संगतता के लिए डेटाबेस की जाँच के लिए अद्यतन दस्तावेज़ में 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 नहीं था , क्योंकि यह केवल 4. के बजाय 3 बाइट्स संग्रहीत करता था। MySQL 8 में, उन्होंने अंत में इसे ठीक करने का फैसला किया : उपनाम utf8जल्द ही एन्कोडिंग utf8mb4और पुराने को जन्म देगा। तालिकाओं में कॉलम बन जाएंगे utf8mb3। भविष्य में, एन्कोडिंग utf8mb3को हटा दिया जाएगा, लेकिन इस रिलीज़ में नहीं। इसलिए, हमने इसे अद्यतन करने के बाद, डीबीएमएस की एक कार्यशील स्थापना पर पहले से ही एन्कोडिंग्स को ठीक करने का निर्णय लिया।

भाग 3: सर्वर अपडेट

इस तरह की ठाठ योजना होने पर क्या गलत हो सकता है? .. अच्छी तरह से पता है कि बारीकियां हमेशा होती हैं, हमने MySQL देव क्लस्टर पर पहला प्रयोग किया।

जैसा कि पहले ही उल्लेख किया गया है, आधिकारिक प्रलेखन प्रतिकृतियों के साथ MySQL सर्वर को अपडेट करने के मुद्दे पर प्रकाश डालता है। लब्बोलुआब यह है कि सबसे पहले यह सभी प्रतिकृतियों (दास) को अपडेट करने के लायक है, क्योंकि MySQL 8 संस्करण 5.7 विज़ार्ड से दोहरा सकता है। कुछ कठिनाई इस तथ्य में निहित है कि हम मास्टर <-> मास्टर मोड का उपयोग करते हैं जब दूरस्थ मास्टर केवल-पढ़ने के लिए मोड में होता है । यही है, वास्तव में, मुकाबला यातायात एक डेटा सेंटर में प्रवेश करता है, और दूसरा बैकअप है।

टोपोलॉजी इस प्रकार है:

अपग्रेड की शुरुआत mysql प्रतिकृति dc 2 प्रतिकृतियों से होनी चाहिए, mysql मास्टर डीसी 2 और mysql replica dc 1, और mysql मास्टर डीसी 1. सर्वर के साथ समाप्त होता है। बेहतर विश्वसनीयता के लिए, हमने वर्चुअल मशीनों को बंद कर दिया, स्नैपशॉट बना दिया, और अद्यतन से ठीक पहले कमांड के साथ प्रतिकृति को रोक दिया STOP SLAVE। बाकी अपडेट इस तरह दिखता है:

प्रत्येक प्रतिकृति पुनः आरंभ, config विकल्प 3 जोड़ने: skip-networking, skip-slave-start, skip-log-bin। तथ्य यह है कि डेटाबेस को अपडेट करने से सिस्टम टेबल को अपडेट करने के साथ बाइनरी लॉग उत्पन्न होता है। ये निर्देश गारंटी देते हैं कि डेटाबेस में एप्लिकेशन डेटा में कोई बदलाव नहीं होगा, और सिस्टम टेबल को अपडेट करने की जानकारी बाइनरी लॉग में नहीं मिलेगी। प्रतिकृति को फिर से शुरू करने पर यह समस्याओं से बचाएगा।
पैकेज स्थापित करें percona-server-server। यह ध्यान रखना महत्वपूर्ण है कि MySQL 8 में, आपको सर्वर को अपडेट करने के बाद कमांड चलाने की आवश्यकता नहींmysqlupgrade है।
एक सफल शुरुआत के बाद, सर्वर को फिर से पुनरारंभ करें - पहले पैरा में जोड़े गए मापदंडों के बिना पहले से ही।
हम सुनिश्चित करते हैं कि प्रतिकृति सफलतापूर्वक काम करती है: हम जांचते हैं 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

Google पर विभिन्न मेलिंग सूचियों के अभिलेखागार के एक अध्ययन से समझ में आया कि ऐसी समस्या MySQL बग के कारण उत्पन्न होती है । हालांकि बल्कि यह एक उपयोगिता बग mysqlcheckऔर भी है mysqlsh।

यह पता चला है कि MySQL ने दशमलव फ़ील्ड (int, smallint, आदि) के लिए डेटा प्रस्तुत करने के तरीके को बदल दिया है, इसलिए उन्हें संग्रहीत करने का एक और तरीका 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_SYS_TABLESPACES, यदि वे, टेबल 5.1 संस्करण में बनाए गए थे। अपग्रेड के दौरान समस्याओं से बचने के लिए, आप संलग्न एसक्यूएल स्क्रिप्ट का उपयोग कर सकते हैं ।

हमें देव पर ऐसी समस्याएँ क्यों नहीं हैं? आधार को समय-समय पर उत्पादन से कॉपी किया जाता है - इस प्रकार, तालिकाओं को फिर से बनाया जाता है ।

दुर्भाग्य से, वास्तव में काम कर रहे बड़े डेटाबेस पर यह सर्वव्यापी लेने और प्रदर्शन करने के लिए काम नहीं करेगा OPTIMIZE। पर्कोना-टूलकिट यहां मदद करेगा: पीटी-ऑनलाइन-स्कीमा-परिवर्तन उपयोगिता ऑनलाइन ऑप्टिमाइज़ ऑपरेशन के लिए उत्कृष्ट है।

अद्यतन योजना इस प्रकार थी:

सभी तालिकाओं का अनुकूलन करें।
डेटाबेस अपग्रेड करें।

इसे जांचने के लिए और उसी समय अद्यतन समय का पता लगाने के लिए, हमने प्रतिकृतियों में से एक को अक्षम कर दिया, और सभी तालिकाओं के लिए हमने निम्नलिखित कमांड को चलाया:

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 के मान के साथ एक तर्क जोड़ा - यह पैरामीटर डेटा के एक पैकेट को एक नई तालिका में स्थानांतरित करने के बाद प्रतीक्षा की लंबाई को नियंत्रित करता है। इस तरह से आप लोड को कम कर सकते हैं यदि वास्तव में चल रहे एप्लिकेशन प्रतिक्रिया समय की मांग कर रहे हैं।

अनुकूलन प्रदर्शन करने के बाद, अद्यतन सफल रहा।

... लेकिन पूरी तरह से नहीं!

अपडेट के आधे घंटे बाद, क्लाइंट एक समस्या लेकर आया। आधार ने बहुत अजीब काम किया: समय-समय पर, कनेक्शन की बूंदें शुरू हुईं । यहां यह देखा गया है कि मॉनिटरिंग में क्या देखा:

स्क्रीनशॉट में sawtooth ग्राफ दिखाई देता है, इस तथ्य के कारण कि MySQL सर्वर के थ्रेड्स का हिस्सा समय-समय पर एक त्रुटि के साथ गिरता है। त्रुटियां आवेदन में दिखाई दीं:

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

लॉग के एक त्वरित निरीक्षण से पता चला है कि मायस्कल्ड डेमन ऑपरेटिंग सिस्टम से आवश्यक संसाधन प्राप्त नहीं कर सका। त्रुटियों से निपटने के दौरान, हमने सिस्टम "अनाथ" एपरमोर पॉलिसी फाइलों में पाया :

# 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

आखिरकार

कोई भी, यहां तक कि सबसे सरल ऑपरेशन, अप्रत्याशित समस्याएं पैदा कर सकता है। और यहां तक कि एक सुविचारित योजना हमेशा अपेक्षित परिणाम की गारंटी नहीं देती है। अब, किसी भी अपडेट योजना में, हमारी टीम में अतिरिक्त फ़ाइलों की अनिवार्य सफाई भी शामिल है, जो हाल ही के कार्यों के परिणामस्वरूप दिखाई दे सकती हैं।

और इस नहीं-तो पेशेवर ग्राफिक काम के साथ, मैं Percona को उनके महान उत्पादों के लिए धन्यवाद देना चाहूंगा!

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

MySQL (Percona Server) को 5.7 से 8.0 तक अपग्रेड करना