Failover Cluster PostgreSQL + Patroni ។ បទពិសោធន៍នៃការអនុវត្ត

នៅក្នុងអត្ថបទខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលយើងទាក់ទងបញ្ហានៃការអត់ឱនកំហុស PostgreSQL ហេតុអ្វីបានជាវាក្លាយជារឿងសំខាន់សម្រាប់យើង និងអ្វីដែលបានកើតឡើងនៅទីបញ្ចប់។

យើងមានសេវាកម្មផ្ទុកខ្ពស់៖ អ្នកប្រើប្រាស់ 2,5 លាននាក់នៅទូទាំងពិភពលោក អ្នកប្រើប្រាស់សកម្ម 50K+ ជារៀងរាល់ថ្ងៃ។ ម៉ាស៊ីនមេមានទីតាំងនៅ Amazone ក្នុងតំបន់មួយនៃប្រទេសអៀរឡង់៖ 100+ servers ផ្សេងៗគ្នាកំពុងដំណើរការឥតឈប់ឈរ ដែលក្នុងនោះស្ទើរតែ 50 ស្ថិតនៅជាមួយមូលដ្ឋានទិន្នន័យ។

ផ្នែកខាងក្រោយទាំងមូលគឺជាកម្មវិធី Java រដ្ឋ monolithic ដ៏ធំដែលរក្សាការភ្ជាប់ websocket ថេរជាមួយអតិថិជន។ នៅពេលដែលអ្នកប្រើប្រាស់ជាច្រើនធ្វើការនៅលើក្តារតែមួយក្នុងពេលតែមួយ ពួកគេទាំងអស់ឃើញការផ្លាស់ប្តូរនៅក្នុងពេលវេលាជាក់ស្តែង ពីព្រោះយើងសរសេរការផ្លាស់ប្តូរនីមួយៗទៅក្នុងមូលដ្ឋានទិន្នន័យ។ យើងមានសំណើប្រហែល 10K ក្នុងមួយវិនាទីទៅកាន់មូលដ្ឋានទិន្នន័យរបស់យើង។ នៅពេលផ្ទុកខ្ពស់បំផុតនៅក្នុង Redis យើងសរសេរសំណើ 80-100K ក្នុងមួយវិនាទី។

ហេតុអ្វីបានជាយើងប្តូរពី Redis ទៅ PostgreSQL

ដំបូង សេវាកម្មរបស់យើងបានធ្វើការជាមួយ Redis ដែលជាឃ្លាំងតម្លៃសំខាន់ដែលរក្សាទុកទិន្នន័យទាំងអស់នៅក្នុង RAM របស់ម៉ាស៊ីនមេ។

គុណសម្បត្តិរបស់ Redis៖

1. ល្បឿនឆ្លើយតបខ្ពស់, ដោយសារតែ អ្វីគ្រប់យ៉ាងត្រូវបានរក្សាទុកនៅក្នុងការចងចាំ;
2. ភាពងាយស្រួលនៃការបម្រុងទុក និងការចម្លង។

គុណវិបត្តិនៃ Redis សម្រាប់យើង:

1. មិនមានប្រតិបត្តិការពិតប្រាកដទេ។ យើងបានព្យាយាមក្លែងធ្វើនៅកម្រិតនៃកម្មវិធីរបស់យើង។ ជាអកុសល វាមិនតែងតែដំណើរការល្អទេ ហើយតម្រូវឱ្យសរសេរកូដស្មុគស្មាញខ្លាំង។
2. ចំនួនទិន្នន័យត្រូវបានកំណត់ដោយចំនួនអង្គចងចាំ។ នៅពេលដែលចំនួនទិន្នន័យកើនឡើង អង្គចងចាំនឹងកើនឡើង ហើយនៅទីបញ្ចប់ យើងនឹងដំណើរការទៅលក្ខណៈនៃវត្ថុដែលបានជ្រើសរើស ដែលនៅក្នុង AWS តម្រូវឱ្យបញ្ឈប់សេវាកម្មរបស់យើងដើម្បីផ្លាស់ប្តូរប្រភេទនៃវត្ថុ។
3. វាចាំបាច់ក្នុងការរក្សាកម្រិត latency ទាបជានិច្ច ពីព្រោះ។ យើង​មាន​សំណើ​ច្រើន​ណាស់។ កម្រិតពន្យាពេលល្អបំផុតសម្រាប់យើងគឺ 17-20 ms ។ នៅកម្រិត 30-40 ms យើងទទួលបានការឆ្លើយតបយ៉ាងយូរចំពោះសំណើពីកម្មវិធីរបស់យើង និងការធ្វើឱ្យខូចសេវាកម្មរបស់យើង។ ជាអកុសល វាបានកើតឡើងចំពោះយើងនៅក្នុងខែកញ្ញា ឆ្នាំ 2018 នៅពេលដែលករណីមួយជាមួយ Redis សម្រាប់ហេតុផលមួយចំនួនបានទទួលការពន្យារពេល 2 ដងច្រើនជាងធម្មតា។ ដើម្បីដោះស្រាយបញ្ហា យើងបានបញ្ឈប់សេវាកម្មពាក់កណ្តាលថ្ងៃសម្រាប់ការថែទាំដែលមិនបានគ្រោងទុក ហើយបានជំនួសឧទាហរណ៍ Redis ដែលមានបញ្ហា។
4. វាងាយស្រួលក្នុងការទទួលបានភាពមិនស៊ីសង្វាក់គ្នានៃទិន្នន័យ ទោះបីជាមានកំហុសតូចតាចនៅក្នុងកូដ ហើយបន្ទាប់មកចំណាយពេលច្រើនក្នុងការសរសេរកូដដើម្បីកែទិន្នន័យនេះ។

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

យើងបានផ្លាស់ប្តូរទៅកាន់មូលដ្ឋានទិន្នន័យថ្មីអស់រយៈពេល 1,5 ឆ្នាំមកហើយ ហើយបានផ្លាស់ទីតែផ្នែកតូចមួយនៃទិន្នន័យ ដូច្នេះឥឡូវនេះយើងកំពុងធ្វើការក្នុងពេលដំណាលគ្នាជាមួយ Redis និង PostgreSQL ។ ព័ត៌មានបន្ថែមអំពីដំណាក់កាលនៃការផ្លាស់ប្តូរ និងការផ្លាស់ប្តូរទិន្នន័យរវាងមូលដ្ឋានទិន្នន័យត្រូវបានសរសេរនៅក្នុង អត្ថបទរបស់មិត្តរួមការងាររបស់ខ្ញុំ.

នៅពេលដែលយើងចាប់ផ្តើមផ្លាស់ប្តូរដំបូង កម្មវិធីរបស់យើងបានធ្វើការដោយផ្ទាល់ជាមួយមូលដ្ឋានទិន្នន័យ ហើយចូលប្រើមេ Redis និង PostgreSQL ។ ចង្កោម PostgreSQL មានមេ និងចម្លងជាមួយការចម្លងអសមកាល។ នេះជារបៀបដែលគ្រោងការណ៍មូលដ្ឋានទិន្នន័យមើលទៅដូចនេះ៖

ការអនុវត្ត PgBouncer

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

យើងមានជម្រើសពីរសម្រាប់អ្នកគ្រប់គ្រងការតភ្ជាប់៖ Pgpool និង PgBouncer ។ ប៉ុន្តែទីមួយមិនគាំទ្ររបៀបប្រតិបត្តិការនៃការធ្វើការជាមួយមូលដ្ឋានទិន្នន័យដូច្នេះយើងបានជ្រើសរើស PgBouncer ។

យើងបានរៀបចំគ្រោងការណ៍ការងារដូចខាងក្រោម៖ កម្មវិធីរបស់យើងចូលប្រើ PgBouncer មួយ ដែលនៅពីក្រោយនោះគឺជាមេ PostgreSQL ហើយនៅពីក្រោយមេនីមួយៗគឺមួយចម្លងជាមួយការចម្លងអសមកាល។


ក្នុងពេលជាមួយគ្នានេះ យើងមិនអាចរក្សាទុកចំនួនទិន្នន័យទាំងមូលនៅក្នុង PostgreSQL ហើយល្បឿននៃការធ្វើការជាមួយមូលដ្ឋានទិន្នន័យមានសារៈសំខាន់សម្រាប់យើង ដូច្នេះយើងបានចាប់ផ្តើមបំបែក PostgreSQL នៅកម្រិតកម្មវិធី។ គ្រោងការណ៍ដែលបានពិពណ៌នាខាងលើគឺមានភាពងាយស្រួលសម្រាប់រឿងនេះ៖ នៅពេលបន្ថែម PostgreSQL shard ថ្មី វាគ្រប់គ្រាន់ដើម្បីធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធ PgBouncer ហើយកម្មវិធីអាចដំណើរការភ្លាមៗជាមួយ shard ថ្មី។

ការបរាជ័យ PgBouncer

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

បន្ទាប់ពីនោះ យើងបានគិតយ៉ាងម៉ត់ចត់អំពីការអត់ឱនចំពោះកំហុសរបស់ PgBouncer និងក្រុម PostgreSQL ពីព្រោះស្ថានភាពស្រដៀងគ្នាអាចកើតឡើងជាមួយករណីណាមួយនៅក្នុងគណនី AWS របស់យើង។

យើងបានបង្កើតគ្រោងការណ៍ការអត់ធ្មត់កំហុស PgBouncer ដូចខាងក្រោម: ម៉ាស៊ីនមេកម្មវិធីទាំងអស់ចូលប្រើ Network Load Balancer ដែលនៅពីក្រោយមាន PgBouncers ពីរ។ PgBouncer នីមួយៗមើលមេ PostgreSQL ដូចគ្នានៃ shard នីមួយៗ។ ប្រសិនបើការគាំង AWS កើតឡើងម្តងទៀត ចរាចរណ៍ទាំងអស់ត្រូវបានបញ្ជូនបន្តតាមរយៈ PgBouncer ផ្សេងទៀត។ Network Load Balancer failover ត្រូវបានផ្តល់ដោយ AWS ។

គ្រោងការណ៍នេះធ្វើឱ្យមានភាពងាយស្រួលក្នុងការបន្ថែមម៉ាស៊ីនមេ PgBouncer ថ្មី។

បង្កើត PostgreSQL Failover Cluster

នៅពេលដោះស្រាយបញ្ហានេះ យើងបានពិចារណាលើជម្រើសផ្សេងៗគ្នា៖ ការបរាជ័យដែលសរសេរដោយខ្លួនឯង, repmgr, AWS RDS, Patroni ។

ស្គ្រីបដែលសរសេរដោយខ្លួនឯង។

ពួកគេអាចត្រួតពិនិត្យការងាររបស់មេ ហើយក្នុងករណីមានការបរាជ័យ ផ្សព្វផ្សាយការចម្លងទៅមេ និងធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធ PgBouncer ។

គុណសម្បត្តិនៃវិធីសាស្រ្តនេះគឺភាពសាមញ្ញបំផុត ព្រោះអ្នកសរសេរស្គ្រីបដោយខ្លួនឯង ហើយយល់ច្បាស់ពីរបៀបដែលវាដំណើរការ។

គុណវិបត្តិ:

• មេប្រហែលជាមិនស្លាប់ទេ ផ្ទុយទៅវិញការបរាជ័យបណ្តាញអាចនឹងកើតឡើង។ បរាជ័យ​ដោយ​មិន​ដឹង​ពី​រឿង​នេះ​នឹង​លើក​កម្ពស់​ការ​ចម្លង​ទៅ​ម្ចាស់ ខណៈ​ម្ចាស់​ចាស់​នឹង​បន្ត​ធ្វើ។ ជាលទ្ធផល យើងនឹងទទួលបានម៉ាស៊ីនមេចំនួនពីរក្នុងតួនាទីជាមេ ហើយយើងនឹងមិនដឹងថាមួយណាក្នុងចំណោមពួកវាមានទិន្នន័យចុងក្រោយបំផុតនោះទេ។ ស្ថានភាពនេះត្រូវបានគេហៅផងដែរថាបំបែកខួរក្បាល;
• យើង​ត្រូវ​បាន​ទុក​ចោល​ដោយ​គ្មាន​ការ​ឆ្លើយ​តប។ នៅក្នុងការកំណត់រចនាសម្ព័ន្ធរបស់យើង មេ និងចម្លងមួយ បន្ទាប់ពីប្តូរ ការចម្លងនឹងផ្លាស់ទីឡើងលើមេ ហើយយើងលែងមានច្បាប់ចម្លងទៀតហើយ ដូច្នេះយើងត្រូវបន្ថែមការចម្លងថ្មីដោយដៃ។
• យើងត្រូវការការត្រួតពិនិត្យបន្ថែមនៃប្រតិបត្តិការបរាជ័យ ខណៈដែលយើងមាន 12 PostgreSQL shards ដែលមានន័យថាយើងត្រូវត្រួតពិនិត្យ 12 clusters ។ ជាមួយនឹងការកើនឡើងនៃចំនួន shards អ្នកក៏ត្រូវចងចាំដើម្បីធ្វើបច្ចុប្បន្នភាពការបរាជ័យផងដែរ។

ការបរាជ័យក្នុងការសរសេរដោយខ្លួនឯងមើលទៅស្មុគស្មាញណាស់ ហើយទាមទារការគាំទ្រដែលមិនសំខាន់។ ជាមួយនឹងចង្កោម PostgreSQL តែមួយ នេះនឹងក្លាយជាជម្រើសងាយស្រួលបំផុត ប៉ុន្តែវាមិនមានទំហំទេ ដូច្នេះវាមិនស័ក្តិសមសម្រាប់យើងទេ។

Repmgr

កម្មវិធីគ្រប់គ្រងការចម្លងសម្រាប់ក្រុម PostgreSQL ដែលអាចគ្រប់គ្រងប្រតិបត្តិការនៃចង្កោម PostgreSQL ។ ក្នុងពេលជាមួយគ្នានេះវាមិនមានការបរាជ័យដោយស្វ័យប្រវត្តិចេញពីប្រអប់នោះទេដូច្នេះសម្រាប់ការងារអ្នកនឹងត្រូវសរសេរ "រុំ" ផ្ទាល់ខ្លួនរបស់អ្នកនៅលើកំពូលនៃដំណោះស្រាយដែលបានបញ្ចប់។ ដូច្នេះ​អ្វីៗ​អាច​ប្រែក្លាយ​កាន់តែ​ស្មុគស្មាញ​ជាង​ស្គ្រីប​ដែល​សរសេរ​ដោយ​ខ្លួនឯង ដូច្នេះ​យើង​មិន​បាន​សាកល្បង Repmgr ទេ។

AWS RDS

គាំទ្រអ្វីគ្រប់យ៉ាងដែលយើងត្រូវការ ដឹងពីរបៀបបង្កើតការបម្រុងទុក និងរក្សាការភ្ជាប់ទំនាក់ទំនង។ វាមានការផ្លាស់ប្តូរដោយស្វ័យប្រវត្តិ៖ នៅពេលដែលមេស្លាប់ អ្នកចម្លងក្លាយជាមេថ្មី ហើយ AWS ផ្លាស់ប្តូរកំណត់ត្រា dns ទៅជាមេថ្មី ខណៈដែលការចម្លងអាចមានទីតាំងនៅ AZs ផ្សេងៗគ្នា។

គុណវិបត្តិរួមមានកង្វះការកែតម្រូវដ៏ល្អ។ ជាឧទាហរណ៍នៃការលៃតម្រូវដ៏ល្អ៖ ករណីរបស់យើងមានការរឹតបន្តឹងសម្រាប់ការតភ្ជាប់ tcp ដែលជាអកុសលមិនអាចធ្វើបាននៅក្នុង RDS៖

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

លើសពីនេះ AWS RDS មានតម្លៃថ្លៃជិតពីរដងធៀបនឹងតម្លៃឧទាហរណ៍ធម្មតា ដែលជាហេតុផលចម្បងសម្រាប់ការបោះបង់ចោលដំណោះស្រាយនេះ។

ប៉ាតូនី

នេះគឺជាគំរូ python សម្រាប់គ្រប់គ្រង PostgreSQL ជាមួយនឹងឯកសារល្អ ការបរាជ័យដោយស្វ័យប្រវត្តិ និងកូដប្រភពនៅលើ github ។

គុណសម្បត្តិរបស់ Patroni៖

• ប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធនីមួយៗត្រូវបានពិពណ៌នា វាច្បាស់អំពីរបៀបដែលវាដំណើរការ។
• ការបរាជ័យដោយស្វ័យប្រវត្តិដំណើរការចេញពីប្រអប់;
• សរសេរជា python ហើយដោយសារយើងខ្លួនឯងសរសេរច្រើននៅក្នុង python វានឹងកាន់តែងាយស្រួលសម្រាប់ពួកយើងក្នុងការដោះស្រាយបញ្ហា ហើយប្រហែលជាជួយដល់ការអភិវឌ្ឍន៍គម្រោងផងដែរ។
• គ្រប់គ្រងទាំងស្រុង PostgreSQL អនុញ្ញាតឱ្យអ្នកផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធនៅលើថ្នាំងទាំងអស់នៃចង្កោមក្នុងពេលតែមួយ ហើយប្រសិនបើចង្កោមត្រូវចាប់ផ្តើមឡើងវិញដើម្បីអនុវត្តការកំណត់រចនាសម្ព័ន្ធថ្មី នោះវាអាចត្រូវបានធ្វើម្តងទៀតដោយប្រើ Patroni ។

គុណវិបត្តិ:

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

ជាលទ្ធផល យើងបានជ្រើសរើស Patroni ដើម្បីបង្កើតចង្កោមបរាជ័យ។

ដំណើរការអនុវត្ត Patroni

មុនពេល Patroni យើងមាន 12 PostgreSQL shards នៅក្នុងការកំណត់រចនាសម្ព័ន្ធនៃមេមួយ និងចម្លងមួយជាមួយការចម្លងអសមកាល។ ម៉ាស៊ីនមេកម្មវិធីបានចូលប្រើមូលដ្ឋានទិន្នន័យតាមរយៈ Network Load Balancer ដែលនៅពីក្រោយនោះជាឧទាហរណ៍ពីរជាមួយ PgBouncer ហើយនៅពីក្រោយពួកវាគឺជាម៉ាស៊ីនមេ PostgreSQL ទាំងអស់។


ដើម្បីអនុវត្ត Patroni យើងត្រូវជ្រើសរើសការកំណត់រចនាសម្ព័ន្ធចង្កោមការផ្ទុកដែលបានចែកចាយ។ Patroni ធ្វើការជាមួយប្រព័ន្ធផ្ទុកកំណត់រចនាសម្ព័ន្ធចែកចាយដូចជា etcd, Zookeeper, Consul ។ យើងទើបតែមានចង្កោមកុងស៊ុលពេញលេញនៅលើទីផ្សារ ដែលធ្វើការរួមគ្នាជាមួយ Vault ហើយយើងមិនប្រើវាទៀតទេ។ ហេតុផលដ៏ល្អដើម្បីចាប់ផ្តើមប្រើប្រាស់កុងស៊ុលសម្រាប់គោលបំណងដែលបានគ្រោងទុក។

របៀបដែល Patroni ធ្វើការជាមួយកុងស៊ុល

យើងមានចង្កោមកុងស៊ុលដែលមានបីថ្នាំង និងចង្កោម Patroni ដែលមានអ្នកដឹកនាំនិងអ្នកចម្លង (នៅក្នុង Patroni មេត្រូវបានគេហៅថាអ្នកដឹកនាំចង្កោម ហើយទាសករត្រូវបានគេហៅថាចម្លង)។ ឧទាហរណ៍នីមួយៗនៃចង្កោម Patroni តែងតែបញ្ជូនព័ត៌មានអំពីស្ថានភាពនៃចង្កោមទៅកុងស៊ុល។ ដូច្នេះ ពីកុងស៊ុល អ្នកតែងតែអាចស្វែងរកការកំណត់រចនាសម្ព័ន្ធបច្ចុប្បន្ននៃចង្កោម Patroni ហើយអ្នកណាជាអ្នកដឹកនាំនៅពេលនេះ។

ដើម្បីភ្ជាប់ Patroni ទៅកុងស៊ុល វាគ្រប់គ្រាន់ហើយក្នុងការសិក្សាឯកសារផ្លូវការដែលនិយាយថាអ្នកត្រូវបញ្ជាក់ម៉ាស៊ីនក្នុងទម្រង់ http ឬ https អាស្រ័យលើរបៀបដែលយើងធ្វើការជាមួយកុងស៊ុល និងគ្រោងការណ៍ការតភ្ជាប់តាមជម្រើស៖

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

វា​មើល​ទៅ​សាមញ្ញ ប៉ុន្តែ​នៅ​ទីនេះ​ការ​ធ្លាក់​ចុះ​ចាប់​ផ្ដើម។ ជាមួយកុងស៊ុល យើងធ្វើការលើការតភ្ជាប់សុវត្ថិភាពតាមរយៈ https ហើយការកំណត់ការតភ្ជាប់របស់យើងនឹងមើលទៅដូចនេះ៖

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ប៉ុន្តែវាមិនដំណើរការទេ។ នៅពេលចាប់ផ្តើម Patroni មិនអាចភ្ជាប់ទៅកុងស៊ុលបានទេព្រោះវាព្យាយាមឆ្លងកាត់ http យ៉ាងណាក៏ដោយ។

កូដប្រភពរបស់ Patroni បានជួយដោះស្រាយបញ្ហា។ រឿងល្អវាត្រូវបានសរសេរជា python ។ វាប្រែថាប៉ារ៉ាម៉ែត្រម៉ាស៊ីនមិនត្រូវបានញែកតាមវិធីណាមួយទេហើយពិធីការត្រូវតែបញ្ជាក់នៅក្នុងគ្រោងការណ៍។ នេះជារបៀបដែលប្លុកកំណត់រចនាសម្ព័ន្ធការងារសម្រាប់ធ្វើការជាមួយកុងស៊ុលមើលទៅដូចយើង៖

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

កុងស៊ុល-គំរូ

ដូច្នេះ យើងបានជ្រើសរើសកន្លែងផ្ទុកសម្រាប់ការកំណត់រចនាសម្ព័ន្ធ។ ឥឡូវនេះយើងត្រូវយល់ពីរបៀបដែល PgBouncer នឹងប្តូរការកំណត់របស់វានៅពេលផ្លាស់ប្តូរអ្នកដឹកនាំនៅក្នុងក្រុម Patroni ។ មិនមានចម្លើយចំពោះសំណួរនេះនៅក្នុងឯកសារទេ ពីព្រោះ។ នៅទីនោះ ជាគោលការណ៍ ការងារជាមួយ PgBouncer មិនត្រូវបានពិពណ៌នាទេ។

ក្នុងការស្វែងរកដំណោះស្រាយ យើងបានរកឃើញអត្ថបទមួយ (ជាអកុសលខ្ញុំមិនចាំចំណងជើងទេ) ដែលវាត្រូវបានសរសេរថា Сonsul-template ជួយបានច្រើនក្នុងការផ្គូផ្គង PgBouncer និង Patroni ។ នេះបានជំរុញឱ្យយើងស៊ើបអង្កេតពីរបៀបដែល Consul-template ដំណើរការ។

វាបានប្រែក្លាយថា Consul-template ត្រួតពិនិត្យជានិច្ចនូវការកំណត់រចនាសម្ព័ន្ធនៃក្រុម PostgreSQL នៅក្នុងកុងស៊ុល។ នៅពេលដែលអ្នកដឹកនាំផ្លាស់ប្តូរ វាធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធ PgBouncer ហើយផ្ញើពាក្យបញ្ជាដើម្បីផ្ទុកវាឡើងវិញ។

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

ស្ថាបត្យកម្មថ្មីជាមួយ Patroni

ជាលទ្ធផលយើងទទួលបានគ្រោងការណ៍ការងារដូចខាងក្រោមៈ


ម៉ាស៊ីនមេកម្មវិធីទាំងអស់ចូលប្រើសមតុល្យ → មានឧទាហរណ៍ពីរនៃ PgBouncer នៅពីក្រោយវា → នៅលើឧទាហរណ៍នីមួយៗ Consul-template ត្រូវបានបើកដំណើរការ ដែលត្រួតពិនិត្យស្ថានភាពនៃក្រុម Patroni នីមួយៗ និងតាមដានភាពពាក់ព័ន្ធនៃការកំណត់រចនាសម្ព័ន្ធ PgBouncer ដែលផ្ញើសំណើទៅកាន់អ្នកដឹកនាំបច្ចុប្បន្ន។ នៃក្រុមនីមួយៗ។

ការធ្វើតេស្តដោយដៃ

យើងបានដំណើរការគ្រោងការណ៍នេះ មុនពេលចាប់ផ្តើមវានៅលើបរិយាកាសសាកល្បងតូចមួយ និងពិនិត្យមើលប្រតិបត្តិការនៃការប្តូរដោយស្វ័យប្រវត្តិ។ ពួកគេបានបើកក្តារ ផ្លាស់ទីស្ទីគ័រ ហើយនៅពេលនោះ ពួកគេបាន "សម្លាប់" មេដឹកនាំនៃចង្កោម។ នៅក្នុង AWS នេះគឺសាមញ្ញដូចជាការបិទ instance តាមរយៈកុងសូល។

ស្ទីគ័រត្រលប់មកវិញក្នុងរយៈពេល 10-20 វិនាទី ហើយបន្ទាប់មកម្តងទៀតចាប់ផ្តើមផ្លាស់ទីជាធម្មតា។ នេះមានន័យថា ចង្កោម Patroni ដំណើរការបានត្រឹមត្រូវ៖ វាបានផ្លាស់ប្តូរអ្នកដឹកនាំ បញ្ជូនព័ត៌មានទៅ Сonsul ហើយ Сonsul-template បានយកព័ត៌មាននេះភ្លាមៗ ជំនួសការកំណត់រចនាសម្ព័ន្ធ PgBouncer ហើយផ្ញើពាក្យបញ្ជាដើម្បីផ្ទុកឡើងវិញ។

តើធ្វើដូចម្តេចដើម្បីរស់នៅក្រោមបន្ទុកខ្ពស់ និងរក្សាពេលវេលារងចាំតិចបំផុត?

អ្វីៗដំណើរការយ៉ាងល្អឥតខ្ចោះ! ប៉ុន្តែមានសំណួរថ្មី: តើវានឹងដំណើរការយ៉ាងដូចម្តេចនៅក្រោមបន្ទុកខ្ពស់? តើធ្វើដូចម្តេចដើម្បីដាក់ចេញនូវអ្វីគ្រប់យ៉ាងនៅក្នុងផលិតកម្មយ៉ាងឆាប់រហ័ស និងដោយសុវត្ថិភាព?

បរិយាកាសសាកល្បងដែលយើងធ្វើការធ្វើតេស្តផ្ទុកជួយយើងឆ្លើយសំណួរទីមួយ។ វាមានលក្ខណៈដូចគ្នាទាំងស្រុងទៅនឹងការផលិតនៅក្នុងលក្ខខណ្ឌនៃស្ថាបត្យកម្ម ហើយបានបង្កើតទិន្នន័យសាកល្បងដែលមានបរិមាណប្រហាក់ប្រហែលនឹងការផលិត។ យើងសម្រេចចិត្តគ្រាន់តែ "សម្លាប់" មេ PostgreSQL ម្នាក់ក្នុងអំឡុងពេលធ្វើតេស្ត ហើយមើលថាមានអ្វីកើតឡើង។ ប៉ុន្តែមុននោះ វាមានសារៈសំខាន់ណាស់ក្នុងការត្រួតពិនិត្យការរំកិលដោយស្វ័យប្រវត្តិ ពីព្រោះនៅលើបរិស្ថាននេះ យើងមាន PostgreSQL shards ជាច្រើន ដូច្នេះយើងនឹងទទួលបានការសាកល្បងដ៏ល្អនៃស្គ្រីបកំណត់រចនាសម្ព័ន្ធមុនពេលផលិត។

ការងារទាំងពីរមើលទៅមានមហិច្ឆតា ប៉ុន្តែយើងមាន PostgreSQL 9.6 ។ តើយើងអាចធ្វើឱ្យប្រសើរឡើងភ្លាមៗទៅ 11.2 បានទេ?

យើងសម្រេចចិត្តធ្វើវាជា 2 ជំហាន៖ ដំបូងធ្វើឱ្យប្រសើរឡើងទៅ 11.2 បន្ទាប់មកបើកដំណើរការ Patroni ។

ការធ្វើបច្ចុប្បន្នភាព PostgreSQL

ដើម្បីធ្វើបច្ចុប្បន្នភាពកំណែ PostgreSQL យ៉ាងឆាប់រហ័ស សូមប្រើជម្រើស -kដែលក្នុងនោះតំណភ្ជាប់រឹងត្រូវបានបង្កើតនៅលើថាស ហើយមិនចាំបាច់ចម្លងទិន្នន័យរបស់អ្នកទេ។ នៅលើមូលដ្ឋាននៃ 300-400 GB ការធ្វើបច្ចុប្បន្នភាពត្រូវចំណាយពេល 1 វិនាទី។

យើងមានផ្នែកជាច្រើន ដូច្នេះការអាប់ដេតត្រូវធ្វើដោយស្វ័យប្រវត្តិ។ ដើម្បីធ្វើដូច្នេះ យើងបានសរសេរសៀវភៅលេង Ansible ដែលគ្រប់គ្រងដំណើរការអាប់ដេតទាំងមូលសម្រាប់យើង៖

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

បើកដំណើរការ Patroni

ដើម្បីដោះស្រាយបញ្ហាទីពីរគ្រាន់តែមើលការកំណត់រចនាសម្ព័ន្ធ Patroni ។ ឃ្លាំងផ្លូវការមានការកំណត់រចនាសម្ព័ន្ធឧទាហរណ៍ជាមួយ initdb ដែលទទួលខុសត្រូវក្នុងការចាប់ផ្តើមមូលដ្ឋានទិន្នន័យថ្មីនៅពេលអ្នកចាប់ផ្តើម Patroni ដំបូង។ ប៉ុន្តែដោយសារយើងមានមូលដ្ឋានទិន្នន័យដែលត្រៀមរួចជាស្រេចរួចហើយ យើងគ្រាន់តែដកផ្នែកនេះចេញពីការកំណត់។

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

rm -rf /var/lib/postgresql/

នេះត្រូវធ្វើតែលើទាសករ!

នៅពេលដែលការចម្លងស្អាតត្រូវបានភ្ជាប់ Patroni បង្កើតមេការបម្រុងទុកមូលដ្ឋាន និងស្ដារវាទៅការចម្លង ហើយបន្ទាប់មកតាមទាន់ស្ថានភាពបច្ចុប្បន្នយោងទៅតាម wal logs ។

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

ការធ្វើតេស្តផ្ទុក

យើងបានចាប់ផ្តើមការសាកល្បងដែលក្លែងធ្វើបទពិសោធន៍អ្នកប្រើប្រាស់នៅលើក្តារ។ នៅពេលដែលបន្ទុកឈានដល់តម្លៃមធ្យមប្រចាំថ្ងៃរបស់យើង យើងបានធ្វើតេស្តដូចគ្នាម្តងទៀត យើងបានបិទឧទាហរណ៍មួយជាមួយនឹងអ្នកដឹកនាំ PostgreSQL ។ ការបរាជ័យដោយស្វ័យប្រវត្តិបានដំណើរការដូចដែលយើងរំពឹងទុក៖ Patroni បានផ្លាស់ប្តូរអ្នកដឹកនាំ កុងស៊ុល-គំរូបានធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធ PgBouncer ហើយបានផ្ញើពាក្យបញ្ជាដើម្បីផ្ទុកឡើងវិញ។ យោងតាមក្រាហ្វរបស់យើងនៅក្នុង Grafana វាច្បាស់ណាស់ថាមានការពន្យារពេលពី 20-30 វិនាទី និងចំនួនតូចមួយនៃកំហុសពីម៉ាស៊ីនមេដែលទាក់ទងនឹងការតភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ។ នេះគឺជាស្ថានភាពធម្មតា តម្លៃបែបនេះអាចទទួលយកបានសម្រាប់ការបរាជ័យរបស់យើង ហើយពិតជាល្អប្រសើរជាងពេលសម្រាកសេវាកម្ម។

នាំ Patroni ទៅផលិតកម្ម

ជាលទ្ធផលយើងបានបង្កើតផែនការដូចខាងក្រោមៈ

• ដាក់ពង្រាយ Consul-template ទៅម៉ាស៊ីនមេ PgBouncer ហើយបើកដំណើរការ។
• PostgreSQL ធ្វើបច្ចុប្បន្នភាពទៅកំណែ 11.2;
• ផ្លាស់ប្តូរឈ្មោះក្រុម;
• បើកដំណើរការក្រុម Patroni ។

ក្នុងពេលជាមួយគ្នានេះ គ្រោងការណ៍របស់យើងអនុញ្ញាតឱ្យយើងបង្កើតចំណុចដំបូងស្ទើរតែគ្រប់ពេល យើងអាចដក PgBouncer នីមួយៗចេញពីការងារ ហើយដាក់ពង្រាយ និងដំណើរការគំរូកុងស៊ុលនៅលើវា។ ដូច្នេះយើងបានធ្វើ។

សម្រាប់ការដាក់ពង្រាយរហ័ស យើងបានប្រើ Ansible ចាប់តាំងពីយើងបានសាកល្បងសៀវភៅលេងទាំងអស់រួចហើយនៅលើបរិយាកាសសាកល្បង ហើយពេលវេលាប្រតិបត្តិនៃស្គ្រីបពេញលេញគឺពី 1,5 ទៅ 2 នាទីសម្រាប់ shard នីមួយៗ។ យើង​អាច​ដាក់​ចេញ​នូវ​អ្វី​គ្រប់​យ៉ាង​ជា​មួយ​ shard នីមួយៗ​ដោយ​មិន​បញ្ឈប់​សេវាកម្ម​របស់​យើង ប៉ុន្តែ​យើង​នឹង​ត្រូវ​បិទ PostgreSQL នីមួយៗ​រយៈពេល​ជាច្រើន​នាទី។ ក្នុងករណីនេះ អ្នកប្រើប្រាស់ដែលមានទិន្នន័យនៅលើ shard នេះមិនអាចដំណើរការពេញលេញបានទេនៅពេលនេះ ហើយនេះមិនអាចទទួលយកបានសម្រាប់ពួកយើង។

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


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


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

ចាប់ផ្ដើមក្រុម Patroni ឡើងវិញ

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

ចង្កោម Patroni មិនអាចទាញយកព័ត៌មានអំពីចង្កោមរបស់វា ហើយចាប់ផ្តើមឡើងវិញបានទេ។

ដើម្បីស្វែងរកដំណោះស្រាយ យើងបានទាក់ទងអ្នកនិពន្ធ Patroni តាមរយៈបញ្ហានៅលើ github ។ ពួកគេបានស្នើឱ្យកែលម្អឯកសារកំណត់រចនាសម្ព័ន្ធរបស់យើង៖

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

យើងអាចចម្លងបញ្ហានៅលើបរិយាកាសសាកល្បង និងសាកល្បងជម្រើសទាំងនេះនៅទីនោះ ប៉ុន្តែជាអកុសលវាមិនដំណើរការទេ។

បញ្ហានៅតែមិនទាន់ដោះស្រាយ។ យើងគ្រោងនឹងសាកល្បងដំណោះស្រាយដូចខាងក្រោមៈ

• ប្រើភ្នាក់ងារកុងស៊ុលលើឧទាហរណ៍ក្រុម Patroni នីមួយៗ។
• ដោះស្រាយបញ្ហានៅក្នុងកូដ។

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

ជាសំណាងល្អ យើងមិនបានជួបប្រទះនឹងកំហុសទៀតទេ។

លទ្ធផលនៃការប្រើប្រាស់ Patroni

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


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

សេចក្តីសង្ខេបតូចមួយនៃការប្រើប្រាស់ Patroni៖

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

ប្រភព: www.habr.com