ទិដ្ឋភាពទូទៅសង្ខេបនៃសេចក្តីថ្លែងការណ៍ PostgreSQL សម្រាប់ Kubernetes ជម្រើស និងបទពិសោធន៍របស់យើង។

កាន់តែខ្លាំងឡើង អតិថិជនកំពុងទទួលបានសំណើដូចខាងក្រោម៖ "យើងចង់បានវាដូចជា Amazon RDS ប៉ុន្តែថោកជាង"; "យើងចង់បានវាដូច RDS ប៉ុន្តែនៅគ្រប់ទីកន្លែងក្នុងហេដ្ឋារចនាសម្ព័ន្ធណាមួយ។" ដើម្បីអនុវត្តដំណោះស្រាយដែលបានគ្រប់គ្រងបែបនេះនៅលើ Kubernetes យើងបានពិនិត្យមើលស្ថានភាពបច្ចុប្បន្ននៃប្រតិបត្តិករពេញនិយមបំផុតសម្រាប់ PostgreSQL (Stolon ប្រតិបត្តិករមកពី Crunchy Data និង Zalando) ហើយបានជ្រើសរើសរបស់យើង។

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

តើ RDS គឺជាអ្វី

នៅពេលដែលមនុស្សនិយាយអំពី RDS នៅក្នុងបទពិសោធន៍របស់យើង ពួកគេមានន័យថាសេវាកម្ម DBMS ដែលគ្រប់គ្រងដែល៖

1. ងាយស្រួលក្នុងការកំណត់រចនាសម្ព័ន្ធ;
2. មានសមត្ថភាពក្នុងការធ្វើការជាមួយរូបថតនិងស្តារឡើងវិញពីពួកគេ (និយមជាមួយការគាំទ្រ PITR);
3. អនុញ្ញាតឱ្យអ្នកបង្កើត master-slave topologies;
4. មានបញ្ជីបន្ថែមនៃផ្នែកបន្ថែម;
5. ផ្តល់សវនកម្ម និងការគ្រប់គ្រងអ្នកប្រើប្រាស់/ការចូលប្រើ។

និយាយជាទូទៅ វិធីសាស្រ្តក្នុងការអនុវត្តកិច្ចការនៅនឹងដៃអាចមានភាពខុសគ្នាខ្លាំង ប៉ុន្តែផ្លូវដែលមានលក្ខខណ្ឌ Ansible មិននៅជិតយើងទេ។ (សហសេវិកមកពី 2GIS បានសន្និដ្ឋានស្រដៀងគ្នាជាលទ្ធផល ការប៉ុនប៉ងរបស់គាត់។ បង្កើត "ឧបករណ៍សម្រាប់ដាក់ពង្រាយក្រុមបរាជ័យដែលមានមូលដ្ឋានលើ Postgres យ៉ាងឆាប់រហ័ស។")

ប្រតិបត្តិករគឺជាវិធីសាស្រ្តទូទៅសម្រាប់ការដោះស្រាយបញ្ហាស្រដៀងគ្នានៅក្នុងប្រព័ន្ធអេកូ Kubernetes ។ នាយកបច្ចេកទេសនៃ "Flanta" បាននិយាយលម្អិតបន្ថែមទៀតអំពីពួកគេរួចហើយ ទាក់ទងនឹងមូលដ្ឋានទិន្នន័យដែលបានបើកដំណើរការនៅខាងក្នុង Kubernetes ។ ឌីស្តុលនៅ របាយការណ៍មួយរបស់គាត់។.

NB៖ ដើម្បីបង្កើតប្រតិបត្តិករសាមញ្ញបានយ៉ាងឆាប់រហ័ស យើងសូមណែនាំឱ្យយកចិត្តទុកដាក់ចំពោះឧបករណ៍ប្រើប្រាស់ប្រភពបើកចំហរបស់យើង។ ប្រតិបត្តិករសែល. ដោយប្រើវា អ្នកអាចធ្វើវាដោយគ្មានចំណេះដឹងអំពី Go ប៉ុន្តែតាមរបៀបដែលកាន់តែស៊ាំជាមួយអ្នកគ្រប់គ្រងប្រព័ន្ធ៖ នៅក្នុង Bash, Python ជាដើម។

មានប្រតិបត្តិករ K8s ដ៏ពេញនិយមមួយចំនួនសម្រាប់ PostgreSQL៖

• ស្តូឡុង;
• ប្រតិបត្តិករ PostgreSQL ទិន្នន័យ Crunchy;
• ប្រតិបត្តិករ Zalando Postgres ។

សូមក្រឡេកមើលពួកគេឱ្យកាន់តែច្បាស់។

ការជ្រើសរើសប្រតិបត្តិករ

បន្ថែមពីលើលក្ខណៈសំខាន់ៗដែលបានរៀបរាប់ខាងលើ យើង - ក្នុងនាមជាវិស្វករប្រតិបត្តិការហេដ្ឋារចនាសម្ព័ន្ធ Kubernetes - ក៏រំពឹងទុកដូចខាងក្រោមពីប្រតិបត្តិករផងដែរ៖

• ការដាក់ពង្រាយពី Git និងជាមួយ ធនធានផ្ទាល់ខ្លួន;
• ការគាំទ្រ pod ប្រឆាំងនឹងភាពស្និទ្ធស្នាល;
• ការដំឡើង affinity node ឬ node selector;
• ការដំឡើងនៃការអត់ធ្មត់;
• លទ្ធភាពនៃការលៃតម្រូវ;
• បច្ចេកវិទ្យាដែលអាចយល់បាន និងសូម្បីតែពាក្យបញ្ជា។

ដោយមិនចូលទៅក្នុងព័ត៌មានលម្អិតលើចំណុចនីមួយៗ (សួរនៅក្នុងមតិយោបល់ ប្រសិនបើអ្នកនៅតែមានសំណួរអំពីពួកគេបន្ទាប់ពីអានអត្ថបទទាំងមូល) ខ្ញុំនឹងកត់សម្គាល់ជាទូទៅថាប៉ារ៉ាម៉ែត្រទាំងនេះគឺចាំបាច់ដើម្បីពណ៌នាឱ្យកាន់តែច្បាស់អំពីឯកទេសនៃថ្នាំងចង្កោម ដើម្បី បញ្ជាឱ្យពួកគេសម្រាប់កម្មវិធីជាក់លាក់។ វិធីនេះយើងអាចសម្រេចបាននូវសមតុល្យដ៏ល្អប្រសើរក្នុងលក្ខខណ្ឌនៃការអនុវត្ត និងការចំណាយ។

ឥឡូវនេះសូមបន្តទៅប្រតិបត្តិករ PostgreSQL ដោយខ្លួនឯង។

1. ស្តុន

ស្តូឡុង ពីក្រុមហ៊ុនអ៊ីតាលី Sorint.lab in របាយការណ៍ដែលបានលើកឡើងរួចហើយ ត្រូវបានចាត់ទុកថាជាប្រភេទស្តង់ដារក្នុងចំណោមប្រតិបត្តិករសម្រាប់ DBMS ។ នេះគឺជាគម្រោងចាស់គួរសម៖ ការចេញផ្សាយជាសាធារណៈលើកដំបូងរបស់វាបានកើតឡើងនៅក្នុងខែវិច្ឆិកា ឆ្នាំ 2015 (!) ហើយឃ្លាំង GitHub មានផ្កាយជិត 3000 និងអ្នកចូលរួម 40+ ។

ជាការពិត Stolon គឺជាឧទាហរណ៍ដ៏ល្អនៃស្ថាបត្យកម្មគិតគូរ៖

ឧបករណ៍របស់ប្រតិបត្តិករនេះអាចត្រូវបានរកឃើញលម្អិតនៅក្នុងរបាយការណ៍ឬ ឯកសារគម្រោង. ជាទូទៅ វាគ្រប់គ្រាន់ក្នុងការនិយាយថា វាអាចធ្វើអ្វីៗគ្រប់យ៉ាងដែលបានពិពណ៌នា៖ ការបរាជ័យ ប្រូកស៊ីសម្រាប់ការចូលប្រើរបស់អតិថិជនប្រកបដោយតម្លាភាព ការបម្រុងទុក... លើសពីនេះទៅទៀត ប្រូកស៊ីផ្តល់នូវការចូលប្រើប្រាស់តាមរយៈសេវាកម្មបញ្ចប់មួយ - មិនដូចដំណោះស្រាយពីរផ្សេងទៀតដែលបានពិភាក្សាខាងក្រោម (ពួកវានីមួយៗមានសេវាកម្មពីរសម្រាប់ ការចូលប្រើមូលដ្ឋាន) ។

ទោះយ៉ាងណា Stolon គ្មានធនធានផ្ទាល់ខ្លួននោះហើយជាមូលហេតុដែលវាមិនអាចត្រូវបានដាក់ឱ្យប្រើប្រាស់តាមរបៀបដែលវាងាយស្រួល និងរហ័ស - "ដូចជានំក្តៅ" - ដើម្បីបង្កើតឧទាហរណ៍ DBMS នៅក្នុង Kubernetes ។ ការគ្រប់គ្រងត្រូវបានអនុវត្តតាមរយៈឧបករណ៍ប្រើប្រាស់ stolonctlការដាក់ពង្រាយត្រូវបានធ្វើឡើងតាមរយៈគំនូសតាង Helm ហើយការកំណត់ផ្ទាល់ខ្លួនត្រូវបានកំណត់ និងបញ្ជាក់នៅក្នុង ConfigMap ។

នៅលើដៃមួយវាប្រែថាប្រតិបត្តិករមិនមែនជាប្រតិបត្តិករទេ (បន្ទាប់ពីទាំងអស់វាមិនប្រើ CRD) ។ ប៉ុន្តែម្យ៉ាងវិញទៀត វាគឺជាប្រព័ន្ធដែលអាចបត់បែនបានដែលអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធធនធាននៅក្នុង K8s ដូចដែលអ្នកឃើញសម។

ដើម្បីសង្ខេប សម្រាប់យើងផ្ទាល់ វាហាក់ដូចជាមិនសមហេតុផលក្នុងការបង្កើតគំនូសតាងដាច់ដោយឡែកសម្រាប់មូលដ្ឋានទិន្នន័យនីមួយៗ។ ដូច្នេះ​ហើយ យើង​ចាប់​ផ្ដើម​ស្វែងរក​ជម្រើស។

2. ប្រតិបត្តិករ PostgreSQL ទិន្នន័យ Crunchy

ប្រតិបត្តិករពី Crunchy Dataដែលជាការចាប់ផ្តើមអាជីវកម្មវ័យក្មេងរបស់អាមេរិក ហាក់ដូចជាជម្រើសដ៏សមហេតុផលមួយ។ ប្រវត្តិសាស្រ្តសាធារណៈរបស់វាចាប់ផ្តើមជាមួយនឹងការចេញផ្សាយលើកដំបូងនៅក្នុងខែមីនា 2017 ចាប់តាំងពីពេលនោះមក ឃ្លាំង GitHub បានទទួលផ្កាយតិចជាង 1300 និងអ្នករួមចំណែក 50+ ។ ការចេញផ្សាយចុងក្រោយបំផុតពីខែកញ្ញាត្រូវបានសាកល្បងដើម្បីដំណើរការជាមួយ Kubernetes 1.15-1.18, OpenShift 3.11+ និង 4.4+, GKE និង VMware Enterprise PKS 1.3+ ។

ស្ថាបត្យកម្មនៃ Crunchy Data PostgreSQL Operator ក៏បំពេញតាមតម្រូវការដែលបានចែងផងដែរ៖

ការគ្រប់គ្រងកើតឡើងតាមរយៈឧបករណ៍ប្រើប្រាស់ pgoទោះយ៉ាងណាក៏ដោយ វាបង្កើតធនធានផ្ទាល់ខ្លួនសម្រាប់ Kubernetes ។ ដូច្នេះ ប្រតិបត្តិករពេញចិត្តយើងជាអ្នកប្រើប្រាស់សក្តានុពល៖

• មានការត្រួតពិនិត្យតាមរយៈ CRD;
• ការគ្រប់គ្រងអ្នកប្រើប្រាស់ងាយស្រួល (តាមរយៈ CRD);
• ការរួមបញ្ចូលជាមួយសមាសធាតុផ្សេងទៀត។ Crunchy Data Container Suite - ការប្រមូលឯកទេសនៃរូបភាពកុងតឺន័រសម្រាប់ PostgreSQL និងឧបករណ៍ប្រើប្រាស់សម្រាប់ធ្វើការជាមួយវា (រួមទាំង pgBackRest, pgAudit, ផ្នែកបន្ថែមពីការរួមចំណែក។ល។)។

ទោះជាយ៉ាងណាក៏ដោយ ការព្យាយាមចាប់ផ្តើមប្រើប្រាស់ប្រតិបត្តិករពី Crunchy Data បានបង្ហាញពីបញ្ហាមួយចំនួន៖

• មិនមានលទ្ធភាពនៃការអត់ឱនទេ - មានតែ nodeSelector ប៉ុណ្ណោះដែលត្រូវបានផ្តល់ជូន។
• ផតឃែរដែលបានបង្កើតគឺជាផ្នែកមួយនៃការដាក់ពង្រាយ ទោះបីជាយើងបានដាក់ពង្រាយកម្មវិធីដែលមានលក្ខណៈរដ្ឋក៏ដោយ។ មិនដូច StatefulSets ការដាក់ពង្រាយមិនអាចបង្កើតថាសបានទេ។

គុណវិបត្តិចុងក្រោយនាំឱ្យមានពេលវេលាគួរឱ្យអស់សំណើច៖ នៅលើបរិយាកាសសាកល្បង យើងបានគ្រប់គ្រងដំណើរការចម្លង 3 ជាមួយថាសមួយ ការផ្ទុកក្នុងស្រុកបណ្តាលឱ្យប្រតិបត្តិកររាយការណ៍ថាការចម្លងចំនួន 3 កំពុងដំណើរការ (ទោះបីជាវាមិនមានក៏ដោយ) ។

លក្ខណៈពិសេសមួយទៀតរបស់ប្រតិបត្តិករនេះគឺការរួមបញ្ចូលដែលត្រៀមរួចជាស្រេចជាមួយនឹងប្រព័ន្ធជំនួយផ្សេងៗ។ ឧទាហរណ៍ វាងាយស្រួលក្នុងការដំឡើង pgAdmin និង pgBounce ហើយនៅក្នុង ឯកសារ Grafana និង Prometheus ដែលបានកំណត់ទុកជាមុនត្រូវបានពិចារណា។ នាពេលថ្មីៗនេះ ចេញផ្សាយ 4.5.0-beta1 ការធ្វើសមាហរណកម្មប្រសើរឡើងជាមួយគម្រោងត្រូវបានកត់សម្គាល់ដោយឡែកពីគ្នា។ pgMonitorអរគុណដែលប្រតិបត្តិករផ្តល់នូវការមើលឃើញយ៉ាងច្បាស់នៃម៉ែត្រ PgSQL ចេញពីប្រអប់។

ទោះជាយ៉ាងណាក៏ដោយ ជម្រើសចម្លែកនៃធនធានដែលបង្កើតដោយ Kubernetes បាននាំឱ្យយើងទៅរកតម្រូវការក្នុងការស្វែងរកដំណោះស្រាយផ្សេង។

3. ប្រតិបត្តិករ Zalando Postgres

យើងបានស្គាល់ផលិតផល Zalando ជាយូរមកហើយ៖ យើងមានបទពិសោធន៍ប្រើប្រាស់ Zalenium ហើយជាការពិតណាស់ យើងបានព្យាយាម ប៉ាតូនី គឺជាដំណោះស្រាយ HA ដ៏ពេញនិយមរបស់ពួកគេសម្រាប់ PostgreSQL ។ អំពីវិធីសាស្រ្តរបស់ក្រុមហ៊ុនក្នុងការបង្កើត ប្រតិបត្តិករ Postgres អ្នកនិពន្ធម្នាក់ឈ្មោះ Alexey Klyukin បាននិយាយនៅលើអាកាស Postgres-ថ្ងៃអង្គារ #5ហើយយើងចូលចិត្តវា។

នេះគឺជាដំណោះស្រាយដ៏ក្មេងបំផុតដែលបានពិភាក្សានៅក្នុងអត្ថបទ៖ ការចេញផ្សាយលើកដំបូងបានកើតឡើងនៅក្នុងខែសីហា ឆ្នាំ 2018 ។ ទោះបីជាយ៉ាងណាក៏ដោយ ទោះបីជាមានការចេញផ្សាយផ្លូវការតិចតួចក៏ដោយ គម្រោងនេះបានឈានទៅដល់ផ្លូវដ៏វែងឆ្ងាយ ដែលដំណោះស្រាយពី Crunchy Data ដែលមានតារា 1300+ នៅលើ GitHub និងចំនួនអ្នករួមចំណែកអតិបរមា (70+) រួចទៅហើយ។

"នៅក្រោមក្រណាត់" ប្រតិបត្តិករនេះប្រើដំណោះស្រាយដែលបានសាកល្បងពេលវេលា៖

• Patroni និង ស្ពូឡូ សម្រាប់ការបើកបរ,
• WAL-E - សម្រាប់ការបម្រុងទុក,
• PgBouncer - ជាអាងតភ្ជាប់។

នេះជារបៀបដែលស្ថាបត្យកម្មប្រតិបត្តិករពី Zalando ត្រូវបានបង្ហាញ:

ប្រតិបត្តិករត្រូវបានគ្រប់គ្រងយ៉ាងពេញលេញតាមរយៈ Custom Resources បង្កើត StatefulSet ដោយស្វ័យប្រវត្តិពីកុងតឺន័រ ដែលបន្ទាប់មកអាចត្រូវបានប្ដូរតាមបំណងដោយបន្ថែម sidecars ផ្សេងៗទៅ pod ។ ទាំងអស់នេះគឺជាអត្ថប្រយោជន៍ដ៏សំខាន់ក្នុងការប្រៀបធៀបជាមួយប្រតិបត្តិករពី Crunchy Data ។

ដោយសារយើងបានជ្រើសរើសដំណោះស្រាយពី Zalando ក្នុងចំណោមជម្រើសទាំង 3 ដែលកំពុងត្រូវបានពិចារណា ការពិពណ៌នាបន្ថែមអំពីសមត្ថភាពរបស់វានឹងត្រូវបានបង្ហាញខាងក្រោមភ្លាមៗ រួមជាមួយនឹងការអនុវត្តកម្មវិធី។

អនុវត្តជាមួយប្រតិបត្តិករ Postgres ពី Zalando

ការដាក់ពង្រាយប្រតិបត្តិករគឺសាមញ្ញណាស់៖ គ្រាន់តែទាញយកការចេញផ្សាយបច្ចុប្បន្នពី GitHub ហើយអនុវត្តឯកសារ YAML ពីថត បង្ហាញរាង. ជាជម្រើសអ្នកក៏អាចប្រើផងដែរ។ មជ្ឈមណ្ឌលប្រតិបត្តិករ.

បន្ទាប់ពីដំឡើងរួច អ្នកគួរព្រួយបារម្ភអំពីការដំឡើង ការផ្ទុកសម្រាប់កំណត់ហេតុ និងការបម្រុងទុក. នេះត្រូវបានធ្វើតាមរយៈ ConfigMap postgres-operator នៅក្នុង namespace ដែលអ្នកបានដំឡើង operator។ នៅពេលដែលឃ្លាំងត្រូវបានកំណត់រចនាសម្ព័ន្ធ អ្នកអាចដាក់ពង្រាយក្រុម PostgreSQL ដំបូងរបស់អ្នក។

ឧទាហរណ៍ ការដាក់ពង្រាយស្តង់ដាររបស់យើងមើលទៅដូចនេះ៖

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

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

វាគួរអោយយកចិត្តទុកដាក់ ផ្ទាំងគ្រប់គ្រងគេហទំព័រ - postgres-operator-ui. វាភ្ជាប់មកជាមួយប្រតិបត្តិករ និងអនុញ្ញាតឱ្យអ្នកបង្កើត និងលុបចង្កោម ក៏ដូចជាធ្វើការជាមួយការបម្រុងទុកដែលធ្វើឡើងដោយប្រតិបត្តិករ។

បញ្ជីនៃក្រុម PostgreSQL

ការគ្រប់គ្រងការបម្រុងទុក

លក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺការគាំទ្រ ក្រុម API. យន្តការនេះបង្កើតដោយស្វ័យប្រវត្តិ តួនាទីនៅក្នុង PostgreSQLដោយផ្អែកលើបញ្ជីលទ្ធផលនៃឈ្មោះអ្នកប្រើប្រាស់។ API បន្ទាប់មកអនុញ្ញាតឱ្យអ្នកត្រឡប់បញ្ជីអ្នកប្រើប្រាស់ដែលតួនាទីត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ។

បញ្ហា និងដំណោះស្រាយ

ទោះជាយ៉ាងណាក៏ដោយ ការប្រើប្រាស់ប្រតិបត្តិករនេះ បានបង្ហាញនូវចំណុចខ្វះខាតសំខាន់ៗមួយចំនួន៖

1. កង្វះនៃការគាំទ្រ nodeSelector;
2. អសមត្ថភាពក្នុងការបិទការបម្រុងទុក;
3. នៅពេលប្រើមុខងារបង្កើតមូលដ្ឋានទិន្នន័យ សិទ្ធិលំនាំដើមមិនលេចឡើងទេ។
4. ពេលខ្លះឯកសារបាត់ ឬហួសសម័យ។

ជាសំណាងល្អពួកគេជាច្រើនអាចត្រូវបានដោះស្រាយ។ ចូរចាប់ផ្តើមពីទីបញ្ចប់ - បញ្ហាជាមួយ ឯកសារ.

ភាគច្រើន អ្នកនឹងជួបប្រទះការពិតដែលថាវាមិនតែងតែច្បាស់អំពីរបៀបចុះឈ្មោះការបម្រុងទុក និងរបៀបភ្ជាប់ធុងបម្រុងទុកទៅ UI របស់ប្រតិបត្តិករនោះទេ។ ឯកសារនិយាយអំពីរឿងនេះក្នុងការឆ្លងកាត់ ប៉ុន្តែការពិពណ៌នាពិតប្រាកដគឺនៅក្នុង PR:

1. ត្រូវការដើម្បីធ្វើឱ្យអាថ៌កំបាំងមួយ;
2. បញ្ជូនវាទៅប្រតិបត្តិករជាប៉ារ៉ាម៉ែត្រ pod_environment_secret_name នៅក្នុង CRD ជាមួយនឹងការកំណត់ប្រតិបត្តិករ ឬនៅក្នុង ConfigMap (អាស្រ័យលើរបៀបដែលអ្នកសម្រេចចិត្តដំឡើងប្រតិបត្តិករ)។

ទោះយ៉ាងណាក៏ដោយដូចដែលវាប្រែថានេះមិនអាចទៅរួចទេនាពេលបច្ចុប្បន្ននេះ។ នោះហើយជាមូលហេតុដែលយើងប្រមូលបាន។ កំណែប្រតិបត្តិកររបស់អ្នក។ ជាមួយនឹងការអភិវឌ្ឍន៍ភាគីទីបីបន្ថែមមួយចំនួន។ សម្រាប់ព័ត៌មានបន្ថែមអំពីវា សូមមើលខាងក្រោម។

ប្រសិនបើអ្នកឆ្លងកាត់ប៉ារ៉ាម៉ែត្រសម្រាប់ការបម្រុងទុកទៅប្រតិបត្តិករ ពោលគឺ - wal_s3_bucket និងចូលប្រើគ្រាប់ចុចនៅក្នុង AWS S3 បន្ទាប់មកវា។ នឹងបម្រុងទុកអ្វីគ្រប់យ៉ាង៖ មិន​ត្រឹម​តែ​មាន​មូលដ្ឋាន​ក្នុង​ការ​ផលិត​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​មាន​ការ​រៀបចំ​ផង​ដែរ។ នេះមិនសមនឹងយើងទេ។

នៅក្នុងការពិពណ៌នាអំពីប៉ារ៉ាម៉ែត្រសម្រាប់ Spilo ដែលជាកញ្ចប់ Docker មូលដ្ឋានសម្រាប់ PgSQL នៅពេលប្រើប្រតិបត្តិករវាបានប្រែក្លាយ៖ អ្នកអាចឆ្លងកាត់ប៉ារ៉ាម៉ែត្រ WAL_S3_BUCKET ទទេ ដោយហេតុនេះបិទការបម្រុងទុក។ ជាងនេះទៅទៀត ខ្ញុំបានរកឃើញថា ដើម្បីភាពរីករាយដ៏អស្ចារ្យ PR រួចរាល់ដែល​យើង​បាន​ទទួល​យក​ភ្លាមៗ​ទៅ​ក្នុង​សម​របស់​យើង។ ឥឡូវនេះអ្នកគ្រាន់តែត្រូវការបន្ថែម enableWALArchiving: false ទៅកាន់ធនធានចង្កោម PostgreSQL ។

បាទ មានឱកាសដើម្បីធ្វើវាខុសគ្នាដោយដំណើរការប្រតិបត្តិករចំនួន 2៖ មួយសម្រាប់ដំណាក់កាល (ដោយគ្មានការបម្រុងទុក) និងទីពីរសម្រាប់ការផលិត។ ប៉ុន្តែយើងអាចធ្វើវាបានជាមួយមួយ។

យល់ព្រម យើងបានរៀនពីរបៀបផ្ទេរសិទ្ធិចូលប្រើមូលដ្ឋានទិន្នន័យសម្រាប់ S3 ហើយការបម្រុងទុកបានចាប់ផ្តើមចូលទៅក្នុងកន្លែងផ្ទុក។ តើធ្វើដូចម្តេចដើម្បីធ្វើឱ្យទំព័របម្រុងទុកដំណើរការនៅក្នុង Operator UI?

អ្នកនឹងត្រូវបន្ថែមអថេរ 3 ទៅ Operator UI៖

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

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

អត្ថប្រយោជន៍មួយទៀតគឺការងារជាមួយ Teams API និងឱកាសច្រើនសម្រាប់បង្កើតមូលដ្ឋានទិន្នន័យ និងតួនាទីដោយប្រើឧបករណ៍ប្រតិបត្តិករ។ ទោះយ៉ាងណាក៏ដោយបានបង្កើត តួនាទីមិនមានសិទ្ធិតាមលំនាំដើមទេ។. ដូច្នោះហើយ អ្នកប្រើប្រាស់ដែលមានសិទ្ធិអានមិនអាចអានតារាងថ្មីបានទេ។

ហេតុអ្វីបានជា​អញ្ចឹង? បើទោះបីជាការពិតដែលថានៅក្នុងកូដ គឺ ចាំបាច់ GRANTពួកវាមិនតែងតែប្រើទេ។ មានវិធី ២យ៉ាង៖ syncPreparedDatabases и syncDatabases។ នេះ syncPreparedDatabases - ទោះបីជាការពិតដែលថានៅក្នុងផ្នែក preparedDatabases គឺ មានលក្ខខណ្ឌមួយ។ defaultRoles и defaultUsers ដើម្បីបង្កើតតួនាទី សិទ្ធិលំនាំដើមមិនត្រូវបានអនុវត្តទេ។ យើងកំពុងស្ថិតក្នុងដំណើរការរៀបចំបំណះ ដើម្បីឱ្យសិទ្ធិទាំងនេះត្រូវបានអនុវត្តដោយស្វ័យប្រវត្តិ។

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

តើមានអ្វីកើតឡើង?

ដោយផ្អែកលើលទ្ធផលនៃការដោះស្រាយបញ្ហាខាងលើ យើងបានបំបែកក្រុមហ៊ុន Postgres Operator ពី Zalando ចូលទៅក្នុង ឃ្លាំងរបស់អ្នក។ដែលជាកន្លែងដែលវាត្រូវបានប្រមូលជាមួយនឹងបំណះដែលមានប្រយោជន៍បែបនេះ។ ហើយសម្រាប់ភាពងាយស្រួលកាន់តែច្រើន យើងក៏បានប្រមូលផងដែរ។ រូបថតរបស់ Docker.

បញ្ជីនៃ PRs ដែលត្រូវបានទទួលយកទៅក្នុងសម:

• ការកសាងរូបភាពទម្ងន់ស្រាលដែលមានសុវត្ថិភាពសម្រាប់ប្រតិបត្តិករនៅក្នុង Docker;
• បិទការបម្រុងទុក;
• ការធ្វើបច្ចុប្បន្នភាពកំណែធនធានសម្រាប់កំណែបច្ចុប្បន្ននៃ k8s;
• ការអនុវត្ត Node Affinity.

វានឹងល្អប្រសិនបើសហគមន៍គាំទ្រ PRs ទាំងនេះដើម្បីឱ្យពួកគេទទួលបានចរន្តជាមួយនឹងកំណែបន្ទាប់នៃប្រតិបត្តិករ (1.6) ។

ប្រាក់រង្វាន់! រឿងជោគជ័យនៃការផ្លាស់ប្តូរផលិតកម្ម

ប្រសិនបើអ្នកប្រើ Patroni ការផលិតបន្តផ្ទាល់អាចត្រូវបានផ្ទេរទៅប្រតិបត្តិករដោយមានពេលវេលារងចាំតិចតួចបំផុត។

Spilo អនុញ្ញាតឱ្យអ្នកបង្កើតបណ្តុំរង់ចាំតាមរយៈឧបករណ៍ផ្ទុក S3 ជាមួយ Wal-Eនៅពេលដែលកំណត់ហេតុប្រព័ន្ធគោលពីរ PgSQL ត្រូវបានរក្សាទុកជាលើកដំបូងនៅក្នុង S3 ហើយបន្ទាប់មកត្រូវបានបូមចេញដោយការចម្លង។ ប៉ុន្តែអ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកមាន មិនមាន ប្រើដោយ Wal-E លើហេដ្ឋារចនាសម្ព័ន្ធចាស់? ដំណោះស្រាយចំពោះបញ្ហានេះមានរួចហើយ វាត្រូវបានណែនាំ នៅលើមជ្ឈមណ្ឌល។

ការចម្លងតាមឡូជីខល PostgreSQL មកជួយសង្គ្រោះ។ ទោះជាយ៉ាងណាក៏ដោយ យើងនឹងមិនលម្អិតអំពីរបៀបបង្កើតការបោះពុម្ពផ្សាយ និងការជាវទេ ពីព្រោះ... ផែនការរបស់យើងគឺខុស។

ការពិតគឺថាមូលដ្ឋានទិន្នន័យមានតារាងផ្ទុកជាច្រើនដែលមានជួររាប់លាន ដែលលើសពីនេះទៅទៀតត្រូវបានបំពេញបន្ថែម និងលុបជាបន្តបន្ទាប់។ ការជាវសាមញ្ញ с copy_dataនៅពេលដែលការចម្លងថ្មីចម្លងមាតិកាទាំងអស់ពីមេ វាមិនអាចបន្តជាមួយមេបានទេ។ ការ​ចម្លង​មាតិកា​បាន​ធ្វើ​ការ​មួយ​សប្តាហ៍​ប៉ុន្តែ​មិន​ដែល​ចាប់​បាន​ជាមួយ​មេ​។ នៅទីបញ្ចប់វាបានជួយខ្ញុំដោះស្រាយបញ្ហា អត្ថបទ សហការីពី Avito៖ អ្នកអាចផ្ទេរទិន្នន័យដោយប្រើ pg_dump. ខ្ញុំនឹងរៀបរាប់អំពីកំណែរបស់យើង (កែប្រែបន្តិច) នៃក្បួនដោះស្រាយនេះ។

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

ពាក្យ​បញ្ជា​បន្ទាប់​ដែល​ពណ៌នា​អំពី​ដំណើរ​ការ​ផ្លាស់​ប្តូរ​នឹង​ប្រើ​សញ្ញាណ​ម៉ាស៊ីន​ដូច​ខាង​ក្រោម៖

1. មេ - ម៉ាស៊ីនមេប្រភព;
2. ចម្លង ៨.៦៩០២១ - ស្ទ្រីមចម្លងនៅលើផលិតកម្មចាស់;
3. ចម្លង ៨.៦៩០២១ - ការចម្លងឡូជីខលថ្មី។

ផែនការចំណាកស្រុក

1. បង្កើតការជាវនៅលើមេសម្រាប់តារាងទាំងអស់នៅក្នុងគ្រោងការណ៍ public មូលដ្ឋាន dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. បង្កើតរន្ធចម្លងនៅលើមេ៖

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. បញ្ឈប់ការចម្លងលើការចម្លងចាស់៖

psql -h replica1 -c "select pg_wal_replay_pause();"

4. ទទួលបានលេខប្រតិបត្តិការពីមេ៖

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. យកកន្លែងចាក់សំរាមចេញពីកន្លែងចម្លងចាស់។ យើង​នឹង​ធ្វើ​វា​ជា​ខ្សែ​ស្រឡាយ​ជា​ច្រើន ដែល​នឹង​ជួយ​ពន្លឿន​ដំណើរការ​នេះ៖

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. ផ្ទុកឯកសារចាក់សំរាមទៅម៉ាស៊ីនមេថ្មី៖

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. បន្ទាប់​ពី​ការ​ទាញ​យក​ការ​បោះចោល​នោះ អ្នក​អាច​ចាប់​ផ្តើ​ម​ការ​ចម្លង​នៅ​លើ​ការ​ចម្លង​ស្ទ្រីម​:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. តោះបង្កើតការជាវនៅលើការចម្លងឡូជីខលថ្មី៖

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. ចូរយើងទទួលបាន oid ការជាវ៖

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. ចូរនិយាយថាវាត្រូវបានទទួល oid=1000. តោះអនុវត្តលេខប្រតិបត្តិការទៅការជាវ៖

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. តោះចាប់ផ្តើមការចម្លង៖

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. ពិនិត្យមើលស្ថានភាពនៃការជាវ ការចម្លងគួរតែដំណើរការ៖

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. បន្ទាប់ពីការចម្លងត្រូវបានចាប់ផ្តើម ហើយមូលដ្ឋានទិន្នន័យត្រូវបានធ្វើសមកាលកម្ម អ្នកអាចប្តូរម្តងទៀត។

13. បន្ទាប់ពីបិទការចម្លង អ្នកត្រូវកែតម្រូវលំដាប់។ នេះត្រូវបានពិពណ៌នាយ៉ាងល្អ នៅក្នុងអត្ថបទនៅលើ wiki.postgresql.org.

សូមអរគុណចំពោះផែនការនេះ ការប្តូរបានធ្វើឡើងជាមួយនឹងការពន្យារពេលតិចតួចបំផុត។

សេចក្តីសន្និដ្ឋាន

ប្រតិបត្តិករ Kubernetes អនុញ្ញាតឱ្យអ្នកសម្រួលសកម្មភាពផ្សេងៗដោយកាត់បន្ថយពួកវាទៅការបង្កើតធនធាន K8s ។ ទោះជាយ៉ាងណាក៏ដោយដោយបានសំរេចបាននូវស្វ័យប្រវត្តិកម្មដ៏គួរឱ្យកត់សម្គាល់ជាមួយនឹងជំនួយរបស់ពួកគេ វាគឺមានតំលៃចងចាំថាវាក៏អាចនាំមកនូវចំនួននៃការ nuances ដែលមិនបានរំពឹងទុកដូច្នេះសូមជ្រើសរើសប្រតិបត្តិកររបស់អ្នកដោយប្រាជ្ញា។

ដោយបានពិចារណាលើប្រតិបត្តិករ Kubernetes ដ៏ពេញនិយមបំផុតចំនួនបីសម្រាប់ PostgreSQL យើងបានជ្រើសរើសគម្រោងពី Zalando ។ ហើយយើងត្រូវជម្នះការលំបាកមួយចំនួនជាមួយវា ប៉ុន្តែលទ្ធផលពិតជាពេញចិត្ត ដូច្នេះហើយយើងមានគម្រោងពង្រីកបទពិសោធន៍នេះទៅកាន់ការដំឡើង PgSQL ផ្សេងទៀត។ ប្រសិនបើអ្នកមានបទពិសោធន៍ប្រើប្រាស់ដំណោះស្រាយស្រដៀងគ្នានេះ យើងនឹងរីករាយក្នុងការមើលព័ត៌មានលម្អិតនៅក្នុងមតិយោបល់!

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «មូលដ្ឋានទិន្នន័យ និង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)»
• «Postgres ថ្ងៃអង្គារ #5: PostgreSQL និង Kubernetes ។ CI/CD ស្វ័យប្រវត្តិកម្មសាកល្បង»
• «រឿងមួយជាមួយប្រតិបត្តិករ Redis នៅក្នុង K8s និងការពិនិត្យឡើងវិញខ្នាតតូចអំពីឧបករណ៍ប្រើប្រាស់សម្រាប់ការវិភាគទិន្នន័យពីមូលដ្ឋានទិន្នន័យនេះ"។

ប្រភព: www.habr.com