នៅ Citymobil យើងប្រើមូលដ្ឋានទិន្នន័យ MySQL ជាការផ្ទុកទិន្នន័យសំខាន់របស់យើង។ យើងមានក្រុមមូលដ្ឋានទិន្នន័យជាច្រើនសម្រាប់សេវាកម្ម និងគោលបំណងផ្សេងៗ។

ភាពអាចរកបានថេរនៃមេគឺជាសូចនាករសំខាន់នៃដំណើរការនៃប្រព័ន្ធទាំងមូលនិងផ្នែកនីមួយៗរបស់វា។ ការងើបឡើងវិញចង្កោមដោយស្វ័យប្រវត្តិនៅក្នុងព្រឹត្តិការណ៍នៃការបរាជ័យមេកាត់បន្ថយពេលវេលាឆ្លើយតបឧប្បត្តិហេតុនិងពេលវេលាមិនដំណើរការរបស់ប្រព័ន្ធយ៉ាងខ្លាំង។ នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងមើលការរចនាដែលអាចរកបានខ្ពស់ (HA) សម្រាប់ចង្កោម MySQL ដោយផ្អែកលើ MySQL Orchestrator និងអាសយដ្ឋាន IP និម្មិត (VIP) ។

ដំណោះស្រាយ HA ផ្អែកលើវីអាយភី

ជាដំបូង ខ្ញុំនឹងប្រាប់អ្នកដោយសង្ខេបថា តើប្រព័ន្ធផ្ទុកទិន្នន័យរបស់យើងជាអ្វី។

យើងប្រើគ្រោងការណ៍ចម្លងបុរាណជាមួយនឹងមេដែលអាចសរសេរបានតែមួយ និងចម្លងបានតែអានច្រើន។ ចង្កោមអាចមានមេកម្រិតមធ្យម - ថ្នាំងដែលចម្លង និងមេសម្រាប់អ្នកដទៃ។ អតិថិជនចូលប្រើការចម្លងតាមរយៈ HAProxy ដែលអនុញ្ញាតឱ្យមានការចែកចាយបន្ទុក និងការធ្វើមាត្រដ្ឋានយ៉ាងងាយស្រួល។ ការប្រើប្រាស់ HAProxy គឺដោយសារហេតុផលប្រវត្តិសាស្ត្រ ហើយបច្ចុប្បន្នយើងកំពុងស្ថិតក្នុងដំណើរការផ្លាស់ប្តូរទៅ ProxySQL ។

ការចម្លងត្រូវបានអនុវត្តនៅក្នុងរបៀបពាក់កណ្តាលសមកាលកម្មដោយផ្អែកលើ GTID. នេះមានន័យថា យ៉ាងហោចណាស់ការចម្លងមួយត្រូវតែកត់ត្រាប្រតិបត្តិការ មុនពេលវាត្រូវបានចាត់ទុកថាជោគជ័យ។ របៀបចម្លងនេះផ្តល់នូវសមតុល្យដ៏ល្អប្រសើររវាងការអនុវត្ត និងសុវត្ថិភាពទិន្នន័យ នៅក្នុងព្រឹត្តិការណ៍នៃការបរាជ័យនៃមេ។ ជាទូទៅការផ្លាស់ប្តូរទាំងអស់ត្រូវបានផ្ទេរពីមេទៅការចម្លងដោយប្រើ Row Based Replication (RBR)ប៉ុន្តែថ្នាំងមួយចំនួនអាចមាន mixed binlog format.

អ្នករៀបចំធ្វើបច្ចុប្បន្នភាពជាប្រចាំនូវស្ថានភាពនៃរចនាសម្ព័ន្ធចង្កោម វិភាគព័ត៌មានដែលទទួលបាន ហើយប្រសិនបើមានបញ្ហាកើតឡើង វាអាចដំណើរការនីតិវិធីសង្គ្រោះដោយស្វ័យប្រវត្តិ។ អ្នកអភិវឌ្ឍន៍ត្រូវទទួលខុសត្រូវចំពោះនីតិវិធីដោយខ្លួនឯង ព្រោះវាអាចត្រូវបានអនុវត្តតាមវិធីផ្សេងៗគ្នា៖ ផ្អែកលើ VIP, DNS ដោយប្រើសេវាកម្មស្វែងរកសេវាកម្ម ឬយន្តការសរសេរដោយខ្លួនឯង។

វិធីសាមញ្ញមួយដើម្បីស្ដារមេប្រសិនបើវាបរាជ័យគឺត្រូវប្រើអាសយដ្ឋាន VIP អណ្តែត។

អ្វីដែលអ្នកត្រូវដឹងអំពីដំណោះស្រាយនេះ មុននឹងឈានទៅមុខ៖

• VIP គឺជាអាសយដ្ឋាន IP ដែលមិនត្រូវបានភ្ជាប់ជាមួយចំណុចប្រទាក់បណ្តាញជាក់ស្តែង។ ប្រសិនបើថ្នាំងមួយបរាជ័យ ឬកំឡុងពេលថែទាំតាមកាលវិភាគ យើងអាចប្តូរវីអាយភីទៅធនធានផ្សេងទៀតដោយប្រើពេលវេលារងចាំតិចបំផុត។
• ការដោះលែង និងចេញអាសយដ្ឋាន IP និម្មិត គឺជាប្រតិបត្តិការថោក និងរហ័ស។
• ដើម្បីធ្វើការជាមួយវីអាយភី អ្នកត្រូវចូលប្រើម៉ាស៊ីនមេតាមរយៈ SSH ឬការប្រើប្រាស់ឧបករណ៍ប្រើប្រាស់ពិសេស ឧទាហរណ៍។ keepalived.

សូមក្រឡេកមើលបញ្ហាដែលអាចកើតមានជាមួយអ្នកជំនួយការរបស់យើង ហើយស្រមៃមើលពីរបៀបដែលយន្តការសង្គ្រោះដោយស្វ័យប្រវត្តិគួរតែដំណើរការ។

ការភ្ជាប់បណ្តាញទៅមេបានបាត់ ឬមានបញ្ហាកើតឡើងនៅកម្រិតផ្នែករឹង ហើយម៉ាស៊ីនមេមិនអាចប្រើបានទេ

1. អ្នក​រៀបចំ​ធ្វើ​បច្ចុប្បន្នភាព​លក្ខណៈ​ចង្កោម ដែល​ការ​ចម្លង​នីមួយៗ​រាយការណ៍​ថា​មេ​មិន​អាច​ប្រើ​បាន​ទេ។ អ្នកប្រគុំតន្ត្រីចាប់ផ្តើមដំណើរការជ្រើសរើសការចម្លងដែលសមរម្យសម្រាប់តួនាទីរបស់មេថ្មី ហើយចាប់ផ្តើមការស្តារឡើងវិញ។
2. យើងកំពុងព្យាយាមដក VIP ចេញពីមេចាស់ - ដោយមិនជោគជ័យ។
3. ចម្លង​ទៅ​តួនាទី​មេ។ topology កំពុងត្រូវបានសាងសង់ឡើងវិញ។
4. ការបន្ថែមចំណុចប្រទាក់បណ្តាញថ្មីជាមួយវីអាយភី។ ដោយសារវាមិនអាចដក VIP ចេញបាន យើងចាប់ផ្តើមផ្ញើសំណើតាមកាលកំណត់ក្នុងផ្ទៃខាងក្រោយ ARP ឥតគិតថ្លៃ. ប្រភេទនៃសំណើ/ការឆ្លើយតបនេះអនុញ្ញាតឱ្យអ្នកធ្វើបច្ចុប្បន្នភាពតារាងផែនទីអាសយដ្ឋាន IP និង MAC នៅលើកុងតាក់ដែលបានភ្ជាប់ ដោយហេតុនេះជូនដំណឹងដល់អ្នកថាវីអាយភីរបស់យើងបានផ្លាស់ប្តូរ។ នេះកាត់បន្ថយលទ្ធភាព split brain នៅពេលប្រគល់ចៅហ្វាយចាស់។
5. ការភ្ជាប់ថ្មីទាំងអស់ត្រូវបានបញ្ជូនបន្តទៅមេថ្មីភ្លាមៗ។ ការភ្ជាប់ចាស់បរាជ័យ ហើយការហៅម្តងហើយម្តងទៀតទៅកាន់មូលដ្ឋានទិន្នន័យត្រូវបានធ្វើឡើងនៅកម្រិតកម្មវិធី។

ម៉ាស៊ីនមេកំពុងដំណើរការក្នុងរបៀបធម្មតា ការបរាជ័យបានកើតឡើងនៅកម្រិត DBMS

ក្បួនដោះស្រាយគឺស្រដៀងគ្នាទៅនឹងករណីមុន៖ ការធ្វើបច្ចុប្បន្នភាព topology និងចាប់ផ្តើមដំណើរការងើបឡើងវិញ។ ដោយសារម៉ាស៊ីនមេអាចប្រើបាន យើងបានចេញផ្សាយ VIP ដោយជោគជ័យនៅលើមេចាស់ ផ្ទេរវាទៅម៉ាស៊ីនថ្មី និងផ្ញើសំណើ ARP ជាច្រើន។ ការត្រឡប់មកវិញដែលអាចធ្វើបានរបស់មេចាស់មិនគួរប៉ះពាល់ដល់ចង្កោមដែលបានសាងសង់ឡើងវិញ និងប្រតិបត្តិការនៃកម្មវិធីនោះទេ។

បញ្ហាផ្សេងៗ

ការបរាជ័យនៃការចម្លងឬចៅហ្វាយនាយកម្រិតមធ្យម មិនដឹកនាំ សកម្មភាពដោយស្វ័យប្រវត្តិ និងទាមទារឱ្យមានអន្តរាគមន៍ដោយដៃ។

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

បញ្ហាអាចកើតឡើងក្នុងអំឡុងពេលដំណើរការស្តារឡើងវិញ ដែលគួរតែត្រូវបានជូនដំណឹងតាមរយៈ Orchestrator UI បន្ថែមពីលើឧបករណ៍ត្រួតពិនិត្យស្តង់ដារ។ យើងបានពង្រីក REST API ដោយបន្ថែមមុខងារនេះ (PR បច្ចុប្បន្នកំពុងស្ថិតក្រោមការត្រួតពិនិត្យ)។

ដ្យាក្រាមទូទៅនៃដំណោះស្រាយ HA ត្រូវបានបង្ហាញខាងក្រោម។

ការជ្រើសរើសមេថ្មី។

អ្នកប្រគុំតន្រ្តីគឺឆ្លាតល្មម ហើយព្យាយាមជ្រើសរើស ការចម្លងដែលសមរម្យបំផុត។ ជាមេថ្មីតាមលក្ខណៈវិនិច្ឆ័យដូចខាងក្រោមៈ

• ការចម្លងនេះនៅខាងក្រោយមេ។
• កំណែ MySQL នៃមេ និងចម្លង;
• ប្រភេទចម្លង (RBR, SBR ឬចម្រុះ);
• ទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដូចគ្នា ឬផ្សេងគ្នា;
• ភាពអាចរកបាន errant GTID - ប្រតិបត្តិការដែលត្រូវបានប្រតិបត្តិលើការចម្លង និងមិនមាននៅលើមេ។
• ច្បាប់ជ្រើសរើសផ្ទាល់ខ្លួនក៏ត្រូវយកមកពិចារណាផងដែរ។

មិនមែនគ្រប់គន្លឺះសុទ្ធតែជាបេក្ខជនដ៏ល្អសម្រាប់មេនោះទេ។ ឧទាហរណ៍ ការចម្លងអាចត្រូវបានប្រើប្រាស់ដើម្បីបម្រុងទុកទិន្នន័យ ឬម៉ាស៊ីនមេមានការកំណត់រចនាសម្ព័ន្ធផ្នែករឹងខ្សោយជាង។ អ្នកភ្លេង គាំទ្រ ច្បាប់ដោយដៃដែលអ្នកអាចប្ដូរតាមបំណងនូវចំណូលចិត្តជ្រើសរើសបេក្ខជនរបស់អ្នកពីចំណូលចិត្តភាគច្រើនទៅជាមិនអើពើ។

ពេលវេលាឆ្លើយតប និងស្តារឡើងវិញ

នៅក្នុងព្រឹត្តិការណ៍នៃឧប្បត្តិហេតុមួយ វាជារឿងសំខាន់ក្នុងការកាត់បន្ថយពេលវេលាមិនដំណើរការរបស់ប្រព័ន្ធ ដូច្នេះសូមពិចារណាអំពីប៉ារ៉ាម៉ែត្រ MySQL ដែលប៉ះពាល់ដល់ការបង្កើត និងការធ្វើបច្ចុប្បន្នភាពនៃក្រុមតន្រ្តីដោយអ្នករៀបចំកម្មវិធី៖

• slave_net_timeout - ចំនួនវិនាទីដែលចម្លងរង់ចាំទិន្នន័យថ្មី ឬសញ្ញាចង្វាក់បេះដូងមកដល់ពីមេ មុនពេលការតភ្ជាប់ត្រូវបានទទួលស្គាល់ថាបាត់បង់ និងភ្ជាប់ឡើងវិញ។ តម្លៃកាន់តែទាប ការចម្លងកាន់តែលឿនអាចកំណត់ថាការទំនាក់ទំនងជាមួយមេត្រូវខូច។ យើងកំណត់តម្លៃនេះទៅ 5 វិនាទី។
• MASTER_CONNECT_RETRY - ចំនួនវិនាទីរវាងការព្យាយាមភ្ជាប់ឡើងវិញ។ នៅក្នុងព្រឹត្តិការណ៍នៃបញ្ហាបណ្តាញ តម្លៃទាបសម្រាប់ប៉ារ៉ាម៉ែត្រនេះនឹងអនុញ្ញាតឱ្យមានការតភ្ជាប់ឡើងវិញយ៉ាងឆាប់រហ័ស និងរារាំងដំណើរការស្តារចង្កោមពីការចាប់ផ្ដើម។ តម្លៃដែលបានណែនាំគឺ 1 វិនាទី។
• MASTER_RETRY_COUNT - ចំនួនអតិបរមានៃការព្យាយាមភ្ជាប់ឡើងវិញ។
• MASTER_HEARTBEAT_PERIOD - ចន្លោះពេលជាវិនាទីបន្ទាប់ពីមេបញ្ជូនសញ្ញាចង្វាក់បេះដូង។ លំនាំដើមដល់ពាក់កណ្តាលតម្លៃ slave_net_timeout.

ប៉ារ៉ាម៉ែត្រ​អ្នក​រៀបចំ៖

• DelayMasterPromotionIfSQLThreadNotUpToDate - បើស្មើគ្នា trueបន្ទាប់មក តួនាទីមេនឹងមិនត្រូវបានអនុវត្តលើការចម្លងបេក្ខជនទេ រហូតទាល់តែខ្សែស្រលាយ SQL របស់ចម្លងបានបញ្ចប់ប្រតិបត្តិការដែលមិនបានអនុវត្តទាំងអស់ពីកំណត់ហេតុបញ្ជូនបន្ត។ យើងប្រើជម្រើសនេះដើម្បីជៀសវាងការបាត់បង់ប្រតិបត្តិការ នៅពេលដែលការចម្លងបេក្ខជនទាំងអស់ធ្លាក់ពីក្រោយ។
• InstancePollSeconds - ភាពញឹកញាប់នៃការសាងសង់ និងការធ្វើបច្ចុប្បន្នភាព topology ។
• RecoveryPollSeconds - ភាពញឹកញាប់នៃការវិភាគ topology ។ ប្រសិនបើបញ្ហាត្រូវបានរកឃើញ ការសង្គ្រោះ topology ត្រូវបានផ្តួចផ្តើម។ នេះ។ ថេរស្មើនឹង 1 វិនាទី។

ថ្នាំងចង្កោមនីមួយៗត្រូវបានស្ទង់មតិដោយអ្នករៀបចំវង់ភ្លេងម្តង InstancePollSeconds វិនាទី នៅពេលរកឃើញបញ្ហា ស្ថានភាពចង្កោមត្រូវបានបង្ខំ បានធ្វើបច្ចុប្បន្នភាពហើយបន្ទាប់មកការសម្រេចចិត្តចុងក្រោយត្រូវបានធ្វើឡើងដើម្បីធ្វើការស្តារឡើងវិញ។ តាមរយៈ​ការ​ពិសោធន៍​ជាមួយ​នឹង​ប៉ារ៉ាម៉ែត្រ​មូលដ្ឋាន​ទិន្នន័យ និង​អ្នក​រៀបចំ​ផ្សេង​គ្នា យើង​អាច​កាត់​បន្ថយ​ពេល​វេលា​នៃ​ការ​ឆ្លើយតប និង​ការ​ស្ដារ​មក​ត្រឹម 30 វិនាទី។

ឈរសាកល្បង

យើងបានចាប់ផ្តើមសាកល្បងគ្រោងការណ៍ HA ជាមួយនឹងការអភិវឌ្ឍន៍ក្នុងស្រុក កៅអីសាកល្បង និងការអនុវត្តបន្ថែមទៀតនៅក្នុងបរិយាកាសសាកល្បង និងផលិតកម្ម។ ការឈរក្នុងតំបន់គឺដោយស្វ័យប្រវត្តិយ៉ាងពេញលេញដោយផ្អែកលើ Docker និងអនុញ្ញាតឱ្យអ្នកធ្វើការពិសោធន៍ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធនៃ orchestrator និងបណ្តាញ ធ្វើមាត្រដ្ឋានចង្កោមពី 2-3 server ទៅរាប់សិប និងធ្វើលំហាត់ក្នុងបរិយាកាសសុវត្ថិភាព។

ក្នុងអំឡុងពេលនៃលំហាត់ យើងជ្រើសរើសវិធីសាស្ត្រត្រាប់តាមបញ្ហាមួយ៖ បាញ់មេដោយប្រើភ្លាមៗ kill -9បញ្ចប់ដំណើរការដោយទន់ភ្លន់ និងបញ្ឈប់ម៉ាស៊ីនមេ (docker-compose stop) ក្លែងធ្វើបញ្ហាបណ្តាញដោយប្រើ iptables -j REJECT ឬ iptables -j DROP. យើងរំពឹងថានឹងមានលទ្ធផលដូចខាងក្រោមៈ

• វង់ភ្លេងនឹងរកឃើញបញ្ហាជាមួយមេ និងធ្វើបច្ចុប្បន្នភាព topology ក្នុងរយៈពេលមិនលើសពី 10 វិនាទី។
• នីតិវិធីនៃការស្តារឡើងវិញនឹងចាប់ផ្តើមដោយស្វ័យប្រវត្តិ៖ ការកំណត់រចនាសម្ព័ន្ធបណ្តាញនឹងផ្លាស់ប្តូរ តួនាទីរបស់មេនឹងឆ្លងទៅការចម្លង តូប៉ូឡូញនឹងត្រូវបានសាងសង់ឡើងវិញ។
• មេថ្មីនឹងអាចសរសេរបាន ការចម្លងបន្តផ្ទាល់នឹងមិនត្រូវបានបាត់បង់ក្នុងអំឡុងពេលដំណើរការសាងសង់ឡើងវិញ។
• ទិន្នន័យនឹងចាប់ផ្តើមសរសេរទៅមេថ្មី ហើយចម្លង។
• រយៈពេលនៃការស្តារឡើងវិញសរុបនឹងមិនលើសពី 30 វិនាទី។

ដូចដែលអ្នកបានដឹងហើយថា ប្រព័ន្ធអាចមានឥរិយាបទខុសគ្នានៅក្នុងបរិយាកាសសាកល្បង និងផលិតកម្ម ដោយសារការកំណត់រចនាសម្ព័ន្ធផ្នែករឹង និងបណ្តាញខុសៗគ្នា ភាពខុសគ្នានៃបន្ទុកសំយោគ និងពិតប្រាកដ។ល។ ដូច្នេះ យើងធ្វើលំហាត់ជាទៀងទាត់ក្នុងស្ថានភាពជាក់ស្តែង ដោយពិនិត្យមើលរបៀបដែលប្រព័ន្ធដំណើរការនៅពេលដែលការភ្ជាប់បណ្តាញត្រូវបានបាត់បង់ ឬផ្នែកនីមួយៗរបស់វាត្រូវបានបំផ្លាញ។ នៅពេលអនាគត យើងចង់បង្កើតហេដ្ឋារចនាសម្ព័ន្ធដូចគ្នាបេះបិទទាំងស្រុងសម្រាប់បរិស្ថានទាំងពីរ និងធ្វើឱ្យការធ្វើតេស្តរបស់វាដោយស្វ័យប្រវត្តិ។

ការរកឃើញ

សុខភាពរបស់ថ្នាំងប្រព័ន្ធផ្ទុកសំខាន់ គឺជាភារកិច្ចចម្បងមួយរបស់ SRE និងក្រុមប្រតិបត្តិការ។ ការអនុវត្តកម្មវិធី Orchestrator និងដំណោះស្រាយ HA ដោយផ្អែកលើ VIP បានអនុញ្ញាតឱ្យយើងសម្រេចបាននូវលទ្ធផលដូចខាងក្រោម៖

• ការរកឃើញដែលអាចទុកចិត្តបាននៃបញ្ហាជាមួយ topology នៃ cluster database;
• ការឆ្លើយតបដោយស្វ័យប្រវត្តិ និងរហ័សចំពោះឧប្បត្តិហេតុដែលទាក់ទងនឹងមេ កាត់បន្ថយពេលវេលារងចាំប្រព័ន្ធ។

ទោះយ៉ាងណាក៏ដោយ ដំណោះស្រាយមានដែនកំណត់ និងគុណវិបត្តិរបស់វា៖

• ការធ្វើមាត្រដ្ឋានគ្រោងការណ៍ HA ទៅមជ្ឈមណ្ឌលទិន្នន័យជាច្រើននឹងតម្រូវឱ្យមានបណ្តាញ L2 តែមួយរវាងពួកវា។
• មុនពេលកំណត់ VIP លើមេថ្មី យើងត្រូវបញ្ចេញវានៅលើមេចាស់។ ដំណើរការគឺបន្តបន្ទាប់គ្នា ដែលបង្កើនពេលវេលានៃការងើបឡើងវិញ។
• ការបញ្ចេញវីអាយភីតម្រូវឱ្យមានការចូលប្រើ SSH ទៅកាន់ម៉ាស៊ីនមេ ឬវិធីសាស្រ្តផ្សេងទៀតនៃការហៅដំណើរការពីចម្ងាយ។ ដោយសារម៉ាស៊ីនមេ ឬមូលដ្ឋានទិន្នន័យកំពុងជួបប្រទះបញ្ហាដែលបណ្តាលឱ្យដំណើរការស្តារឡើងវិញ យើងមិនអាចប្រាកដថាការដកចេញ VIP នឹងបញ្ចប់ដោយជោគជ័យនោះទេ។ ហើយនេះអាចនាំឱ្យមានរូបរាងនៃម៉ាស៊ីនមេពីរដែលមានអាសយដ្ឋាន IP និម្មិតដូចគ្នា និងមានបញ្ហា split brain.

ដើម្បីជៀសវាង split brainអ្នកអាចប្រើវិធីសាស្រ្ត ស្តុននីត ("បាញ់ថ្នាំងផ្សេងទៀតនៅក្នុងក្បាល") ដែលផ្តាច់ទាំងស្រុង ឬបិទថ្នាំងបញ្ហា។ មានវិធីផ្សេងទៀតដើម្បីអនុវត្តភាពអាចរកបានខ្ពស់របស់ចង្កោម៖ ការរួមបញ្ចូលគ្នានៃវីអាយភី និង DNS ការរកឃើញសេវាកម្ម និងសេវាកម្មប្រូកស៊ី ការចម្លងសមកាលកម្ម និងវិធីសាស្រ្តផ្សេងទៀតដែលមានគុណវិបត្តិ និងគុណសម្បត្តិផ្ទាល់ខ្លួន។

ខ្ញុំបាននិយាយអំពីវិធីសាស្រ្តរបស់យើងក្នុងការបង្កើត MySQL failover cluster ។ វាមានភាពងាយស្រួលក្នុងការអនុវត្ត និងផ្តល់នូវកម្រិតដែលអាចទទួលយកបាននៃភាពជឿជាក់ក្រោមលក្ខខណ្ឌបច្ចុប្បន្ន។ នៅពេលដែលប្រព័ន្ធទាំងមូលជាទូទៅ និងហេដ្ឋារចនាសម្ព័ន្ធជាពិសេសមានការអភិវឌ្ឍន៍ វិធីសាស្រ្តនេះនឹងវិវឌ្ឍដោយមិនសង្ស័យ។

ប្រភព: www.habr.com