MySQL 8.0 काफी समय से हमारे साथ है और कई MySQL उपयोगकर्ता पहले ही इस संस्करण में अपग्रेड कर चुके हैं। उन लोगों के लिए जो अभी भी पुराने MySQL संस्करणों का उपयोग कर रहे हैं, हम इस ब्लॉग को प्रस्तुत करना चाहेंगे जहां हम कुछ सुझाव और जानकारी साझा करेंगे जो MySQL 8.0 के लिए अपग्रेड प्रक्रिया में मदद करते हैं।
माइंड योर वर्जन
अपग्रेड प्रक्रिया में सॉफ्टवेयर संस्करण काफी महत्वपूर्ण हैं। शुरुआत के लिए, केवल एक प्रमुख संस्करण अंतर समर्थित है। इससे पहले कि आप MySQL 8.0 में अपग्रेड कर सकें, आपको MySQL 5.7 चलाना होगा। यह ध्यान रखना काफी महत्वपूर्ण है कि MySQL 5.6 अपने जीवन के अंत के करीब पहुंच रहा है और इसे अब समर्थित नहीं किया जाएगा। आप सभी के लिए जो MySQL 5.6 का उपयोग करते हैं, आपको यह सुनिश्चित करना होगा कि आपने इसे पहले MySQL 5.7 में और फिर अंत में, MySQL 8.0 में अपग्रेड किया है।
जिस बात की पुरज़ोर अनुशंसा की जाती है वह यह है कि आप MySQL 5.7 के लिए उपलब्ध नवीनतम संस्करण में अपग्रेड करें। इस ब्लॉग को लिखने के समय यह 5.7.31 था लेकिन अंततः यह बदल जाएगा, आप इसे हमेशा MySQL वेबसाइट पर देख सकते हैं।
कृपया यह भी ध्यान दें कि गैर-जीए (और गैर-जीए) संस्करणों से अपग्रेड समर्थित नहीं हैं। ऐसा नहीं है कि गैर-जीए संस्करणों को उत्पादन में चलाने का कोई मतलब है लेकिन हम इसे भी स्पष्ट करना चाहते थे।
यह एकतरफा टिकट है
जब भी आप अपग्रेड करने का निर्णय लेते हैं, तो कृपया ध्यान रखें कि, एक बार अपग्रेड पूरा हो जाने के बाद, वापस नहीं आना है। परिवर्तन संगत नहीं हैं और आप बस MySQL 8.0 से MySQL 5.7 पर डेटा निर्देशिका का उपयोग नहीं कर सकते हैं। सुनिश्चित करें कि आप अपग्रेड से पहले सीधे अपने MySQL 5.7 डेटा का बैकअप लेते हैं - आप इसे MySQL 5.7 इंस्टेंस पर पुनर्स्थापित करने में सक्षम होंगे, आपको परिवर्तन को वापस करने की आवश्यकता होगी। कृपया यह भी ध्यान रखें, क्योंकि यह आश्चर्य की बात हो सकती है, कि MySQL 8.0.x से MySQL 8.0.x+1 में अपग्रेड भी संगत नहीं हो सकता है और, भले ही यह एक मामूली संस्करण अपग्रेड है, आपको डाउनग्रेड की उम्मीद नहीं करनी चाहिए संभव हो सकता है। यह Oracle के परिनियोजन चक्र का परिणाम है - नवीनतम GA शाखा के लिए फ़ीचर-फ़्रीज़ करने के बजाय, जैसा कि पिछले संस्करणों के मामले में था, नई सुविधाएँ, कभी-कभी असंगत, 8.0 शाखा की नई रिलीज़ के रूप में धकेल दी जाती हैं।
इन-प्लेस अपग्रेड एक जाना है
अतीत में MySQL का इन-प्लेस अपग्रेड करना हमेशा संभव नहीं था। कुछ मामलों में आपको डेटा को SQL प्रारूप में डंप करने और फिर इसे नए संस्करण में वापस लोड करने के लिए मजबूर किया गया था। सौभाग्य से, MySQL 8.0 अधिक व्यवस्थापक-अनुकूल है और इन-प्लेस अपग्रेड समर्थित है। आपको बस इतना करना है कि उपयुक्त अपग्रेड या यम अपडेट चलाना है और आप पूरी तरह तैयार हैं। अपग्रेड और भी सुविधाजनक है - अतीत में यह सुनिश्चित करने के लिए mysql_upgrad को चलाने के लिए ध्यान रखना पड़ता था कि सभी सिस्टम टेबल MySQL के नए संस्करण के लिए आवश्यक प्रारूप में ठीक से अपग्रेड किए गए हैं। MySQL 8.0 में, MySQL 8.0.16 से शुरू होकर, इसकी अब आवश्यकता नहीं है - आपको बस इतना करना है कि MySQL प्रक्रिया, mysqld, और, डिफ़ॉल्ट रूप से, अपग्रेड डेटा डिक्शनरी और अन्य सिस्टम स्कीमा पर किया जाएगा जब भी यह होगा आवश्यक होना निर्धारित है। विभिन्न मापदंडों को --अपग्रेड सर्वर विकल्प में पास करके इस व्यवहार को बदलना संभव है, लेकिन अधिकांश मामलों में आप इस सुधार से लाभ उठाना चाहेंगे।
क्या मैं अपग्रेड करने के लिए सुरक्षित हूं?
बेशक, सुरक्षित अपग्रेड के लिए पूर्वापेक्षाएँ हैं। आइए कुछ तरीकों पर एक नज़र डालते हैं जो आपको यह सुनिश्चित करने में मदद करेंगे कि आप सुरक्षित रूप से MySQL 8.0 में अपग्रेड कर सकते हैं।
स्वच्छता जांच
कुछ भी करने का प्रयास करने से पहले, आपको दोबारा जांच करनी चाहिए कि MySQL 8.0 में अपग्रेड करने से पहले आपका मौजूदा MySQL 5.7 सेटअप विवेक चेकलिस्ट के सभी बॉक्स पर टिक करता है। MySQL प्रलेखन परीक्षण करने के लिए चीजों की एक विस्तृत सूची प्रस्तुत करता है। यहाँ सूची पर जाने का कोई मतलब नहीं है क्योंकि यह MySQL प्रलेखन में शामिल है, लेकिन यहाँ कुछ बिंदु हैं जिन्हें आप ध्यान में रखना चाहते हैं।
पहले, विभाजन अब केवल उन्हीं इंजनों में समर्थित है जो इसे अपने अंत में लागू करते हैं, जो केवल NDB और InnoDB हैं। कृपया सुनिश्चित करें कि सभी विभाजित टेबल उन स्टोरेज इंजनों में से एक का उपयोग करते हैं या आप अपग्रेड से पहले विभाजन को हटा देते हैं।
आप शायद दौड़ना चाहें
mysqlcheck -u root -p --all-databases --check-upgradeयह दोबारा जांचने के लिए कि टेबल उचित प्रारूप में हैं।
ऐसी अन्य जांच भी हैं जो आपको करनी चाहिए - लगभग हर नया MySQL संस्करण आरक्षित शब्दों की एक अद्यतन सूची के साथ आता है और आपको यह जांचना चाहिए कि आप अपने डेटाबेस में उनका उपयोग नहीं करते हैं। आपको विदेशी कुंजी बाधा नामों की जांच करने की आवश्यकता है, वे 64 वर्णों से अधिक लंबे नहीं हो सकते। sql_mode के लिए कुछ विकल्प हटा दिए गए हैं, इसलिए आपको यह सुनिश्चित करना चाहिए कि आप उनका उपयोग नहीं करते हैं। जैसा कि हमने उल्लेख किया है, परीक्षण करने के लिए चीजों की एक विस्तृत सूची है।
MySQL शेल टू द रेस्क्यू
उन सभी स्थितियों का परीक्षण करने में काफी समय लगता है इसलिए Oracle ने MySQL शेल में एक विकल्प बनाया जिसका उद्देश्य यह सत्यापित करने के लिए परीक्षणों की एक श्रृंखला चलाना है कि क्या आपका मौजूदा इंस्टॉलेशन MySQL 8.0 में अपग्रेड करने के लिए सुरक्षित है। शुरुआत के लिए, यदि आपके पास MySQL शेल स्थापित नहीं है, तो आपको ऐसा करना चाहिए। आप Oracle की वेबसाइट पर डाउनलोड पा सकते हैं। एक बार जब आप इसे सेट कर लेते हैं, तो आप अपने MySQL 5.7 से जुड़ सकते हैं और परीक्षण चला सकते हैं। आइए देखें कि यह कैसा दिख सकता है:
[email protected]:~# mysqlsh
MySQL Shell 8.0.21
Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
Type '\help' or '\?' for help; '\quit' to exit.
MySQL JS > \c [email protected]
Creating a session to '[email protected]'
Please provide the password for '[email protected]': ****
Save password for '[email protected]'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 71 (X protocol)
Server version: 5.7.31-log MySQL Community Server (GPL)
No default schema selected; type \use <schema> to set one.हम MySQL शेल का उपयोग करके लोकलहोस्ट पर MySQL इंस्टेंस से जुड़े हैं। अब हम चेक चला सकते हैं। हम अधिक विस्तृत परीक्षणों के लिए कॉन्फ़िगरेशन फ़ाइल का पथ पास करेंगे:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})तब हमारे पास एक लंबा आउटपुट होता है।
The MySQL server at localhost:33060, version 5.7.31-log - MySQL Community
Server (GPL), will now be checked for compatibility issues for upgrade to MySQL
8.0.21...
1) Usage of old temporal type
No issues found
2) Usage of db objects with names conflicting with new reserved keywords
No issues found
3) Usage of utf8mb3 charset
No issues found
4) Table names in the mysql schema conflicting with new tables in 8.0
No issues found
5) Partitioned tables using engines with non native partitioning
No issues found
6) Foreign key constraint names longer than 64 characters
No issues found
7) Usage of obsolete MAXDB sql_mode flag
No issues found
8) Usage of obsolete sql_mode flags
No issues found
9) ENUM/SET column definitions containing elements longer than 255 characters
No issues found
10) Usage of partitioned tables in shared tablespaces
No issues found
11) Circular directory references in tablespace data file paths
No issues found
12) Usage of removed functions
No issues found
13) Usage of removed GROUP BY ASC/DESC syntax
No issues found
14) Removed system variables for error logging to the system log configuration
No issues found
15) Removed system variables
Error: Following system variables that were detected as being used will be
removed. Please update your system to not rely on them before the upgrade.
More information:
https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed
log_warnings - is set and will be removed, consider using log_error_verbosity
instead
query_cache_size - is set and will be removed
query_cache_type - is set and will be removed
16) System variables with new default values
Warning: Following system variables that are not defined in your
configuration file will have new default values. Please review if you rely on
their current values and if so define them before performing upgrade.
More information:
https://mysqlserverteam.com/new-defaults-in-mysql-8-0/
back_log - default value will change
character_set_server - default value will change from latin1 to utf8mb4
collation_server - default value will change from latin1_swedish_ci to
utf8mb4_0900_ai_ci
event_scheduler - default value will change from OFF to ON
explicit_defaults_for_timestamp - default value will change from OFF to ON
innodb_flush_neighbors - default value will change from 1 (enable) to 0
(disable)
innodb_max_dirty_pages_pct - default value will change from 75 (%) 90 (%)
innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
(%)
innodb_undo_log_truncate - default value will change from OFF to ON
innodb_undo_tablespaces - default value will change from 0 to 2
log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
max_error_count - default value will change from 64 to 1024
optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
performance_schema_consumer_events_transactions_current - default value will
change from OFF to ON
performance_schema_consumer_events_transactions_history - default value will
change from OFF to ON
slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
transaction_write_set_extraction - default value will change from OFF to
XXHASH64
17) Zero Date, Datetime, and Timestamp values
No issues found
18) Schema inconsistencies resulting from file removal or corruption
No issues found
19) Tables recognized by InnoDB that belong to a different engine
No issues found
20) Issues reported by 'check table x for upgrade' command
No issues found
21) New default authentication plugin considerations
Warning: The new default authentication plugin 'caching_sha2_password' offers
more secure password hashing than previously used 'mysql_native_password'
(and consequent improved client connection authentication). However, it also
has compatibility implications that may affect existing MySQL installations.
If your MySQL installation must serve pre-8.0 clients and you encounter
compatibility issues after upgrading, the simplest way to address those
issues is to reconfigure the server to revert to the previous default
authentication plugin (mysql_native_password). For example, use these lines
in the server option file:
[mysqld]
default_authentication_plugin=mysql_native_password
However, the setting should be viewed as temporary, not as a long term or
permanent solution, because it causes new accounts created with the setting
in effect to forego the improved authentication security.
If you are using replication please take time to understand how the
authentication plugin changes may impact you.
More information:
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication
Errors: 3
Warnings: 18
Notices: 0
3 errors were found. Please correct these issues before upgrading to avoid compatibility issues.जैसा कि आप देख सकते हैं, कुल 21 परीक्षण किए गए हैं, जांच में कॉन्फ़िगरेशन विकल्पों से संबंधित 3 त्रुटियां पाई गई हैं जो MySQL 8.0.21 में मौजूद नहीं होंगी। परीक्षण काफी विस्तृत हैं। अन्य बातों के अलावा आप उन चरों के लिए डिफ़ॉल्ट मानों में परिवर्तन के बारे में जानेंगे जिन्हें आपने अपने MySQL कॉन्फ़िगरेशन में कॉन्फ़िगर नहीं किया है (इसलिए, जब आप MySQL 8.0 स्थापित करते हैं तो वे सेटिंग्स बदल जाएंगी)।
असफल अपग्रेड को वापस लाना
जैसा कि हमने पहले बताया, अपग्रेड पूरा होने के बाद आप MySQL 8.0 से डाउनग्रेड नहीं कर सकते। सौभाग्य से, इसका मतलब यह नहीं है कि अगर यह बीच में विफल हो जाता है तो आप अपग्रेड को रोलबैक नहीं कर सकते। वास्तव में, यह अर्ध-स्वचालित रूप से होता है यदि पिछले अनुभाग में हमने जिन मुद्दों पर चर्चा की उनमें से एक का पता चला है। अपग्रेड के दौरान पाई गई समस्याओं को दूर करने के लिए केवल मैन्युअल कार्रवाई की आवश्यकता है कि रीडो लॉग को हटा दें और MySQL 5.7 को शुरू करें। फिर आपको यह सुनिश्चित करने के लिए धीमा शटडाउन (innodb_fast_shutdown=0) करना चाहिए कि सब कुछ टेबलस्पेस पर लिखा गया है और फिर आप एक बार फिर से अपग्रेड का प्रयास करने के लिए तैयार हैं।
अंतिम सुझाव
डिफ़ॉल्ट व्यवहार में दो महत्वपूर्ण परिवर्तन हैं जो MySQL 8.0 के साथ आते हैं जिन्हें हम हाइलाइट करना चाहेंगे।
कैशिंग_sha2_password डिफ़ॉल्ट के रूप में
कृपया सुनिश्चित करें कि आप दोबारा जांच लें कि क्या आपके एप्लिकेशन और प्रॉक्सी caching_sha2_password प्रमाणीकरण प्लगइन के साथ ठीक से काम करेंगे क्योंकि यह MySQL 8.0 में डिफ़ॉल्ट बन जाता है। पुराने एप्लिकेशन प्रभावित हो सकते हैं और डेटाबेस से कनेक्ट करने में सक्षम नहीं हो सकते हैं। बेशक, आप इसे अपने इच्छित प्रमाणीकरण प्लगइन में बदल सकते हैं (जैसे mysql_native_password उदाहरण के लिए, क्योंकि यह पिछले MySQL संस्करणों में डिफ़ॉल्ट था) इसलिए यह किसी भी तरह से अवरोधक नहीं है। अपग्रेड से पहले परीक्षण करना याद रखने वाली बात है ताकि आप MySQL 8.0 और ऐसे ऐप्स के साथ समाप्त न हों जो इससे कनेक्ट नहीं हो सकते हैं जब तक कि आप अपने डेटाबेस को पुराने प्रमाणीकरण तंत्र का उपयोग करने के लिए पुन:कॉन्फ़िगर नहीं करते हैं।
UTF8mb4 डिफ़ॉल्ट वर्णसेट के रूप में
यह देखते हुए आश्चर्य की बात नहीं होनी चाहिए कि समुदाय में व्यापक रूप से UTF8 में कैसे बदलाव किया गया था, लेकिन यह तथ्य है - MySQL 8.0 डिफ़ॉल्ट के रूप में UTF8mb4 वर्णसेट के साथ आता है। इसके कुछ अतिरिक्त प्रभाव हैं जिनसे आपको अवगत होना चाहिए। सबसे पहले, यदि आप UTF8mb4 वर्णसेट का उपयोग करेंगे तो आपके डेटासेट का आकार बढ़ सकता है। इससे मेमोरी बफ़र्स latin1 charset वाले डेटा की तुलना में कम मात्रा में डेटा संग्रहीत करने में सक्षम होते हैं। दूसरा, MySQL का प्रदर्शन कम होने की उम्मीद है। निश्चित रूप से, Oracle ने इस परिवर्तन के प्रभाव को कम करने का बहुत अच्छा काम किया है, लेकिन आप यह उम्मीद नहीं कर सकते कि कोई भी प्रदर्शन प्रभाव नहीं पड़ेगा - यह कुछ ही होगा।
हमें उम्मीद है कि यह ब्लॉग पोस्ट आपको MySQL 5.7 से MySQL 8.0 में अपग्रेड करने की प्रक्रिया से गुजरने में मदद करेगी। यदि इस प्रक्रिया पर आपके विचार हैं, तो हम आपको उन्हें इस पोस्ट के नीचे टिप्पणियों में साझा करने के लिए प्रोत्साहित करते हैं।
