5.7 থেকে 8.0 পর্যন্ত MySQL (Percona সার্ভার) আপডেট করা হচ্ছে

অগ্রগতি স্থির থাকে না, তাই MySQL এর সর্বশেষ সংস্করণে আপগ্রেড করার কারণগুলি ক্রমশ বাধ্য হয়ে উঠছে৷ খুব বেশি দিন আগে, আমাদের একটি প্রকল্পে, আরামদায়ক Percona সার্ভার 5.7 ক্লাস্টারগুলিকে সংস্করণ 8-এ আপডেট করার সময় ছিল। এই সমস্ত উবুন্টু লিনাক্স 16.04 প্ল্যাটফর্মে ঘটেছে। ন্যূনতম ডাউনটাইম সহ কীভাবে এই জাতীয় অপারেশন করা যায় এবং আপডেটের সময় আমরা কী সমস্যার মুখোমুখি হয়েছিলাম - এই নিবন্ধে পড়ুন।

প্রশিক্ষণ

ডাটাবেস সার্ভারের যেকোন আপডেট সম্ভবত ডাটাবেস পুনঃকনফিগারেশনের সাথে যুক্ত: সিস্টেম রিসোর্সের সীমাবদ্ধতার জন্য প্রয়োজনীয়তার পরিবর্তন এবং ডাটাবেস কনফিগারেশনের সংশোধন যা পুরানো নির্দেশাবলী থেকে সাফ করা দরকার।

আপডেট করার আগে, আমরা অবশ্যই অফিসিয়াল ডকুমেন্টেশন পড়ব:

• মাইএসকিউএল 8 রিলিজ নোট;
• মাইএসকিউএল আপগ্রেড গাইড;
• Percona আপডেট গাইড;
• প্রতিলিপি এবং মাস্টার আপডেট করার জন্য মাইএসকিউএল গাইড.

এবং আসুন একটি কর্ম পরিকল্পনা আঁকুন:

1. পুরানো নির্দেশাবলী অপসারণ করে কনফিগারেশন ফাইলগুলি সঠিক করুন।
2. ইউটিলিটিগুলির সাথে সামঞ্জস্যতা পরীক্ষা করুন।
3. প্যাকেজ ইনস্টল করে স্লেভ ডাটাবেস আপডেট করুন percona-server-server.
4. একই প্যাকেজ দিয়ে মাস্টার আপডেট করুন।

আসুন পরিকল্পনার প্রতিটি পয়েন্ট দেখুন এবং দেখুন কি ভুল হতে পারে।

গুরুত্বপূর্ণ! গ্যালারার উপর ভিত্তি করে একটি মাইএসকিউএল ক্লাস্টার আপডেট করার পদ্ধতিটির নিজস্ব সূক্ষ্মতা রয়েছে যা নিবন্ধে বর্ণনা করা হয়নি। আপনি এই ক্ষেত্রে এই নির্দেশ ব্যবহার করা উচিত নয়.

পার্ট 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.

চেক করতে, আমরা পারকোনা সার্ভারের ডকার ইমেজ ব্যবহার করব। আমরা ডিরেক্টরিতে সার্ভার কনফিগার রাখব 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 এর আধুনিক সংস্করণে একটি ইউটিলিটি পাওয়া যায় 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-এ এটি অবশেষে এটা ঠিক করার সিদ্ধান্ত নিয়েছে: alias utf8 শীঘ্রই কোডিং করতে হবে utf8mb4, এবং টেবিলের পুরানো কলাম হয়ে যাবে utf8mb3. আরও এনকোডিং utf8mb3 সরানো হবে, কিন্তু এই রিলিজে নয়। অতএব, আমরা ইতিমধ্যেই চলমান DBMS ইনস্টলেশনে থাকা এনকোডিংগুলিকে আপডেট করার পরে সংশোধন করার সিদ্ধান্ত নিয়েছি।

পার্ট 3: সার্ভার আপডেট

এমন একটি স্মার্ট প্ল্যান থাকলে কী ভুল হতে পারে?... সূক্ষ্ম বিষয়গুলি সর্বদা ঘটে তা ভালভাবে বোঝার জন্য, আমরা একটি MySQL ডেভ ক্লাস্টারে প্রথম পরীক্ষা পরিচালনা করেছি।

যেমনটা ইতিমধ্যে উল্লেখিত, অফিসিয়াল ডকুমেন্টেশন প্রতিলিপি সহ MySQL সার্ভার আপডেট করার বিষয়টি কভার করে। নীচের লাইন হল যে আপনার প্রথমে সমস্ত প্রতিলিপি (স্লেভ) আপডেট করা উচিত, যেহেতু MySQL 8 একটি মাস্টার সংস্করণ 5.7 থেকে প্রতিলিপি করতে পারে। কিছু অসুবিধা এই যে আমরা মোড ব্যবহার করি মাস্টার <-> মাস্টার, যখন রিমোট মাস্টার মোডে থাকে শুধুমাত্র পাঠযোগ্য. অর্থাৎ, আসলে, যুদ্ধের ট্র্যাফিক একটি ডেটা সেন্টারে যায় এবং দ্বিতীয়টি একটি ব্যাকআপ।

টপোলজি এই মত দেখায়:

আপডেট অবশ্যই প্রতিলিপি দিয়ে শুরু করতে হবে মাইএসকিউএল রেপ্লিকা ডিসি 2, মাইএসকিউএল মাস্টার ডিসি 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. এটি মাইএসকিউএল সংস্করণ 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-এ বিভিন্ন মেইলিং তালিকার সংরক্ষণাগারগুলি নিয়ে গবেষণা করার ফলে এই সমস্যাটি ঘটে মাইএসকিউএল বাগ. যদিও এটি একটি ইউটিলিটি বাগ হওয়ার সম্ভাবনা বেশি mysqlcheck и mysqlsh.

দেখা যাচ্ছে যে মাইএসকিউএল দশমিক ক্ষেত্রের (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. percona-toolkit এখানে সাহায্য করবে: pt-online-schema-change ইউটিলিটি অনলাইন অপ্টিমাইজ অপারেশনের জন্য চমৎকার।

আপডেট করা প্ল্যানটি দেখতে এরকম ছিল:

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 সার্ভারের কিছু থ্রেড পর্যায়ক্রমে একটি ত্রুটির সাথে ক্র্যাশ হওয়ার কারণে স্ক্রিনশটটি একটি sawtooth গ্রাফ দেখায়। অ্যাপ্লিকেশনে ত্রুটি দেখা দিয়েছে:

[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

উপসংহার ইন

যে কোনো, এমনকি সহজ অপারেশন, অপ্রত্যাশিত সমস্যা হতে পারে। এবং এমনকি একটি সুচিন্তিত পরিকল্পনা থাকা সর্বদা প্রত্যাশিত ফলাফলের গ্যারান্টি দেয় না। এখন, আমাদের টিমের যেকোন আপডেট পরিকল্পনায় অপ্রয়োজনীয় ফাইলগুলির বাধ্যতামূলক পরিস্কার অন্তর্ভুক্ত রয়েছে যা সাম্প্রতিক ক্রিয়াকলাপের ফলে উপস্থিত হতে পারে।

এবং এটি খুব পেশাদার নয় এমন গ্রাফিক সৃজনশীলতার সাথে, আমি পারকোনাকে তাদের দুর্দান্ত পণ্যগুলির জন্য একটি বিশাল ধন্যবাদ জানাতে চাই!

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «ডাটাবেস এবং কুবারনেটস (ওভারভিউ এবং ভিডিও রিপোর্ট)";
• «Kubernetes টিপস এবং কৌশল: বড় ডাটাবেসের জন্য বুটস্ট্র্যাপ দ্রুত করা";
• «আমাদের এসআরই দৈনন্দিন জীবনের 6টি ব্যবহারিক গল্প";
• «K8s-এ Redis অপারেটরের সাথে একটি গল্প এবং এই ডাটাবেস থেকে ডেটা বিশ্লেষণের জন্য ইউটিলিটিগুলির একটি ছোট-পর্যালোচনা";
• «বিরামহীন MongoDB থেকে Kubernetes মাইগ্রেশন».

উত্স: www.habr.com