प्रोहोस्टर > ब्लॉग > प्रशासन > MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

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

ट्रेनिंग

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

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

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

  1. पुराने निर्देशों को हटाकर कॉन्फ़िगरेशन फ़ाइलों को ठीक करें।
  2. उपयोगिताओं के साथ संगतता की जाँच करें।
  3. पैकेज स्थापित करके स्लेव डेटाबेस को अद्यतन करें percona-server-server.
  4. Обновить мастер, поставив тот же пакет.

आइए योजना के प्रत्येक बिंदु पर नजर डालें और देखें कि क्या गलत हो सकता है।

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

भाग 1: कॉन्फ़िगरेशन की जाँच करना

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

जाँच करने के लिए, हम पेरकोना सर्वर की डॉकर छवि का उपयोग करेंगे। हम सर्वर कॉन्फिगरेशन को डायरेक्टरी में रखेंगे mysql_config_test, और इसके आगे हम डेटा और लॉग के लिए निर्देशिकाएँ बनाएंगे। पेरकोना-सर्वर कॉन्फ़िगरेशन परीक्षण उदाहरण:

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 (परकोना सर्वर) को 5.7 से 8.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 (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

सामान्य तौर पर, कुछ भी महत्वपूर्ण नहीं - केवल एन्कोडिंग के बारे में चेतावनियाँ (निचे देखो). समग्र निष्पादन परिणाम:

MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

हमने तय किया कि अपडेट बिना किसी समस्या के होना चाहिए।

एन्कोडिंग के साथ समस्याओं का संकेत देने वाली उपरोक्त चेतावनियों के बारे में एक नोट। तथ्य यह है कि हाल तक MySQL में UTF-8 था यूटीएफ-8 "सही" नहीं था, क्योंकि यह 3 के बजाय केवल 4 बाइट्स संग्रहीत करता है। MySQL 8 में यह अंततः संभव है इसे ठीक करने का निर्णय लिया: उपनाम utf8 जल्द ही कोडिंग को बढ़ावा मिलेगा utf8mb4, और तालिकाओं में पुराने कॉलम बन जाएंगे utf8mb3. आगे एन्कोडिंग utf8mb3 हटा दिया जाएगा, लेकिन इस रिलीज़ में नहीं. इसलिए, हमने अद्यतन करने के बाद चल रहे DBMS इंस्टालेशन पर पहले से मौजूद एन्कोडिंग को ठीक करने का निर्णय लिया।

Часть 3: Обновление серверов

जब ऐसी स्मार्ट योजना हो तो क्या गलत हो सकता है?.. यह अच्छी तरह से समझते हुए कि बारीकियाँ हमेशा होती रहती हैं, हमने MySQL डेव क्लस्टर पर पहला प्रयोग किया।

जैसा कि पहले ही उल्लेख किया, आधिकारिक दस्तावेज प्रतिकृतियों के साथ MySQL सर्वर को अद्यतन करने के मुद्दे को शामिल किया गया है। लब्बोलुआब यह है कि आपको पहले सभी प्रतिकृतियों (दास) को अद्यतन करना चाहिए, क्योंकि MySQL 8 मास्टर संस्करण 5.7 से प्रतिकृति कर सकता है। कुछ कठिनाई इस तथ्य में निहित है कि हम मोड का उपयोग करते हैं master <-> master, когда удалённый мастер находится в режиме केवल पढ़ने के लिए. वास्तव में, लड़ाकू ट्रैफ़िक एक डेटा सेंटर में जाता है, और दूसरा बैकअप होता है।

Топология выглядит следующим образом:

MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

अद्यतन प्रतिकृतियों से प्रारंभ होना चाहिए MySQL प्रतिकृति डीसी 2, MySQL मास्टर डीसी 2 и mysql replica dc 1, और MySQL मास्टर डीसी 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 на production не обошёлся без сюрпризов.

सौभाग्य से, अद्यतन प्रक्रिया स्वयं प्रतिकृतियों से शुरू होती है, इसलिए जब हमें कठिनाइयों का सामना करना पड़ा, तो हमने काम रोक दिया और स्नैपशॉट से प्रतिकृति को पुनर्स्थापित किया। समस्याओं की जाँच अगली सुबह तक के लिए स्थगित कर दी गई। लॉग में निम्नलिखित प्रविष्टियाँ थीं:

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-सर्वर उन्हें संग्रहीत करने के लिए एक अलग तरीके का उपयोग करता है। यदि आपका डेटाबेस शुरू में संस्करण 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. पेरकोना-टूलकिट यहां मदद करेगा: पीटी-ऑनलाइन-स्कीमा-चेंज उपयोगिता ऑनलाइन ऑप्टिमाइज़ ऑपरेशन के लिए उत्कृष्ट है।

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

  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 (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

स्क्रीनशॉट इस तथ्य के कारण एक सॉटूथ ग्राफ़ दिखाता है कि कुछ 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

अंत में

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

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

MySQL (परकोना सर्वर) को 5.7 से 8.0 तक अपडेट किया जा रहा है

पुनश्च

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

स्रोत: www.habr.com

एक टिप्पणी जोड़ें