សេចក្តីណែនាំ

មួយរយៈមុនខ្ញុំត្រូវបានផ្តល់ភារកិច្ចឱ្យបង្កើតក្រុមបរាជ័យសម្រាប់ PostgreSQLប្រតិបត្តិការនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យជាច្រើនដែលតភ្ជាប់ដោយសរសៃអុបទិកក្នុងទីក្រុងតែមួយ និងមានសមត្ថភាពទប់ទល់នឹងការបរាជ័យ (ឧទាហរណ៍ ការដាច់ភ្លើង) នៃមជ្ឈមណ្ឌលទិន្នន័យមួយ។ ជាកម្មវិធីដែលទទួលខុសត្រូវចំពោះការអត់ឱនកំហុស ខ្ញុំបានជ្រើសរើស ផាសស្ទឺរដោយសារតែនេះគឺជាដំណោះស្រាយផ្លូវការពី RedHat សម្រាប់ការបង្កើតក្រុមបរាជ័យ។ វាល្អព្រោះ RedHat ផ្តល់ការគាំទ្រសម្រាប់វា ហើយដោយសារតែដំណោះស្រាយនេះគឺមានលក្ខណៈជាសកល (ម៉ូឌុល)។ ដោយមានជំនួយរបស់វា វានឹងអាចធានាបាននូវការអត់ឱនចំពោះកំហុសមិនត្រឹមតែរបស់ PostgreSQL ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានសេវាកម្មផ្សេងទៀតផងដែរ ទាំងការប្រើប្រាស់ម៉ូឌុលស្តង់ដារ ឬបង្កើតវាសម្រាប់តម្រូវការជាក់លាក់។

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

ឥឡូវនេះ អ្នកគ្រប់គ្រងបានអនុញ្ញាតហើយ។ បើកគម្រោងទៅសហគមន៍ប្រភពបើកចំហក្រោមអាជ្ញាប័ណ្ណ MIT. README នឹងត្រូវបានបកប្រែជាភាសាអង់គ្លេសឆាប់ៗនេះ (ព្រោះវាត្រូវបានគេរំពឹងថាអ្នកប្រើប្រាស់សំខាន់នឹងក្លាយជាអ្នកអភិវឌ្ឍន៍ Pacemaker និងអ្នកបង្កើត PostgreSQL) ហើយខ្ញុំបានសម្រេចចិត្តបង្ហាញកំណែចាស់របស់ README ជាភាសារុស្សី (ផ្នែកខ្លះ) ក្នុងទម្រង់នៃអត្ថបទនេះ។

ចង្កោមត្រូវបានដាក់ពង្រាយនៅលើម៉ាស៊ីននិម្មិត VirtualBox. ម៉ាស៊ីននិម្មិតសរុបចំនួន 12 (សរុប 36GiB) នឹងត្រូវបានដាក់ពង្រាយ ដែលបង្កើតជាចង្កោមដែលអត់ឱនកំហុសចំនួន 4 (ជម្រើសផ្សេងគ្នា)។ ចង្កោមពីរដំបូងមានម៉ាស៊ីនមេ PostgreSQL ពីរដែលមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា និងម៉ាស៊ីនមេទូទៅ។ សាក្សី c ឧបករណ៍កូរ៉ុម (រៀបចំនៅលើម៉ាស៊ីននិម្មិតថោកនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទីបី) ដែលដោះស្រាយភាពមិនច្បាស់លាស់ 50% / 50%ផ្តល់សន្លឹកឆ្នោតរបស់អ្នកទៅឱ្យគណបក្សណាមួយ។ ចង្កោមទីបីនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យបី៖ មេម្នាក់ ទាសករពីរនាក់ ទេ។ ឧបករណ៍កូរ៉ុម. ចង្កោមទីបួនមានម៉ាស៊ីនមេ PostgreSQL ចំនួនបួន ពីរក្នុងមួយមជ្ឈមណ្ឌលទិន្នន័យ៖ មេមួយ ចម្លងនៅសល់ និងប្រើប្រាស់ផងដែរ។ សាក្សី c ឧបករណ៍កូរ៉ុម. ទីបួនអាចទប់ទល់នឹងការបរាជ័យនៃម៉ាស៊ីនមេពីរឬមជ្ឈមណ្ឌលទិន្នន័យមួយ។ ដំណោះ​ស្រាយ​នេះ​អាច​ត្រូវ​បាន​ធ្វើ​មាត្រដ្ឋាន​ទៅ​ជា​ចំនួន​ច្រើន​នៃ​ការ​ចម្លង​បើ​ចាំបាច់។

សេវាកម្មពេលវេលាត្រឹមត្រូវ។ ntpd បានកំណត់រចនាសម្ព័ន្ធឡើងវិញសម្រាប់ការអត់ឱនកំហុស ប៉ុន្តែវាប្រើវិធីសាស្រ្តខ្លួនឯង ntpd (របៀបក្មេងកំព្រា) ម៉ាស៊ីនមេដែលបានចែករំលែក សាក្សី ដើរតួនាទីជាម៉ាស៊ីនមេ NTP កណ្តាល ចែកចាយពេលវេលារបស់វាទៅគ្រប់ចង្កោម ដោយហេតុនេះធ្វើសមកាលកម្មម៉ាស៊ីនមេទាំងអស់ជាមួយគ្នាទៅវិញទៅមក។ ប្រសិនបើ សាក្សី បរាជ័យ ឬ​ក្លាយ​ជា​ដាច់​ដោយ​ឡែក បន្ទាប់​មក​ម៉ាស៊ីន​បម្រើ​ចង្កោម​មួយ (ក្នុង​ចង្កោម) នឹង​ចាប់​ផ្ដើម​ចែកចាយ​ពេល​វេលា​របស់​វា។ ឃ្លាំងសម្ងាត់ជំនួយ ប្រូកស៊ី HTTP ក៏​បាន​លើក​ឡើង​ទៅ​ សាក្សីដោយមានជំនួយរបស់វា ម៉ាស៊ីននិម្មិតផ្សេងទៀតមានសិទ្ធិចូលប្រើឃ្លាំង Yum ។ តាមការពិត សេវាកម្មដូចជាពេលវេលាត្រឹមត្រូវ និងប្រូកស៊ីទំនងជានឹងត្រូវបានបង្ហោះនៅលើម៉ាស៊ីនមេដែលយកចិត្តទុកដាក់ ប៉ុន្តែនៅក្នុងស្តង់ពួកគេត្រូវបានរៀបចំនៅលើ សាក្សី ដើម្បីសន្សំចំនួនម៉ាស៊ីននិម្មិត និងលំហ។

កំណែ។

v0. ធ្វើការជាមួយ CentOS 7 និង PostgreSQL 11 នៅលើ VirtualBox 6.1 ។

រចនាសម្ព័ន្ធចង្កោម

ចង្កោមទាំងអស់ត្រូវបានរចនាឡើងដើម្បីឱ្យមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យជាច្រើន រួមបញ្ចូលគ្នាទៅក្នុងបណ្តាញផ្ទះល្វែងតែមួយ ហើយត្រូវតែទប់ទល់នឹងការបរាជ័យ ឬបណ្តាញដាច់ពីគេនៃមជ្ឈមណ្ឌលទិន្នន័យតែមួយ។ នោះ​ហើយ​ជា​មូល​ហេតុ​ដែល គឺមិនអាចទៅរួចទេ ប្រើដើម្បីការពារប្រឆាំងនឹង ខួរក្បាលបំបែក បច្ចេកវិទ្យា Pacemaker ស្តង់ដារត្រូវបានគេហៅថា ស្តុននីត (បាញ់ថ្នាំងផ្សេងទៀតនៅក្បាល) ឬ ហ៊ុមព័ទ្ធ. ខ្លឹមសាររបស់វា៖ ប្រសិនបើថ្នាំងនៅក្នុងចង្កោមចាប់ផ្តើមសង្ស័យថាមានអ្វីមួយខុសជាមួយថ្នាំងមួយចំនួន វាមិនឆ្លើយតប ឬមានអាកប្បកិរិយាមិនត្រឹមត្រូវទេ បន្ទាប់មកពួកគេបិទវាដោយបង្ខំតាមរយៈឧបករណ៍ "ខាងក្រៅ" ឧទាហរណ៍ កាតត្រួតពិនិត្យ IPMI ឬ UPS ។ . ប៉ុន្តែវានឹងដំណើរការតែក្នុងករណីដែលក្នុងករណីមានការបរាជ័យតែមួយ ម៉ាស៊ីនមេ IPMI ឬ UPS បន្តដំណើរការ។ នៅទីនេះយើងមានគម្រោងការពារប្រឆាំងនឹងការបរាជ័យដ៏មហន្តរាយបន្ថែមទៀត នៅពេលដែលមជ្ឈមណ្ឌលទិន្នន័យទាំងមូលបរាជ័យ (ឧទាហរណ៍ បាត់បង់ថាមពល)។ ហើយជាមួយនឹងការបដិសេធបែបនេះអ្វីគ្រប់យ៉ាង ស្តូនីត-ឧបករណ៍ (IPMI, UPS ។ល។) ក៏នឹងមិនដំណើរការដែរ។

ផ្ទុយ​ទៅ​វិញ ប្រព័ន្ធ​គឺ​ផ្អែក​លើ​គំនិត​នៃ​កូរ៉ុម។ ថ្នាំងទាំងអស់មានសំឡេង ហើយមានតែថ្នាំងដែលអាចមើលឃើញច្រើនជាងពាក់កណ្តាលនៃថ្នាំងទាំងអស់ប៉ុណ្ណោះដែលអាចដំណើរការបាន។ បរិមាណនៃ "ពាក់កណ្តាល + 1" ត្រូវបានគេហៅថា កូរ៉ុម. ប្រសិនបើ​កូរ៉ុម​មិន​ត្រូវ​បាន​ឈាន​ដល់​ទេ នោះ​ថ្នាំង​សម្រេច​ថា​វា​ស្ថិត​ក្នុង​ភាព​ឯកោ​នៃ​បណ្តាញ ហើយ​ត្រូវ​តែ​បិទ​ធនធាន​របស់​វា ឧ. នេះគឺជាអ្វីដែលវាគឺជា ការការពារខួរក្បាលបំបែក. ប្រសិនបើកម្មវិធីដែលទទួលខុសត្រូវចំពោះឥរិយាបទនេះមិនដំណើរការទេ នោះអ្នកឃ្លាំមើលឧទាហរណ៍ផ្អែកលើ IPMI នឹងត្រូវដំណើរការ។

ប្រសិនបើចំនួនថ្នាំងគឺស្មើ (ចង្កោមនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យពីរ) នោះ អ្វីដែលគេហៅថាភាពមិនច្បាស់លាស់អាចនឹងកើតឡើង 50% / 50% (ហាសិប​ហាសិប) នៅពេលដែលភាពឯកោបណ្តាញបែងចែកចង្កោមយ៉ាងពិតប្រាកដជាពាក់កណ្តាល។ ដូច្នេះសម្រាប់ចំនួនគូនៃ nodes យើងបន្ថែម ឧបករណ៍កូរ៉ុម គឺជាដេមិនដែលមិនទាមទារ ដែលអាចត្រូវបានដាក់ឱ្យដំណើរការនៅលើម៉ាស៊ីននិម្មិតថោកបំផុតនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទីបី។ គាត់ផ្តល់ការបោះឆ្នោតរបស់គាត់ទៅផ្នែកមួយ (ដែលគាត់មើលឃើញ) ហើយដោយហេតុនេះ ដោះស្រាយភាពមិនច្បាស់លាស់ 50%/50%។ ខ្ញុំបានដាក់ឈ្មោះម៉ាស៊ីនមេ ដែលឧបករណ៍កូរ៉ុមនឹងត្រូវបានបើកដំណើរការ សាក្សី (វាក្យសព្ទពី repmgr ខ្ញុំចូលចិត្តវា)។

ធនធានអាចត្រូវបានផ្លាស់ប្តូរពីកន្លែងមួយទៅកន្លែងមួយ ឧទាហរណ៍ ពីម៉ាស៊ីនមេដែលមានកំហុស ទៅជាឧបករណ៍ដែលមានសុខភាពល្អ ឬតាមបញ្ជារបស់អ្នកគ្រប់គ្រងប្រព័ន្ធ។ ដើម្បីឱ្យអតិថិជនដឹងពីកន្លែងដែលធនធានដែលពួកគេត្រូវការមានទីតាំងនៅ (កន្លែងដែលត្រូវភ្ជាប់?), IP អណ្តែត (អណ្តែត IP) ទាំងនេះគឺជា IPs ដែល Pacemaker អាចផ្លាស់ទីជុំវិញថ្នាំង (អ្វីគ្រប់យ៉ាងគឺនៅលើបណ្តាញរាបស្មើ)។ ពួកវានីមួយៗតំណាងឱ្យធនធាន (សេវាកម្ម) ហើយនឹងមានទីតាំងនៅកន្លែងដែលអ្នកត្រូវភ្ជាប់ដើម្បីទទួលបានការចូលប្រើសេវាកម្មនេះ (ក្នុងករណីរបស់យើង មូលដ្ឋានទិន្នន័យ) ។

Tuchanka1 (សៀគ្វីជាមួយនឹងការបង្រួម)

រចនាសម្ព័ន្ធ

គំនិតនេះគឺថាយើងមានមូលដ្ឋានទិន្នន័យតូចៗជាច្រើនជាមួយនឹងការផ្ទុកទាប ដែលវាមិនមានប្រយោជន៍ក្នុងការថែរក្សាម៉ាស៊ីនបម្រើទាសករដែលខិតខំប្រឹងប្រែងក្នុងរបៀបរង់ចាំក្តៅសម្រាប់តែប្រតិបត្តិការអាន (មិនចាំបាច់ត្រូវការធនធានបែបនេះទេ)។

មជ្ឈមណ្ឌលទិន្នន័យនីមួយៗមានម៉ាស៊ីនមេមួយ។ ម៉ាស៊ីនមេនីមួយៗមានឧទាហរណ៍ PostgreSQL ពីរ (នៅក្នុងពាក្យ PostgreSQL ពួកគេត្រូវបានគេហៅថា clusters ប៉ុន្តែដើម្បីជៀសវាងការភាន់ច្រលំ ខ្ញុំនឹងហៅវាថា instances (ដោយភាពស្រដៀងគ្នាជាមួយ databases ផ្សេងទៀត) ហើយខ្ញុំនឹងហៅទៅតែ Pacemaker clusters clusters)។ វត្ថុមួយដំណើរការក្នុងរបៀបមេ ហើយមានតែវាប៉ុណ្ណោះដែលផ្តល់សេវាកម្ម (មានតែ IP អណ្តែតដែលនាំទៅដល់វា)។ វត្ថុទីពីរដំណើរការជាទាសករសម្រាប់មជ្ឈមណ្ឌលទិន្នន័យទីពីរ ហើយនឹងផ្តល់សេវាកម្មលុះត្រាតែមេរបស់វាបរាជ័យ។ ដោយសារពេលវេលាភាគច្រើនមានតែវត្ថុមួយក្នុងចំណោមវត្ថុពីរប៉ុណ្ណោះ (មេ) នឹងផ្តល់សេវាកម្ម (អនុវត្តសំណើ) ធនធានម៉ាស៊ីនមេទាំងអស់ត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់មេ (អង្គចងចាំត្រូវបានបម្រុងទុកសម្រាប់ឃ្លាំងសម្ងាត់ចែករំលែក_buffers ។ល។) ប៉ុន្តែដូច្នេះឧទាហរណ៍ទីពីរ ក៏មានធនធានគ្រប់គ្រាន់ (ទោះបីជាសម្រាប់ប្រតិបត្តិការល្អបំផុតតាមរយៈឃ្លាំងសម្ងាត់ប្រព័ន្ធឯកសារ) ក្នុងករណីមានការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យណាមួយ។ ទាសករមិនផ្តល់សេវាកម្ម (មិនអនុវត្តសំណើដែលបានអានតែប៉ុណ្ណោះ) កំឡុងពេលប្រតិបត្តិការធម្មតានៃចង្កោម ដូច្នេះកុំឱ្យមានសង្រ្គាមសម្រាប់ធនធានជាមួយមេនៅលើម៉ាស៊ីនតែមួយ។

ក្នុងករណីមានថ្នាំងពីរ ការអត់ឱនកំហុសគឺអាចធ្វើទៅបានតែជាមួយការចម្លងអសមកាលទេ ព្រោះជាមួយនឹងការចម្លងតាមសមកាលកម្ម ការបរាជ័យនៃទាសករនឹងនាំទៅដល់ការបញ្ឈប់មេ។

បរាជ័យក្នុងការធ្វើជាសាក្សី

បរាជ័យក្នុងការធ្វើជាសាក្សី (ឧបករណ៍កូរ៉ុម) ខ្ញុំ​នឹង​ពិចារណា​សម្រាប់​តែ​ចង្កោម Tuchanka1 ប៉ុណ្ណោះ ជាមួយ​នឹង​អ្វី​ផ្សេង​ទៀត​វា​នឹង​ជា​រឿង​ដដែល។ ប្រសិនបើសាក្សីបរាជ័យ គ្មានអ្វីនឹងផ្លាស់ប្តូរនៅក្នុងរចនាសម្ព័ន្ធចង្កោមនោះទេ អ្វីៗនឹងបន្តដំណើរការដូចដែលវាបានធ្វើ។ ប៉ុន្តែកូរ៉ុមនឹងក្លាយជា 2 ក្នុងចំណោម 3 ដូច្នេះហើយការបរាជ័យជាបន្តបន្ទាប់ណាមួយនឹងមានគ្រោះថ្នាក់ដល់ជីវិតសម្រាប់ចង្កោម។ វានឹងនៅតែត្រូវជួសជុលជាបន្ទាន់។

Tuchanka1 ការបដិសេធ

ការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យមួយសម្រាប់ Tuchanka1 ។ ក្នុងករណី​នេះ សាក្សី បោះ​ឆ្នោត​របស់​ខ្លួន​ទៅ​ថ្នាំង​ទីពីរ​ក្នុង​មជ្ឈមណ្ឌល​ទិន្នន័យ​ទីពីរ។ នៅទីនោះ អតីតទាសករប្រែទៅជាមេ ជាលទ្ធផល ចៅហ្វាយនាយទាំងពីរធ្វើការនៅលើម៉ាស៊ីនមេតែមួយ ហើយ IPs អណ្តែតរបស់ពួកគេទាំងពីរចង្អុលទៅពួកគេ។

Tuchanka2 (បុរាណ)

រចនាសម្ព័ន្ធ

គ្រោងការណ៍បុរាណនៃថ្នាំងពីរ។ ចៅហ្វាយ​ធ្វើ​ការ​លើ​ម្នាក់ ខ្ញុំ​បម្រើ​នៅ​ទីពីរ។ ទាំងពីរអាចប្រតិបត្តិសំណើបាន (ទាសករត្រូវបានអានតែប៉ុណ្ណោះ) ដូច្នេះទាំងពីរត្រូវបានចង្អុលបង្ហាញដោយ float IP: krogan2 គឺជាមេ krogan2s1 គឺជាទាសករ។ ទាំងចៅហ្វាយនិងទាសករនឹងមានការអត់ឱនចំពោះកំហុស។

ក្នុងករណីមានថ្នាំងពីរ ការអត់ឱនកំហុសគឺអាចធ្វើទៅបានតែជាមួយការចម្លងអសមកាលទេ ពីព្រោះជាមួយនឹងការចម្លងតាមសមកាលកម្ម ការបរាជ័យនៃទាសករនឹងនាំទៅដល់ការបញ្ឈប់មេ។

Tuchanka2 ការបដិសេធ

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

Tuchanka4 (ទាសករជាច្រើន)

រចនាសម្ព័ន្ធ

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

លក្ខណៈ​ពិសេស​មួយ​ទៀត​នៃ​គ្រោងការណ៍​នេះ​គឺ​ថា​វា​អាច​រៀបចំ​ការ​ចម្លង​សមកាលកម្ម​មួយ​រួច​ទៅ​ហើយ។ វាត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីចម្លងទៅមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀត ប្រសិនបើអាចធ្វើទៅបាន ជាជាងការចម្លងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដូចគ្នានឹងមេ។ មេ និងទាសករនីមួយៗត្រូវបានចង្អុលបង្ហាញដោយ IP អណ្តែត។ ជាសំណាងល្អ រវាងទាសករ វានឹងចាំបាច់ក្នុងការថ្លឹងថ្លែងសំណើដូចម្ដេច ប្រូកស៊ី sqlឧទាហរណ៍នៅខាងអតិថិជន។ ប្រភេទផ្សេងគ្នានៃអតិថិជនអាចត្រូវការប្រភេទផ្សេងគ្នា ប្រូកស៊ី sqlហើយមានតែអ្នកអភិវឌ្ឍន៍អតិថិជនប៉ុណ្ណោះដែលដឹងថាអ្នកណាត្រូវការអ្វី។ មុខងារនេះអាចត្រូវបានអនុវត្តដោយដេមិនខាងក្រៅ ឬដោយបណ្ណាល័យអតិថិជន (ក្រុមតភ្ជាប់) ។ល។ ទាំងអស់នេះហួសពីប្រធានបទនៃបណ្តុំមូលដ្ឋានទិន្នន័យដែលបរាជ័យ (failover ប្រូកស៊ី SQL អាចត្រូវបានអនុវត្តដោយឯករាជ្យ រួមជាមួយនឹងការអត់ឱនចំពោះកំហុសរបស់អតិថិជន)។

Tuchanka4 ការបដិសេធ

ប្រសិនបើមជ្ឈមណ្ឌលទិន្នន័យមួយ (ឧ. ម៉ាស៊ីនមេពីរ) បរាជ័យ សាក្សីបោះឆ្នោតឱ្យទីពីរ។ ជាលទ្ធផល មានម៉ាស៊ីនមេពីរដែលកំពុងដំណើរការនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទីពីរ៖ មួយកំពុងដំណើរការមេ ហើយមេអណ្តែត IP ចង្អុលទៅវា (សម្រាប់ការទទួលសំណើអាន-សរសេរ); ហើយនៅលើម៉ាស៊ីនមេទីពីរមាន slave ដែលកំពុងដំណើរការជាមួយនឹងការចម្លងតាមសមកាលកម្ម ហើយ slave float IPs មួយចង្អុលទៅវា (សម្រាប់តែការស្នើរសុំអានប៉ុណ្ណោះ)។

រឿងដំបូងដែលត្រូវកត់សម្គាល់គឺថាមិនមែន slave float IPs ទាំងអស់នឹងក្លាយជាកម្មករនោះទេ ប៉ុន្តែមានតែមួយប៉ុណ្ណោះ។ ហើយដើម្បីធ្វើការជាមួយវាឱ្យបានត្រឹមត្រូវវានឹងចាំបាច់ ប្រូកស៊ី sql បានបញ្ជូនបន្តសំណើទាំងអស់ទៅកាន់ IP អណ្តែតដែលនៅសេសសល់តែមួយគត់។ ហើយ​ប្រសិន​បើ ប្រូកស៊ី sql ទេ បន្ទាប់មកអ្នកអាចរាយបញ្ជី IP slaves ទាំងអស់ដែលបំបែកដោយសញ្ញាក្បៀសនៅក្នុង URL នៃការតភ្ជាប់។ ក្នុងករណីនេះជាមួយ libpq ការតភ្ជាប់នឹងទៅជា IP ដំណើរការដំបូង នេះត្រូវបានធ្វើនៅក្នុងប្រព័ន្ធសាកល្បងស្វ័យប្រវត្តិ។ ប្រហែលជានៅក្នុងបណ្ណាល័យផ្សេងទៀត ឧទាហរណ៍ JDBC វានឹងមិនដំណើរការទេ ហើយជាការចាំបាច់ ប្រូកស៊ី sql. នេះត្រូវបានធ្វើដោយសារតែ float IPs សម្រាប់ slaves ត្រូវបានហាមឃាត់មិនឱ្យលើកឡើងក្នុងពេលដំណាលគ្នានៅលើ server មួយ ដូច្នេះពួកវាត្រូវបានចែកចាយស្មើៗគ្នាក្នុងចំណោម slave servers ប្រសិនបើមានពួកវាជាច្រើនដែលកំពុងដំណើរការ។

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

Tuchanka3 (មជ្ឈមណ្ឌលទិន្នន័យ 3)

រចនាសម្ព័ន្ធ

នេះគឺជាចង្កោមសម្រាប់ស្ថានភាពមួយដែលមានមជ្ឈមណ្ឌលទិន្នន័យដំណើរការពេញលេញចំនួនបី ដែលនីមួយៗមានម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យដំណើរការពេញលេញ។ ក្នុងករណី​នេះ ឧបករណ៍កូរ៉ុម មិន​ត្រូវការ។ មជ្ឈមណ្ឌល​ទិន្នន័យ​មួយ​មាន​បុគ្គលិក​ដោយ​មេ ហើយ​ពីរ​ទៀត​គឺ​បុគ្គលិក​ដោយ​ទាសករ។ ការចម្លងត្រូវបានធ្វើសមកាលកម្ម វាយ ANY (slave1, slave2) មានន័យថា អតិថិជននឹងទទួលបានការបញ្ជាក់អំពីការប្តេជ្ញាចិត្ត នៅពេលដែលទាសករណាមួយគឺជាអ្នកដំបូងដែលឆ្លើយតបថាគាត់បានទទួលយកការប្តេជ្ញា។ ធនធានត្រូវបានចង្អុលបង្ហាញដោយ IP អណ្តែតមួយសម្រាប់មេ និងពីរសម្រាប់ទាសករ។ មិនដូច Tuchanka4 ទេ IP អណ្តែតទាំងបីគឺមានភាពអត់ធ្មត់ចំពោះកំហុស។ ដើម្បីធ្វើឱ្យមានតុល្យភាពសំណួរ SQL បានតែអានអ្នកអាចប្រើ ប្រូកស៊ី sql (ដោយមានការអត់ឱនខុសដោយឡែកពីគ្នា) ឬកំណត់ slave float IP មួយទៅពាក់កណ្តាលនៃអតិថិជន និងពាក់កណ្តាលទៀតទៅទីពីរ។

Tuchanka3 ការបដិសេធ

ប្រសិនបើ​មជ្ឈមណ្ឌល​ទិន្នន័យ​មួយ​បរាជ័យ នោះ​ពីរ​នៅ​សល់។ នៅក្នុងមួយ IP មេ និងអណ្តែតពីមេត្រូវបានលើកឡើង ហើយទីពីរ - slave និង slave float IPs ទាំងពីរ (ឧទាហរណ៍ត្រូវតែមានធនធានបម្រុងពីរដងដើម្បីទទួលយកការតភ្ជាប់ទាំងអស់ពី slave float IPs ទាំងពីរ)។ ការធ្វើសមកាលកម្មចម្លងរវាងចៅហ្វាយនាយ និងទាសករ។ ដូចគ្នានេះផងដែរ ចង្កោមនឹងរក្សាទុកព័ត៌មានអំពីប្រតិបត្តិការដែលបានប្តេជ្ញាចិត្ត និងបានបញ្ជាក់ (នឹងមិនមានការបាត់បង់ព័ត៌មាន) នៅក្នុងព្រឹត្តិការណ៍នៃការបំផ្លាញមជ្ឈមណ្ឌលទិន្នន័យពីរ (ប្រសិនបើវាមិនត្រូវបានបំផ្លាញក្នុងពេលដំណាលគ្នា)។

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

ប្រព័ន្ធសាកល្បងស្វ័យប្រវត្តិ

ដើម្បីសាកល្បងភាពអត់ធ្មត់នៃកំហុសនៃចង្កោមដោយការក្លែងបន្លំកំហុសផ្សេងៗ ប្រព័ន្ធសាកល្បងស្វ័យប្រវត្តិត្រូវបានបង្កើតឡើង។ បើកដំណើរការដោយស្គ្រីប test/failure. ស្គ្រីបអាចយកជាប៉ារ៉ាម៉ែត្រនៃចំនួនចង្កោមដែលអ្នកចង់សាកល្បង។ ឧទាហរណ៍ពាក្យបញ្ជានេះ៖

test/failure 2 3

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

ស្ថានីយ​ត្រូវ​បាន​បែង​ចែក​ជា​ជួរ​ឈរ​តាម​ចំនួន​ចង្កោម​ដែល​ត្រូវ​បាន​សាកល្បង; តាម​លំនាំដើម (ក្នុង​រូបថត​អេក្រង់) មាន​បួន។ ខ្ញុំនឹងរៀបរាប់អំពីខ្លឹមសារនៃជួរឈរដោយប្រើឧទាហរណ៍នៃ Tuchanka2 ។ បន្ទះនៅក្នុងរូបថតអេក្រង់មានលេខរៀង៖

1. ស្ថិតិតេស្តត្រូវបានបង្ហាញនៅទីនេះ។ ជួរ​ឈរ៖
   • បរាជ័យ - ឈ្មោះនៃការធ្វើតេស្ត (មុខងារនៅក្នុងស្គ្រីប) ដែលត្រាប់តាមកំហុស។
   • ប្រតិកម្ម - រយៈពេលមធ្យមនព្វន្ធគិតជាវិនាទី ក្នុងអំឡុងពេលដែលចង្កោមបានដំណើរការមុខងាររបស់វា។ វាត្រូវបានវាស់ពីការចាប់ផ្តើមនៃស្គ្រីបដែលត្រាប់តាមកំហុស រហូតដល់ពេលដែលចង្កោមស្តារមុខងាររបស់វាឡើងវិញ ហើយអាចបន្តផ្តល់សេវាកម្មបាន។ ឧទាហរណ៍ ប្រសិនបើពេលវេលាខ្លីណាស់ ប្រាំមួយវិនាទី (វាកើតឡើងជាចង្កោមជាមួយទាសករជាច្រើននាក់ (Tuchanka3 និង Tuchanka4)) នេះមានន័យថាកំហុសគឺស្ថិតនៅលើទាសករអសមកាល ហើយមិនប៉ះពាល់ដល់ការសម្តែងតាមមធ្យោបាយណាមួយឡើយ មិនមាន កុងតាក់រដ្ឋចង្កោម។
   • គម្លាត - បង្ហាញការរីករាលដាល (ភាពត្រឹមត្រូវ) នៃតម្លៃ ប្រតិកម្ម ដោយប្រើវិធីសាស្ត្រគម្លាតស្តង់ដារ។
   • រាប់ - តើការធ្វើតេស្តនេះត្រូវបានអនុវត្តប៉ុន្មានដង។
2. កំណត់ហេតុខ្លីអនុញ្ញាតឱ្យអ្នកវាយតម្លៃនូវអ្វីដែលក្រុមកំពុងធ្វើនាពេលបច្ចុប្បន្ន។ លេខសម្គាល់ពេលវេលា និងឈ្មោះប្រតិបត្តិការត្រូវបានបង្ហាញ។ ការរត់យូរពេក (> 5 នាទី) បង្ហាញពីបញ្ហា។
3. បេះដូង (បេះដូង) - ពេលវេលាបច្ចុប្បន្ន។ សម្រាប់ការវាយតម្លៃដែលមើលឃើញនៃការអនុវត្ត ចៅហ្វាយនាយ ពេលវេលាបច្ចុប្បន្នត្រូវបានសរសេរទៅកាន់តារាងរបស់វាជានិច្ច ដោយប្រើមេ IP អណ្តែត។ ប្រសិនបើជោគជ័យ លទ្ធផលត្រូវបានបង្ហាញនៅក្នុងបន្ទះនេះ។
4. វាយ (ជីពចរ) - "ពេលវេលាបច្ចុប្បន្ន" ដែលត្រូវបានកត់ត្រាពីមុនដោយស្គ្រីប បេះដូង ដើម្បីធ្វើជាម្ចាស់ឥឡូវនេះអានពី ទាសករ តាមរយៈ IP អណ្តែតរបស់វា។ អនុញ្ញាតឱ្យអ្នកវាយតម្លៃដោយមើលឃើញនូវការអនុវត្តរបស់ទាសករ និងការចម្លង។ នៅក្នុង Tuchanka1 មិនមានទាសករដែលមាន IP អណ្តែតទេ (គ្មានទាសករដែលផ្តល់សេវាកម្ម) ប៉ុន្តែមានឧទាហរណ៍ពីរ (DBs) ដូច្នេះវានឹងមិនត្រូវបានបង្ហាញនៅទីនេះទេ វាយនិង បេះដូង ឧទាហរណ៍ទីពីរ។
5. ការត្រួតពិនិត្យសុខភាពចង្កោមដោយប្រើឧបករណ៍ប្រើប្រាស់ pcs mon. បង្ហាញរចនាសម្ព័ន្ធ ការចែកចាយធនធាននៅទូទាំងថ្នាំង និងព័ត៌មានមានប្រយោជន៍ផ្សេងទៀត។
6. ការត្រួតពិនិត្យប្រព័ន្ធពីម៉ាស៊ីននិម្មិតនីមួយៗនៅក្នុងចង្កោមត្រូវបានបង្ហាញនៅទីនេះ។ វាអាចមានបន្ទះបែបនេះច្រើន អាស្រ័យលើចំនួនម៉ាស៊ីននិម្មិតដែលចង្កោមមាន។ ក្រាហ្វពីរ ការផ្ទុកស៊ីភីយូ (ម៉ាស៊ីននិម្មិតមានប្រព័ន្ធដំណើរការពីរ) ឈ្មោះម៉ាស៊ីននិម្មិត ការផ្ទុកប្រព័ន្ធ (ហៅថា Load Average ព្រោះវាជាមធ្យមលើសពី 5, 10 និង 15 នាទី) ដំណើរការទិន្នន័យ និងការបែងចែកអង្គចងចាំ។
7. ដាននៃស្គ្រីបដែលកំពុងធ្វើការសាកល្បង។ នៅក្នុងព្រឹត្តិការណ៍នៃដំណើរការខុសប្រក្រតី - ការរំខានភ្លាមៗនៃប្រតិបត្តិការ ឬវដ្តនៃការរង់ចាំគ្មានទីបញ្ចប់ - នៅទីនេះអ្នកអាចឃើញហេតុផលសម្រាប់ឥរិយាបថនេះ។

ការធ្វើតេស្តត្រូវបានអនុវត្តជាពីរដំណាក់កាល។ ដំបូង ស្គ្រីបឆ្លងកាត់ការធ្វើតេស្តគ្រប់ប្រភេទ ដោយជ្រើសរើសម៉ាស៊ីននិម្មិតដោយចៃដន្យ ដើម្បីអនុវត្តការធ្វើតេស្តនេះ។ បន្ទាប់មក វដ្តនៃការធ្វើតេស្តគ្មានទីបញ្ចប់ត្រូវបានអនុវត្ត ម៉ាស៊ីននិម្មិត និងកំហុសត្រូវបានជ្រើសរើសដោយចៃដន្យរាល់ពេល។ ការបញ្ចប់ភ្លាមៗនៃស្គ្រីបសាកល្បង (បន្ទះខាងក្រោម) ឬរង្វិលជុំគ្មានទីបញ្ចប់នៃការរង់ចាំអ្វីមួយ (> 5 នាទីដំណើរការសម្រាប់ប្រតិបត្តិការមួយ នេះអាចត្រូវបានគេមើលឃើញនៅក្នុងដាន) បង្ហាញថាការធ្វើតេស្តមួយចំនួននៅលើចង្កោមនេះបានបរាជ័យ។

ការធ្វើតេស្តនីមួយៗមានប្រតិបត្តិការដូចខាងក្រោមៈ

1. បើកដំណើរការមុខងារដែលត្រាប់តាមកំហុស។
2. ត្រៀមខ្លួនជាស្រេច? - រង់ចាំសម្រាប់ចង្កោមត្រូវបានស្ដារឡើងវិញ (នៅពេលដែលសេវាកម្មទាំងអស់ត្រូវបានផ្តល់ជូន) ។
3. បង្ហាញការអស់ពេលនៃការសង្គ្រោះចង្កោម (ប្រតិកម្ម).
4. ជួសជុល - ចង្កោមកំពុងត្រូវបាន "ជួសជុល" ។ បន្ទាប់ពីនោះ វាគួរតែត្រឡប់ទៅស្ថានភាពប្រតិបត្តិការពេញលេញ និងត្រៀមខ្លួនសម្រាប់ដំណើរការខុសប្រក្រតីបន្ទាប់ទៀត។

នេះគឺជាបញ្ជីនៃការធ្វើតេស្តជាមួយនឹងការពិពណ៌នាអំពីអ្វីដែលពួកគេធ្វើ៖

• ForkBomb៖ បង្កើត "Out of memory" ដោយប្រើគ្រាប់បែក fork ។
• អស់​កន្លែង៖ ថាសរឹងពេញហើយ។ ប៉ុន្តែការធ្វើតេស្តនេះមានលក្ខណៈជានិមិត្ដរូប ដោយមានបន្ទុកមិនសំខាន់ដែលត្រូវបានបង្កើតកំឡុងពេលធ្វើតេស្ត PostgreSQL ជាធម្មតាមិនបរាជ័យនៅពេលដែល hard drive ពេញ។
• Postgres-សម្លាប់៖ សម្លាប់ PostgreSQL ដោយប្រើពាក្យបញ្ជា killall -KILL postgres.
• Postgres-STOP៖ ព្យួរពាក្យបញ្ជា PostgreSQL killall -STOP postgres.
• ថាមពលបិទ៖ "de-energizes" ម៉ាស៊ីននិម្មិតដោយប្រើពាក្យបញ្ជា VBoxManage controlvm "виртуалка" poweroff.
• កំណត់​ឡើង​វិញ៖ ផ្ទុកលើសទម្ងន់ម៉ាស៊ីននិម្មិតដោយប្រើពាក្យបញ្ជា VBoxManage controlvm "виртуалка" reset.
• SBD-STOP៖ ផ្អាកបិសាច SBD ដោយប្រើពាក្យបញ្ជា killall -STOP sbd.
• បិទ៖ ផ្ញើពាក្យបញ្ជាទៅម៉ាស៊ីននិម្មិតតាមរយៈ SSH systemctl poweroff, ប្រព័ន្ធបិទយ៉ាងរលូន។
• ផ្ដាច់៖ ឯកោបណ្តាញ, ពាក្យបញ្ជា VBoxManage controlvm "виртуалка" setlinkstate1 off.

ការបញ្ចប់ការធ្វើតេស្តដោយប្រើពាក្យបញ្ជា tmux ស្តង់ដារ "kill-window" Ctrl-b &ឬពាក្យបញ្ជា "ផ្ដាច់អតិថិជន" Ctrl-b ឃ: នៅចំណុចនេះបញ្ចប់ការធ្វើតេស្ត tmux បិទ ម៉ាស៊ីននិម្មិតត្រូវបានបិទ។

បញ្ហាដែលបានកំណត់អំឡុងពេលធ្វើតេស្ត

• នៅពេលនេះ ឆ្មាំបិសាច sbd ធ្វើការលើការបញ្ឈប់ដេមិនដែលបានសង្កេត ប៉ុន្តែមិនបង្កកពួកវាទេ។ ហើយជាលទ្ធផលកំហុសដែលនាំទៅដល់ការបង្កកតែប៉ុណ្ណោះ កូរ៉ូស៊ីស៊ី и ផាសស្ទឺរប៉ុន្តែមិនព្យួរ sbd... សម្រាប់ការត្រួតពិនិត្យ កូរ៉ូស៊ីស៊ី មានរួចហើយ PR#83 (នៅលើ GitHub នៅ sbd), ទទួលយកទៅខ្សែស្រឡាយ មេ. ពួកគេបានសន្យា (នៅក្នុង PR # 83) ថានឹងមានអ្វីមួយស្រដៀងគ្នាសម្រាប់ Pacemaker ខ្ញុំសង្ឃឹមថាដោយ RedHat ៧ នឹង​ធ្វើ។ ប៉ុន្តែ "ដំណើរការខុសប្រក្រតី" បែបនេះគឺជាការស្មាន ហើយអាចត្រូវបានក្លែងធ្វើដោយសិប្បនិម្មិតយ៉ាងងាយស្រួលដោយប្រើឧទាហរណ៍។ killall -STOP corosyncប៉ុន្តែមិនដែលជួបគ្នាក្នុងជីវិតពិត។

• У ផាសស្ទឺរ នៅក្នុងកំណែសម្រាប់ CentOS 7 កំណត់មិនត្រឹមត្រូវ sync_អស់ពេល у ឧបករណ៍កូរ៉ុម, ជា​លទ្ធផល ប្រសិនបើថ្នាំងមួយបានបរាជ័យ ជាមួយនឹងប្រូបាប៊ីលីតេមួយចំនួន ថ្នាំងទីពីរក៏ចាប់ផ្ដើមឡើងវិញផងដែរ។ដែលមេត្រូវផ្លាស់ទី។ ព្យាបាលដោយការពង្រីក sync_អស់ពេល у ឧបករណ៍កូរ៉ុម កំឡុងពេលដាក់ពង្រាយ (ក្នុងស្គ្រីប setup/setup1) វិសោធនកម្មនេះមិនត្រូវបានទទួលយកដោយអ្នកអភិវឌ្ឍន៍ទេ។ ផាសស្ទឺរផ្ទុយទៅវិញ ពួកគេបានសន្យាថានឹងរៀបចំរចនាសម្ព័ន្ធឡើងវិញតាមរបៀបនេះ (នៅពេលអនាគតដែលមិនបានបញ្ជាក់) ដែលពេលវេលានេះនឹងត្រូវបានគណនាដោយស្វ័យប្រវត្តិ។

• ប្រសិនបើការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យបញ្ជាក់នោះ។ LC_MESSAGES (សារជាអក្សរ) អាចប្រើយូនីកូដ ឧ. ru_RU.UTF-8បន្ទាប់មកនៅពេលចាប់ផ្តើម postgres នៅក្នុងបរិយាកាសដែលមូលដ្ឋានមិនមែនជា UTF-8 និយាយថានៅក្នុងបរិយាកាសទទេ (នៅទីនេះ ឧបករណ៍និយ័តបេះដូង+pgsqlms(paf) រត់ postgres), បន្ទាប់មក កំណត់ហេតុនឹងមានសញ្ញាសួរជំនួសឱ្យអក្សរ UTF-8. អ្នកអភិវឌ្ឍន៍ PostgreSQL មិនបានយល់ព្រមលើអ្វីដែលត្រូវធ្វើក្នុងករណីនេះទេ។ វាមានតម្លៃអ្នកត្រូវដំឡើង LC_MESSAGES=en_US.UTF-8 នៅពេលកំណត់រចនាសម្ព័ន្ធ (បង្កើត) ឧទាហរណ៍មូលដ្ឋានទិន្នន័យ។

• ប្រសិនបើ wal_receiver_timeout ត្រូវបានកំណត់ (តាមលំនាំដើមវាគឺ 60s) បន្ទាប់មកក្នុងអំឡុងពេលធ្វើតេស្ត PostgreSQL-STOP នៅលើមេនៅក្នុងចង្កោម tuchanka3 និង tuchanka4 ការចម្លងមិនភ្ជាប់ទៅមេថ្មីទេ។. ការចម្លងនៅទីនោះមានភាពស៊ីសង្វាក់គ្នា ដូច្នេះមិនត្រឹមតែទាសករឈប់ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានម្ចាស់ថ្មីផងដែរ។ ធ្វើការនៅជុំវិញដោយការកំណត់ wal_receiver_timeout=0 នៅពេលកំណត់រចនាសម្ព័ន្ធ PostgreSQL ។

• ម្តងម្កាល ខ្ញុំបានសង្កេតឃើញការបង្កកការចម្លងនៅក្នុង PostgreSQL នៅក្នុងការធ្វើតេស្ត ForkBomb (លើសចំណុះ)។ បន្ទាប់ពី ForkBomb ពេលខ្លះទាសករប្រហែលជាមិនភ្ជាប់ទំនាក់ទំនងជាមួយមេថ្មីទេ។. ខ្ញុំបានជួបប្រទះវានៅក្នុងចង្កោម tuchanka3 និង tuchanka4 ដែលមេបានបង្កកដោយសារតែការចម្លងតាមសមកាលកម្ម។ បញ្ហានេះបានបាត់ទៅវិញដោយខ្លួនឯងបន្ទាប់ពីរយៈពេលយូរ (ប្រហែលពីរម៉ោង) ។ ត្រូវការការស្រាវជ្រាវបន្ថែម ដើម្បីកែបញ្ហានេះ។ រោគ​សញ្ញា​គឺ​ស្រដៀង​គ្នា​នឹង​មេរោគ​មុន​ដែល​បណ្តាល​មក​ពី​ហេតុផល​ផ្សេង​គ្នា ប៉ុន្តែ​មាន​ផល​វិបាក​ដូច​គ្នា។

រូបថតរបស់ Krogan សិល្បៈ Deviant ដោយមានការអនុញ្ញាតពីអ្នកនិពន្ធ៖

ប្រភព: www.habr.com