Patroni Failure Stories ឬរបៀបគាំងក្រុម PostgreSQL របស់អ្នក។ Alexey Lesovsky

គោលដៅចម្បងរបស់ Patroni គឺផ្តល់នូវភាពអាចរកបានខ្ពស់សម្រាប់ PostgreSQL ។ ប៉ុន្តែ Patroni គ្រាន់តែជាគំរូមួយ មិនមែនជាឧបករណ៍ដែលត្រៀមរួចជាស្រេច (ដែលជាទូទៅត្រូវបាននិយាយនៅក្នុងឯកសារ)។ នៅក្រឡេកមើលដំបូង ដោយបានដំឡើង Patroni នៅក្នុងមន្ទីរពិសោធន៍សាកល្បង អ្នកអាចដឹងថាវាជាឧបករណ៍ដ៏អស្ចារ្យមួយណា ហើយវាងាយស្រួលគ្រប់គ្រងការប៉ុនប៉ងរបស់យើងក្នុងការបំបែកចង្កោម។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តជាក់ស្តែង នៅក្នុងបរិយាកាសផលិតកម្ម អ្វីគ្រប់យ៉ាងមិនតែងតែកើតឡើងយ៉ាងស្រស់ស្អាត និងឆើតឆាយដូចនៅក្នុងមន្ទីរពិសោធន៍សាកល្បងនោះទេ។

ខ្ញុំនឹងប្រាប់អ្នកបន្តិចអំពីខ្លួនខ្ញុំ។ ខ្ញុំចាប់ផ្តើមជាអ្នកគ្រប់គ្រងប្រព័ន្ធ។ បានធ្វើការនៅក្នុងការអភិវឌ្ឍន៍គេហទំព័រ។ ខ្ញុំបានធ្វើការនៅ Data Egret តាំងពីឆ្នាំ 2014។ ក្រុមហ៊ុននេះត្រូវបានចូលរួមនៅក្នុងការប្រឹក្សានៅក្នុងវិស័យ Postgres ។ ហើយយើងបម្រើ Postgres យ៉ាងពិតប្រាកដ ហើយយើងធ្វើការជាមួយ Postgres ជារៀងរាល់ថ្ងៃ ដូច្នេះយើងមានជំនាញផ្សេងៗគ្នាទាក់ទងនឹងប្រតិបត្តិការ។

ហើយនៅចុងឆ្នាំ 2018 យើងបានចាប់ផ្តើមប្រើប្រាស់ Patroni បន្តិចម្តងៗ។ ហើយបទពិសោធន៍ខ្លះត្រូវបានប្រមូល។ យើង​បាន​ធ្វើ​រោគ​វិនិច្ឆ័យ​វា សម្រួល​វា មក​ដល់​ការអនុវត្ត​ល្អ​បំផុត​របស់​យើង។ ហើយនៅក្នុងរបាយការណ៍នេះ ខ្ញុំនឹងនិយាយអំពីពួកគេ។

ក្រៅពី Postgres ខ្ញុំចូលចិត្តលីនុច។ ខ្ញុំចូលចិត្តដើរជុំវិញវា ហើយរុករក ខ្ញុំចូលចិត្តប្រមូលស្នូល។ ខ្ញុំចូលចិត្តនិម្មិត, ធុង, docker, Kubernetes ។ ទាំងអស់នេះចាប់អារម្មណ៍ខ្ញុំព្រោះទម្លាប់ចាស់របស់adminកំពុងប៉ះពាល់ដល់។ ខ្ញុំចូលចិត្តដោះស្រាយជាមួយការត្រួតពិនិត្យ។ ហើយខ្ញុំចូលចិត្តរឿង Postgres ដែលទាក់ទងនឹងការគ្រប់គ្រង ពោលគឺការចម្លង ការបម្រុងទុក។ ហើយនៅពេលទំនេរខ្ញុំសរសេរក្នុង Go ។ ខ្ញុំ​មិន​មែន​ជា​វិស្វករ​កម្មវិធី​ទេ ខ្ញុំ​គ្រាន់​តែ​សរសេរ​សម្រាប់​ខ្លួន​ខ្ញុំ​នៅ​ក្នុង Go ។ ហើយវាផ្តល់ឱ្យខ្ញុំនូវសេចក្តីរីករាយ។

• ខ្ញុំគិតថាអ្នកទាំងអស់គ្នាដឹងថា Postgres មិនមាន HA (High Availability) ចេញពីប្រអប់នោះទេ។ ដើម្បីទទួលបាន HA អ្នកត្រូវដំឡើងអ្វីមួយ កំណត់រចនាសម្ព័ន្ធវា ខិតខំប្រឹងប្រែង និងទទួលបានវា។
• មានឧបករណ៍ជាច្រើន ហើយ Patroni គឺជាឧបករណ៍មួយក្នុងចំនោមពួកគេដែលដោះស្រាយ HA ស្អាត និងល្អណាស់។ ប៉ុន្តែដោយការដាក់វាទាំងអស់នៅក្នុងមន្ទីរពិសោធន៍ និងដំណើរការវា យើងអាចឃើញថាវាដំណើរការទាំងអស់ យើងអាចបង្កើតឡើងវិញនូវបញ្ហាមួយចំនួន សូមមើលពីរបៀបដែល Patroni បម្រើពួកគេ។ ហើយយើងនឹងឃើញថាវាដំណើរការយ៉ាងអស្ចារ្យ។
• ប៉ុន្តែ​ក្នុង​ការ​អនុវត្ត យើង​បាន​ប្រឈម​នឹង​បញ្ហា​ផ្សេង​គ្នា។ ហើយខ្ញុំនឹងនិយាយអំពីបញ្ហាទាំងនេះ។
• ខ្ញុំ​នឹង​ប្រាប់​អ្នក​ពី​របៀប​ដែល​យើង​ធ្វើ​រោគ​វិនិច្ឆ័យ​វា អ្វី​ដែល​យើង​កែ​សម្រួល - ថា​តើ​វា​បាន​ជួយ​យើង​ឬ​អត់។

• ខ្ញុំនឹងមិនប្រាប់អ្នកពីរបៀបដំឡើង Patroni ទេព្រោះអ្នកអាច google នៅលើអ៊ីនធឺណិត អ្នកអាចមើលឯកសារកំណត់រចនាសម្ព័ន្ធដើម្បីយល់ពីរបៀបដែលវាចាប់ផ្តើមទាំងអស់ របៀបកំណត់រចនាសម្ព័ន្ធ។ អ្នកអាចយល់ពីគ្រោងការណ៍ ស្ថាបត្យកម្ម ស្វែងរកព័ត៌មានអំពីវានៅលើអ៊ីនធឺណិត។
• ខ្ញុំនឹងមិននិយាយអំពីបទពិសោធន៍របស់នរណាម្នាក់ឡើយ។ ខ្ញុំ​នឹង​និយាយ​តែ​ពី​បញ្ហា​ដែល​យើង​បាន​ជួប។
• ហើយខ្ញុំនឹងមិននិយាយអំពីបញ្ហាដែលនៅក្រៅ Patroni និង PostgreSQL ទេ។ ឧទាហរណ៍ ប្រសិនបើមានបញ្ហាទាក់ទងនឹងតុល្យភាព នៅពេលដែលចង្កោមរបស់យើងបានដួលរលំ ខ្ញុំនឹងមិននិយាយអំពីវាទេ។

និងការបដិសេធតូចមួយមុនពេលយើងចាប់ផ្តើមរបាយការណ៍របស់យើង។

បញ្ហាទាំងអស់នេះដែលយើងជួបប្រទះ យើងមានវានៅក្នុង 6-7-8 ខែដំបូងនៃប្រតិបត្តិការ។ យូរៗទៅ យើងបានមកដល់ការអនុវត្តល្អបំផុតផ្ទៃក្នុងរបស់យើង។ ហើយបញ្ហារបស់យើងបានបាត់។ ដូច្នេះហើយ របាយការណ៍នេះត្រូវបានប្រកាសប្រហែលប្រាំមួយខែមុន នៅពេលដែលវាស្រស់នៅក្នុងក្បាលរបស់ខ្ញុំ ហើយខ្ញុំចងចាំវាយ៉ាងល្អឥតខ្ចោះ។

ក្នុង​ពេល​រៀប​ចំ​របាយ​ការណ៍​នេះ ខ្ញុំ​បាន​លើក​យក​សព​ចាស់ៗ​មក​ពិនិត្យ​មើល​កំណត់​ហេតុ។ ហើយព័ត៌មានលម្អិតខ្លះអាចត្រូវបានគេបំភ្លេចចោល ឬព័ត៌មានលម្អិតខ្លះមិនអាចស៊ើបអង្កេតបានពេញលេញក្នុងអំឡុងពេលនៃការវិភាគបញ្ហា ដូច្នេះនៅចំណុចខ្លះវាហាក់ដូចជាបញ្ហាមិនត្រូវបានពិចារណាពេញលេញ ឬខ្វះព័ត៌មានខ្លះ។ ដូច្នេះ​ហើយ​ខ្ញុំ​សុំ​ឱ្យ​អ្នក​លើក​លែង​ខ្ញុំ​សម្រាប់​ពេល​នេះ​។

តើ Patroni ជាអ្វី?

• នេះគឺជាគំរូសម្រាប់ការសាងសង់ HA ។ នោះហើយជាអ្វីដែលវានិយាយនៅក្នុងឯកសារ។ ហើយតាមទស្សនៈរបស់ខ្ញុំ នេះគឺជាការបញ្ជាក់ត្រឹមត្រូវណាស់។ Patroni មិន​មែន​ជា​គ្រាប់​ប្រាក់​ដែល​នឹង​ដោះស្រាយ​រាល់​បញ្ហា​របស់​អ្នក​នោះ​ទេ ពោល​គឺ​អ្នក​ត្រូវ​ប្រឹងប្រែង​ធ្វើ​ឱ្យ​វា​ដំណើរការ និង​នាំ​មក​នូវ​អត្ថប្រយោជន៍។
• នេះគឺជាសេវាកម្មភ្នាក់ងារដែលត្រូវបានដំឡើងនៅលើគ្រប់សេវាកម្មមូលដ្ឋានទិន្នន័យ និងជាប្រភេទនៃប្រព័ន្ធ init សម្រាប់ Postgres របស់អ្នក។ វាចាប់ផ្តើម Postgres បញ្ឈប់ ចាប់ផ្តើមឡើងវិញ កំណត់រចនាសម្ព័ន្ធឡើងវិញ និងផ្លាស់ប្តូរ topology នៃ cluster របស់អ្នក។
• ដូច្នោះហើយ ដើម្បីរក្សាទុកស្ថានភាពនៃចង្កោម តំណាងបច្ចុប្បន្នរបស់វា ដូចដែលវាមើលទៅ ប្រភេទនៃការផ្ទុកមួយចំនួនគឺត្រូវការ។ ហើយតាមទស្សនៈនេះ Patroni បានយកផ្លូវនៃការរក្សាទុករដ្ឋនៅក្នុងប្រព័ន្ធខាងក្រៅ។ វាគឺជាប្រព័ន្ធផ្ទុកកំណត់រចនាសម្ព័ន្ធចែកចាយ។ វាអាចជា Etcd, Consul, ZooKeeper ឬ kubernetes Etcd ពោលគឺជម្រើសមួយក្នុងចំណោមជម្រើសទាំងនេះ។
• ហើយលក្ខណៈពិសេសមួយរបស់ Patroni គឺថាអ្នកទទួលបាន autofiler ចេញពីប្រអប់ ដោយគ្រាន់តែដំឡើងវាប៉ុណ្ណោះ។ ប្រសិនបើយើងយក Repmgr សម្រាប់ការប្រៀបធៀប នោះឯកសារត្រូវបានរួមបញ្ចូលនៅទីនោះ។ ជាមួយនឹង Repmgr យើងទទួលបានការផ្លាស់ប្តូរមួយ ប៉ុន្តែប្រសិនបើយើងចង់បាន autofiler នោះយើងត្រូវកំណត់រចនាសម្ព័ន្ធវាបន្ថែម។ Patroni មាន autofiler ចេញពីប្រអប់រួចហើយ។
• ហើយមានរឿងជាច្រើនទៀត។ ឧទាហរណ៍ ការថែរក្សាការកំណត់រចនាសម្ព័ន្ធ ចាក់ការចម្លងថ្មី ការបម្រុងទុក។ល។ ប៉ុន្តែនេះគឺហួសពីវិសាលភាពនៃរបាយការណ៍ ខ្ញុំនឹងមិននិយាយអំពីវាទេ។

ហើយលទ្ធផលតូចមួយគឺថា ភារកិច្ចចម្បងរបស់ Patroni គឺធ្វើ autofile ឱ្យបានល្អ និងអាចទុកចិត្តបាន ដូច្នេះ cluster របស់យើងនៅតែដំណើរការ ហើយកម្មវិធីមិនកត់សំគាល់ការផ្លាស់ប្តូរនៅក្នុង cluster topology ទេ។

ប៉ុន្តែនៅពេលដែលយើងចាប់ផ្តើមប្រើ Patroni ប្រព័ន្ធរបស់យើងកាន់តែស្មុគស្មាញបន្តិច។ ប្រសិនបើមុននេះយើងមាន Postgres បន្ទាប់មកនៅពេលប្រើ Patroni យើងទទួលបាន Patroni ខ្លួនយើងទទួលបាន DCS ដែលរដ្ឋត្រូវបានរក្សាទុក។ ហើយវាទាំងអស់ត្រូវដំណើរការដូចម្ដេច។ ដូច្នេះតើមានអ្វីអាចទៅខុស?

អាចបំបែក៖

• Postgres អាចនឹងខូច។ វាអាចជាមេ ឬចម្លង មួយក្នុងចំណោមពួកគេអាចនឹងបរាជ័យ។
• Patroni ខ្លួនឯងអាចបំបែកបាន។
• DCS ដែលរដ្ឋត្រូវបានរក្សាទុកអាចខូច។
• ហើយបណ្តាញអាចបំបែកបាន។

ចំណុចទាំងអស់នេះ ខ្ញុំនឹងពិចារណាក្នុងរបាយការណ៍។

ខ្ញុំ​នឹង​ពិចារណា​ករណី​ទាំង​នោះ​ព្រោះ​វា​កាន់តែ​ស្មុគស្មាញ មិនមែន​តាម​ទស្សនៈ​ដែល​ករណី​នេះ​មាន​សមាសធាតុ​ជា​ច្រើន​ទេ។ ហើយតាមទស្សនៈនៃអារម្មណ៍ប្រធានបទ ថាករណីនេះពិបាកសម្រាប់ខ្ញុំ វាពិបាកក្នុងការរុះរើវា ... ហើយផ្ទុយទៅវិញ ករណីខ្លះស្រាល ហើយវាងាយស្រួលក្នុងការរុះរើវា។

ហើយករណីដំបូងគឺងាយស្រួលបំផុត។ នេះ​ជា​ករណី​នៅ​ពេល​ដែល​យើង​យក​ចង្កោម​មូលដ្ឋាន​ទិន្នន័យ ហើយ​ដាក់​ពង្រាយ​កន្លែង​ផ្ទុក DCS របស់​យើង​នៅ​លើ​ចង្កោម​តែមួយ។ នេះគឺជាកំហុសទូទៅបំផុត។ នេះគឺជាកំហុសក្នុងការសាងសង់ស្ថាបត្យកម្ម ពោលគឺការបញ្ចូលគ្នានូវធាតុផ្សំផ្សេងៗគ្នានៅកន្លែងតែមួយ

អ៊ីចឹង​មាន​អ្នក​ដាក់​ឯកសារ​មក​ដោះស្រាយ​រឿង​ហ្នឹង។

ហើយនៅទីនេះយើងចាប់អារម្មណ៍នៅពេលដែលឯកសារបានកើតឡើង។ នោះ​គឺ​យើង​ចាប់​អារម្មណ៍​ក្នុង​ពេល​នេះ​នៅ​ពេល​ដែល​ស្ថានភាព​ចង្កោម​បាន​ផ្លាស់​ប្តូរ។

ប៉ុន្តែអ្នកដាក់ឯកសារមិនតែងតែភ្លាមៗនោះទេ ពោលគឺវាមិនចំណាយពេលណាមួយទេ វាអាចត្រូវបានពន្យារពេល។ វាអាចប្រើប្រាស់បានយូរ។

ដូច្នេះ វាមានពេលវេលាចាប់ផ្តើម និងពេលវេលាបញ្ចប់ ពោលគឺវាជាព្រឹត្តិការណ៍បន្ត។ ហើយ​យើង​បែងចែក​ព្រឹត្តិការណ៍​ទាំងអស់​ជា​បី​ចន្លោះពេល៖ យើង​មាន​ពេល​មុន​អ្នក​ដាក់​ឯកសារ កំឡុង​ពេល​អ្នក​ដាក់​ឯកសារ និង​បន្ទាប់​ពី​អ្នក​ដាក់​ឯកសារ។ នោះគឺយើងពិចារណាព្រឹត្តិការណ៍ទាំងអស់នៅក្នុងបន្ទាត់ពេលវេលានេះ។

ហើយ​រឿង​ដំបូង​ដែល​អ្នក​ដាក់​ឯកសារ​បាន​កើត​ឡើង យើង​រក​មើល​មូលហេតុ​នៃ​អ្វី​ដែល​បាន​កើត​ឡើង តើ​អ្វី​ជា​មូលហេតុ​នៃ​អ្វី​ដែល​នាំ​ឱ្យ​អ្នក​ដាក់​ឯកសារ។

ប្រសិនបើយើងក្រឡេកមើលកំណត់ហេតុនោះ ពួកវានឹងជាកំណត់ហេតុ Patroni បុរាណ។ គាត់ប្រាប់យើងនៅក្នុងពួកគេថាម៉ាស៊ីនមេបានក្លាយជាមេ ហើយតួនាទីរបស់មេបានឆ្លងទៅថ្នាំងនេះ។ នៅទីនេះវាត្រូវបានគូសបញ្ជាក់។

បន្ទាប់មក យើងត្រូវយល់ពីមូលហេតុដែល filer កើតឡើង ពោលគឺ ព្រឹត្តិការណ៍ដែលកើតឡើងដែលបណ្តាលឱ្យតួនាទីមេផ្លាស់ទីពី node មួយទៅ node មួយទៀត។ ហើយក្នុងករណីនេះអ្វីគ្រប់យ៉ាងគឺសាមញ្ញ។ យើងមានកំហុសក្នុងការធ្វើអន្តរកម្មជាមួយប្រព័ន្ធផ្ទុក។ មេបានដឹងថាគាត់មិនអាចធ្វើការជាមួយ DCS បានទេ ពោលគឺមានបញ្ហាមួយចំនួនជាមួយអន្តរកម្ម។ ហើយ​គាត់​ថា​គាត់​មិន​អាច​ធ្វើ​ជា​ម្ចាស់​បាន​ទៀត​ទេ ហើយ​លាលែង​ពី​តំណែង។ បន្ទាត់នេះ "បន្ទាបបន្ថោកខ្លួនឯង" និយាយយ៉ាងពិតប្រាកដ។

ប្រសិនបើយើងក្រឡេកមើលព្រឹត្តិការណ៍ដែលកើតឡើងមុនអ្នកដាក់ឯកសារនោះ យើងអាចឃើញនៅទីនោះនូវហេតុផលជាច្រើនដែលជាបញ្ហាសម្រាប់ការបន្តរបស់អ្នកជំនួយការ។

ប្រសិនបើយើងក្រឡេកមើលកំណត់ហេតុរបស់ Patroni យើងនឹងឃើញថាយើងមានកំហុសជាច្រើន ការអស់ពេល ពោលគឺភ្នាក់ងារ Patroni មិនអាចធ្វើការជាមួយ DCS បានទេ។ ក្នុងករណីនេះនេះគឺជាភ្នាក់ងារកុងស៊ុលដែលកំពុងទំនាក់ទំនងនៅលើច្រក 8500 ។

ហើយបញ្ហានៅទីនេះគឺថា Patroni និងមូលដ្ឋានទិន្នន័យកំពុងដំណើរការលើម៉ាស៊ីនតែមួយ។ ហើយម៉ាស៊ីនមេកុងស៊ុលត្រូវបានដាក់ឱ្យដំណើរការនៅលើថ្នាំងដូចគ្នា។ តាមរយៈការបង្កើតការផ្ទុកនៅលើម៉ាស៊ីនមេ យើងបានបង្កើតបញ្ហាសម្រាប់ម៉ាស៊ីនមេកុងស៊ុលផងដែរ។ ពួកគេមិនអាចទំនាក់ទំនងបានត្រឹមត្រូវ។

បន្ទាប់ពីពេលខ្លះ នៅពេលដែលបន្ទុកបានថយចុះ ប៉ាតូនីរបស់យើងអាចទាក់ទងជាមួយភ្នាក់ងារម្តងទៀត។ ការងារធម្មតាបានបន្ត។ ហើយម៉ាស៊ីនមេ Pgdb-2 ដូចគ្នាបានក្លាយជាមេម្តងទៀត។ នោះគឺមានការបំផ្លិចបំផ្លាញតូចមួយ ដោយសារតែថ្នាំងបានលាលែងពីអំណាចរបស់មេ ហើយបន្ទាប់មកបានយកពួកគេម្តងទៀត ពោលគឺអ្វីៗបានត្រលប់មកវិញដូចដើម។

ហើយនេះអាចចាត់ទុកថាជាការជូនដំណឹងមិនពិត ឬអាចចាត់ទុកថា Patroni បានធ្វើអ្វីគ្រប់យ៉ាងត្រឹមត្រូវ។ នោះគឺគាត់បានដឹងថាគាត់មិនអាចរក្សាស្ថានភាពនៃចង្កោមបានទេហើយដកសិទ្ធិអំណាចរបស់គាត់។

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

ហើយ​យើង​បាន​សម្រេច​ចិត្ត​ថា​វា​មិន​គួរ​រស់នៅ​ជាមួយ​គ្នា​ទេ យើង​បាន​បែងចែក​ចង្កោម​ដាច់ដោយឡែក​សម្រាប់​កុងស៊ុល។ ហើយ Patroni បានធ្វើការជាមួយកុងស៊ុលដាច់ដោយឡែករួចហើយ ពោលគឺមានចង្កោម Postgres ដាច់ដោយឡែក ដែលជាចង្កោមកុងស៊ុលដាច់ដោយឡែក។ នេះ​ជា​ការ​ណែនាំ​ជា​មូលដ្ឋាន​អំពី​ការ​កាន់​និង​រក្សា​របស់​ទាំង​អស់​នេះ​ដើម្បី​កុំ​ឲ្យ​វា​នៅ​ជាមួយ​គ្នា។

ជាជម្រើស អ្នកអាចបង្វែរប៉ារ៉ាម៉ែត្រ ttl, loop_wait, retry_timeout, ឧ. ព្យាយាមដើម្បីរស់រានមានជីវិតពីការកើនឡើងរយៈពេលខ្លីទាំងនេះដោយបង្កើនប៉ារ៉ាម៉ែត្រទាំងនេះ។ ប៉ុន្តែនេះមិនមែនជាជម្រើសដែលសមស្របបំផុតនោះទេព្រោះការផ្ទុកនេះអាចមានរយៈពេលវែង។ ហើយយើងនឹងទៅហួសពីដែនកំណត់នៃប៉ារ៉ាម៉ែត្រទាំងនេះ។ ហើយនោះប្រហែលជាមិនអាចជួយអ្វីបានឡើយ។

បញ្ហាទីមួយ ដូចដែលអ្នកយល់គឺសាមញ្ញ។ យើងយកនិងដាក់ DCS រួមគ្នាជាមួយមូលដ្ឋានយើងមានបញ្ហា។

បញ្ហាទីពីរគឺស្រដៀងនឹងទីមួយ។ វាស្រដៀងគ្នាដែរដែលយើងមានបញ្ហាអន្តរប្រតិបត្តិការជាមួយប្រព័ន្ធ DCS ម្តងទៀត។

ប្រសិនបើយើងក្រឡេកមើលកំណត់ហេតុ យើងនឹងឃើញថាយើងមានបញ្ហាទំនាក់ទំនងម្តងទៀត។ ហើយ Patroni និយាយថាខ្ញុំមិនអាចធ្វើអន្តរកម្មជាមួយ DCS ដូច្នេះមេបច្ចុប្បន្នចូលទៅក្នុងរបៀបចម្លង។

មេចាស់ក្លាយជាអ្នកចម្លង នៅទីនេះ Patroni ដំណើរការដូចដែលវាគួរតែជា។ វាដំណើរការ pg_rewind ដើម្បីត្រឡប់កំណត់ហេតុប្រតិបត្តិការ ហើយបន្ទាប់មកភ្ជាប់ទៅមេថ្មី ដើម្បីចាប់មេថ្មី។ នៅទីនេះ Patroni ធ្វើការចេញដូចដែលគាត់គួរ។

នៅទីនេះ យើងត្រូវស្វែងរកកន្លែងដែលនៅពីមុខ filer ពោលគឺ កំហុសទាំងនោះដែលបណ្តាលឱ្យយើងមាន filer ។ ហើយក្នុងន័យនេះ កំណត់ហេតុរបស់ Patroni គឺមានភាពងាយស្រួលក្នុងការធ្វើការជាមួយ។ គាត់សរសេរសារដូចគ្នានៅចន្លោះពេលជាក់លាក់មួយ។ ហើយប្រសិនបើយើងចាប់ផ្តើមរមូរតាមកំណត់ហេតុទាំងនេះយ៉ាងលឿន នោះយើងនឹងឃើញពីកំណត់ហេតុដែលកំណត់ហេតុបានផ្លាស់ប្តូរ ដែលមានន័យថាបញ្ហាមួយចំនួនបានចាប់ផ្តើមហើយ។ យើងត្រឡប់ទៅកន្លែងនេះវិញយ៉ាងលឿន ឃើញមានអ្វីកើតឡើង។

ហើយនៅក្នុងស្ថានភាពធម្មតា កំណត់ហេតុមើលទៅដូចនេះ។ ម្ចាស់សោត្រូវបានត្រួតពិនិត្យ។ ហើយប្រសិនបើម្ចាស់ឧទាហរណ៍បានផ្លាស់ប្តូរ នោះព្រឹត្តិការណ៍មួយចំនួនអាចកើតឡើងដែល Patroni ត្រូវតែឆ្លើយតប។ ប៉ុន្តែ​ក្នុង​ករណី​នេះ យើង​មិន​អី​ទេ។ យើងកំពុងស្វែងរកកន្លែងដែលកំហុសបានចាប់ផ្តើម។

ហើយដោយបានរមូរទៅចំណុចដែលកំហុសចាប់ផ្តើមលេចឡើង យើងឃើញថាយើងមានឯកសារអូតូ ហើយចាប់តាំងពីកំហុសរបស់យើងទាក់ទងនឹងអន្តរកម្មជាមួយ DCS ហើយក្នុងករណីរបស់យើងយើងបានប្រើកុងស៊ុល យើងក៏ពិនិត្យមើលកំណត់ហេតុកុងស៊ុលផងដែរ តើមានអ្វីកើតឡើងនៅទីនោះ។

ដោយការប្រៀបធៀបពេលវេលារបស់អ្នកដាក់ពាក្យ និងពេលវេលានៅក្នុងកំណត់ហេតុកុងស៊ុល យើងឃើញថាអ្នកជិតខាងរបស់យើងនៅក្នុងចង្កោមកុងស៊ុលបានចាប់ផ្តើមសង្ស័យអំពីអត្ថិភាពនៃសមាជិកផ្សេងទៀតនៃក្រុមកុងស៊ុល។

ហើយប្រសិនបើអ្នកក្រឡេកមើលកំណត់ហេតុរបស់ភ្នាក់ងារកុងស៊ុលផ្សេងទៀត អ្នកក៏អាចមើលឃើញថាការដួលរលំបណ្តាញមួយចំនួនកំពុងកើតឡើងនៅទីនោះ។ ហើយសមាជិកទាំងអស់នៃក្រុមកុងស៊ុលមានការសង្ស័យពីអត្ថិភាពរបស់គ្នាទៅវិញទៅមក។ ហើយ​នេះ​ជា​កម្លាំង​ចិត្ត​សម្រាប់​អ្នក​ដាក់​ឯកសារ។

ប្រសិនបើអ្នកក្រឡេកមើលអ្វីដែលបានកើតឡើងមុនពេលមានកំហុសទាំងនេះ អ្នកអាចមើលឃើញថាមានកំហុសគ្រប់ប្រភេទ ឧទាហរណ៍ កាលបរិច្ឆេទផុតកំណត់ RPC បានធ្លាក់ចុះ នោះគឺច្បាស់ណាស់មានបញ្ហាមួយចំនួននៅក្នុងអន្តរកម្មរបស់សមាជិកក្រុមកុងស៊ុលជាមួយគ្នាទៅវិញទៅមក។ .

ចម្លើយសាមញ្ញបំផុតគឺត្រូវជួសជុលបណ្តាញ។ ប៉ុន្តែ​សម្រាប់​ខ្ញុំ ការ​ឈរ​លើ​វេទិកា វា​ងាយ​នឹង​និយាយ​បែប​នេះ។ ប៉ុន្តែកាលៈទេសៈគឺបែបនេះ ដែលមិនមែនតែងតែអតិថិជនអាចមានលទ្ធភាពជួសជុលបណ្តាញនោះទេ។ គាត់អាចរស់នៅក្នុង DC ហើយប្រហែលជាមិនអាចជួសជុលបណ្តាញបាន ប៉ះពាល់ដល់ឧបករណ៍។ ដូច្នេះហើយ ជម្រើសផ្សេងទៀតមួយចំនួនគឺត្រូវការ។

មានជម្រើស៖

• ជម្រើសដ៏សាមញ្ញបំផុតដែលត្រូវបានសរសេរ តាមគំនិតរបស់ខ្ញុំ សូម្បីតែនៅក្នុងឯកសារគឺត្រូវបិទការត្រួតពិនិត្យកុងស៊ុល ពោលគឺគ្រាន់តែឆ្លងកាត់អារេទទេ។ ហើយយើងប្រាប់ភ្នាក់ងារកុងស៊ុលកុំឱ្យប្រើការត្រួតពិនិត្យណាមួយឡើយ។ ជាមួយនឹងការត្រួតពិនិត្យទាំងនេះ យើងអាចព្រងើយកន្តើយចំពោះព្យុះបណ្តាញទាំងនេះ ហើយមិនចាប់ផ្តើមអ្នកបង្កើតឯកសារទេ។
• ជម្រើសមួយទៀតគឺពិនិត្យមើល raft_multiplier ពីរដង។ នេះគឺជាប៉ារ៉ាម៉ែត្រនៃម៉ាស៊ីនមេកុងស៊ុលខ្លួនឯង។ តាមលំនាំដើម វាត្រូវបានកំណត់ទៅ 5. តម្លៃនេះត្រូវបានណែនាំដោយឯកសារសម្រាប់បរិស្ថានដំណាក់កាល។ តាមពិតទៅ វាប៉ះពាល់ដល់ភាពញឹកញាប់នៃការផ្ញើសាររវាងសមាជិកនៃបណ្តាញកុងស៊ុល។ តាមពិត ប៉ារ៉ាម៉ែត្រនេះប៉ះពាល់ដល់ល្បឿននៃការទំនាក់ទំនងសេវាកម្មរវាងសមាជិកនៃក្រុមកុងស៊ុល។ ហើយសម្រាប់ការផលិត វាត្រូវបានណែនាំរួចហើយដើម្បីកាត់បន្ថយវាដើម្បីឱ្យថ្នាំងផ្លាស់ប្តូរសារញឹកញាប់ជាងមុន។
• ជម្រើសមួយទៀតដែលយើងបានមកគឺដើម្បីបង្កើនអាទិភាពនៃដំណើរការកុងស៊ុលក្នុងចំណោមដំណើរការផ្សេងទៀតសម្រាប់អ្នកកំណត់ពេលដំណើរការនៃប្រព័ន្ធប្រតិបត្តិការ។ មានប៉ារ៉ាម៉ែត្រ "ល្អ" បែបនេះ វាគ្រាន់តែកំណត់អាទិភាពនៃដំណើរការដែលត្រូវបានយកមកពិចារណាដោយកម្មវិធីកំណត់ពេល OS នៅពេលកំណត់ពេល។ យើងក៏បានកាត់បន្ថយតម្លៃដ៏ល្អសម្រាប់ភ្នាក់ងារកុងស៊ុល, i.e. បង្កើនអាទិភាព ដូច្នេះប្រព័ន្ធប្រតិបត្តិការផ្តល់ឱ្យកុងស៊ុលដំណើរការពេលវេលាបន្ថែមទៀតដើម្បីធ្វើការ និងប្រតិបត្តិកូដរបស់ពួកគេ។ ក្នុងករណីរបស់យើង វាបានដោះស្រាយបញ្ហារបស់យើង។
• ជម្រើសមួយទៀតគឺមិនត្រូវប្រើកុងស៊ុលទេ។ ខ្ញុំមានមិត្តម្នាក់ដែលជាអ្នកគាំទ្រដ៏ធំរបស់ Etcd ។ ហើយយើងតែងតែប្រកែកជាមួយគាត់ថាមួយណាល្អជាង Etcd ឬ Consul ។ ប៉ុន្តែបើនិយាយពីអ្វីដែលប្រសើរជាងនេះ ជាធម្មតាយើងយល់ស្របជាមួយគាត់ថាកុងស៊ុលមានភ្នាក់ងារដែលគួរតែដំណើរការលើថ្នាំងនីមួយៗជាមួយនឹងមូលដ្ឋានទិន្នន័យ។ នោះគឺអន្តរកម្មរបស់ Patroni ជាមួយចង្កោមកុងស៊ុលឆ្លងកាត់ភ្នាក់ងារនេះ។ ហើយភ្នាក់ងារនេះក្លាយជាឧបសគ្គ។ ប្រសិនបើមានអ្វីមួយកើតឡើងចំពោះភ្នាក់ងារ នោះ Patroni មិនអាចធ្វើការជាមួយក្រុមកុងស៊ុលទៀតទេ។ ហើយនេះគឺជាបញ្ហា។ មិនមានភ្នាក់ងារនៅក្នុងផែនការ Etcd ទេ។ Patroni អាចធ្វើការដោយផ្ទាល់ជាមួយបញ្ជីនៃម៉ាស៊ីនមេ Etcd និងទាក់ទងជាមួយពួកគេរួចហើយ។ ក្នុងន័យនេះ ប្រសិនបើអ្នកប្រើ Etcd នៅក្នុងក្រុមហ៊ុនរបស់អ្នក នោះ Etcd ប្រហែលជាជម្រើសប្រសើរជាងកុងស៊ុល។ ប៉ុន្តែយើងនៅអតិថិជនរបស់យើងតែងតែមានកម្រិតដោយអ្វីដែលអតិថិជនបានជ្រើសរើស និងប្រើប្រាស់។ ហើយយើងមានកុងស៊ុលសម្រាប់ផ្នែកភាគច្រើនសម្រាប់អតិថិជនទាំងអស់។
• ហើយចំណុចចុងក្រោយគឺត្រូវពិនិត្យឡើងវិញនូវតម្លៃប៉ារ៉ាម៉ែត្រ។ យើងអាចលើកប៉ារ៉ាម៉ែត្រទាំងនេះឡើងដោយសង្ឃឹមថាបញ្ហាបណ្តាញរយៈពេលខ្លីរបស់យើងនឹងខ្លីហើយមិនស្ថិតនៅក្រៅជួរនៃប៉ារ៉ាម៉ែត្រទាំងនេះទេ។ វិធីនេះយើងអាចកាត់បន្ថយការឈ្លានពានរបស់ Patroni ទៅ autofile ប្រសិនបើបញ្ហាបណ្តាញមួយចំនួនកើតឡើង។

ខ្ញុំគិតថាមនុស្សជាច្រើនដែលប្រើ Patroni ស្គាល់ពាក្យបញ្ជានេះ។

ពាក្យបញ្ជានេះបង្ហាញពីស្ថានភាពបច្ចុប្បន្ននៃចង្កោម។ ហើយនៅ glance ដំបូងរូបភាពនេះអាចហាក់ដូចជាធម្មតា។ យើង​មាន​មេ យើង​មាន​ការ​ចម្លង​មិន​មាន​ភាព​យឺតយ៉ាវ​នៃ​ការ​ចម្លង​ទេ។ ប៉ុន្តែរូបភាពនេះគឺជារឿងធម្មតា ទាល់តែយើងដឹងថាចង្កោមនេះគួរតែមានបីថ្នាំង មិនមែនពីរទេ។

ដូច្នោះហើយមានឯកសារស្វ័យប្រវត្តិ។ ហើយបន្ទាប់ពីឯកសារស្វ័យប្រវត្តិនេះ ឯកសារចម្លងរបស់យើងបានបាត់។ យើង​ត្រូវ​រក​ឱ្យ​ឃើញ​ថា​ហេតុ​អ្វី​បាន​ជា​នាង​បាត់​ខ្លួន ហើយ​នាំ​នាង​ត្រឡប់​មក​វិញ ស្ដារ​នាង​ឡើង​វិញ។ ហើយយើងម្តងទៀតទៅកាន់កំណត់ហេតុ ហើយមើលថាហេតុអ្វីបានជាយើងមានឯកសារអូតូ។

ក្នុងករណីនេះអ្នកចម្លងទីពីរបានក្លាយជាមេ។ វាទាំងអស់នៅទីនេះ។

ហើយ​យើង​ត្រូវ​មើល​ការ​ចម្លង​ដែល​បាន​ធ្លាក់​ចុះ ហើយ​មួយ​ណា​មិន​នៅ​ក្នុង​ចង្កោម។ យើងបើកកំណត់ហេតុ Patroni ហើយឃើញថាយើងមានបញ្ហាកំឡុងពេលដំណើរការតភ្ជាប់ទៅ cluster នៅដំណាក់កាល pg_rewind។ ដើម្បីភ្ជាប់ទៅចង្កោម អ្នកត្រូវត្រឡប់កំណត់ហេតុប្រតិបត្តិការឡើងវិញ ស្នើសុំកំណត់ហេតុប្រតិបត្តិការដែលត្រូវការពីមេ ហើយប្រើវាដើម្បីចាប់មេ។

ក្នុងករណីនេះ យើងមិនមានកំណត់ហេតុប្រតិបត្តិការទេ ហើយការចម្លងមិនអាចចាប់ផ្តើមបានទេ។ ដូច្នោះហើយ យើងបញ្ឈប់ Postgres ជាមួយនឹងកំហុសមួយ។ ដូច្នេះហើយ វាមិនស្ថិតនៅក្នុងចង្កោមទេ។

យើងត្រូវយល់ពីមូលហេតុដែលវាមិននៅក្នុងចង្កោម ហើយហេតុអ្វីបានជាមិនមានកំណត់ហេតុ។ យើង​ទៅ​រក​ម្ចាស់​ថ្មី ហើយ​មើល​អ្វី​ដែល​គាត់​មាន​ក្នុង​កំណត់ហេតុ។ វាប្រែថានៅពេលដែល pg_rewind ត្រូវបានធ្វើរួច ចំណុចត្រួតពិនិត្យមួយបានកើតឡើង។ ហើយកំណត់ហេតុប្រតិបត្តិការចាស់មួយចំនួនត្រូវបានប្តូរឈ្មោះយ៉ាងសាមញ្ញ។ នៅពេលដែលមេចាស់ព្យាយាមភ្ជាប់ទៅមេថ្មី ហើយសួរកំណត់ហេតុទាំងនេះ ពួកគេត្រូវបានប្តូរឈ្មោះរួចហើយ វាគ្រាន់តែមិនមាន។

ខ្ញុំបានប្រៀបធៀបពេលវេលាដែលព្រឹត្តិការណ៍ទាំងនេះបានកើតឡើង។ ហើយនៅទីនោះភាពខុសគ្នាគឺ 150 មិល្លីវិនាទី ពោលគឺ ច្រកត្រួតពិនិត្យដែលបានបញ្ចប់ក្នុងរយៈពេល 369 មីលីវិនាទី ផ្នែក WAL ត្រូវបានប្តូរឈ្មោះ។ ហើយតាមព្យញ្ជនៈនៅឆ្នាំ 517 បន្ទាប់ពី 150 មិល្លីវិនាទី ការត្រលប់មកវិញបានចាប់ផ្តើមនៅលើការចម្លងចាស់។ នោះមានន័យថា 150 មីលីវិនាទីគឺគ្រប់គ្រាន់សម្រាប់យើង ដូច្នេះការចម្លងមិនអាចតភ្ជាប់ និងរកប្រាក់ចំណូលបាន។

តើមានជម្រើសអ្វីខ្លះ?

ដំបូងយើងប្រើរន្ធចម្លង។ យើង​បាន​គិត​ថា​វា​ជា​ការ​ល្អ។ ទោះបីជានៅដំណាក់កាលដំបូងនៃប្រតិបត្តិការយើងបានបិទរន្ធដោត។ វាហាក់ដូចជាយើងថាប្រសិនបើរន្ធដោតកកកុញផ្នែក WAL ច្រើន យើងអាចទម្លាក់មេបាន។ គាត់នឹងដួល។ យើង​បាន​រង​ទុក្ខ​មួយ​រយៈ​ដោយ​គ្មាន​រន្ធ។ ហើយ​យើង​បាន​ដឹង​ថា​យើង​ត្រូវ​ការ​រន្ធ​ដោត យើង​បាន​ត្រឡប់​រន្ធ​វិញ​។

ប៉ុន្តែមានបញ្ហានៅទីនេះ ដែលនៅពេលដែលមេទៅកន្លែងចម្លង វាលុបរន្ធដោត និងលុបផ្នែក WAL រួមជាមួយនឹងរន្ធដោត។ ហើយដើម្បីលុបបំបាត់បញ្ហានេះ យើងបានសម្រេចចិត្តលើកប៉ារ៉ាម៉ែត្រ wal_keep_segments ។ វាកំណត់លំនាំដើមទៅ 8 ផ្នែក។ យើងបានបង្កើនវាដល់ 1 ហើយពិនិត្យមើលថាតើយើងមានកន្លែងទំនេរប៉ុន្មាន។ ហើយយើងបានបរិច្ចាគ 000 ជីហ្គាបៃសម្រាប់ wal_keep_segments ។ នោះគឺនៅពេលប្តូរ យើងតែងតែមានទុនបម្រុង 16 ជីហ្គាបៃនៃកំណត់ហេតុប្រតិបត្តិការនៅលើថ្នាំងទាំងអស់។

ហើយបូក - វានៅតែពាក់ព័ន្ធសម្រាប់ការងារថែទាំរយៈពេលវែង។ ឧបមាថា យើងត្រូវធ្វើបច្ចុប្បន្នភាពមួយនៃការចម្លង។ ហើយយើងចង់បិទវា។ យើងត្រូវធ្វើបច្ចុប្បន្នភាពកម្មវិធី ប្រហែលជាប្រព័ន្ធប្រតិបត្តិការ អ្វីផ្សេងទៀត។ ហើយនៅពេលដែលយើងបិទការចម្លង រន្ធសម្រាប់ចម្លងនោះក៏ត្រូវបានដកចេញផងដែរ។ ហើយប្រសិនបើយើងប្រើ wal_keep_segments តូចមួយ នោះជាមួយនឹងអវត្តមានយូរនៃការចម្លង កំណត់ហេតុប្រតិបត្តិការនឹងត្រូវបាត់បង់។ យើងនឹងលើកការចម្លងមួយ វានឹងស្នើសុំកំណត់ហេតុប្រតិបត្តិការទាំងនោះនៅកន្លែងដែលវាឈប់ ប៉ុន្តែពួកវាប្រហែលជាមិនស្ថិតនៅលើមេទេ។ ហើយការចម្លងនឹងមិនអាចភ្ជាប់បានឡើយ។ ដូច្នេះ យើង​រក្សា​ស្តុក​ទស្សនាវដ្ដី​ដ៏​ច្រើន​។

យើងមានមូលដ្ឋានផលិតកម្ម។ មានគម្រោងកំពុងដំណើរការរួចហើយ។

មានអ្នកដាក់ឯកសារ។ យើងបានចូលទៅហើយមើល - អ្វីគ្រប់យ៉ាងគឺស្ថិតនៅក្នុងលំដាប់, ការចម្លងគឺនៅនឹងកន្លែង, មិនមានការយឺតយ៉ាវនៃការចម្លង។ មិនមានកំហុសនៅក្នុងកំណត់ហេតុនោះទេ អ្វីគ្រប់យ៉ាងគឺស្ថិតនៅក្នុងលំដាប់។

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

វាច្បាស់ណាស់ថា pg_rewind ខកខានពួកគេ។ យើង​បាន​យល់​ពី​រឿង​នេះ​ភ្លាម ប៉ុន្តែ​បាន​ទៅ​មើល​ថា​មាន​អ្វី​កើត​ឡើង។

នៅក្នុងកំណត់ហេតុ យើងតែងតែអាចរកឃើញនៅពេលដែលអ្នកដាក់ឯកសារបានកើតឡើង អ្នកណាក្លាយជាមេ ហើយយើងអាចកំណត់ថាអ្នកណាជាមេចាស់ ហើយនៅពេលណាដែលគាត់ចង់ក្លាយជាអ្នកចម្លង ពោលគឺយើងត្រូវការកំណត់ហេតុទាំងនេះ ដើម្បីស្វែងរកបរិមាណនៃកំណត់ហេតុប្រតិបត្តិការនោះ។ ត្រូវបានបាត់បង់។

មេចាស់របស់យើងបានចាប់ផ្ដើមឡើងវិញ។ ហើយ Patroni ត្រូវបានចុះឈ្មោះនៅក្នុង autorun ។ បើកដំណើរការ Patroni ។ បន្ទាប់មកគាត់បានចាប់ផ្តើម Postgres ។ ច្បាស់ជាងនេះទៅទៀត មុនពេលចាប់ផ្តើម Postgres និងមុនពេលធ្វើឱ្យវាក្លាយជាការចម្លង Patroni បានចាប់ផ្តើមដំណើរការ pg_rewind ។ ដូច្នោះហើយ គាត់បានលុបផ្នែកនៃកំណត់ហេតុប្រតិបត្តិការ ទាញយកថ្មី និងភ្ជាប់។ នៅទីនេះ Patroni បានធ្វើការយ៉ាងឆ្លាតវៃ នោះគឺជាការរំពឹងទុក។ ចង្កោមត្រូវបានស្ដារឡើងវិញ។ យើងមានថ្នាំង 3 បន្ទាប់ពីអ្នកដាក់ឯកសារ 3 ថ្នាំង - អ្វីគ្រប់យ៉ាងគឺត្រជាក់។

យើងបានបាត់បង់ទិន្នន័យមួយចំនួន។ ហើយ​យើង​ត្រូវ​យល់​ថា​តើ​យើង​បាន​បាត់​បង់​ប៉ុន្មាន​? យើង​កំពុង​តែ​ស្វែង​រក​ពេល​វេលា​ដែល​យើង​បាន​ត្រឡប់​មក​វិញ​។ យើងអាចរកវាបាននៅក្នុងធាតុទិនានុប្បវត្តិបែបនេះ។ ចាប់ផ្តើមឡើងវិញ ធ្វើអ្វីមួយនៅទីនោះ ហើយបញ្ចប់។

យើងត្រូវស្វែងរកទីតាំងនៅក្នុងកំណត់ហេតុប្រតិបត្តិការដែលមេចាស់បានចាកចេញ។ ក្នុងករណីនេះនេះគឺជាសញ្ញាសម្គាល់។ ហើយ​យើង​ត្រូវ​ការ​សញ្ញា​ទីពីរ ពោល​គឺ​ចម្ងាយ​ដែល​មេ​ចាស់​ខុស​ពី​សញ្ញា​ថ្មី។

យើងយក pg_wal_lsn_diff ធម្មតា ហើយប្រៀបធៀបសញ្ញាទាំងពីរនេះ។ ហើយក្នុងករណីនេះយើងទទួលបាន 17 មេកាបៃ។ ច្រើន​ឬ​តិច គ្រប់​គ្នា​សម្រេច​ដោយ​ខ្លួន​ឯង។ ដោយសារតែសម្រាប់នរណាម្នាក់ 17 មេកាបៃគឺមិនច្រើនទេសម្រាប់នរណាម្នាក់វាច្រើនហើយមិនអាចទទួលយកបាន។ នៅទីនេះបុគ្គលម្នាក់ៗកំណត់ដោយខ្លួនឯងស្របតាមតម្រូវការរបស់អាជីវកម្ម។

ប៉ុន្តែតើយើងបានរកឃើញអ្វីសម្រាប់ខ្លួនយើង?

ដំបូងយើងត្រូវសម្រេចចិត្តដោយខ្លួនឯង - តើយើងតែងតែត្រូវការ Patroni ដើម្បីចាប់ផ្តើមដោយស្វ័យប្រវត្តិបន្ទាប់ពីការចាប់ផ្តើមប្រព័ន្ធឡើងវិញទេ? វាតែងតែកើតឡើងដែលយើងត្រូវទៅរកចៅហ្វាយចាស់មើលថាតើគាត់បានទៅឆ្ងាយ។ ប្រហែលជាពិនិត្យមើលផ្នែកនៃកំណត់ហេតុប្រតិបត្តិការ សូមមើលអ្វីដែលនៅទីនោះ។ ហើយដើម្បីយល់ថាតើយើងអាចបាត់បង់ទិន្នន័យនេះឬថាតើយើងត្រូវដំណើរការមេចាស់នៅក្នុងរបៀបឯករាជ្យដើម្បីទាញទិន្នន័យនេះចេញ។

ហើយមានតែបន្ទាប់ពីនោះយើងគួរតែធ្វើការសម្រេចចិត្តថាយើងអាចបោះបង់ទិន្នន័យនេះ ឬយើងអាចស្ដារវាឡើងវិញ ភ្ជាប់ថ្នាំងនេះជាការចម្លងទៅចង្កោមរបស់យើង។

លើសពីនេះទៀតមានប៉ារ៉ាម៉ែត្រ "maximum_lag_on_failover" ។ តាមលំនាំដើម ប្រសិនបើអង្គចងចាំរបស់ខ្ញុំបម្រើខ្ញុំ ប៉ារ៉ាម៉ែត្រនេះមានតម្លៃ 1 មេកាបៃ។

តើគាត់ធ្វើការយ៉ាងដូចម្តេច? ប្រសិនបើការចម្លងរបស់យើងនៅពីក្រោយទិន្នន័យ 1 មេកាបៃនៅក្នុងភាពយឺតយ៉ាវនៃការចម្លង នោះការចម្លងនេះមិនចូលរួមក្នុងការបោះឆ្នោតទេ។ ហើយប្រសិនបើភ្លាមៗមានការផ្ទេរឯកសារ Patroni មើលទៅថាតើការចម្លងមួយណាដែលយឺតយ៉ាវ។ ប្រសិនបើពួកគេនៅពីក្រោយដោយចំនួនច្រើននៃកំណត់ហេតុប្រតិបត្តិការ ពួកគេមិនអាចក្លាយជាមេបានទេ។ នេះគឺជាមុខងារសុវត្ថិភាពដ៏ល្អដែលការពារអ្នកពីការបាត់បង់ទិន្នន័យជាច្រើន។

ប៉ុន្តែមានបញ្ហាក្នុងការចម្លងនៅក្នុងចង្កោម Patroni និង DCS ត្រូវបានធ្វើបច្ចុប្បន្នភាពនៅចន្លោះពេលជាក់លាក់មួយ។ ខ្ញុំគិតថា 30 វិនាទីគឺជាតម្លៃ ttl លំនាំដើម។

ដូច្នោះហើយ វាអាចមានស្ថានភាពដែលមានភាពយឺតយ៉ាវនៃការចម្លងមួយសម្រាប់ការចម្លងនៅក្នុង DCS ប៉ុន្តែតាមពិតវាអាចមានភាពយឺតយ៉ាវខុសគ្នាទាំងស្រុង ឬប្រហែលជាមិនមានការយឺតយ៉ាវទាល់តែសោះ ពោលគឺ រឿងនេះមិនមែនជាពេលវេលាជាក់ស្តែងទេ។ ហើយវាមិនតែងតែឆ្លុះបញ្ចាំងពីរូបភាពពិតនោះទេ។ ហើយវាមិនមានតម្លៃក្នុងការធ្វើតក្កវិជ្ជាដ៏ប្រណិតលើវាទេ។

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

ហើយមានដំណឹងល្អ។ នៅពេលដែលមេចាស់បានទៅមុន គាត់អាចទៅមុខបានដោយសារតែដំណើរការផ្ទៃខាងក្រោយមួយចំនួន។ នោះគឺមានប្រភេទមួយចំនួននៃ autovacuum គាត់បានសរសេរទិន្នន័យរក្សាទុកពួកវាទៅក្នុងកំណត់ហេតុប្រតិបត្តិការ។ ហើយយើងអាចមិនអើពើ និងបាត់បង់ទិន្នន័យនេះបានយ៉ាងងាយស្រួល។ មិនមានបញ្ហាក្នុងរឿងនេះទេ។

ហើយនេះជារបៀបដែលកំណត់ហេតុមើលទៅប្រសិនបើ maximum_lag_on_failover ត្រូវបានកំណត់ ហើយឯកសារមួយបានកើតឡើង ហើយអ្នកត្រូវជ្រើសរើសមេថ្មី។ អ្នកចម្លងវាយតម្លៃខ្លួនឯងថាគ្មានសមត្ថភាពចូលរួមក្នុងការបោះឆ្នោត។ ហើយនាងបដិសេធមិនចូលរួមក្នុងការប្រណាំងសម្រាប់អ្នកដឹកនាំ។ ហើយនាងរង់ចាំជ្រើសរើសមេថ្មី ទើបនាងអាចភ្ជាប់ទៅវាបាន។ នេះគឺជាវិធានការបន្ថែមប្រឆាំងនឹងការបាត់បង់ទិន្នន័យ។

នៅទីនេះយើងមានក្រុមផលិតផលដែលបានសរសេរថាផលិតផលរបស់ពួកគេមានបញ្ហាជាមួយ Postgres ។ ក្នុងពេលជាមួយគ្នានេះ មេខ្លួនឯងមិនអាចចូលបានទេ ព្រោះវាមិនមានតាមរយៈ SSH។ ហើយ autofile ក៏មិនកើតឡើងដែរ។

ម៉ាស៊ីននេះត្រូវបានបង្ខំឱ្យចាប់ផ្ដើមឡើងវិញ។ ដោយសារតែការចាប់ផ្តើមឡើងវិញ ឯកសារស្វ័យប្រវត្តិមួយបានកើតឡើង ទោះបីជាវាអាចធ្វើទៅបានដើម្បីធ្វើឯកសារស្វ័យប្រវត្តិដោយដៃ ដូចដែលខ្ញុំបានយល់នៅពេលនេះក៏ដោយ។ ហើយបន្ទាប់ពីការចាប់ផ្ដើមឡើងវិញ យើងនឹងឃើញនូវអ្វីដែលយើងមានជាមួយមេបច្ចុប្បន្នរួចហើយ។

ក្នុងពេលជាមួយគ្នានេះ យើងបានដឹងជាមុនថាយើងមានបញ្ហាជាមួយថាស ពោលគឺយើងបានដឹងរួចហើយពីការត្រួតពិនិត្យកន្លែងដែលត្រូវជីក និងអ្វីដែលត្រូវរកមើល។

យើងបានចូលទៅក្នុងកំណត់ហេតុរបស់ Postgres បានចាប់ផ្តើមមើលអ្វីដែលកំពុងកើតឡើងនៅទីនោះ។ យើង​ឃើញ​ការ​ប្រព្រឹត្ត​ដែល​មាន​រយៈពេល​មួយ ពីរ បី​វិនាទី ដែល​មិន​ធម្មតា​ទាល់​តែ​សោះ។ យើងបានឃើញថា autovacuum របស់យើងចាប់ផ្តើមយឺត និងចម្លែកណាស់។ ហើយយើងបានឃើញឯកសារបណ្តោះអាសន្ននៅលើថាស។ នោះគឺទាំងនេះគឺជាសូចនាករទាំងអស់នៃបញ្ហាជាមួយថាស។

យើងបានពិនិត្យមើលប្រព័ន្ធ dmesg (កំណត់ហេតុខឺណែល) ។ ហើយយើងឃើញថាយើងមានបញ្ហាជាមួយថាសមួយ។ ប្រព័ន្ធរងរបស់ថាសគឺជាកម្មវិធី Raid ។ យើងបានមើលនៅ /proc/mdstat ហើយឃើញថាយើងបាត់ដ្រាយមួយ។ នោះគឺមានការវាយឆ្មក់នៃថាសចំនួន 8 យើងកំពុងបាត់មួយ។ ប្រសិនបើអ្នកក្រឡេកមើលស្លាយដោយប្រុងប្រយ័ត្នបន្ទាប់មកនៅក្នុងលទ្ធផលអ្នកអាចមើលឃើញថាយើងមិនមាន sde នៅទីនោះទេ។ នៅយើងនិយាយតាមលក្ខខណ្ឌ ថាសបានធ្លាក់ចុះ។ នេះបានបង្កឱ្យមានបញ្ហាថាស ហើយកម្មវិធីក៏ជួបប្រទះបញ្ហានៅពេលធ្វើការជាមួយក្រុម Postgres ។

ហើយក្នុងករណីនេះ Patroni នឹងមិនជួយយើងតាមមធ្យោបាយណាមួយទេព្រោះ Patroni មិនមានភារកិច្ចត្រួតពិនិត្យស្ថានភាពនៃម៉ាស៊ីនមេស្ថានភាពនៃឌីស។ ហើយ​យើង​ត្រូវ​តែ​ត្រួត​ពិនិត្យ​ស្ថានភាព​បែប​នេះ​ដោយ​ការ​ត្រួត​ពិនិត្យ​ខាង​ក្រៅ។ យើងបានបន្ថែមការត្រួតពិនិត្យថាសទៅការត្រួតពិនិត្យខាងក្រៅយ៉ាងឆាប់រហ័ស។

ហើយ​មាន​ការ​គិត​បែប​នេះ - តើ​កម្មវិធី​ហ៊ុមព័ទ្ធ ឬ​កម្មវិធី​ឃ្លាំមើល​អាច​ជួយ​យើង​បាន​ទេ? យើងគិតថាគាត់ស្ទើរតែមិនបានជួយយើងក្នុងករណីនេះទេ ពីព្រោះក្នុងអំឡុងពេលមានបញ្ហា Patroni បានបន្តធ្វើអន្តរកម្មជាមួយចង្កោម DCS ហើយមិនឃើញមានបញ្ហាអ្វីឡើយ។ នោះគឺតាមទស្សនៈរបស់ DCS និង Patroni អ្វីគ្រប់យ៉ាងគឺល្អជាមួយចង្កោម ទោះបីជាការពិតមានបញ្ហាជាមួយថាសក៏ដោយ ក៏មានបញ្ហាជាមួយនឹងភាពអាចរកបាននៃមូលដ្ឋានទិន្នន័យដែរ។

តាមគំនិតរបស់ខ្ញុំ នេះគឺជាបញ្ហាចំលែកមួយ ដែលខ្ញុំបានស្រាវជ្រាវអស់រយៈពេលជាយូរណាស់មកហើយ ខ្ញុំបានអានកំណត់ហេតុជាច្រើន ជ្រើសរើសឡើងវិញ ហើយហៅវាថា ក្លែងធ្វើចង្កោម។

បញ្ហាគឺថាមេចាស់មិនអាចក្លាយជាការចម្លងធម្មតាបានទេ ពោលគឺ Patroni បានចាប់ផ្តើមវា Patroni បានបង្ហាញថាថ្នាំងនេះមានវត្តមានជាអ្នកចម្លង ប៉ុន្តែក្នុងពេលតែមួយវាមិនមែនជាការចម្លងធម្មតានោះទេ។ ឥឡូវនេះអ្នកនឹងឃើញមូលហេតុ។ នេះជាអ្វីដែលខ្ញុំបានរក្សាទុកពីការវិភាគនៃបញ្ហានោះ។

ហើយតើវាចាប់ផ្តើមដោយរបៀបណា? វាបានចាប់ផ្តើមដូចនៅក្នុងបញ្ហាមុនជាមួយនឹងហ្វ្រាំងឌីស។ យើងមានការសន្យាមួយវិនាទី ពីរ។

មានការបែកធ្លាយនៅក្នុងការតភ្ជាប់ ពោលគឺអតិថិជនត្រូវបានរហែក។

មានការស្ទះនៃភាពធ្ងន់ធ្ងរផ្សេងៗគ្នា។

ហើយតាមនោះ ប្រព័ន្ធរងរបស់ថាសមិនឆ្លើយតបខ្លាំងទេ។

ហើយរឿងអាថ៌កំបាំងបំផុតសម្រាប់ខ្ញុំគឺសំណើរបិទជាបន្ទាន់ដែលបានមកដល់។ Postgres មានរបៀបបិទបី៖

• វាពិតជាល្អណាស់នៅពេលដែលយើងរង់ចាំអតិថិជនទាំងអស់ផ្តាច់ទំនាក់ទំនងដោយខ្លួនឯង។
• វាមានល្បឿនលឿននៅពេលដែលយើងបង្ខំអតិថិជនឱ្យផ្តាច់ទំនាក់ទំនង ពីព្រោះយើងនឹងបិទ។
• និងជាបន្ទាន់។ ក្នុង​ករណី​នេះ ភ្លាម​ៗ​ក៏​មិន​ប្រាប់​អតិថិជន​ឱ្យ​បិទ​ដែរ គឺ​បិទ​ដោយ​មិន​មាន​ការ​ព្រមាន​។ ហើយចំពោះអតិថិជនទាំងអស់ ប្រព័ន្ធប្រតិបត្តិការបានផ្ញើសារ RST រួចហើយ (សារ TCP ដែលការតភ្ជាប់ត្រូវបានរំខាន ហើយម៉ាស៊ីនភ្ញៀវគ្មានអ្វីដែលត្រូវចាប់ទៀតទេ)។

តើអ្នកណាជាអ្នកបញ្ជូនសញ្ញានេះ? ដំណើរការផ្ទៃខាងក្រោយ Postgres មិនបញ្ជូនសញ្ញាបែបនេះទៅគ្នាទៅវិញទៅមកទេ ពោលគឺនេះគឺជា kill-9 ។ ពួកគេមិនផ្ញើរឿងបែបនេះទៅគ្នាទៅវិញទៅមកទេ ពួកគេគ្រាន់តែប្រតិកម្មចំពោះរឿងបែបនេះ ពោលគឺនេះគឺជាការចាប់ផ្តើមឡើងវិញជាបន្ទាន់របស់ Postgres។ អ្នកណាផ្ញើមក ខ្ញុំមិនដឹងទេ។

ខ្ញុំបានក្រឡេកមើលពាក្យបញ្ជា "ចុងក្រោយ" ហើយខ្ញុំបានឃើញមនុស្សម្នាក់ដែលបានចូលម៉ាស៊ីនមេនេះជាមួយយើងដែរ ប៉ុន្តែខ្ញុំខ្មាស់អៀនពេកក្នុងការសួរសំណួរមួយ។ ប្រហែលជាវាត្រូវបានសម្លាប់ -9 ។ ខ្ញុំនឹងឃើញសម្លាប់ -៩ នៅក្នុងកំណត់ហេតុពីព្រោះ Postgres និយាយថាវាបានសម្លាប់ -9 ប៉ុន្តែខ្ញុំមិនបានឃើញវានៅក្នុងកំណត់ហេតុទេ។

ក្រឡេកមើលបន្ថែមទៀតខ្ញុំឃើញថា Patroni មិនបានសរសេរទៅកំណត់ហេតុអស់រយៈពេលជាយូរមកហើយ - 54 វិនាទី។ ហើយ​ប្រសិនបើ​យើង​ប្រៀបធៀប​ការ​បោះត្រា​ពីរដង​នោះ​មិនមាន​សារ​ប្រហែល 54 វិនាទី​ទេ។

ហើយក្នុងអំឡុងពេលនេះមានឯកសារស្វ័យប្រវត្តិ។ Patroni ធ្វើបានល្អណាស់នៅទីនេះម្តងទៀត។ ម្ចាស់ចាស់របស់យើងមិនអាចប្រើបានទេ មានអ្វីមួយកើតឡើងចំពោះគាត់។ ហើយការបោះឆ្នោតជ្រើសរើសចៅហ្វាយនាយថ្មីបានចាប់ផ្តើម។ អ្វីៗដំណើរការបានល្អនៅទីនេះ។ pgsql01 របស់យើងបានក្លាយជាអ្នកដឹកនាំថ្មី។

យើងមានការចម្លងដែលបានក្លាយជាមេ។ ហើយមានការឆ្លើយតបទីពីរ។ ហើយមានបញ្ហាជាមួយការចម្លងទីពីរ។ នាងបានព្យាយាមកំណត់រចនាសម្ព័ន្ធឡើងវិញ។ ដូចដែលខ្ញុំយល់ហើយ នាងបានព្យាយាមផ្លាស់ប្តូរ recovery.conf ចាប់ផ្តើម Postgres ឡើងវិញ ហើយភ្ជាប់ទៅមេថ្មី។ នាង​សរសេរ​សារ​រាល់ ១០ វិនាទី​ដែល​នាង​ព្យាយាម ប៉ុន្តែ​នាង​មិន​បាន​ជោគជ័យ​ទេ។

ហើយក្នុងអំឡុងពេលព្យាយាមទាំងនេះ សញ្ញាបិទភ្លាមៗបានមកដល់មេចាស់។ មេត្រូវបានចាប់ផ្តើមឡើងវិញ។ ហើយការងើបឡើងវិញក៏ឈប់ដែរ ដោយសារមេចាស់ចូលដំណើរការឡើងវិញ។ នោះគឺការចម្លងមិនអាចភ្ជាប់ទៅវាបានទេព្រោះវាស្ថិតនៅក្នុងរបៀបបិទ។

នៅចំណុចខ្លះវាដំណើរការ ប៉ុន្តែការចម្លងមិនបានចាប់ផ្តើមទេ។

ការស្មានតែមួយគត់របស់ខ្ញុំគឺថាមានអាសយដ្ឋានមេចាស់នៅក្នុង recovery.conf ។ ហើយនៅពេលដែលមេថ្មីបានបង្ហាញខ្លួន អ្នកចម្លងទីពីរនៅតែព្យាយាមភ្ជាប់ជាមួយមេចាស់។

នៅពេលដែល Patroni បានចាប់ផ្តើមនៅលើការចម្លងទីពីរ ថ្នាំងបានចាប់ផ្តើមឡើង ប៉ុន្តែមិនអាចចម្លងបានទេ។ ហើយភាពយឺតយ៉ាវនៃការចម្លងត្រូវបានបង្កើតឡើង ដែលមើលទៅដូចនេះ។ នោះគឺថ្នាំងទាំងបីនៅនឹងកន្លែង ប៉ុន្តែថ្នាំងទីពីរនៅខាងក្រោយ។

ក្នុងពេលជាមួយគ្នានេះ ប្រសិនបើអ្នកក្រឡេកមើលកំណត់ហេតុដែលត្រូវបានសរសេរ អ្នកអាចឃើញថាការចម្លងមិនអាចចាប់ផ្តើមបានទេ ដោយសារកំណត់ហេតុប្រតិបត្តិការខុសគ្នា។ ហើយកំណត់ហេតុប្រតិបត្តិការទាំងនោះដែលមេផ្តល់ជូន ដែលត្រូវបានបញ្ជាក់នៅក្នុង recovery.conf គឺមិនសមនឹងថ្នាំងបច្ចុប្បន្នរបស់យើងទេ។

ហើយនៅទីនេះខ្ញុំបានធ្វើខុស។ ខ្ញុំត្រូវមកមើលអ្វីដែលមាននៅក្នុង recovery.conf ដើម្បីសាកល្បងសម្មតិកម្មរបស់ខ្ញុំថាយើងកំពុងភ្ជាប់ទៅមេខុស។ ប៉ុន្តែបន្ទាប់មកខ្ញុំទើបតែដោះស្រាយរឿងនេះ ហើយវាមិនបានកើតឡើងចំពោះខ្ញុំទេ ឬខ្ញុំឃើញថាការចម្លងនេះកំពុងយឺតយ៉ាវ ហើយនឹងត្រូវបំពេញឡើងវិញ ពោលគឺខ្ញុំធ្វើការដោយមិនយកចិត្តទុកដាក់។ នេះជាការរួមរបស់ខ្ញុំ។

បន្ទាប់ពី 30 នាទី, អ្នកគ្រប់គ្រងបានមករួចហើយ, ឧ។ ខ្ញុំបានចាប់ផ្ដើម Patroni ឡើងវិញនៅលើការចម្លង។ ខ្ញុំ​បាន​បញ្ចប់​វា​រួច​ហើយ ខ្ញុំ​គិត​ថា​វា​នឹង​ត្រូវ​តែ​ត្រូវ​បាន​បំពេញ​។ ហើយខ្ញុំបានគិត - ខ្ញុំនឹងចាប់ផ្តើម Patroni ឡើងវិញ ប្រហែលជាអ្វីដែលល្អនឹងចេញមក។ ការស្តារឡើងវិញបានចាប់ផ្តើម។ ហើយមូលដ្ឋានសូម្បីតែបើកវារួចរាល់ដើម្បីទទួលយកការតភ្ជាប់។

ការចម្លងបានចាប់ផ្តើមហើយ។ ប៉ុន្តែ​មួយ​នាទី​ក្រោយ​មក នាង​បាន​ធ្លាក់​ចេញ​ដោយ​មាន​កំហុស​ថា​កំណត់ហេតុ​ប្រតិបត្តិការ​មិន​សមរម្យ​សម្រាប់​នាង។

ខ្ញុំគិតថាខ្ញុំនឹងចាប់ផ្តើមឡើងវិញម្តងទៀត។ ខ្ញុំបានចាប់ផ្ដើម Patroni ម្តងទៀត ហើយខ្ញុំមិនបានចាប់ផ្ដើម Postgres ឡើងវិញទេ ប៉ុន្តែបានចាប់ផ្ដើម Patroni ឡើងវិញដោយសង្ឃឹមថាវានឹងចាប់ផ្តើមមូលដ្ឋានទិន្នន័យដោយមន្តអាគម។

ការ​ចម្លង​បាន​ចាប់​ផ្ដើម​ម្ដង​ទៀត ប៉ុន្តែ​សញ្ញា​នៅ​ក្នុង​កំណត់ហេតុ​ប្រតិបត្តិការ​គឺ​ខុស​គ្នា មិន​ដូច​ការ​ព្យាយាម​ចាប់​ផ្ដើម​មុន​នោះ​ទេ។ ការចម្លងបានឈប់ម្តងទៀត។ ហើយ​សារ​នោះ​គឺ​ខុស​គ្នា​បន្តិច​ហើយ។ ហើយវាមិនមានព័ត៌មានច្រើនសម្រាប់ខ្ញុំទេ។

ហើយបន្ទាប់មកវាកើតឡើងចំពោះខ្ញុំ - ចុះប្រសិនបើខ្ញុំចាប់ផ្តើម Postgres ឡើងវិញនៅពេលនេះ ខ្ញុំធ្វើការត្រួតពិនិត្យលើមេបច្ចុប្បន្ន ដើម្បីផ្លាស់ទីចំណុចនៅក្នុងកំណត់ហេតុប្រតិបត្តិការទៅមុខបន្តិច ដើម្បីឱ្យការងើបឡើងវិញចាប់ផ្តើមពីពេលផ្សេងទៀត? លើសពីនេះ យើងនៅតែមានភាគហ៊ុនរបស់ WAL។

ខ្ញុំបានចាប់ផ្ដើម Patroni ឡើងវិញ បានធ្វើការត្រួតពិនិត្យពីរបីនៅលើមេ ចំណុចចាប់ផ្ដើមឡើងវិញពីរបីនៅលើចម្លងនៅពេលវាបើក។ ហើយវាបានជួយ។ ខ្ញុំបានគិតជាយូរមកហើយថាហេតុអ្វីបានជាវាជួយ និងរបៀបដែលវាដំណើរការ។ ហើយការចម្លងបានចាប់ផ្តើម។ ហើយការចម្លងមិនត្រូវបានរហែកទៀតទេ។

បញ្ហា​បែប​នេះ​សម្រាប់​ខ្ញុំ​គឺ​ជា​បញ្ហា​អាថ៌កំបាំង​មួយ​ទៀត ដែល​ខ្ញុំ​នៅ​តែ​ឆ្ងល់​អំពី​អ្វី​ដែល​ពិត​ជា​បាន​កើត​ឡើង​នៅ​ទីនោះ។

តើមានផលប៉ះពាល់អ្វីខ្លះនៅទីនេះ? Patroni អាចធ្វើការដូចបំណង និងដោយគ្មានកំហុស។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ នេះមិនមែនជាការធានា 100% ថាអ្វីគ្រប់យ៉ាងគឺល្អជាមួយយើងនោះទេ។ ការចម្លងអាចចាប់ផ្តើម ប៉ុន្តែវាអាចស្ថិតក្នុងស្ថានភាពពាក់កណ្តាលដំណើរការ ហើយកម្មវិធីមិនអាចដំណើរការជាមួយការចម្លងបែបនេះបានទេ ព្រោះវានឹងមានទិន្នន័យចាស់។

ហើយបន្ទាប់ពីអ្នកដាក់ឯកសារ អ្នកតែងតែត្រូវពិនិត្យមើលថាអ្វីគ្រប់យ៉ាងគឺស្ថិតនៅក្នុងលំដាប់ជាមួយចង្កោម នោះគឺមានចំនួននៃការចម្លងតាមតម្រូវការ វាមិនមានភាពយឺតយ៉ាវក្នុងការចម្លងទេ។

ហើយនៅពេលយើងឆ្លងកាត់បញ្ហាទាំងនេះ ខ្ញុំនឹងធ្វើការណែនាំ។ ខ្ញុំបានព្យាយាមបញ្ចូលពួកវាទៅជាស្លាយពីរ។ ប្រហែលជារឿងទាំងអស់អាចបញ្ចូលគ្នាជាស្លាយពីរ ហើយគ្រាន់តែប្រាប់ប៉ុណ្ណោះ។

នៅពេលអ្នកប្រើ Patroni អ្នកត្រូវតែមានការត្រួតពិនិត្យ។ អ្នកគួរដឹងជានិច្ចនៅពេលដែល autofileover កើតឡើង ព្រោះប្រសិនបើអ្នកមិនដឹងថាអ្នកមាន autofileover នោះអ្នកមិនមានការគ្រប់គ្រងលើ cluster ទេ។ ហើយនោះជារឿងអាក្រក់។

បន្ទាប់ពី filer នីមួយៗ យើងតែងតែត្រូវពិនិត្យ cluster ដោយដៃ។ យើងត្រូវប្រាកដថាយើងតែងតែមានលេខចម្លងទាន់សម័យជានិច្ច មិនមានការចម្លងយឺតយ៉ាវ មិនមានកំហុសក្នុងកំណត់ហេតុដែលទាក់ទងនឹងការចម្លងស្ទ្រីមជាមួយ Patroni ជាមួយនឹងប្រព័ន្ធ DCS ។

ស្វ័យប្រវត្តិកម្មអាចដំណើរការដោយជោគជ័យ Patroni គឺជាឧបករណ៍ល្អណាស់។ វាអាចដំណើរការបាន ប៉ុន្តែវានឹងមិននាំចង្កោមទៅស្ថានភាពដែលចង់បាននោះទេ។ ហើយ​បើ​យើង​មិន​ដឹង​ពី​វា​ទេ យើង​នឹង​មាន​បញ្ហា។

ហើយ Patroni មិនមែនជាគ្រាប់កាំភ្លើងទេ។ យើងនៅតែត្រូវយល់ពីរបៀបដែល Postgres ដំណើរការ របៀបចម្លងដំណើរការ និងរបៀបដែល Patroni ធ្វើការជាមួយ Postgres និងរបៀបទំនាក់ទំនងរវាងថ្នាំងត្រូវបានផ្តល់។ នេះគឺចាំបាច់ដើម្បីអាចដោះស្រាយបញ្ហាដោយដៃរបស់អ្នក។

តើខ្ញុំទាក់ទងបញ្ហារោគវិនិច្ឆ័យដោយរបៀបណា? វាបានកើតឡើងដូច្នេះថាយើងធ្វើការជាមួយអតិថិជនផ្សេងគ្នា ហើយគ្មាននរណាម្នាក់មានជង់ ELK ហើយយើងត្រូវតម្រៀបកំណត់ហេតុដោយបើក 6 កុងសូល និង 2 ផ្ទាំង។ នៅក្នុងផ្ទាំងមួយ ទាំងនេះគឺជាកំណត់ហេតុរបស់ Patroni សម្រាប់ថ្នាំងនីមួយៗ នៅក្នុងផ្ទាំងផ្សេងទៀត ទាំងនេះគឺជាកំណត់ហេតុកុងស៊ុល ឬ Postgres ប្រសិនបើចាំបាច់។ វាពិបាកណាស់ក្នុងការធ្វើរោគវិនិច្ឆ័យនេះ។

តើខ្ញុំបានយកវិធីសាស្រ្តអ្វីខ្លះ? ទីមួយ ខ្ញុំតែងតែរកមើលនៅពេលដែលឯកសារបានមកដល់។ ហើយ​សម្រាប់​ខ្ញុំ​នេះ​គឺ​ជា​ទឹក​។ ខ្ញុំមើលអ្វីដែលបានកើតឡើងមុនពេលអ្នកដាក់ឯកសារ កំឡុងពេលអ្នកដាក់ឯកសារ និងបន្ទាប់ពីអ្នកដាក់ឯកសារ។ ការដាក់ឯកសារមានសញ្ញាពីរ៖ នេះគឺជាពេលវេលាចាប់ផ្តើម និងបញ្ចប់។

បន្ទាប់មកទៀត ខ្ញុំរកមើលនៅក្នុងកំណត់ហេតុសម្រាប់ព្រឹត្តិការណ៍មុនពេលអ្នកដាក់ឯកសារ ដែលនាំមុខអ្នកដាក់ឯកសារ ពោលគឺខ្ញុំរកមើលមូលហេតុដែលអ្នកដាក់ឯកសារកើតឡើង។

ហើយនេះផ្តល់នូវរូបភាពនៃការយល់ដឹងអំពីអ្វីដែលបានកើតឡើង និងអ្វីដែលអាចធ្វើបាននៅពេលអនាគត ដើម្បីកុំឱ្យកាលៈទេសៈបែបនេះកើតឡើង (ហើយជាលទ្ធផលគឺគ្មានឯកសារ)។

ហើយតើយើងមើលទៅជាធម្មតានៅឯណា? ខ្ញុំ​មើល:

• ទីមួយទៅកាន់កំណត់ហេតុ Patroni ។
• បន្ទាប់ខ្ញុំមើលកំណត់ហេតុ Postgres ឬកំណត់ហេតុ DCS អាស្រ័យលើអ្វីដែលបានរកឃើញនៅក្នុងកំណត់ហេតុរបស់ Patroni ។
• ហើយ​កំណត់ហេតុ​ប្រព័ន្ធ​ក៏​ជួនកាល​ផ្តល់​ឱ្យ​នូវ​ការ​យល់​ដឹង​អំពី​អ្វី​ដែល​បណ្តាល​ឱ្យ​អ្នក​ដាក់​ឯកសារ។

តើខ្ញុំមានអារម្មណ៍យ៉ាងណាចំពោះ Patroni? ខ្ញុំមានទំនាក់ទំនងល្អជាមួយ Patroni ។ តាមគំនិតរបស់ខ្ញុំ នេះគឺល្អបំផុតដែលមានសព្វថ្ងៃនេះ។ ខ្ញុំស្គាល់ផលិតផលជាច្រើនទៀត។ ទាំងនេះគឺ Stolon, Repmgr, Pg_auto_failover, PAF ។ 4 ឧបករណ៍។ ខ្ញុំបានសាកល្បងពួកវាទាំងអស់។ Patroni គឺជាសំណព្វរបស់ខ្ញុំ។

ប្រសិនបើពួកគេសួរខ្ញុំថា "តើខ្ញុំណែនាំ Patroni ទេ?" ។ ខ្ញុំនឹងនិយាយថា បាទ ព្រោះខ្ញុំចូលចិត្ត Patroni ។ ហើយខ្ញុំគិតថាខ្ញុំបានរៀនពីរបៀបចំអិនវា។

ប្រសិនបើអ្នកចាប់អារម្មណ៍ក្នុងការមើលថាតើមានបញ្ហាអ្វីផ្សេងទៀតដែលមានជាមួយ Patroni ក្រៅពីបញ្ហាដែលខ្ញុំបានលើកឡើងនោះ អ្នកតែងតែអាចពិនិត្យមើលទំព័រ បញ្ហា នៅលើ GitHub ។ មានរឿងប្លែកៗជាច្រើន ហើយបញ្ហាគួរឱ្យចាប់អារម្មណ៍ជាច្រើនត្រូវបានពិភាក្សានៅទីនោះ។ ហើយជាលទ្ធផល កំហុសមួយចំនួនត្រូវបានណែនាំ និងដោះស្រាយ ពោលគឺនេះគឺជាការអានដ៏គួរឱ្យចាប់អារម្មណ៍មួយ។

មានរឿងគួរឱ្យចាប់អារម្មណ៍មួយចំនួនអំពីមនុស្សបាញ់ខ្លួនឯងនៅជើង។ ព័ត៌មានល្អណាស់។ អ្នកអានហើយយល់ថាវាមិនចាំបាច់ដើម្បីធ្វើដូច្នេះទេ។ ខ្ញុំបានគូសខ្លួនឯង។

ហើយខ្ញុំសូមថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះ Zalando សម្រាប់ការអភិវឌ្ឍន៍គម្រោងនេះ ពោលគឺចំពោះ Alexander Kukushkin និង Alexey Klyukin ។ Aleksey Klyukin គឺជាសហអ្នកនិពន្ធម្នាក់ គាត់លែងធ្វើការនៅ Zalando ទៀតហើយ ប៉ុន្តែនេះគឺជាមនុស្សពីរនាក់ដែលបានចាប់ផ្តើមធ្វើការជាមួយផលិតផលនេះ។

ហើយ​ខ្ញុំ​គិត​ថា Patroni គឺ​ជា​រឿង​ល្អ​ណាស់។ ខ្ញុំសប្បាយចិត្តដែលនាងមាន វាគួរឱ្យចាប់អារម្មណ៍ជាមួយនាង។ ហើយសូមថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះអ្នករួមចំណែកទាំងអស់ដែលបង្កើតបំណះដល់ Patroni ។ ខ្ញុំសង្ឃឹមថា Patroni នឹងកាន់តែមានភាពចាស់ទុំ ត្រជាក់ និងមានប្រសិទ្ធភាពទៅតាមអាយុ។ វាមានមុខងាររួចហើយ ប៉ុន្តែខ្ញុំសង្ឃឹមថាវានឹងកាន់តែប្រសើរឡើង។ ដូច្នេះប្រសិនបើអ្នកមានគម្រោងប្រើ Patroni នោះកុំខ្លាចអី។ នេះគឺជាដំណោះស្រាយដ៏ល្អ វាអាចត្រូវបានអនុវត្ត និងប្រើប្រាស់បាន។

អស់ហើយ។ ប្រសិនបើអ្នកមានសំណួរសូមសួរ។

សំណួរ

អរគុណសម្រាប់របាយការណ៍! ប្រសិនបើបន្ទាប់ពីអ្នកដាក់ឯកសារ អ្នកនៅតែត្រូវរកមើលនៅទីនោះដោយប្រុងប្រយ័ត្ន នោះហេតុអ្វីបានជាយើងត្រូវការឯកសារដោយស្វ័យប្រវត្តិ?

ព្រោះវាជារបស់ថ្មី។ យើង​នៅ​ជាមួយ​នាង​បាន​តែ​មួយ​ឆ្នាំ​ប៉ុណ្ណោះ។ ប្រសើរជាងដើម្បីមានសុវត្ថិភាព។ យើង​ចង់​ចូល​មក​មើល​ថា​អ្វី​គ្រប់​យ៉ាង​ពិត​ជា​បាន​សម្រេច​ដូច​ដែល​វា​គួរ​ធ្វើ។ នេះគឺជាកម្រិតនៃការមិនទុកចិត្តរបស់មនុស្សពេញវ័យ - វាជាការល្អប្រសើរជាងមុនដើម្បីពិនិត្យមើលពីរដងនិងមើលឃើញ។

ឧទាហរណ៍​ថា​យើង​ទៅ​ពេល​ព្រឹក​ហើយ​មើល​មែន​ទេ?

មិនមែននៅពេលព្រឹកទេ ជាធម្មតាយើងរៀនអំពីឯកសារស្វ័យប្រវត្តិស្ទើរតែភ្លាមៗ។ យើងទទួលបានការជូនដំណឹង យើងឃើញថាឯកសារស្វ័យប្រវត្តិបានកើតឡើង។ យើងស្ទើរតែទៅមើលភ្លាម។ ប៉ុន្តែការត្រួតពិនិត្យទាំងអស់នេះគួរតែត្រូវបាននាំយកទៅកម្រិតត្រួតពិនិត្យ។ ប្រសិនបើអ្នកចូលប្រើ Patroni តាមរយៈ REST API មានប្រវត្តិ។ តាម​ប្រវត្តិ អ្នក​អាច​ឃើញ​ត្រា​ពេល​វេលា​នៅ​ពេល​ដែល​ឯកសារ​បាន​កើត​ឡើង។ ដោយផ្អែកលើនេះការត្រួតពិនិត្យអាចធ្វើទៅបាន។ អ្នក​អាច​មើល​ឃើញ​ពី​ប្រវត្តិសាស្ត្រ តើ​មាន​ព្រឹត្តិការណ៍​ប៉ុន្មាន​នៅ​ទីនោះ។ ប្រសិនបើយើងមានព្រឹត្តិការណ៍ច្រើនទៀតនោះ ឯកសារស្វ័យប្រវត្តិបានកើតឡើង។ អ្នកអាចទៅមើល។ ឬស្វ័យប្រវត្តិកម្មត្រួតពិនិត្យរបស់យើងបានពិនិត្យថាយើងមានឧបករណ៍ចម្លងទាំងអស់នៅនឹងកន្លែង មិនមានការយឺតយ៉ាវទេ ហើយអ្វីៗគឺល្អ។

សូមអរគុណ!

អរគុណច្រើនសម្រាប់រឿងដ៏អស្ចារ្យ! ប្រសិនបើយើងផ្លាស់ទីចង្កោម DCS នៅកន្លែងណាមួយឆ្ងាយពីចង្កោម Postgres នោះចង្កោមនេះក៏ត្រូវផ្តល់សេវាតាមកាលកំណត់ដែរទេ? តើការអនុវត្តល្អបំផុតអ្វីខ្លះដែលផ្នែកខ្លះនៃចង្កោម DCS ចាំបាច់ត្រូវបិទ អ្វីដែលត្រូវធ្វើជាមួយពួកគេ ។ល។ តើរចនាសម្ព័ន្ធទាំងមូលនេះនៅរស់ដោយរបៀបណា? ហើយតើអ្នកធ្វើរឿងទាំងនេះដោយរបៀបណា?

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

នោះ​គឺ​ខ្ញុំ​យល់​បាន​ត្រឹមត្រូវ​ថា​ខ្ញុំ​ត្រូវ​ការ​បិទ Patroni បិទ​កម្មវិធី​ឯកសារ​បិទ​អ្វី​គ្រប់​យ៉ាង​មុន​ពេល​ធ្វើ​អ្វី​មួយ​ជាមួយ​ម៉ាស៊ីន​?

វាអាស្រ័យលើចំនួនថ្នាំងដែលយើងមាននៅក្នុងចង្កោម DCS ។ ប្រសិនបើមានថ្នាំងជាច្រើន ហើយប្រសិនបើយើងបិទតែថ្នាំងមួយប៉ុណ្ណោះ (ការចម្លង) នោះចង្កោមនឹងរក្សាកូរ៉ុម។ ហើយ Patroni នៅតែដំណើរការ។ ហើយគ្មានអ្វីត្រូវបានកេះទេ។ ប្រសិនបើយើងមានប្រតិបត្តិការស្មុគ្រស្មាញមួយចំនួនដែលប៉ះពាល់ដល់ថ្នាំងច្រើនទៀត អវត្តមានដែលអាចបំផ្លាញកូរ៉ុម បន្ទាប់មក - បាទ វាប្រហែលជាសមហេតុផលក្នុងការដាក់ Patroni ឱ្យផ្អាក។ វាមានពាក្យបញ្ជាដែលត្រូវគ្នា - ផ្អាក patronictl បន្ត patronictl ។ យើងគ្រាន់តែផ្អាក ហើយ autofiler មិនដំណើរការនៅពេលនោះ។ យើងធ្វើការថែទាំនៅលើចង្កោម DCS បន្ទាប់មកយើងឈប់ផ្អាក ហើយបន្តរស់នៅ។

សូមអរគុណខ្លាំងណាស់!

សូមអរគុណច្រើនចំពោះរបាយការណ៍របស់អ្នក! តើ​ក្រុម​ផលិតផល​មាន​អារម្មណ៍​យ៉ាង​ណា​ចំពោះ​ទិន្នន័យ​ដែល​ត្រូវ​បាន​បាត់បង់?

ក្រុមផលិតផលមិនខ្វល់ទេ ហើយអ្នកដឹកនាំក្រុមមានការព្រួយបារម្ភ។

តើមានការធានាអ្វីខ្លះ?

ការធានាគឺពិបាកណាស់។ Alexander Kukushkin មានរបាយការណ៍ "របៀបគណនា RPO និង RTO" ពោលគឺពេលវេលានៃការងើបឡើងវិញ និងចំនួនទិន្នន័យដែលយើងអាចបាត់បង់។ ខ្ញុំគិតថាយើងត្រូវស្វែងរកស្លាយទាំងនេះ ហើយសិក្សាវា។ តាមខ្ញុំចាំមានជំហានជាក់លាក់អំពីរបៀបគណនារបស់ទាំងនេះ។ តើប្រតិបត្តិការប៉ុន្មានដែលយើងអាចបាត់បង់ តើយើងអាចបាត់បង់ទិន្នន័យប៉ុន្មាន។ ជាជម្រើស យើងអាចប្រើការចម្លងតាមសមកាលកម្មនៅកម្រិត Patroni ប៉ុន្តែនេះគឺជាដាវមុខពីរ៖ យើងមានភាពជឿជាក់លើទិន្នន័យ ឬយើងបាត់បង់ល្បឿន។ មានការចម្លងតាមសមកាលកម្ម ប៉ុន្តែវាក៏មិនធានាការការពារ 100% ប្រឆាំងនឹងការបាត់បង់ទិន្នន័យផងដែរ។

Alexey អរគុណសម្រាប់របាយការណ៍ដ៏អស្ចារ្យ! មានបទពិសោធន៍ជាមួយការប្រើប្រាស់ Patroni សម្រាប់ការការពារកម្រិតសូន្យទេ? នោះគឺជាការភ្ជាប់ជាមួយសមកាលកម្មរង់ចាំ? នេះជាសំណួរដំបូង។ ហើយសំណួរទីពីរ។ អ្នកបានប្រើដំណោះស្រាយផ្សេងៗ។ យើងបានប្រើ Repmgr ប៉ុន្តែដោយគ្មាន autofiler ហើយឥឡូវនេះយើងគ្រោងនឹងបញ្ចូល autofiler ។ ហើយយើងចាត់ទុក Patroni ជាដំណោះស្រាយជំនួស។ តើអ្នកអាចនិយាយអ្វីខ្លះជាគុណសម្បត្តិបើប្រៀបធៀបទៅនឹង Repmgr?

សំណួរទីមួយគឺអំពីការចម្លងសមកាលកម្ម។ គ្មាន​នរណា​ម្នាក់​ប្រើ​ការ​ចម្លង​តាម​សមកាលកម្ម​នៅ​ទីនេះ​ទេ ព្រោះ​អ្នក​រាល់​គ្នា​ភ័យ​ខ្លាច (អតិថិជន​ជា​ច្រើន​កំពុង​ប្រើ​វា​ជា​គោលការណ៍ ពួកគេ​មិន​បាន​កត់​សម្គាល់​ឃើញ​បញ្ហា​ក្នុង​ការ​អនុវត្ត​ទេ - កំណត់ចំណាំរបស់អ្នកនិយាយ) ប៉ុន្តែយើងបានបង្កើតច្បាប់មួយសម្រាប់ខ្លួនយើងថា គួរតែមានយ៉ាងហោចណាស់ថ្នាំងបីនៅក្នុងចង្កោមចម្លងដែលធ្វើសមកាលកម្មមួយ ពីព្រោះប្រសិនបើយើងមានថ្នាំងពីរ ហើយប្រសិនបើមេ ឬការចម្លងបរាជ័យនោះ Patroni ប្តូរថ្នាំងនេះទៅជារបៀប Standalone ដើម្បីឱ្យកម្មវិធីបន្ត ការងារ។ ក្នុងករណីនេះមានហានិភ័យនៃការបាត់បង់ទិន្នន័យ។

ទាក់ទងនឹងសំណួរទីពីរ យើងបានប្រើ Repmgr ហើយនៅតែធ្វើជាមួយអតិថិជនមួយចំនួនសម្រាប់ហេតុផលប្រវត្តិសាស្ត្រ។ តើមានអ្វីអាចនិយាយបាន? Patroni ភ្ជាប់មកជាមួយ autofiler ចេញពីប្រអប់ Repmgr ភ្ជាប់មកជាមួយ autofiler ជាមុខងារបន្ថែមដែលចាំបាច់ត្រូវបើក។ យើងត្រូវដំណើរការដេមិន Repmgr នៅលើថ្នាំងនីមួយៗ ហើយបន្ទាប់មកយើងអាចកំណត់រចនាសម្ព័ន្ធ autofiler ។

Repmgr ពិនិត្យមើលថាតើថ្នាំង Postgres នៅរស់ដែរឬទេ។ ដំណើរការ Repmgr ពិនិត្យមើលអត្ថិភាពនៃគ្នាទៅវិញទៅមក នេះមិនមែនជាវិធីសាស្រ្តដ៏មានប្រសិទ្ធភាពខ្លាំងនោះទេ។ វាអាចមានករណីស្មុគ្រស្មាញនៃភាពឯកោបណ្តាញ ដែលចង្កោម Repmgr ដ៏ធំមួយអាចបំបែកទៅជាក្រុមតូចៗជាច្រើន ហើយបន្តធ្វើការ។ ខ្ញុំមិនបានតាមដាន Repmgr យូរហើយ ប្រហែលជាវាត្រូវបានជួសជុល ... ឬប្រហែលជាអត់។ ប៉ុន្តែការដកចេញនូវព័ត៌មានអំពីស្ថានភាពនៃចង្កោមនៅក្នុង DCS ដូចដែល Stolon, Patroni ធ្វើ គឺជាជម្រើសដែលអាចសម្រេចបានបំផុត។

Alexey, ខ្ញុំមានសំណួរមួយ, ប្រហែលជា lamer មួយ។ នៅក្នុងឧទាហរណ៍ដំបូងមួយ អ្នកបានផ្លាស់ប្តូរ DCS ពីម៉ាស៊ីនមូលដ្ឋានទៅម៉ាស៊ីនពីចម្ងាយ។ យើងយល់ថាបណ្តាញគឺជាវត្ថុដែលមានលក្ខណៈផ្ទាល់ខ្លួនរបស់វាវារស់នៅដោយខ្លួនឯង។ ហើយតើមានអ្វីកើតឡើងប្រសិនបើសម្រាប់ហេតុផលមួយចំនួន ចង្កោម DCS មិនអាចប្រើបាន? ខ្ញុំនឹងមិននិយាយហេតុផលទេ វាអាចមានច្រើននៃពួកគេ៖ ពីដៃអ្នកបង្កើតបណ្តាញទៅបញ្ហាពិត។

ខ្ញុំមិនបាននិយាយវាខ្លាំងៗទេ ប៉ុន្តែចង្កោម DCS ក៏ត្រូវតែបរាជ័យដែរ ពោលគឺវាជាចំនួនសេសនៃ nodes ដើម្បីឱ្យកូរ៉ុមត្រូវបានបំពេញ។ តើមានអ្វីកើតឡើងប្រសិនបើចង្កោម DCS ក្លាយជាមិនអាចប្រើបាន ឬកូរ៉ុមមិនអាចបំពេញបាន ពោលគឺប្រភេទនៃបណ្តាញបំបែក ឬថ្នាំងបរាជ័យ? ក្នុងករណីនេះ ចង្កោម Patroni ចូលទៅក្នុងរបៀបបានតែអានប៉ុណ្ណោះ។ ចង្កោម Patroni មិនអាចកំណត់ស្ថានភាពនៃចង្កោម និងអ្វីដែលត្រូវធ្វើ។ វាមិនអាចទាក់ទង DCS និងរក្សាទុកស្ថានភាពចង្កោមថ្មីនៅទីនោះទេ ដូច្នេះចង្កោមទាំងមូលចូលទៅក្នុងតែអានប៉ុណ្ណោះ។ ហើយរង់ចាំការអន្តរាគមន៍ដោយដៃពីប្រតិបត្តិករ ឬសម្រាប់ DCS ដើម្បីសង្គ្រោះ។

និយាយឱ្យចំទៅ DCS ក្លាយជាសេវាកម្មមួយសម្រាប់យើងដែលសំខាន់ដូចមូលដ្ឋានខ្លួនឯង?

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

សូមអរគុណ!

ប្រភព: www.habr.com