5.7 کان 8.0 تائين MySQL (Percona سرور) کي اپڊيٽ ڪرڻ

ترقي اڃا بيھي نه آھي، تنھنڪري MySQL جي جديد ورزن ۾ اپڊيٽ ڪرڻ جا سبب تمام گھڻو مجبور ٿي رھيا آھن. گهڻو اڳ نه، اسان جي منصوبن مان هڪ ۾، اهو وقت هو آرامده پرڪونا سرور 5.7 ڪلستر کي نسخو 8 تائين اپڊيٽ ڪرڻ. اهو سڀ ڪجهه ٿيو Ubuntu Linux 16.04 پليٽ فارم تي. گھٽ ۾ گھٽ وقت سان اهڙي آپريشن کي ڪيئن انجام ڏيو ۽ اپڊيٽ دوران اسان کي ڪهڙيون مشڪلاتون پيش آيون - هن مضمون ۾ پڙهو.

جي تياري

ڊيٽابيس سرور جي ڪا به تازه ڪاري گهڻو ڪري ڊيٽابيس جي ٻيهر ترتيب سان لاڳاپيل آهي: سسٽم وسيلن تي حدن جي ضرورتن ۾ تبديليون ۽ ڊيٽابيس جي ترتيبن جي اصلاح جي ضرورت آهي جيڪا پراڻي هدايتن کي صاف ڪرڻ جي ضرورت آهي.

تازه ڪاري ڪرڻ کان پهريان، اسان ضرور ضرور حوالو ڪنداسين سرڪاري دستاويز:

۽ اچو ته هڪ ايڪشن پلان ٺاهيو:

درست ڪنفگريشن فائلن کي ختم ڪرڻ سان پراڻي هدايتون.
افاديت سان مطابقت چيڪ ڪريو.
پيڪيج کي انسٽال ڪندي غلام ڊيٽابيس کي تازه ڪاري ڪريو percona-server-server.
ساڳئي پيڪيج سان ماسٽر کي اپڊيٽ ڪريو.

اچو ته منصوبي جي هر نقطي تي نظر رکون ۽ ڏسو ته ڇا غلط ٿي سگهي ٿو.

ضروري! Galera جي بنياد تي MySQL ڪلستر کي اپڊيٽ ڪرڻ جي طريقيڪار جون پنهنجون ذيليون شيون آهن جيڪي مضمون ۾ بيان نه ڪيون ويون آهن. توهان هن معاملي ۾ هن هدايتون استعمال نه ڪرڻ گهرجي.

حصو 1: ٺاھ جوڙ چيڪ ڪرڻ

MySQL ورزن 8 ۾ هٽايو ويو query_cache. دراصل هو هو فرسوده قرار ڏنو واپس ورزن 5.7 ۾، پر هاڻي مڪمل طور تي ختم ٿيل. ان جي مطابق، ان سان لاڳاپيل هدايتن کي ختم ڪرڻ ضروري آهي. ۽ درخواستن کي ڪيش ڪرڻ لاءِ توھان ھاڻي خارجي اوزار استعمال ڪري سگھو ٿا - مثال طور، ProxySQL.

پڻ config ۾ اتي جي باري ۾ پراڻيون هدايتون هئا innodb_file_format. جيڪڏهن MySQL 5.7 ۾ اهو ممڪن آهي ته InnoDB فارميٽ کي چونڊيو، پوء 8 ورجن اڳ ۾ ئي ڪم ڪري ٿو صرف Barracuda فارميٽ سان.

اسان جو نتيجو هيٺ ڏنل هدايتن کي ختم ڪرڻ آهي:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

چيڪ ڪرڻ لاء، اسان استعمال ڪنداسين Docker تصوير 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-shell (Percona جي صورت ۾ هي پيڪيج آهي 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 هٽايو ويندو، پر هن رليز ۾ نه. تنهن ڪري، اسان انڪوڊنگ کي درست ڪرڻ جو فيصلو ڪيو اڳ ۾ ئي هلندڙ DBMS تنصيب تي، ان کي اپڊيٽ ڪرڻ کان پوء.

حصو 3: سرور تازه ڪاريون

ڇا غلط ٿي سگهي ٿو جڏهن ڪو اهڙو سمارٽ پلان هجي؟... مڪمل طور تي سمجھڻ سان ته nuances هميشه ٿينديون آهن، اسان پهريون تجربو MySQL dev ڪلستر تي ڪيو.

جيئن ا already ۾ ئي ذڪر ڪيو ويو آهي ، سرڪاري دستاويز replicas سان MySQL سرورز کي اپڊيٽ ڪرڻ جي مسئلي کي ڍڪي ٿو. هيٺئين لائن اها آهي ته توهان کي پهريان سڀني نقلن (غلام) کي اپڊيٽ ڪرڻ گهرجي، ڇاڪاڻ ته MySQL 8 ماسٽر ورزن 5.7 کان نقل ڪري سگهي ٿو. ڪجهه مشڪل حقيقت ۾ ڪوڙ آهي ته اسان موڊ استعمال ڪندا آهيون ماسٽر ماسٽر، جڏهن ريموٽ ماسٽر موڊ ۾ آهي صرف پڙهو. اهو آهي، حقيقت ۾، جنگي ٽرئفڪ هڪ ڊيٽا سينٽر ڏانهن وڃي ٿو، ۽ ٻيو هڪ بيڪ اپ آهي.

Topology هن طرح نظر اچي ٿو:

اپڊيٽ کي replicas سان شروع ٿيڻ گهرجي mysql ريپليڪا ڊي سي 2, mysql ماسٽر ڊي سي 2 и mysql replica dc 1، ۽ ختم ڪيو mysql master dc 1 سرور سان. وڌيڪ قابل اعتماد ٿيڻ لاءِ، اسان ورچوئل مشينن کي روڪيو، انهن جا سنيپ شاٽ ورتا، ۽ تازه ڪاري کان فوري اڳ حڪم سان نقل ڪرڻ بند ڪيو. STOP SLAVE. باقي اپڊيٽ هن طرح ڏسڻ ۾ اچي ٿي:

اسان هر نقل کي ٻيهر شروع ڪريون ٿا ترتيب ڏيڻ ۾ 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

گوگل تي مختلف ميلنگ لسٽن جي آرڪائيوز کي ريسرچ ڪرڻ سان اهو سمجھ ۾ آيو ته هي مسئلو ان ڪري ٿئي ٿو 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 utility آن لائن 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

لاگز جي هڪ تڪڙو معائنو ظاهر ڪيو ته 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

نتيجو

ڪو به، جيتوڻيڪ آسان آپريشن، اڻڄاتل مسئلا پيدا ڪري سگهي ٿو. ۽ جيتوڻيڪ هڪ چڱي طرح سوچڻ وارو منصوبو هميشه متوقع نتيجو جي ضمانت نٿو ڏئي. هاڻي، ڪنهن به تازه ڪاري جو منصوبو اسان جي ٽيم ۾ پڻ شامل آهي غير ضروري فائلن جي لازمي صفائي جيڪا تازي ڪارناما جي نتيجي ۾ ظاهر ٿي سگهي ٿي.

۽ انهي سان گڏ نه تمام پروفيشنل گرافڪ تخليقيت ، مان چوڻ چاهيان ٿو پرڪونا کي انهن جي بهترين پروڊڪٽس لاءِ وڏي مهرباني!

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تازه ڪاري MySQL (Percona سرور) 5.7 کان 8.0 تائين