MySQL (Percona Server) ကို 5.7 မှ 8.0 သို့ အပ်ဒိတ်လုပ်ခြင်း။

တိုးတက်မှုသည် ရပ်တန့်မနေဘဲ၊ ထို့ကြောင့် MySQL ၏နောက်ဆုံးထွက်ဗားရှင်းသို့ အဆင့်မြှင့်တင်ရန် အကြောင်းပြချက်များသည် ပိုမိုဆွဲဆောင်မှုရှိလာပါသည်။ မကြာသေးမီက၊ ကျွန်ုပ်တို့၏ ပရောဂျက်တစ်ခုတွင်၊ အဆင်ပြေသော Percona Server 5.7 အစုအဝေးများကို ဗားရှင်း 8 သို့ အပ်ဒိတ်လုပ်ရန် အချိန်ကျရောက်ခဲ့သည်။ ဤအရာအားလုံးသည် Ubuntu Linux 16.04 ပလပ်ဖောင်းပေါ်တွင်ဖြစ်ပျက်ခဲ့သည်။ စက်ရပ်ချိန်အနည်းဆုံးနှင့် အပ်ဒိတ်လုပ်နေစဉ်အတွင်း ကျွန်ုပ်တို့ကြုံတွေ့ရသည့် ပြဿနာများကို မည်သို့လုပ်ဆောင်ရမည်နည်း - ဤဆောင်းပါးတွင် ဖတ်ရှုပါ။

လေ့ကျင့်ရေး

ဒေတာဘေ့စ်ဆာဗာ၏ အပ်ဒိတ်မှန်သမျှသည် ဒေတာဘေ့စ်ပြန်လည်ဖွဲ့စည်းခြင်းနှင့် ဆက်စပ်မှုရှိနိုင်သည်- စနစ်ရင်းမြစ်များအပေါ် ကန့်သတ်ချက်များအတွက် အပြောင်းအလဲများနှင့် ခေတ်မမီတော့သော ညွှန်ကြားချက်များကို ရှင်းပစ်ရန် လိုအပ်သည့် ဒေတာဘေ့စ်ပုံစံပြင်ဆင်ခြင်းဆိုင်ရာ ကန့်သတ်ချက်များ။

မွမ်းမံပြင်ဆင်ခြင်းမပြုမီ၊ ကျွန်ုပ်တို့သည် တရားဝင်စာရွက်စာတမ်းများကို သေချာပေါက် ကိုးကားပါမည်-

• MySQL 8 ထုတ်ပြန်သည့် မှတ်စုများ;
• MySQL အဆင့်မြှင့်တင်မှုလမ်းညွှန်;
• Percona အပ်ဒိတ်လမ်းညွှန်;
• ပုံတူများနှင့် မာစတာများကို အဆင့်မြှင့်တင်ခြင်းအတွက် MySQL လမ်းညွှန်.

ပြီးတော့ လုပ်ဆောင်ချက်အစီအစဉ်တစ်ခု ရေးဆွဲကြပါစို့။

1. ခေတ်မမီတော့သော ညွှန်ကြားချက်များကို ဖယ်ရှားခြင်းဖြင့် ဖွဲ့စည်းမှုဖိုင်များကို ပြင်ပါ။
2. အသုံးအဆောင်များနှင့် ကိုက်ညီမှုရှိမရှိ စစ်ဆေးပါ။
3. ပက်ကေ့ဂျ်ကို ထည့်သွင်းခြင်းဖြင့် ကျွန်ဒေတာဘေ့စ်များကို အပ်ဒိတ်လုပ်ပါ။ percona-server-server.
4. တူညီသောအထုပ်ဖြင့် မာစတာကို အပ်ဒိတ်လုပ်ပါ။

အစီအစဥ်တစ်ခုစီရဲ့ အချက်တစ်ချက်စီကို ကြည့်ပြီး ဘာတွေမှားသွားနိုင်လဲ ကြည့်ရအောင်။

အရေးကြီး! Galera ကိုအခြေခံထားသော MySQL အစုအဝေးကို အဆင့်မြှင့်တင်ခြင်းလုပ်ငန်းစဉ်တွင် ဆောင်းပါးတွင်ဖော်ပြထားခြင်းမရှိသော ၎င်း၏ကိုယ်ပိုင်အသေးစိတ်အချက်များရှိသည်။ ဤကိစ္စတွင် သင်သည် ဤညွှန်ကြားချက်ကို မသုံးသင့်ပါ။

အပိုင်း 1- ပြင်ဆင်မှုများကို စစ်ဆေးနေသည်။

MySQL ကို ဗားရှင်း 8 တွင် ဖယ်ရှားခဲ့သည်။ query_cache. အမှန်တော့ သူပဲ။ အသုံးမပြုတော့ကြောင်း ကြေညာသည်။ ဗားရှင်း 5.7 သို့ပြန်သွားသော်လည်းယခု လုံးဝ ဖျက်လိုက်ပြီ။. ထို့ကြောင့် သက်ဆိုင်ရာ ညွှန်ကြားချက်များကို ဖယ်ရှားရန် လိုအပ်ပါသည်။ ကက်ရှ်တောင်းဆိုမှုများအတွက် သင်သည် ပြင်ပကိရိယာများကို ယခုအသုံးပြုနိုင်ပြီ - ဥပမာ၊ ProxySQL.

ထို့အပြင် config တွင် ခေတ်မမီသော ညွှန်ကြားချက်များ ပါရှိသည်။ innodb_file_format. MySQL 5.7 တွင် InnoDB ဖော်မတ်ကို ရွေးချယ်နိုင်လျှင် 8th ဗားရှင်းသည် အလုပ်လုပ်နေပြီဖြစ်သည်။ Barracuda ဖော်မတ်ဖြင့်သာ.

ကျွန်ုပ်တို့၏ရလဒ်မှာ အောက်ပါညွှန်ကြားချက်များကို ဖယ်ရှားခြင်းဖြစ်သည်-

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

စစ်ဆေးရန်၊ ကျွန်ုပ်တို့သည် Percona Server ၏ Docker ပုံကို အသုံးပြုပါမည်။ ဆာဗာ config ကို လမ်းညွှန်တွင် ထားရှိပါမည်။ mysql_config_test၎င်းနောက်တွင် ဒေတာနှင့် မှတ်တမ်းများအတွက် လမ်းညွှန်များ ဖန်တီးပါမည်။ Percona-server configuration စမ်းသပ်မှု ဥပမာ-

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

အောက်ခြေလိုင်း- Docker မှတ်တမ်းများတွင်ဖြစ်စေ သို့မဟုတ် မှတ်တမ်းများပါရှိသော လမ်းညွှန်များတွင်ဖြစ်စေ - သင်၏ configs ပေါ်မူတည်၍ - ပြဿနာရှိသော ညွှန်ကြားချက်များကို ဖော်ပြမည့် ဖိုင်တစ်ခု ပေါ်လာပါမည်။

ဤသည်မှာ ကျွန်ုပ်တို့ ရရှိခဲ့သည်-

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- လုပ်ဆောင်နေသော တပ်ဆင်မှုများကို စစ်ဆေးခြင်း။

အပ်ဒိတ်စာရွက်စာတမ်းတွင် ဒေတာဘေ့စ်ကို စစ်ဆေးရန်အတွက် အသုံးဝင်မှု ၂ ခုပါရှိသည်။ ၎င်းတို့၏အသုံးပြုမှုသည် စီမံခန့်ခွဲသူအား လက်ရှိဒေတာဖွဲ့စည်းပုံ၏ လိုက်ဖက်ညီမှုကို စစ်ဆေးရန် ကူညီပေးသည်။

ဂန္တဝင် mysqlcheck utility ဖြင့်စကြပါစို့။ ရိုးရိုးရှင်းရှင်း ပြေးပါ

mysqlcheck -u root -p --all-databases --check-upgrade

ပြဿနာမတွေ့ပါက၊ utility သည် ကုဒ် 0 ဖြင့် ထွက်ပါမည်-

ထို့အပြင် MySQL ၏ ခေတ်မီဗားရှင်းများတွင် အသုံးဝင်မှုတစ်ခုကို ရနိုင်သည်။ mysql-shell (Percona ၏ဖြစ်ရပ်တွင်ဤသည်အထုပ်ဖြစ်သည်။ percona-mysql-shell) ၎င်းသည် ဂန္ထဝင် mysql ကလိုင်းယင့်အတွက် အစားထိုးပြီး client တစ်ခု၊ SQL ကုဒ်တည်းဖြတ်သူနှင့် MySQL စီမံခန့်ခွဲရေးကိရိယာများ၏ လုပ်ဆောင်ချက်များကို ပေါင်းစပ်ထားသည်။ မွမ်းမံခြင်းမပြုမီ ဆာဗာအား စစ်ဆေးရန်၊ ၎င်းမှတစ်ဆင့် အောက်ပါ command များကို သင်လုပ်ဆောင်နိုင်သည်-

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 bytes သာ သိမ်းဆည်းထားသောကြောင့် MySQL 8 တွင် ၎င်းသည် နောက်ဆုံးဖြစ်သည်။ ပြင်ဖို့ဆုံးဖြတ်လိုက်တယ်။: နာမည်အရင်း utf8 မကြာခင် coding ကို ဦးတည်သွားပါလိမ့်မယ်။ utf8mb4၊ ဇယားများရှိ ကော်လံဟောင်းများ ဖြစ်လာလိမ့်မည်။ utf8mb3. နောက်ထပ် ကုဒ်နံပါတ် utf8mb3 ဖယ်ရှားမည်ဖြစ်သော်လည်း ဤထုတ်ဝေမှုတွင် မဟုတ်ပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို အပ်ဒိတ်လုပ်ပြီးနောက် လုပ်ဆောင်နေသည့် DBMS တပ်ဆင်မှုတွင် ရှိပြီးသား ကုဒ်နံပါတ်များကို ပြင်ရန် ဆုံးဖြတ်ခဲ့သည်။

အပိုင်း 3- ဆာဗာ အပ်ဒိတ်များ

ဒီလို စမတ်ကျတဲ့ အစီအစဥ်တစ်ခု ရှိတဲ့အခါ ဘာတွေ မှားသွားနိုင်သလဲ?။ ။ ကွဲလွဲမှုတွေ အမြဲဖြစ်ပေါ်နေတယ်ဆိုတာကို အပြည့်အဝ နားလည်သဘောပေါက်ပြီး MySQL ဆော့ဖ်ဝဲ အစုအဝေးမှာ ပထမဆုံး စမ်းသပ်မှု ပြုလုပ်ခဲ့ပါတယ်။

ဖော်ပြခဲ့သည့်အတိုင်း၊ တရားဝင်စာရွက်စာတမ်း MySQL ဆာဗာများကို ပုံစံတူများဖြင့် အပ်ဒိတ်လုပ်ခြင်းဆိုင်ရာ ပြဿနာကို အကျုံးဝင်သည်။ အဓိကအချက်မှာ MySQL 8 သည် မာစတာဗားရှင်း 5.7 မှ ပုံတူကူးယူနိုင်သောကြောင့် ပုံတူများ (slaves) အားလုံးကို ဦးစွာ အပ်ဒိတ်လုပ်သင့်ပါသည်။ အချို့သောအခက်အခဲမှာ ကျွန်ုပ်တို့သည် မုဒ်ကိုအသုံးပြုခြင်းကြောင့်ဖြစ်သည်။ မာစတာ <-> မာစတာအဝေးထိန်းမာစတာမုဒ်တွင်ရှိသည့်အခါ၊ ဖတ်ရန်သာ. အမှန်မှာ၊ တိုက်ခိုက်ရေးလမ်းကြောင်းသည် ဒေတာစင်တာတစ်ခုသို့သွားသည်၊ ဒုတိယတစ်ခုသည် အရန်ကူးယူမှုတစ်ခုဖြစ်သည်။

topology သည် ဤကဲ့သို့ ဖြစ်သည်-

အပ်ဒိတ်သည် ပုံစံတူများဖြင့် စတင်ရပါမည်။ mysql ပုံတူ dc ၂, mysql master dc ၂ и mysql replica dc 1၊ mysql master dc 1 ဆာဗာဖြင့် အဆုံးသတ်ပါ။ ပိုမိုယုံကြည်စိတ်ချရစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် virtual machines များကို ရပ်လိုက်ပြီး ၎င်းတို့ကို လျှပ်တစ်ပြက်ရိုက်ယူကာ၊ အပ်ဒိတ်သည် အမိန့်ပေးချက်ဖြင့် ပုံတူပွားခြင်းကို မရပ်တန့်မီ ချက်ချင်းပင်၊ STOP SLAVE. ကျန်သောအပ်ဒိတ်များသည် ဤကဲ့သို့ဖြစ်နေသည်-

1. configs တွင် ရွေးချယ်စရာ 3 ခုကို ပေါင်းထည့်ခြင်းဖြင့် ပုံတူတစ်ခုစီကို ပြန်လည်စတင်သည်- skip-networking, skip-slave-start, skip-log-bin. အမှန်မှာ ဒေတာဘေ့စ်ကို အပ်ဒိတ်လုပ်ခြင်းသည် စနစ်ဇယားများသို့ အပ်ဒိတ်များဖြင့် binary မှတ်တမ်းများကို ထုတ်ပေးသည်။ ဤလမ်းညွှန်ချက်များသည် ဒေတာဘေ့စ်အတွင်း အပလီကေးရှင်းဒေတာကို အပြောင်းအလဲမရှိစေဘဲ၊ စနစ်ဇယားများကို အဆင့်မြှင့်တင်ခြင်းဆိုင်ရာ အချက်အလက်များကို binary မှတ်တမ်းများတွင် ထည့်သွင်းမည်မဟုတ်ကြောင်း အာမခံပါသည်။ ၎င်းသည် ပုံတူပွားခြင်းကို ပြန်လည်လုပ်ဆောင်သည့်အခါ ပြဿနာများကို ရှောင်ရှားနိုင်မည်ဖြစ်သည်။
2. အထုပ်ကို ထည့်သွင်းခြင်း။ percona-server-server. MySQL ဗားရှင်း 8 တွင် သတိပြုရန် အရေးကြီးပါသည်။ မဟုတ် သင် command ကို run ရန်လိုအပ်သည်။ mysqlupgrade server update ပြီးနောက်။
3. အောင်မြင်စွာစတင်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် ပထမစာပိုဒ်တွင် ထည့်သွင်းထားသော ကန့်သတ်ချက်များမပါဘဲ ဆာဗာကို ပြန်လည်စတင်ပါသည်။
4. ပုံတူကူးချခြင်း အောင်မြင်စွာ လုပ်ဆောင်ကြောင်း သေချာစေသည်- စစ်ဆေးပါ။ 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

Google ရှိ အမျိုးမျိုးသော စာပို့စာရင်းများ၏ မော်ကွန်းတိုက်များကို ရှာဖွေခြင်းသည် ဤပြဿနာကြောင့် ဖြစ်ပွားရခြင်းဖြစ်သည်ကို နားလည်သဘောပေါက်လာခဲ့သည်။ MySQL ချို့ယွင်းချက်. ဒါပေမယ် ဒါက utility bug ပိုများပါတယ်။ mysqlcheck и mysqlsh.

MySQL သည် ဒဿမအကွက်များ (int၊ tinyint စသည်ဖြင့်) အတွက် ဒေတာကို ကိုယ်စားပြုပုံအား ပြောင်းလဲလိုက်သောကြောင့် mysql-server သည် ၎င်းတို့ကို သိမ်းဆည်းရန် အခြားနည်းလမ်းကို အသုံးပြုပါသည်။ မင်းရဲ့ဒေတာဘေ့စ်ရှိရင် အစပိုင်းတွင် ဗားရှင်း 5.5 သို့မဟုတ် 5.1 တွင်ရှိပြီး၊ ထို့နောက် 5.7 သို့ အပ်ဒိတ်လုပ်ရန် လိုအပ်နိုင်သည် OPTIMIZE အချို့စားပွဲများအတွက်။ ထို့နောက် MySQL သည် ဒေတာဖိုင်များကို အပ်ဒိတ်လုပ်ကာ ၎င်းတို့အား လက်ရှိသိုလှောင်မှုပုံစံသို့ လွှဲပြောင်းပေးမည်ဖြစ်သည်။

၎င်းကို utility ဖြင့်လည်း စစ်ဆေးနိုင်သည်။ 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 script ကိုတွဲထားသည်။.

အဘယ်ကြောင့် ကျွန်ုပ်တို့သည် dev တွင် ထိုသို့သောပြဿနာများ မရှိခဲ့သနည်း။ ဒေတာဘေ့စ်ကို ထုတ်လုပ်မှုမှ အခါအားလျော်စွာ ကူးယူသည် - ထို့ကြောင့်၊ ဇယားများကို ပြန်လည်ဖန်တီးထားသည်။.

ကံမကောင်းစွာဖြင့်၊ အမှန်တကယ်အလုပ်လုပ်သော ကြီးမားသောဒေတာဘေ့စ်တစ်ခုတွင်၊ သင်သည် universal တစ်ခုအား ထုတ်ယူရုံမျှမက လုပ်ဆောင်နိုင်မည်မဟုတ်ပေ။ OPTIMIZE. percona-toolkit သည် ဤနေရာတွင် ကူညီပေးပါမည်- pt-online-schema-change utility သည် online OPTIMIZE လုပ်ဆောင်ချက်အတွက် အကောင်းဆုံးဖြစ်သည်။

အပ်ဒိတ်လုပ်ထားသော အစီအစဉ်သည် ဤကဲ့သို့ဖြစ်သည်-

1. ဇယားအားလုံးကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။
2. ဒေတာဘေ့စ်များကို အပ်ဒိတ်လုပ်ပါ။

၎င်းကိုစစ်ဆေးရန်နှင့် အပ်ဒိတ်အချိန်ကို သိရှိရန် တစ်ချိန်တည်းတွင်၊ ကျွန်ုပ်တို့သည် ပုံစံတူများထဲမှ တစ်ခုကို ပိတ်လိုက်ပြီး ဇယားအားလုံးအတွက် အောက်ပါ command ကို လုပ်ဆောင်ပါသည်။

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

utility သည် ပင်မဇယားမှ အချက်အလက်များကို ကူးယူသည့် ယာယီဇယားအသစ်ကို ဖန်တီးပေးသောကြောင့် ဇယားများကို ရှည်လျားသောသော့ခတ်ခြင်းမရှိဘဲ အပ်ဒိတ်လုပ်ပါသည်။ ဇယားနှစ်ခုလုံး တူညီနေချိန်တွင် မူလဇယားကို လော့ခ်ချထားပြီး အသစ်နှင့် အစားထိုးပါသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ဇယားများအားလုံးကို အပ်ဒိတ်လုပ်ရန် တစ်ရက်ခန့် အချိန်ယူရမည်ဟု စမ်းသပ်မှုတစ်ခုက ပြသခဲ့သော်လည်း ဒေတာကို ကူးယူခြင်းသည် disks တွင် load များလွန်းခြင်းကြောင့်ဖြစ်သည်။

၎င်းကိုရှောင်ရှားရန်၊ ထုတ်လုပ်ရေးတွင်ကျွန်ုပ်တို့သည် command တွင် argument ကိုထည့်သွင်းထားသည်။ --sleep 10 တန်ဖိုးဖြင့် - ဤကန့်သတ်ချက်သည် ဒေတာတစ်သုတ်ကို ဇယားအသစ်တစ်ခုသို့ လွှဲပြောင်းပြီးနောက် စောင့်ဆိုင်းချိန်ကို ချိန်ညှိပေးသည်။ ဤနည်းဖြင့် အမှန်တကယ် လုပ်ဆောင်နေသည့် အပလီကေးရှင်းသည် တုံ့ပြန်ချိန်အတွင်း တောင်းဆိုပါက ဝန်ကို လျှော့ချနိုင်သည်။

ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်ပြီးနောက်၊ အပ်ဒိတ်အောင်မြင်ခဲ့သည်။

ဒါပေမယ့် လုံးလုံးတော့ မဟုတ်ဘူး!

အပ်ဒိတ်လုပ်ပြီးနောက် နာရီဝက်အတွင်းတွင်၊ ကလိုင်းယင့် ပြဿနာတစ်ခု ရောက်လာသည်။ ဒေတာဘေ့စ်သည် အလွန်ထူးခြားစွာ အလုပ်လုပ်သည်- အခါအားလျော်စွာ ၎င်းတို့ စတင်ခဲ့သည်။ ချိတ်ဆက်မှုကို ပြန်လည်သတ်မှတ်သည်။. ဤအရာသည် စောင့်ကြည့်ခြင်းတွင် ပုံသဏ္ဍာန်ဖြစ်သည်-

MySQL server threads အချို့မှာ error တစ်ခုနှင့်တစ်ခု အခါအားလျော်စွာ ပျက်စီးသွားသောကြောင့် မျက်နှာပြင်တွင် sawtooth ဂရပ်ကို ပြသထားသည်။ အပလီကေးရှင်းတွင် အမှားအယွင်းများ ပေါ်လာသည်-

[PDOException] SQLSTATE[HY000] [2002] Connection refused

မှတ်တမ်းများကို အမြန်စစ်ဆေးခြင်းသည် mysqld daemon သည် လည်ပတ်မှုစနစ်မှ လိုအပ်သောအရင်းအမြစ်များကို မရရှိနိုင်ကြောင်း ထင်ရှားစေသည်။ အမှားများကို ခွဲထုတ်နေစဉ်၊ ကျွန်ုပ်တို့သည် စနစ်တွင် ရှာဖွေတွေ့ရှိခဲ့သည်။ "မိဘမဲ့" အ၀တ်အထည်မူဝါဒဖိုင်များ:

# 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 သို့ အဆင့်မြှင့်တင်ပြီး ဖယ်ရှားထားသော ပက်ကေ့ခ်ျတစ်ခုမှ ဤဖိုင်များကို ဖန်တီးခဲ့ခြင်းဖြစ်သည်။ ဖိုင်များကိုဖျက်ခြင်းနှင့် apparmor ဝန်ဆောင်မှုကိုပြန်လည်စတင်ခြင်းပြဿနာကိုဖြေရှင်းခဲ့သည်-

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

နိဂုံးချုပ်

အရိုးရှင်းဆုံး လုပ်ဆောင်ချက်ကတောင် မမျှော်လင့်ထားတဲ့ ပြဿနာတွေကို ဖြစ်ပေါ်စေနိုင်ပါတယ်။ ကောင်းစွာ တွေးခေါ်မှုရှိသော အစီအစဉ်ရှိခြင်းသည်ပင် မျှော်လင့်ထားသော ရလဒ်ကို အမြဲတမ်း အာမခံချက်မရှိပါ။ ယခု၊ ကျွန်ုပ်တို့၏အဖွဲ့သည် မကြာသေးမီက လုပ်ဆောင်မှုများကြောင့် ထွက်ပေါ်လာနိုင်သည့် မလိုအပ်သောဖိုင်များကို မဖြစ်မနေ သန့်ရှင်းရေးလုပ်ရမည့် အပ်ဒိတ်အစီအစဥ်များတွင်လည်း ပါဝင်ပါသည်။

အလွန်ပရော်ဖက်ရှင်နယ်ဂရပ်ဖစ်ဖန်တီးမှုမဟုတ်သောကြောင့် Percona သည် ၎င်းတို့၏အလွန်ကောင်းမွန်သောထုတ်ကုန်များအတွက် ကျေးဇူးတင်ကြောင်း ပြောကြားလိုပါသည်။

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «ဒေတာဘေ့စ်များနှင့် Kubernetes (ပြန်လည်သုံးသပ်ခြင်းနှင့် ဗီဒီယိုအစီရင်ခံစာ)";
• «Kubernetes အကြံပြုချက်များနှင့် လှည့်ကွက်များ- ကြီးမားသောဒေတာဘေ့စ်များအတွက် bootstrap ကို အရှိန်မြှင့်ခြင်း။";
• «ကျွန်ုပ်တို့၏ SRE နေ့စဉ်ဘဝမှ လက်တွေ့ကျသော ပုံပြင် 6 ခု";
• «K8s ရှိ Redis အော်ပရေတာနှင့် ဇာတ်လမ်းတစ်ပုဒ်နှင့် ဤဒေတာဘေ့စ်မှ ဒေတာများကို ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် အသုံးဝင်မှုအသေးစား သုံးသပ်ချက်";
• «MongoDB ၏ Kubernetes သို့ ချောမွေ့စွာ ရွှေ့ပြောင်းခြင်း။"။

source: www.habr.com