🥇 له 5.7 څخه تر 8.0 پورې MySQL (Percona سرور) تازه کول

پرمختګ لاهم ولاړ نه دی، نو د MySQL وروستي نسخو ته د لوړولو دلیلونه په زیاتیدونکي توګه مجبور کیږي. ډیر وخت دمخه ، زموږ په یوه پروژه کې ، دا وخت و چې آرامه پرکونا سرور 5.7 کلسترونه نسخه 8 ته تازه کړئ. دا ټول د اوبنټو لینکس 16.04 پلیټ فارم کې پیښ شوي. د لږترلږه وخت سره دا ډول عملیات څنګه ترسره کول او د تازه کولو پرمهال موږ کومې ستونزې سره مخ شوي - پدې مقاله کې ولولئ.

د چمتو کولو لپاره

د ډیټابیس سرور هر ډول تازه کول ډیری احتمال د ډیټابیس بیا تنظیم کولو سره تړاو لري: د سیسټم سرچینو محدودیتونو اړتیاو کې بدلون او د ډیټابیس تشکیلاتو سمون چې اړتیا لري د پخوانیو لارښوونو څخه پاک شي.

د تازه کولو دمخه، موږ به یقینا رسمي اسنادو ته مراجعه وکړو:

او راځئ چې د عمل پلان جوړ کړو:

د پخوانیو لارښوونو په لرې کولو سره د تنظیم کولو فایلونه سم کړئ.
د اسانتیاوو سره مطابقت چیک کړئ.
د بسته بندۍ په نصبولو سره د غلام ډیټابیس تازه کړئ percona-server-server.
ماسټر د ورته کڅوړې سره تازه کړئ.

راځئ چې د پلان هرې نقطې ته وګورو او وګورو چې څه غلط کیدی شي.

مهم! د ګیلیرا پراساس د مای ایس کیو ایل کلستر تازه کولو پروسه خپل فرعي اړخونه لري چې په مقاله کې ندي بیان شوي. تاسو باید پدې قضیه کې دا لارښوونې ونه کاروئ.

برخه 1: د تشکیلاتو چک کول

MySQL په 8 نسخه کې لرې شوی query_cache. په حقیقت کې هغه وه متروک اعلان شو بیرته په 5.7 نسخه کې، مګر اوس په بشپړه توګه حذف شوی. په دې اساس، اړینه ده چې اړونده لارښوونې لرې کړئ. او د غوښتنې زیرمه کولو لپاره تاسو اوس کولی شئ بهرني وسیلې وکاروئ - د مثال په توګه ، پراکسي ایس کیو ایل.

په ترتیب کې هم د دې په اړه زاړه لارښوونې وې 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.

د چک کولو لپاره، موږ به د پرکونا سرور ډاکر عکس وکاروو. موږ به د سرور ترتیب په لارښود کې ځای په ځای کړو 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-shell (د پرکونا په قضیه کې دا کڅوړه ده percona-mysql-shell). دا د کلاسیک mysql پیرودونکي لپاره بدیل دی او د پیرودونکي دندې ، د SQL کوډ مدیر او د مای ایس کیو ایل ادارې وسیلې ترکیب کوي. د تازه کولو دمخه د سرور چیک کولو لپاره ، تاسو کولی شئ د دې له لارې لاندې کمانډونه پرمخ وړئ:

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 نصب کولو کې مخکې له مخکې کوډونه سم کړو.

دریمه برخه: د سرور تازه معلومات

څه شی غلط کیدی شي کله چې داسې یو سمارټ پلان شتون ولري؟ ... په بشپړ ښه پوهیدلو سره چې باریکونه تل پیښیږي ، موږ لومړۍ تجربه د MySQL dev کلستر کې ترسره کړه.

لکه څنګه چې مخکې یادونه وشوه ، رسمي اسناد د نقلونو سره د MySQL سرورونو تازه کولو مسله پوښي. لاندینۍ کرښه دا ده چې تاسو باید لومړی ټول نقلونه (غلامان) تازه کړئ، ځکه چې MySQL 8 کولی شي د ماسټر نسخه 5.7 څخه نقل کړي. یو څه مشکل پدې حقیقت کې دی چې موږ موډ کاروو ماسټر <-> ماسټر، کله چې ریموټ ماسټر په حالت کې وي یوازې لوستل. دا په حقیقت کې، جنګي ټرافيک د معلوماتو مرکز ته ځي، او دویم یو بیک اپ دی.

ټوپولوژي داسې ښکاري:

اوسمهال باید د نقلونو سره پیل شي د mysql نقل dc 2, د mysql ماسټر DC 2 и mysql replica dc 1، او د mysql ماسټر dc 1 سرور سره پای ته ورسیږئ. د لا ډیر باوري کیدو لپاره ، موږ مجازی ماشینونه ودرول ، د دوی عکسونه یې واخیستل ، او سمدلاسه مخکې له دې چې اپډیټ د کمانډ سره نقل ودروي STOP SLAVE. پاتې تازه معلومات داسې ښکاري:

موږ په تشکیلاتو کې د 3 اختیارونو اضافه کولو سره هر نقل بیا پیل کوو: skip-networking, skip-slave-start, skip-log-bin. حقیقت دا دی چې د ډیټابیس تازه کول د سیسټم میزونو ته د تازه معلوماتو سره بائنری لاګونه رامینځته کوي. دا لارښوونې تضمین کوي چې په ډیټابیس کې به د غوښتنلیک ډیټا کې هیڅ بدلون نه وي، او د سیسټم میزونو تازه کولو په اړه معلومات به په بائنری لاګونو کې شامل نه وي. دا به د بیا تکرار کولو په وخت کې د ستونزو مخه ونیسي.
د کڅوړې نصب کول percona-server-server. دا مهمه ده چې په یاد ولرئ چې د MySQL نسخه 8 کې نه تاسو اړتیا لرئ کمانډ چل کړئ mysqlupgrade د سرور تازه کولو وروسته.
د بریالي پیل وروسته، موږ سرور بیا پیل کوو - پرته له هغه پیرامیټونو څخه چې په لومړي پراګراف کې اضافه شوي.
ډاډ ترلاسه کول چې نقل په بریالیتوب سره کار کوي: چیک کړئ SHOW SLAVE STATUS او وګورئ چې د غوښتنلیک ډیټابیس کې د کاونټرونو میزونه تازه شوي.

دا ټول خورا ساده ښکاري: د dev تازه کول بریالي و. ښه، تاسو کولی شئ په خوندي ډول د تولید لپاره د شپې تازه مهالویش مهالویش کړئ.

هیڅ غم نه و - موږ محصول تازه کړ

په هرصورت، تولید ته د بریالي 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

په ګوګل کې د مختلف بریښنالیک لیستونو آرشیفونو څیړنه د دې لامل شوې چې پوه شي چې دا ستونزه د دې له امله رامینځته کیږي. د 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 د آنلاین آپټیمائز عملیاتو لپاره خورا ښه دی.

تازه شوی پلان داسې ښکاري:

ټول میزونه اصلاح کړئ.
ډیټابیسونه تازه کړئ.

د دې د چک کولو لپاره او په ورته وخت کې د تازه وخت موندلو لپاره، موږ یو نقل غیر فعال کړ او د ټولو میزونو لپاره لاندې کمانډ چلول:

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 ارزښت سره - دا پیرامیټر نوي میز ته د ډیټا د یوې ډلې له لیږدولو وروسته د انتظار اوږدوالی تنظیموي. پدې توګه تاسو کولی شئ بار کم کړئ که چیرې ریښتیني چلونکي غوښتنلیک د ځواب وخت غوښتنه وکړي.

د اصلاح کولو وروسته، تازه کول بریالي وو.

... مګر په بشپړه توګه نه!

د تازه کولو وروسته نیم ساعت کې، پیرودونکي د ستونزې سره راغلل. ډیټابیس خورا عجیب کار وکړ: په وخت سره دوی پیل کړل پیوستون بیا تنظیمول. دا هغه څه دي چې په نظارت کې ورته ښکاري:

د سکرین شاټ د دې حقیقت له امله چې د مای ایس کیو ایل سرور ځینې تارونه په دوره توګه د یوې خطا سره ټکر شوي د سیوټوت ګراف ښیې. په غوښتنلیک کې تېروتنې څرګندې شوې:

[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

په پای کې

هر، حتی ساده عملیات کولی شي غیر متوقع ستونزې رامینځته کړي. او حتی د ښه فکر کولو پلان درلودل تل د متوقع پایلې تضمین نه کوي. اوس، زموږ د ټیم هرډول تازه پلانونه د غیر ضروري فایلونو لازمي پاکول هم شامل دي چې ممکن د وروستیو کړنو په پایله کې څرګند شوي وي.

او د دې خورا مسلکي ګرافیک خلاقیت سره ، زه غواړم د پرکونا څخه د دوی غوره محصولاتو لپاره ډیره مننه ووایم!

PS

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

د MySQL (Percona سرور) تازه کول له 5.7 څخه تر 8.0 پورې