ការធ្វើបច្ចុប្បន្នភាព 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. ធ្វើបច្ចុប្បន្នភាពមូលដ្ឋានទិន្នន័យ slave ដោយដំឡើងកញ្ចប់ percona-server-server.
4. ធ្វើបច្ចុប្បន្នភាពមេជាមួយនឹងកញ្ចប់ដូចគ្នា។

សូមក្រឡេកមើលចំណុចនីមួយៗនៃផែនការ ហើយមើលថាតើមានអ្វីខុស។

សំខាន់! នីតិវិធីសម្រាប់ការធ្វើបច្ចុប្បន្នភាព MySQL cluster ដោយផ្អែកលើ Galera មាន subtleties ផ្ទាល់ខ្លួនរបស់វាដែលមិនត្រូវបានពិពណ៌នានៅក្នុងអត្ថបទ។ អ្នកមិនគួរប្រើការណែនាំនេះក្នុងករណីនេះទេ។

ផ្នែកទី 1: ពិនិត្យមើលការកំណត់

MySQL ត្រូវបានដកចេញនៅក្នុងកំណែ 8 query_cache. តាមពិតគាត់គឺជា បានប្រកាសថាលែងប្រើ ត្រលប់ទៅកំណែ 5.7 ប៉ុន្តែឥឡូវនេះ បានលុបទាំងស្រុង. ដូច្នោះហើយ ចាំបាច់ត្រូវដកចេញនូវការណែនាំដែលពាក់ព័ន្ធ។ ហើយ​ដើម្បី​ដាក់​សំណើ​ក្នុង​ឃ្លាំង​សម្ងាត់ អ្នក​ឥឡូវ​អាច​ប្រើ​ឧបករណ៍​ខាង​ក្រៅ​បាន - ឧទាហរណ៍ ប្រូកស៊ីSQL.

ផងដែរនៅក្នុងការកំណត់មានការណែនាំហួសសម័យអំពី 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 Server។ យើងនឹងដាក់ server config នៅក្នុងថត 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

បន្ទាត់ខាងក្រោម៖ ទាំងនៅក្នុងកំណត់ហេតុ Docker ឬនៅក្នុងថតដែលមានកំណត់ហេតុ - អាស្រ័យលើការកំណត់របស់អ្នក - ឯកសារមួយនឹងលេចឡើងដែលការណែនាំដែលមានបញ្ហានឹងត្រូវបានពិពណ៌នា។

នេះជាអ្វីដែលយើងមាន៖

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

នេះជាមតិដែលយើងបានទទួល៖

ជាទូទៅគ្មានអ្វីសំខាន់ទេ - មានតែការព្រមានអំពីការអ៊ិនកូដប៉ុណ្ណោះ។ (មើល​ខាង​ក្រោម). លទ្ធផលសរុបនៃការអនុវត្ត៖

យើងបានសម្រេចចិត្តថាការអាប់ដេតគួរតែដំណើរការដោយគ្មានបញ្ហា។

កំណត់ចំណាំអំពីការព្រមានខាងលើដែលបង្ហាញពីបញ្ហាជាមួយនឹងការអ៊ិនកូដ។ ការពិតគឺថា UTF-8 នៅក្នុង MySQL រហូតមកដល់ពេលថ្មីៗនេះ មិនមែនជា "ពិត" UTF-8 ទេ។ចាប់តាំងពីវារក្សាទុកតែ 3 បៃជំនួសឱ្យ 4. នៅក្នុង MySQL 8 នេះទីបំផុត បានសម្រេចចិត្តជួសជុលវា។៖ ឈ្មោះក្លែងក្លាយ utf8 ឆាប់ៗនេះនឹងនាំទៅដល់ការសរសេរកូដ utf8mb4ហើយជួរឈរចាស់នៅក្នុងតារាងនឹងក្លាយជា utf8mb3. ការអ៊ិនកូដបន្ថែម utf8mb3 នឹងត្រូវដកចេញ ប៉ុន្តែមិនមាននៅក្នុងការចេញផ្សាយនេះទេ។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តកែការបំប្លែងកូដរួចហើយនៅលើការដំឡើង DBMS ដែលកំពុងដំណើរការ បន្ទាប់ពីធ្វើបច្ចុប្បន្នភាពវា។

ផ្នែកទី 3៖ ការធ្វើបច្ចុប្បន្នភាពម៉ាស៊ីនមេ

តើមានអ្វីអាចខុសនៅពេលដែលមានផែនការដ៏ឆ្លាតវៃបែបនេះ?.. ដោយយល់យ៉ាងច្បាស់ថាភាពខុសប្លែកគ្នាតែងតែកើតឡើង យើងបានធ្វើការពិសោធន៍លើកដំបូងលើក្រុមអ្នកអភិវឌ្ឍន៍ MySQL ។

ដូចដែលបានបញ្ជាក់រួចមកហើយ, ឯកសារផ្លូវការ គ្របដណ្តប់បញ្ហានៃការធ្វើបច្ចុប្បន្នភាពម៉ាស៊ីនមេ MySQL ជាមួយនឹងការចម្លង។ ចំណុចសំខាន់គឺថាដំបូងអ្នកគួរតែធ្វើបច្ចុប្បន្នភាពការចម្លងទាំងអស់ (ទាសករ) ចាប់តាំងពី MySQL 8 អាចចម្លងពីកំណែមេ 5.7 ។ ការលំបាកខ្លះស្ថិតនៅក្នុងការពិតដែលថាយើងប្រើរបៀប មេ <-> មេនៅពេលដែលមេពីចម្ងាយស្ថិតនៅក្នុងរបៀប អាច​បាន​តែ​អាន. នោះជាការពិត ចរាចរណ៍ប្រយុទ្ធទៅមជ្ឈមណ្ឌលទិន្នន័យមួយ ហើយទីពីរគឺជាការបម្រុងទុកមួយ។

topology មើលទៅដូចនេះ៖

ការធ្វើបច្ចុប្បន្នភាពត្រូវតែចាប់ផ្តើមជាមួយនឹងការចម្លង mysql ចម្លង dc ២, mysql master dc ២ и mysql replica dc 1ហើយបញ្ចប់ដោយម៉ាស៊ីនមេ mysql master dc 1។ ដើម្បីឱ្យកាន់តែជឿជាក់ យើងបានបញ្ឈប់ម៉ាស៊ីននិម្មិត ថតរូបពួកវា ហើយភ្លាមៗមុនពេលអាប់ដេតបានបញ្ឈប់ការចម្លងដោយប្រើពាក្យបញ្ជា STOP SLAVE. ការអាប់ដេតដែលនៅសល់មើលទៅដូចនេះ៖

1. យើងចាប់ផ្តើមការចម្លងនីមួយៗឡើងវិញដោយបន្ថែមជម្រើស 3 ទៅក្នុងការកំណត់៖ skip-networking, skip-slave-start, skip-log-bin. ការពិតគឺថាការធ្វើបច្ចុប្បន្នភាពមូលដ្ឋានទិន្នន័យបង្កើតកំណត់ហេតុគោលពីរជាមួយនឹងការធ្វើបច្ចុប្បន្នភាពតារាងប្រព័ន្ធ។ ការណែនាំទាំងនេះធានាថានឹងមិនមានការផ្លាស់ប្តូរទិន្នន័យកម្មវិធីនៅក្នុងមូលដ្ឋានទិន្នន័យទេ ហើយព័ត៌មានអំពីការធ្វើបច្ចុប្បន្នភាពតារាងប្រព័ន្ធនឹងមិនត្រូវបានរួមបញ្ចូលនៅក្នុងកំណត់ហេតុគោលពីរទេ។ វានឹងជៀសវាងបញ្ហានៅពេលបន្តការចម្លងឡើងវិញ។
2. ការដំឡើងកញ្ចប់ percona-server-server. វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថានៅក្នុង MySQL កំណែ 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 បាននាំឱ្យមានការយល់ដឹងថាបញ្ហានេះកើតឡើងដោយសារ កំហុស 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.

ហេតុអ្វីបានជាយើងមិនមានបញ្ហាបែបនេះនៅលើ dev? មូលដ្ឋានទិន្នន័យត្រូវបានចម្លងជាទៀងទាត់នៅទីនោះពីផលិតកម្ម - ដូច្នេះ តារាងត្រូវបានបង្កើតឡើងវិញ.

ជាអកុសល នៅលើមូលដ្ឋានទិន្នន័យដ៏ធំដែលដំណើរការយ៉ាងពិតប្រាកដ អ្នកនឹងមិនអាចគ្រាន់តែយក និងប្រតិបត្តិជាសកលបាននោះទេ។ OPTIMIZE. percona-toolkit នឹងជួយនៅទីនេះ៖ ឧបករណ៍ប្រើប្រាស់ការផ្លាស់ប្តូរ pt-online-schema-change គឺល្អឥតខ្ចោះសម្រាប់ប្រតិបត្តិការ OPTIMIZE លើអ៊ីនធឺណិត។

ផែនការដែលបានធ្វើបច្ចុប្បន្នភាពមើលទៅដូចនេះ៖

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 - ប៉ារ៉ាម៉ែត្រនេះកែតម្រូវរយៈពេលរង់ចាំបន្ទាប់ពីផ្ទេរទិន្នន័យមួយបាច់ទៅតារាងថ្មី។ វិធីនេះអ្នកអាចកាត់បន្ថយបន្ទុកបាន ប្រសិនបើកម្មវិធីដែលកំពុងដំណើរការពិតប្រាកដទាមទារពេលវេលាឆ្លើយតប។

បន្ទាប់​ពី​អនុវត្ត​ការ​បង្កើន​ប្រសិទ្ធភាព ការ​អាប់ដេត​បាន​ជោគជ័យ។

...តែមិនទាំងស្រុង!

ក្នុងរយៈពេលកន្លះម៉ោងបន្ទាប់ពីការអាប់ដេត អតិថិជនមានបញ្ហា។ មូលដ្ឋានទិន្នន័យដំណើរការយ៉ាងចម្លែក៖ ជាទៀងទាត់ពួកគេបានចាប់ផ្តើម កំណត់ការតភ្ជាប់ឡើងវិញ. នេះជាអ្វីដែលវាមើលទៅក្នុងការត្រួតពិនិត្យ៖

រូបថតអេក្រង់បង្ហាញក្រាហ្វ 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 កាលពីប៉ុន្មានឆ្នាំមុន ហើយជាកម្មសិទ្ធិរបស់កញ្ចប់ដែលបានដកចេញ។ ការលុបឯកសារ និងចាប់ផ្តើមសេវាកម្ម 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 សម្រាប់មូលដ្ឋានទិន្នន័យធំ»
• «រឿងជាក់ស្តែងចំនួន 6 ពីជីវិតប្រចាំថ្ងៃរបស់ SRE របស់យើង។»
• «រឿងមួយជាមួយប្រតិបត្តិករ Redis នៅក្នុង K8s និងការពិនិត្យឡើងវិញខ្នាតតូចអំពីឧបករណ៍ប្រើប្រាស់សម្រាប់ការវិភាគទិន្នន័យពីមូលដ្ឋានទិន្នន័យនេះ»
• «ការធ្វើចំណាកស្រុកដោយរលូននៃ MongoDB ទៅ Kubernetes"។

ប្រភព: www.habr.com