Orchestrator សម្រាប់ MySQL៖ ហេតុអ្វីបានជាអ្នកមិនអាចបង្កើតគម្រោងដែលអត់ឱនចំពោះកំហុសដោយគ្មានវា។

គម្រោងធំណាមួយបានចាប់ផ្តើមជាមួយម៉ាស៊ីនមេពីរ។ ដំបូងមានម៉ាស៊ីនមេ DB មួយ បន្ទាប់មកទាសករត្រូវបានបន្ថែមទៅវាដើម្បីធ្វើមាត្រដ្ឋានការអាន។ ហើយបន្ទាប់មក - ឈប់! មានចៅហ្វាយតែមួយ ប៉ុន្តែមានទាសករជាច្រើន ប្រសិនបើទាសករម្នាក់ចាកចេញ នោះអ្វីៗនឹងល្អ ប៉ុន្តែប្រសិនបើមេចាកចេញ វានឹងអាក្រក់៖ ពេលវេលារងចាំ អ្នកគ្រប់គ្រងកំពុងព្យាយាមដំឡើងម៉ាស៊ីនមេ។ អ្វី​ដែល​ត្រូវធ្វើ? កក់ទុកមេ។ សហសេវិករបស់ខ្ញុំ Pavel បានសរសេររួចហើយអំពីរឿងនេះ អត្ថបទខ្ញុំនឹងមិននិយាយឡើងវិញទេ។ ផ្ទុយទៅវិញ ខ្ញុំនឹងប្រាប់អ្នកពីមូលហេតុដែលអ្នកពិតជាត្រូវការ Orchestrator សម្រាប់ MySQL!

ចូរចាប់ផ្តើមជាមួយនឹងសំណួរចម្បង: "តើយើងនឹងប្តូរលេខកូដទៅម៉ាស៊ីនថ្មីដោយរបៀបណានៅពេលមេចាកចេញ?"

• ខ្ញុំចូលចិត្តគ្រោងការណ៍ជាមួយវីអាយភី (អាយភីនិម្មិត) បំផុត យើងនឹងនិយាយអំពីវាខាងក្រោម។ វាគឺសាមញ្ញបំផុត និងជាក់ស្តែងបំផុត ទោះបីជាវាមានដែនកំណត់ជាក់ស្តែងក៏ដោយ៖ មេដែលយើងនឹងបម្រុងទុកត្រូវតែស្ថិតនៅក្នុងផ្នែក L2 ជាមួយនឹងម៉ាស៊ីនថ្មី ពោលគឺយើងអាចភ្លេចអំពី DC ទីពីរ។ ហើយតាមរបៀបដ៏ស្និទ្ធស្នាលមួយ ប្រសិនបើអ្នកធ្វើតាមច្បាប់ដែលថា L2 ធំគឺអាក្រក់ ពីព្រោះ L2 គឺត្រឹមតែក្នុងមួយ rack ហើយ L3 គឺនៅចន្លោះ racks ហើយគ្រោងការណ៍បែបនេះមានការរឹតត្បិតថែមទៀត។
• អ្នកអាចសរសេរឈ្មោះ DNS នៅក្នុងកូដ ហើយដោះស្រាយវាតាមរយៈ /etc/hosts ។ ការពិតវានឹងមិនមានដំណោះស្រាយទេ។ អត្ថប្រយោជន៍នៃគ្រោងការណ៍: មិនមានការកំណត់លក្ខណៈនៃវិធីសាស្ត្រទីមួយទេ នោះគឺអាចរៀបចំ DC ឆ្លងកាត់បាន។ ប៉ុន្តែបន្ទាប់មកសំណួរជាក់ស្តែងកើតឡើង: តើយើងអាចបញ្ជូនការផ្លាស់ប្តូរទៅ /etc/hosts តាមរយៈ Puppet-Ansible បានលឿនប៉ុណ្ណា?
• អ្នកអាចផ្លាស់ប្តូរវិធីសាស្រ្តទីពីរបន្តិច៖ ដំឡើងឃ្លាំងសម្ងាត់ DNS នៅលើម៉ាស៊ីនមេបណ្តាញទាំងអស់ តាមរយៈការដែលកូដនឹងទៅមូលដ្ឋានទិន្នន័យមេ។ អ្នកអាចកំណត់ TTL 60 សម្រាប់ធាតុនេះនៅក្នុង DNS ។ វាហាក់ដូចជាថាប្រសិនបើអនុវត្តបានត្រឹមត្រូវវិធីសាស្រ្តគឺល្អ។
• គ្រោងការណ៍ជាមួយនឹងការរកឃើញសេវាកម្ម បង្កប់ន័យការប្រើប្រាស់កុងស៊ុល និងល។
• ជម្រើសគួរឱ្យចាប់អារម្មណ៍ជាមួយ ប្រូកស៊ីSQL. អ្នកត្រូវបញ្ជូនចរាចរទាំងអស់ទៅកាន់ MySQL តាមរយៈ ProxySQL; ProxySQL ខ្លួនវាអាចកំណត់ថាអ្នកណាជាមេ។ ដោយវិធីនេះអ្នកអាចអានអំពីជម្រើសមួយក្នុងចំណោមជម្រើសសម្រាប់ការប្រើប្រាស់ផលិតផលនេះនៅក្នុងរបស់ខ្ញុំ អត្ថបទ.

អ្នកនិពន្ធនៃ Orchestrator ដែលធ្វើការនៅ Github ដំបូងបានអនុវត្តគ្រោងការណ៍ដំបូងជាមួយ VIP ហើយបន្ទាប់មកបានបម្លែងវាទៅជាគ្រោងការណ៍ជាមួយកុងស៊ុល។

ប្លង់ហេដ្ឋារចនាសម្ព័ន្ធធម្មតា៖

ខ្ញុំនឹងពណ៌នាភ្លាមៗអំពីស្ថានភាពជាក់ស្តែងដែលចាំបាច់ត្រូវយកមកពិចារណា៖

• អាសយដ្ឋាន VIP មិនគួរត្រូវបានចុះឈ្មោះក្នុងការកំណត់នៅលើម៉ាស៊ីនមេណាមួយឡើយ។ ចូរយើងស្រមៃមើលស្ថានភាពមួយ៖ មេបានចាប់ផ្ដើមឡើងវិញ ហើយខណៈពេលដែលវាកំពុងផ្ទុក អ្នក Orchestrator បានចូលទៅក្នុងរបៀបបរាជ័យ ហើយបានធ្វើឱ្យទាសករម្នាក់ក្លាយជាមេ។ ពេល​នោះ​មេ​ចាស់​បាន​ក្រោក​ឡើង ហើយ​ឥឡូវ​ VIP ជិះ​ឡាន​ពីរ។ នេះ​ជា​រឿង​អាក្រក់។
• សម្រាប់អ្នកវង់ភ្លេង អ្នកនឹងត្រូវសរសេរអក្សរសម្រាប់ហៅមេចាស់ និងមេថ្មី។ នៅលើមេចាស់ អ្នកត្រូវដំណើរការ ifdown ហើយនៅលើមេថ្មី - ifup vip ។ វាជាការល្អក្នុងការរួមបញ្ចូលនៅក្នុងស្គ្រីបនេះផងដែរ ដែលនៅក្នុងព្រឹត្តិការណ៍នៃការបរាជ័យ ច្រកនៅលើកុងតាក់របស់មេចាស់ត្រូវបានបិទយ៉ាងសាមញ្ញ ដើម្បីជៀសវាងការបំបែកខួរក្បាលណាមួយ។
• បន្ទាប់ពី Orchestrator បានហៅ script របស់អ្នកដើម្បីដក VIP និង/ឬពន្លត់ port ចេញពី switch ហើយបន្ទាប់មកហៅថា VIP raising script នៅលើ master ថ្មី កុំភ្លេចប្រើពាក្យបញ្ជា arping ដើម្បីប្រាប់អ្នកទាំងអស់គ្នាថា VIP ថ្មីឥឡូវនេះ នៅទីនេះ
• ទាសករទាំងអស់គួរតែមាន read_only=1 ហើយដរាបណាអ្នកផ្សព្វផ្សាយទាសករទៅមេ វាគួរតែមាន read_only=0។
• កុំភ្លេចថាទាសករណាដែលយើងជ្រើសរើសសម្រាប់នេះអាចក្លាយជាមេបាន (អ្នកប្រគុំតន្ត្រីមានយន្តការចំណូលចិត្តទាំងមូលដែលទាសករត្រូវពិចារណាជាបេក្ខជនសម្រាប់ចៅហ្វាយថ្មីនៅកន្លែងដំបូង ដែលនៅកន្លែងទីពីរ និងទាសករមួយណាគួរ មិន​ត្រូវ​បាន​ជ្រើស​រើស​នៅ​គ្រប់​កាលៈទេសៈ​ណា​មួយ​មេ)។ ប្រសិនបើទាសករក្លាយជាម្ចាស់ នោះបន្ទុករបស់ទាសករនឹងនៅតែមាននៅលើវា ហើយបន្ទុករបស់ចៅហ្វាយនឹងត្រូវបានបន្ថែម នេះត្រូវតែយកមកពិចារណា។

ហេតុអ្វីបានជាអ្នកត្រូវការ Orchestrator ប្រសិនបើអ្នកមិនមានមួយ?

• Orchestrator មានចំណុចប្រទាក់ក្រាហ្វិកដែលងាយស្រួលប្រើខ្លាំងណាស់ ដែលបង្ហាញនូវ topology ទាំងមូល (សូមមើលរូបថតអេក្រង់ខាងក្រោម)។
• Orchestrator អាចតាមដានថាតើទាសករណាខ្លះដែលយឺតយ៉ាវ និងកន្លែងដែលការចម្លងជាទូទៅត្រូវបានខូច (យើងមានស្គ្រីបភ្ជាប់ជាមួយ Orchestrator សម្រាប់ផ្ញើសារ SMS)។
• Orchestrator ប្រាប់អ្នកថាទាសករណាដែលមានកំហុស GTID ។

ចំណុចប្រទាក់ Orchestrator៖

តើ GTID ខុសអ្វី?

មានតម្រូវការសំខាន់ពីរសម្រាប់ Orchestrator ដើម្បីធ្វើការ៖

• វាចាំបាច់ដែល pseudo GTID ត្រូវបានបើកនៅលើម៉ាស៊ីនទាំងអស់នៅក្នុង MySQL cluster យើងបានបើក GTID ។
• វាចាំបាច់ដែលមានប្រភេទនៃ binlogs នៅគ្រប់ទីកន្លែង អ្នកអាចប្រើសេចក្តីថ្លែងការណ៍បាន។ យើង​មាន​ការ​កំណត់​រចនាសម្ព័ន្ធ​មួយ​ដែល​មេ និង​ទាសករ​ភាគ​ច្រើន​មាន​ជួរដេក ហើយ​ពីរ​នាក់​ជា​ប្រវត្តិសាស្ត្រ​នៅ​ក្នុង​របៀប​ចម្រុះ។ ជាលទ្ធផល Orchestrator គ្រាន់តែមិនចង់ភ្ជាប់ទាសករទាំងនេះទៅនឹងម្ចាស់ថ្មីទេ។

សូមចាំថាអ្វីដែលសំខាន់បំផុតនៅក្នុងទាសករផលិតកម្មគឺភាពស៊ីសង្វាក់គ្នាជាមួយមេ! ប្រសិនបើអ្នកបានបើកដំណើរការ Global Transaction ID (GTID) ទាំងមេ និង slave របស់អ្នក នោះអ្នកអាចប្រើមុខងារ gtid_subset ដើម្បីរកមើលថាតើសំណើដូចគ្នាសម្រាប់ការផ្លាស់ប្តូរទិន្នន័យពិតជាត្រូវបានប្រតិបត្តិនៅលើម៉ាស៊ីនទាំងនេះឬអត់។ អ្នកអាចអានបន្ថែមអំពីរឿងនេះ នៅទីនេះ.

ដូច្នេះ Orchestrator បង្ហាញអ្នកតាមរយៈកំហុស GTID ថាមានប្រតិបត្តិការលើ slave ដែលមិនមាននៅលើមេ។ ហេតុអ្វីបានជារឿងនេះកើតឡើង?

• Read_only=1 មិន​ត្រូវ​បាន​បើក​នៅ​លើ slave មាន​នរណា​ម្នាក់​បាន​ភ្ជាប់ និង​បំពេញ​សំណើ​ដើម្បី​ផ្លាស់​ប្តូរ​ទិន្នន័យ។
• Super_read_only=1 មិន​ត្រូវ​បាន​បើក​នៅ​លើ slave ទេ បន្ទាប់​មក​អ្នក​គ្រប់គ្រង ដោយ​បាន​ច្រឡំ​ម៉ាស៊ីន​បម្រើ បាន​ចូល​ទៅ​ហើយ​ប្រតិបត្តិ​សំណើ​នៅ​ទីនោះ។
• ប្រសិនបើអ្នកពិចារណាលើចំណុចទាំងពីរមុន នោះមានល្បិចមួយទៀត៖ នៅក្នុង MySQL សំណើដើម្បីលុប binlogs ក៏ទៅ binlog ដែរ ដូច្នេះនៅពេល flush ដំបូង កំហុស GTID នឹងលេចឡើងនៅលើមេ និងទាសករទាំងអស់។ តើធ្វើដូចម្តេចដើម្បីជៀសវាងបញ្ហានេះ? Perona-5.7.25-28 បានណែនាំការកំណត់ binlog_skip_flush_commands=1 ដែលហាមឃាត់ការសរសេរ flush ទៅកាន់ binlogs។ មានមួយដែលបានបង្កើតឡើងនៅលើគេហទំព័រ mysql.com កំហុស.

ខ្ញុំសូមសង្ខេបទាំងអស់ខាងលើ។ ប្រសិនបើ​អ្នក​មិន​ចង់​ប្រើ Orchestrator ក្នុង​របៀប​បរាជ័យ​នៅឡើយ​ទេ សូម​ដាក់វា​ក្នុង​របៀប​សង្កេត។ បន្ទាប់មកអ្នកនឹងតែងតែមានផែនទីនៃអន្តរកម្មនៃម៉ាស៊ីន MySQL និងព័ត៌មានដែលមើលឃើញអំពីប្រភេទនៃការចម្លងនៅលើម៉ាស៊ីននីមួយៗថាតើទាសករកំពុងយឺតយ៉ាវហើយសំខាន់បំផុត តើពួកគេមានភាពស៊ីសង្វាក់គ្នាជាមួយមេប៉ុណ្ណា!

សំណួរជាក់ស្តែងគឺ៖ "តើ Orchestrator គួរធ្វើការយ៉ាងដូចម្តេច?" គាត់ត្រូវតែជ្រើសរើសមេថ្មីពីទាសករបច្ចុប្បន្ន ហើយបន្ទាប់មកភ្ជាប់ទាសករទាំងអស់ទៅវាឡើងវិញ (នេះគឺជាអ្វីដែល GTID ត្រូវការសម្រាប់ ប្រសិនបើអ្នកប្រើយន្តការចាស់ជាមួយ binlog_name និង binlog_pos បន្ទាប់មកប្តូរទាសករពីមេបច្ចុប្បន្នទៅថ្មីមួយ។ វាមិនអាចទៅរួចទេ!) មុនពេលដែលយើងមាន Orchestrator ខ្ញុំធ្លាប់ធ្វើអ្វីៗទាំងអស់នេះដោយដៃ។ មេចាស់បានព្យួរកដោយសារតែឧបករណ៍បញ្ជា Adaptec ដ៏អាក្រក់ វាមានទាសករប្រហែល 10 នាក់។ ខ្ញុំត្រូវការផ្ទេរ VIP ពីមេទៅទាសករម្នាក់ ហើយភ្ជាប់ទាសករផ្សេងទៀតទាំងអស់ទៅវាវិញ។ តើខ្ញុំត្រូវបើកកុងសូលប៉ុន្មានគ្រឿង តើខ្ញុំបញ្ចូលពាក្យបញ្ជាដំណាលគ្នាប៉ុន្មាន... ខ្ញុំត្រូវរង់ចាំរហូតដល់ម៉ោង 3 ទៀបភ្លឺ ដកបន្ទុកចេញពីទាសករទាំងអស់ លើកលែងតែពីរ ធ្វើម៉ាស៊ីនទីមួយរបស់មេពីរ ភ្ជាប់ម៉ាស៊ីនទីពីរភ្លាមៗ។ ដូច្នេះ ចូរភ្ជាប់ទាសករផ្សេងទៀតទាំងអស់ទៅម្ចាស់ថ្មី ហើយប្រគល់បន្ទុកវិញ។ សរុបមក គួរអោយខ្លាច...

តើ Orchestrator ដំណើរការយ៉ាងដូចម្តេច នៅពេលដែលវាចូលទៅក្នុងរបៀបបរាជ័យ? នេះត្រូវបានបង្ហាញយ៉ាងងាយស្រួលបំផុតដោយឧទាហរណ៍នៃស្ថានភាពដែលយើងចង់ធ្វើឱ្យមេមួយម៉ាស៊ីនដ៏មានឥទ្ធិពល និងទំនើបជាងដែលយើងមានឥឡូវនេះ។

តួលេខបង្ហាញពីពាក់កណ្តាលនៃដំណើរការ។ តើ​មាន​អ្វី​បាន​ធ្វើ​រួច​ហើយ​រហូត​ដល់​ចំណុច​នេះ? យើងបាននិយាយថាយើងចង់បង្កើតទាសករខ្លះជាចៅហ្វាយថ្មី Orchestrator បានចាប់ផ្តើមភ្ជាប់ទាសករផ្សេងទៀតទាំងអស់ទៅវាឡើងវិញដោយមេថ្មីដើរតួជាម៉ាស៊ីនឆ្លងកាត់។ ជាមួយនឹងគ្រោងការណ៍នេះ មិនមានកំហុសកើតឡើងទេ ទាសករទាំងអស់ដំណើរការ Orchestrator ដក VIP ចេញពីមេចាស់ ផ្ទេរវាទៅថ្មី ធ្វើឱ្យ read_only=0 ហើយភ្លេចអំពីមេចាស់។ ទាំងអស់! ពេលវេលារងចាំនៃសេវាកម្មរបស់យើងគឺជាពេលវេលាផ្ទេរប្រាក់ VIP ដែលមានរយៈពេល 2-3 វិនាទី។

អស់ហើយសម្រាប់ថ្ងៃនេះ អរគុណអ្នកទាំងអស់គ្នា។ នឹងមានអត្ថបទទីពីរអំពី Orchestrator ឆាប់ៗនេះ។ នៅក្នុងខ្សែភាពយន្តសូវៀតដ៏ល្បីល្បាញ "យានដ្ឋាន" តួអង្គមួយបាននិយាយថា "ខ្ញុំនឹងមិនទៅឈ្លបយកការណ៍ជាមួយគាត់ទេ!" ដូច្នេះ Orchestrator ខ្ញុំនឹងទៅជាមួយអ្នកក្នុងការឈ្លបយកការណ៍!

ប្រភព: www.habr.com