ការបម្រុងទុកពី WAL-G ។ តើមានអ្វីនៅឆ្នាំ 2019? Andrey Borodin

ខ្ញុំស្នើឱ្យអ្នកអានប្រតិចារិកនៃរបាយការណ៍ពីដើមឆ្នាំ 2019 ដោយ Andrey Borodin "ការបម្រុងទុកជាមួយ WAL-G ។ តើមានអ្វីនៅក្នុងឆ្នាំ 2019?"

សួស្តី​អ្នក​ទាំងអស់គ្នា! ខ្ញុំឈ្មោះ Andrey Borodin ។ ខ្ញុំជាអ្នកអភិវឌ្ឍន៍នៅ Yandex ។ ខ្ញុំបានចាប់អារម្មណ៍លើ PostgreSQL តាំងពីឆ្នាំ 2016 បន្ទាប់ពីខ្ញុំបាននិយាយជាមួយអ្នកអភិវឌ្ឍន៍ ហើយពួកគេបាននិយាយថាអ្វីគ្រប់យ៉ាងគឺសាមញ្ញ - អ្នកយកកូដប្រភពហើយបង្កើតវា ហើយអ្វីៗនឹងដំណើរការ។ ហើយចាប់តាំងពីពេលនោះមកខ្ញុំមិនអាចបញ្ឈប់បានទេ - ខ្ញុំសរសេរគ្រប់ប្រភេទផ្សេងៗគ្នា។

រឿងមួយដែលខ្ញុំកំពុងធ្វើការគឺប្រព័ន្ធបម្រុងទុក។ WAL-G. ជាទូទៅនៅ Yandex យើងបានធ្វើការលើប្រព័ន្ធបម្រុងទុកនៅក្នុង PostgreSQL អស់រយៈពេលជាយូរមកហើយ។ ហើយអ្នកអាចរកឃើញនៅលើអ៊ីនធឺណិតនូវរបាយការណ៍ចំនួនប្រាំមួយអំពីវិធីដែលយើងបង្កើតប្រព័ន្ធបម្រុងទុក។ ហើយជារៀងរាល់ឆ្នាំពួកគេវិវឌ្ឍបន្តិចបន្តួច អភិវឌ្ឍតិចតួច និងកាន់តែអាចទុកចិត្តបាន។

ប៉ុន្តែថ្ងៃនេះ របាយការណ៍នេះមិនត្រឹមតែនិយាយអំពីអ្វីដែលយើងបានធ្វើប៉ុណ្ណោះទេ ប៉ុន្តែក៏និយាយអំពីរបៀបដែលវាសាមញ្ញ និងអ្វីដែលជា។ តើអ្នកប៉ុន្មាននាក់បានមើលរបាយការណ៍របស់ខ្ញុំអំពី WAL-G រួចហើយ? វាល្អដែលមនុស្សមួយចំនួនមិនបានមើលទេ ព្រោះខ្ញុំនឹងចាប់ផ្តើមជាមួយរឿងសាមញ្ញបំផុត។

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

ឧទាហរណ៍ អ្នកអាចមកឈររបស់យើង ហើយយកលេខកូដផ្សព្វផ្សាយសម្រាប់ Yandex Object Storage ដែលជា S3 ដែលត្រូវគ្នា។

បន្ទាប់មកបង្កើត Bucket ។ វាគ្រាន់តែជាធុងសម្រាប់ព័ត៌មានប៉ុណ្ណោះ។

បង្កើតអ្នកប្រើប្រាស់សេវាកម្ម។

បង្កើតសោចូលប្រើសម្រាប់អ្នកប្រើប្រាស់សេវា៖ aws-s3-key។

ទាញយកការចេញផ្សាយស្ថេរភាពចុងក្រោយបំផុតនៃ WAL-G ។

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

នៅពេលដែលអ្នកបានទាញយក WAL-G អ្នកអាចដំណើរការពាក្យបញ្ជា "បញ្ជីបម្រុងទុក" សាមញ្ញដោយឆ្លងកាត់អថេរបរិស្ថាន។ ហើយវានឹងភ្ជាប់ទៅ Object Storage ហើយប្រាប់អ្នកថាតើអ្នកមានការបម្រុងទុកអ្វីខ្លះ។ ជាដំបូង អ្នកមិនគួរមានការបម្រុងទុកទេ។ ចំនុចនៃស្លាយនេះគឺដើម្បីបង្ហាញថាអ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់។ នេះគឺជាពាក្យបញ្ជាកុងសូលដែលទទួលយកអថេរបរិស្ថាន និងប្រតិបត្តិពាក្យបញ្ជារង។

បន្ទាប់ពីនេះ អ្នកអាចធ្វើការបម្រុងទុកដំបូងរបស់អ្នក។ និយាយថា "backup-push" នៅក្នុង WAL-G ហើយបញ្ជាក់នៅក្នុង WAL-G នូវទីតាំង pgdata នៃ cluster របស់អ្នក។ ហើយភាគច្រើនទំនងជា PostgreSQL នឹងប្រាប់អ្នកថា ប្រសិនបើអ្នកមិនទាន់មានប្រព័ន្ធបម្រុងទុកទេ អ្នកត្រូវបើក ​​"របៀបបណ្ណសារ"។

នេះមានន័យថាអ្នកត្រូវចូលទៅកាន់ការកំណត់ ហើយបើក “archive_mode=on” ហើយបន្ថែម “archive_command” ដែលជាពាក្យបញ្ជារងនៅក្នុង WAL-G ផងដែរ។ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួន មនុស្សតែងតែប្រើស្គ្រីបរបារលើប្រធានបទនេះ ហើយរុំវាជុំវិញ WAL-G។ សូមកុំធ្វើបែបនេះ។ ប្រើមុខងារដែលមាននៅក្នុង WAL-G។ ប្រសិនបើអ្នកបាត់អ្វីមួយ សូមសរសេរទៅ GitHub. WAL-G សន្មត់ថាវាជាកម្មវិធីតែមួយគត់ដែលដំណើរការក្នុង archive_command ។

យើងប្រើ WAL-G ជាចម្បងដើម្បីបង្កើតចង្កោមដែលអាចរកបានខ្ពស់នៅក្នុងការគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ Yandex ។

ហើយជាធម្មតាវាត្រូវបានគេប្រើនៅក្នុង topology នៃ Master មួយ និងការចម្លងជាច្រើន។ ក្នុងពេលជាមួយគ្នានេះវាបង្កើតច្បាប់ចម្លងបម្រុងទុកនៅក្នុង Yandex Object Storage ។

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

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

និងស្ថានភាពស្រដៀងគ្នាមួយទៀត។ នេះគឺជាតម្រូវការក្នុងការចាប់ផ្តើម Master ចាស់ឡើងវិញ បន្ទាប់ពីប្តូរ Cluster Master ពីមជ្ឈមណ្ឌលទិន្នន័យដែលការតភ្ជាប់ត្រូវបានបាត់បង់។

• ជាលទ្ធផល នៅពេលបង្កើតតម្រូវការសម្រាប់ប្រព័ន្ធចម្លង យើងបានដឹងថា pg_basebackup មិនស័ក្តិសមសម្រាប់យើងទេ នៅពេលដំណើរការលើពពក។
• យើងចង់អាចបង្រួមទិន្នន័យរបស់យើង។ ប៉ុន្តែប្រព័ន្ធបម្រុងទុកស្ទើរតែទាំងអស់ក្រៅពីអ្វីដែលមាននៅក្នុងប្រអប់នឹងផ្តល់នូវការបង្ហាប់ទិន្នន័យ។
• យើង​ចង់​ធ្វើ​ឱ្យ​ស្រប​គ្នា​គ្រប់​យ៉ាង​ព្រោះ​អ្នក​ប្រើ​ក្នុង​ពពក​ទិញ​ស្នូល​ដំណើរការ​មួយ​ចំនួន​ធំ។ ប៉ុន្តែប្រសិនបើយើងមិនមានភាពស្របគ្នានៅក្នុងប្រតិបត្តិការមួយចំនួននោះ ស្នូលមួយចំនួនធំនឹងក្លាយទៅជាគ្មានប្រយោជន៍។
• យើងត្រូវការការអ៊ិនគ្រីប ព្រោះជាញឹកញាប់ទិន្នន័យមិនមែនជារបស់យើង ហើយមិនអាចរក្សាទុកជាអត្ថបទច្បាស់លាស់បានទេ។ ដោយវិធីនេះ ការរួមចំណែករបស់យើងចំពោះ WAL-G បានចាប់ផ្តើមជាមួយនឹងការអ៊ិនគ្រីប។ យើងបានបញ្ចប់ការអ៊ិនគ្រីបនៅក្នុង WAL-G បន្ទាប់ពីនោះយើងត្រូវបានគេសួរថា "ប្រហែលជាពួកយើងនឹងអភិវឌ្ឍគម្រោង?" ហើយចាប់តាំងពីពេលនោះមកខ្ញុំបានធ្វើការជាមួយ WAL-G អស់រយៈពេលជាងមួយឆ្នាំ។
• យើងក៏ត្រូវការការទប់ស្កាត់ធនធានផងដែរ ពីព្រោះយូរៗទៅដោយប្រើពពក យើងបានរកឃើញថា ពេលខ្លះមនុស្សមានទំនិញសំខាន់ៗនៅពេលយប់ ហើយបន្ទុកនេះមិនអាចរំខានបានទេ។ នោះហើយជាមូលហេតុដែលយើងបន្ថែមការទប់ស្កាត់ធនធាន។
• ក៏ដូចជាការចុះបញ្ជី និងការគ្រប់គ្រង។
• និងការផ្ទៀងផ្ទាត់។

យើងបានមើលឧបករណ៍ផ្សេងៗជាច្រើន។ ជាសំណាងល្អ យើងមានជម្រើសដ៏ធំនៅក្នុង PostgreSQL ។ ហើយគ្រប់ទីកន្លែងដែលយើងកំពុងបាត់អ្វីមួយ មុខងារតូចមួយ មុខងារតូចមួយ។

ហើយដោយបានពិនិត្យមើលប្រព័ន្ធដែលមានស្រាប់ យើងបានសន្និដ្ឋានថាយើងនឹងអភិវឌ្ឍ WAL-G ។ វាជាគម្រោងថ្មីមួយនៅពេលនោះ។ វាងាយស្រួលណាស់ក្នុងការជះឥទ្ធិពលដល់ការអភិវឌ្ឍន៍ឆ្ពោះទៅរកហេដ្ឋារចនាសម្ព័ន្ធពពកនៃប្រព័ន្ធបម្រុងទុក។

មនោគមវិជ្ជាចម្បងដែលយើងប្រកាន់ខ្ជាប់គឺថា WAL-G គួរតែមានលក្ខណៈសាមញ្ញដូច balalaika ដែរ។

WAL-G មាន 4 ពាក្យបញ្ជា។ នេះ៖

WAL-PUSH - ទុកក្នុងប័ណ្ណសារ។

WAL-FETCH - ទទួលបានរាង។

BACKUP-PUSH - ធ្វើការបម្រុងទុក។

BACKUP-FETCH - ទទួលបានការបម្រុងទុកពីប្រព័ន្ធបម្រុងទុក។

តាមពិត WAL-G ក៏មានការគ្រប់គ្រងការបម្រុងទុកទាំងនេះដែរ ពោលគឺការចុះបញ្ជី និងការលុបកំណត់ត្រា និងការបម្រុងទុកក្នុងប្រវត្តិដែលលែងត្រូវការនៅពេលនេះ។

មុខងារសំខាន់មួយសម្រាប់យើងគឺមុខងារនៃការបង្កើតច្បាប់ចម្លងដីសណ្ត។

ច្បាប់ចម្លង Delta មានន័យថាយើងមិនបង្កើតការបម្រុងទុកពេញលេញនៃចង្កោមទាំងមូលទេ ប៉ុន្តែមានតែទំព័រដែលបានផ្លាស់ប្តូរនៃឯកសារដែលបានផ្លាស់ប្តូរនៅក្នុងចង្កោមប៉ុណ្ណោះ។ វាហាក់បីដូចជាមុខងារនេះគឺស្រដៀងទៅនឹងសមត្ថភាពក្នុងការសង្គ្រោះដោយប្រើ WAL ។ ប៉ុន្តែ​យើង​អាច​ដាក់​ការ​បម្រុង​ទុក​ខ្សែ​មួយ​ខ្សែ WAL ស្រប​គ្នា។ ដូច្នោះហើយ នៅពេលដែលយើងមានការបម្រុងទុកជាមូលដ្ឋានដែលបានធ្វើឡើងនៅថ្ងៃសៅរ៍ ការបម្រុងទុកតំបន់ដីសណ្តជារៀងរាល់ថ្ងៃ ហើយនៅថ្ងៃព្រហស្បតិ៍យើងបរាជ័យ នោះយើងត្រូវធ្វើការបម្រុងទុក 4 delta និង 10 ម៉ោងនៃ WAL ។ វានឹងចំណាយពេលដូចគ្នា ព្រោះការបម្រុងទុកដីសណ្តរវិលស្របគ្នា។

LSN-based deltas - នេះមានន័យថានៅពេលបង្កើតការបម្រុងទុក យើងនឹងត្រូវការបញ្ចូលគ្នានូវទំព័រនីមួយៗ ហើយពិនិត្យមើល LSN របស់វាជាមួយនឹង LSN នៃការបម្រុងទុកពីមុន ដើម្បីយល់ថាវាបានផ្លាស់ប្តូរ។ ទំព័រណាមួយដែលអាចផ្ទុកទិន្នន័យដែលបានផ្លាស់ប្តូរគួរតែមានវត្តមាននៅក្នុងការបម្រុងទុកតំបន់ដីសណ្ត។

ដូចដែលខ្ញុំបាននិយាយ ការយកចិត្តទុកដាក់ជាច្រើនត្រូវបានយកចិត្តទុកដាក់ចំពោះភាពស្របគ្នា។

ប៉ុន្តែ API បណ្ណសារនៅក្នុង PostgreSQL គឺស្រប។ PostgreSQL រក្សាទុកឯកសារ WAL មួយ ហើយនៅពេលស្ដារវាស្នើសុំឯកសារ WAL មួយ។ ប៉ុន្តែនៅពេលដែលមូលដ្ឋានទិន្នន័យស្នើសុំឯកសារ WAL មួយដោយប្រើពាក្យបញ្ជា "WAL-FETCH" យើងហៅពាក្យបញ្ជា "WAL-PREFETCH" ដែលរៀបចំឯកសារ 8 បន្ទាប់ដើម្បីទាញយកទិន្នន័យពីឃ្លាំងវត្ថុស្របគ្នា។

ហើយនៅពេលដែលមូលដ្ឋានទិន្នន័យសុំឱ្យយើងរក្សាទុកឯកសារមួយ យើងពិនិត្យមើល archive_status ហើយមើលថាតើមានឯកសារ WAL ផ្សេងទៀតដែរឬទេ។ ហើយយើងក៏កំពុងព្យាយាមទាញយក WAL ស្របគ្នា។ នេះផ្តល់នូវការទទួលបានប្រសិទ្ធភាពគួរឱ្យកត់សម្គាល់ និងកាត់បន្ថយចម្ងាយយ៉ាងច្រើននៅក្នុងចំនួន WALs ដែលមិនបានរក្សាទុក។ អ្នកបង្កើតប្រព័ន្ធបម្រុងទុកជាច្រើនជឿថា នេះគឺជាប្រព័ន្ធប្រថុយប្រថាន ពីព្រោះយើងពឹងផ្អែកលើចំណេះដឹងរបស់យើងអំពីផ្នែកខាងក្នុងនៃកូដដែលមិនមែនជា PostgreSQL API ។ PostgreSQL មិនធានានូវវត្តមានរបស់ archive_status folder សម្រាប់ពួកយើងទេ និងមិនធានានូវ semantics វត្តមាននៃសញ្ញាត្រៀមខ្លួនសម្រាប់ឯកសារ WAL នៅទីនោះ។ យ៉ាង​ណា​ក៏​ដោយ យើង​កំពុង​សិក្សា​កូដ​ប្រភព យើង​ឃើញ​ថា​វា​ដូច្នេះ ហើយ​យើង​កំពុង​ព្យាយាម​ទាញ​យក​វា​។ ហើយយើងគ្រប់គ្រងទិសដៅដែល PostgreSQL កំពុងអភិវឌ្ឍ ប្រសិនបើភ្លាមៗយន្តការនេះត្រូវបានខូច យើងនឹងឈប់ប្រើវា។

នៅក្នុងទម្រង់ដ៏បរិសុទ្ធរបស់វា ដីសណ្ត WAL ដែលមានមូលដ្ឋានលើ LSN តម្រូវឱ្យអានឯកសារចង្កោមណាមួយដែលពេលវេលានៅក្នុងប្រព័ន្ធឯកសារបានផ្លាស់ប្តូរចាប់តាំងពីការបម្រុងទុកពីមុនមក។ យើង​រស់​នៅ​ជាមួយ​នេះ​អស់​រយៈពេល​ជិត​មួយ​ឆ្នាំ។ ហើយនៅទីបញ្ចប់យើងបានឈានដល់ការសន្និដ្ឋានថាយើងមាន WAL deltas ។

នេះមានន័យថា រាល់ពេលដែលយើងរក្សាទុក WAL នៅលើ Master យើងមិនត្រឹមតែបង្ហាប់វា អ៊ិនគ្រីបវា និងផ្ញើវាទៅបណ្តាញប៉ុណ្ណោះទេ ប៉ុន្តែយើងក៏អានវាក្នុងពេលតែមួយផងដែរ។ យើងវិភាគនិងអានកំណត់ត្រានៅក្នុងវា។ យើងយល់ថាប្លុកណាមួយដែលបានផ្លាស់ប្តូរ និងប្រមូលឯកសារ delta

ឯកសារ delta ពិពណ៌នាអំពីជួរជាក់លាក់នៃឯកសារ WAL ពិពណ៌នាអំពីព័ត៌មានអំពីប្លុកដែលត្រូវបានផ្លាស់ប្តូរនៅក្នុងជួរនៃ WAL នេះ។ ហើយបន្ទាប់មកឯកសារ delta ទាំងនេះក៏ត្រូវបានទុកក្នុងប័ណ្ណសារផងដែរ។

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

ជាលទ្ធផល យើងត្រូវដាក់បំណែកដែលមិនអាចយល់បានទៅក្នុងឯកសារ _delta_partial ។ ជាលទ្ធផល នៅពេលដែលយើងត្រលប់ទៅអតីតកាលវិញ យើងនឹងបិទភ្ជាប់បំណែកនៃកំណត់ត្រា WAL ទៅជាមួយ បន្ទាប់មកយើងនឹងញែកវា និងយល់ពីអ្វីដែលបានផ្លាស់ប្តូរនៅក្នុងវា។

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

ជាលទ្ធផល ការរងទុក្ខទាំងអស់របស់យើងបាននាំឱ្យមានការពិតថា យើងបានបើកប្រភពបើកចំហបណ្ណាល័យវិភាគ WAL-G ។ តាម​ខ្ញុំ​ដឹង​អត់​មាន​អ្នក​ណា​ប្រើ​ទេ តែ​បើ​អ្នក​ណា​ចង់​សរសេរ​ប្រើ​វា​ជា​សាធារណៈ។ (តំណភ្ជាប់ដែលបានធ្វើបច្ចុប្បន្នភាព https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

នៅលើក្រាហ្វអ្វីគ្រប់យ៉ាងមើលទៅសាមញ្ញជាង។ នេះ​ជា​ការ​ទាញ​យក​ពី​ក្រុម​ពិត​មួយ​របស់​យើង។ យើងមាន LSN-based ដែលបង្កើតឡើងក្នុងមួយថ្ងៃ។ ហើយយើងឃើញថាការបម្រុងទុកតំបន់ដីសណ្តដែលមានមូលដ្ឋានលើ LSN កំពុងដំណើរការពីម៉ោងបីព្រឹកដល់ម៉ោងប្រាំព្រឹក។ នេះគឺជាបន្ទុកនៅក្នុងចំនួនស្នូលនៃខួរក្បាល។ WAL-delta បាននាំពួកយើងប្រហែល 20 នាទីនៅទីនេះ។ នោះគឺវាកាន់តែលឿនគួរឱ្យកត់សម្គាល់ ប៉ុន្តែនៅពេលជាមួយគ្នានោះមានការផ្លាស់ប្តូរកាន់តែខ្លាំងនៅលើបណ្តាញ។

ដោយសារយើងមានព័ត៌មានអំពីប្លុកណាដែលបានផ្លាស់ប្តូរ និងនៅពេលណានៅក្នុងប្រវត្តិសាស្រ្តនៃមូលដ្ឋានទិន្នន័យ យើងបានទៅបន្ថែមទៀត ហើយបានសម្រេចចិត្តបញ្ចូលមុខងារ - ផ្នែកបន្ថែម PostgreSQL ដែលហៅថា "pg_prefaulter"

នេះមានន័យថានៅពេលដែលមូលដ្ឋានឈរដោយប្រតិបត្តិពាក្យបញ្ជាស្ដារ វាប្រាប់ WAL-G ឱ្យទៅយកឯកសារ WAL បន្ទាប់។ យើងយល់អំពីទិន្នន័យដែលរារាំងដំណើរការស្តារ WAL នឹងចូលប្រើក្នុងពេលអនាគតដ៏ខ្លី ហើយចាប់ផ្តើមប្រតិបត្តិការអាននៅលើប្លុកទាំងនេះ។ នេះត្រូវបានធ្វើដើម្បីបង្កើនប្រសិទ្ធភាពនៃឧបករណ៍បញ្ជា SSD ។ ដោយសារតែវិល WAL នឹងទៅដល់ទំព័រដែលត្រូវផ្លាស់ប្តូរ។ ទំព័រនេះស្ថិតនៅលើថាស ហើយមិននៅក្នុងឃ្លាំងសម្ងាត់ទំព័រទេ។ ហើយគាត់នឹងរង់ចាំក្នុងពេលដំណាលគ្នាសម្រាប់ទំព័រនេះមកដល់។ ប៉ុន្តែនៅក្បែរនោះគឺ WAL-G ដែលដឹងថាក្នុងប៉ុន្មានរយមេកាបៃនៃ WAL ខាងមុខនេះ យើងនឹងត្រូវការទំព័រជាក់លាក់ ហើយនៅពេលជាមួយគ្នានេះចាប់ផ្តើមធ្វើឱ្យពួកវាឡើងកំដៅ។ ចាប់ផ្តើមការចូលប្រើថាសច្រើន ដូច្នេះពួកវាត្រូវបានប្រតិបត្តិស្របគ្នា។ វាដំណើរការបានយ៉ាងល្អនៅលើដ្រាយ SSD ប៉ុន្តែជាអកុសល វាពិតជាមិនអាចអនុវត្តបានសម្រាប់ដ្រាយវ៍រឹងនោះទេ ពីព្រោះយើងគ្រាន់តែជ្រៀតជ្រែកជាមួយវាជាមួយនឹងការជម្រុញរបស់យើង។

នេះគឺជាអ្វីដែលមាននៅក្នុងកូដឥឡូវនេះ។

មានលក្ខណៈពិសេសដែលយើងចង់បន្ថែម។

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

ចំនុចនោះគឺថានៅពេលដែលយើងស្តារចង្កោមឡើងវិញ យើងកាត់បន្ថយចំនួនរឿងដែលយើងត្រូវរមៀលឡើងជាបន្តបន្ទាប់។ នោះគឺបរិមាណ WAL ដែល PostgreSQL វិលគួរតែត្រូវបានកាត់បន្ថយ ព្រោះវាត្រូវការពេលវេលាដ៏សំខាន់។

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

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

ប៉ុន្តែនេះនៅតែជាគំនិតដែលកំពុងត្រូវបានពិភាក្សាយ៉ាងសកម្មនៅក្នុងខ្លួនយើង ប៉ុន្តែវាមិនទាន់ឈានដល់កូដនៅឡើយ។

យើងចង់បង្កើតមុខងារមួយបន្ថែមទៀតនៅក្នុង WAL-G។ យើងចង់ធ្វើឱ្យវាអាចពង្រីកបាន ពីព្រោះយើងត្រូវគាំទ្រមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នា ហើយចង់មានលទ្ធភាពទាក់ទងការគ្រប់គ្រងការបម្រុងទុកតាមរបៀបដូចគ្នា។ ប៉ុន្តែបញ្ហាគឺថា MySQL APIs មានភាពខុសគ្នាខ្លាំង។ នៅក្នុង MySQL PITR មិនមែនផ្អែកលើកំណត់ហេតុ WAL ទេ ប៉ុន្តែនៅលើ binlog ។ ហើយយើងមិនមានប្រព័ន្ធបណ្ណសារនៅក្នុង MySQL ដែលនឹងប្រាប់ប្រព័ន្ធខាងក្រៅមួយចំនួនថា binlog នេះត្រូវបានបញ្ចប់ ហើយចាំបាច់ត្រូវទុកក្នុងប័ណ្ណសារ។ យើងត្រូវឈរនៅកន្លែងណាមួយក្នុង cron ជាមួយមូលដ្ឋានទិន្នន័យ ហើយពិនិត្យមើលថាតើមានអ្វីមួយរួចរាល់ហើយឬនៅ?

ហើយតាមរបៀបដូចគ្នា កំឡុងពេលស្ដារ MySQL មិនមានពាក្យបញ្ជាស្ដារដែលអាចប្រាប់ប្រព័ន្ធថាខ្ញុំត្រូវការឯកសារបែបនេះទេ។ មុនពេលអ្នកចាប់ផ្តើមបង្កើតចង្កោមរបស់អ្នកឡើងវិញ អ្នកត្រូវដឹងថាតើឯកសារអ្វីខ្លះដែលអ្នកនឹងត្រូវការ។ អ្នក​ផ្ទាល់​ត្រូវ​ទាយ​ថា​តើ​ឯកសារ​អ្វី​ដែល​អ្នក​នឹង​ត្រូវ​ការ។ ប៉ុន្តែ​បញ្ហា​ទាំង​នេះ​អាច​នឹង​ត្រូវ​បាន​ជៀស​វាង​ដោយ​របៀប​ណា​មួយ​។ (បញ្ជាក់៖ MySQL ត្រូវបានគាំទ្ររួចហើយ)

នៅក្នុងរបាយការណ៍ ខ្ញុំក៏ចង់និយាយអំពីករណីទាំងនោះនៅពេលដែល WAL-G មិនស័ក្តិសមសម្រាប់អ្នក។

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

ជារឿយៗខ្ញុំឃើញមនុស្សព្យាយាមដំណើរការទាំង WAL-G និង WAL-E ក្នុងពេលតែមួយ។ យើងគាំទ្រភាពឆបគ្នាថយក្រោយក្នុងន័យថា WAL-G អាចស្ដារឯកសារពី WAL-E និងអាចស្ដារការបម្រុងទុកដែលបានធ្វើឡើងនៅក្នុង WAL-E ។ ប៉ុន្តែដោយសារប្រព័ន្ធទាំងពីរនេះប្រើ Wal-push ស្របគ្នា ពួកគេចាប់ផ្តើមលួចឯកសារពីគ្នាទៅវិញទៅមក។ ប្រសិនបើយើងជួសជុលវានៅក្នុង WAL-G វានឹងនៅតែស្ថិតក្នុង WAL-E។ នៅក្នុង WAL-E វាមើលទៅលើ archive-status ឃើញឯកសារដែលបានបញ្ចប់ និងរក្សាទុកពួកវា ខណៈដែលប្រព័ន្ធផ្សេងទៀតនឹងមិនដឹងថាមានឯកសារ WAL នេះទេ ព្រោះ PostgreSQL នឹងមិនព្យាយាមរក្សាទុកវាជាលើកទីពីរទេ។

តើយើងនឹងជួសជុលអ្វីនៅទីនេះនៅខាង WAL-G? យើងនឹងមិនជូនដំណឹងដល់ PostgreSQL ថាឯកសារនេះត្រូវបានផ្ទេរស្របគ្នានោះទេ ហើយនៅពេលដែល PostgreSQL ស្នើសុំឱ្យយើងរក្សាទុកវា យើងនឹងដឹងរួចហើយថាឯកសារបែបនេះជាមួយនឹងពេលវេលារបៀបនេះ ហើយជាមួយ md5 នេះត្រូវបានទុកក្នុងប័ណ្ណសាររួចហើយ ហើយយើងនឹងនិយាយយ៉ាងសាមញ្ញថា PostgreSQL - យល់ព្រម អ្វីគ្រប់យ៉ាងគឺរួចរាល់ដោយមិនចាំបាច់ធ្វើអ្វីទាំងអស់។

ប៉ុន្តែបញ្ហានេះមិនទំនងត្រូវបានជួសជុលនៅខាង WAL-E ទេ ដូច្នេះបច្ចុប្បន្នវាមិនអាចទៅរួចទេក្នុងការបង្កើតពាក្យបញ្ជាបណ្ណសារដែលនឹងរក្សាទុកឯកសារទាំង WAL-G និង WAL-E ។

លើសពីនេះទៀតមានករណីដែល WAL-G មិនសមនឹងអ្នកឥឡូវនេះ ប៉ុន្តែយើងពិតជានឹងជួសជុលវា។

ទីមួយ បច្ចុប្បន្នយើងមិនមានការផ្ទៀងផ្ទាត់ការបម្រុងទុកដែលភ្ជាប់មកជាមួយទេ។ យើង​មិន​មាន​ការ​ផ្ទៀង​ផ្ទាត់​ទាំង​កំឡុង​ពេល​បម្រុង​ទុក​ឬ​ការ​ងើប​ឡើង​វិញ​។ ជាការពិតណាស់នេះត្រូវបានអនុវត្តនៅក្នុងពពក។ ប៉ុន្តែ​វា​ត្រូវ​បាន​អនុវត្ត​ដោយ​ការ​ពិនិត្យ​ជា​មុន​ដោយ​គ្រាន់​តែ​ស្ដារ​ចង្កោម​ឡើង​វិញ​។ ខ្ញុំចង់ផ្តល់មុខងារនេះដល់អ្នកប្រើប្រាស់។ ប៉ុន្តែតាមរយៈការផ្ទៀងផ្ទាត់ ខ្ញុំសន្មត់ថានៅក្នុង WAL-G វានឹងអាចស្តារចង្កោមឡើងវិញ ហើយចាប់ផ្តើមវា ហើយដំណើរការការធ្វើតេស្តផ្សែង៖ pg_dumpall ទៅ /dev/null និងការផ្ទៀងផ្ទាត់សន្ទស្សន៍ amcheck ។

បច្ចុប្បន្ននៅក្នុង WAL-G មិនមានវិធីដើម្បីពន្យារពេលការបម្រុងទុកមួយពី WAL ទេ។ នោះគឺយើងគាំទ្របង្អួចមួយចំនួន។ ឧទាហរណ៍ រក្សាទុករយៈពេលប្រាំពីរថ្ងៃចុងក្រោយ រក្សាទុកការបម្រុងទុកដប់ចុងក្រោយ រក្សាទុកការបម្រុងទុកពេញលេញចំនួនបីចុងក្រោយ។ ជាញឹក​ញាប់​មនុស្ស​មក​និយាយ​ថា​៖ «យើង​ត្រូវ​ការ​ការ​បម្រុង​ទុក​នូវ​អ្វី​ដែល​បាន​កើត​ឡើង​នៅ​ថ្ងៃ​ចូល​ឆ្នាំ​ថ្មី ហើយ​យើង​ចង់​រក្សា​វា​ជា​រៀង​រហូត»។ WAL-G មិនទាន់ដឹងពីរបៀបធ្វើបែបនេះទេ។ (ចំណាំ - វាត្រូវបានជួសជុលរួចហើយ https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

ហើយ​យើង​មិន​មាន​ការ​ពិនិត្យ​ទំព័រ​និង​ការ​ត្រួតពិនិត្យ​សុចរិតភាព​សម្រាប់​ផ្នែក​រាង​ទាំងអស់​នៅ​ពេល​ដែល​មាន​សុពលភាព​ PITR ។

ពីទាំងអស់នេះខ្ញុំបានដាក់បញ្ចូលគ្នានូវគម្រោងសម្រាប់ Google Summer of Code ។ ប្រសិនបើអ្នកស្គាល់សិស្សឆ្លាតដែលចង់សរសេរអ្វីមួយនៅក្នុង Go ហើយទទួលបានប្រាក់រាប់ពាន់ដុល្លារពីក្រុមហ៊ុនមួយដែលមានអក្សរ "G" សូមណែនាំគម្រោងរបស់យើងឱ្យពួកគេ។ ខ្ញុំនឹងដើរតួជាអ្នកណែនាំសម្រាប់គម្រោងនេះ ពួកគេអាចធ្វើបាន។ បើគ្មានសិស្សទេ ខ្ញុំនឹងយកវា ហើយធ្វើវាដោយខ្លួនឯងនៅរដូវក្តៅ។

ហើយ​យើង​មាន​បញ្ហា​តូចៗ​ជា​ច្រើន​ទៀត​ដែល​យើង​កំពុង​ធ្វើ​ជា​បណ្តើរៗ។ ហើយ​រឿង​ចម្លែក​ៗ​មួយ​ចំនួន​កើត​ឡើង។

ឧទាហរណ៍ ប្រសិនបើអ្នកផ្តល់ឱ្យ WAL-G ការបម្រុងទុកទទេ វានឹងធ្លាក់ចុះយ៉ាងសាមញ្ញ។ ឧទាហរណ៍ ប្រសិនបើអ្នកប្រាប់គាត់ថាគាត់ត្រូវការបម្រុងទុកថតទទេ។ ឯកសារ pg_control នឹងមិនមាននៅទីនោះទេ។ ហើយគាត់នឹងគិតថាគាត់មិនយល់អ្វីមួយ។ តាមទ្រឹស្តី ក្នុងករណីនេះអ្នកត្រូវសរសេរសារធម្មតាទៅកាន់អ្នកប្រើប្រាស់ ដើម្បីពន្យល់គាត់ពីរបៀបប្រើប្រាស់ឧបករណ៍។ ប៉ុន្តែ​នេះ​មិន​មែន​ជា​លក្ខណៈ​នៃ​ការ​សរសេរ​កម្មវិធី​ទេ ប៉ុន្តែ​ជា​លក្ខណៈ​នៃ​ភាសា​ដែល​អាច​យល់​បាន​ល្អ។

យើងមិនដឹងពីរបៀបធ្វើការបម្រុងទុកក្រៅបណ្តាញទេ។ ប្រសិនបើមូលដ្ឋានទិន្នន័យកុហក យើងមិនអាចបម្រុងទុកវាបានទេ។ ប៉ុន្តែអ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់នៅទីនេះ។ យើងហៅការបម្រុងទុកដោយ LSN នៅពេលវាចាប់ផ្តើម។ LSN នៃមូលដ្ឋានមូលដ្ឋានត្រូវតែត្រូវបានអានពីឯកសារត្រួតពិនិត្យ។ ហើយ​នេះ​ជា​លក្ខណៈ​ពិសេស​ដែល​មិន​អាច​ដឹង​បាន។ ប្រព័ន្ធបម្រុងទុកជាច្រើនអាចបម្រុងទុកមូលដ្ឋានទិន្នន័យមូលដ្ឋាន។ ហើយវាងាយស្រួល។

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

ហើយរឿងសំខាន់ដែលធ្វើឲ្យយើងព្រួយបារម្ភនោះគឺថា យើងចង់បានការធ្វើតេស្តរួមបញ្ចូល docker ឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន ដែលពិនិត្យមើលស្ថានភាពផ្សេងៗ។ ឥឡូវនេះ យើងគ្រាន់តែសាកល្បងសេណារីយ៉ូមូលដ្ឋានប៉ុណ្ណោះ។ នៅរាល់ commit ប៉ុន្តែយើងចង់ពិនិត្យមើល commit-by-commit នូវមុខងារទាំងអស់ដែលយើងគាំទ្រ។ ជាពិសេស ជាឧទាហរណ៍ យើងនឹងមានការគាំទ្រគ្រប់គ្រាន់សម្រាប់ PostgreSQL 9.4-9.5 ។ យើងគាំទ្រពួកគេ ពីព្រោះសហគមន៍គាំទ្រ PostgreSQL ប៉ុន្តែយើងមិនពិនិត្យមើលការប្តេជ្ញាចិត្តដោយ commit ដើម្បីប្រាកដថាអ្វីៗទាំងអស់មិនខូច។ ហើយវាហាក់ដូចជាខ្ញុំថា នេះគឺជាហានិភ័យធ្ងន់ធ្ងរជាង។

យើងមាន WAL-G ដែលដំណើរការលើចង្កោមជាងមួយពាន់នៅក្នុងការគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ Yandex ។ ហើយវាបម្រុងទុកទិន្នន័យរាប់រយ terabytes ជារៀងរាល់ថ្ងៃ។

យើងមាន TODO ជាច្រើននៅក្នុងកូដរបស់យើង។ ប្រសិនបើអ្នកចង់កម្មវិធី មក យើងកំពុងរង់ចាំការស្នើសុំទាញ យើងកំពុងរង់ចាំសំណួរ។

សំណួរ

រាត្រីសួស្តី! សូមអរគុណ! ការស្មានរបស់ខ្ញុំគឺថា ប្រសិនបើអ្នកកំពុងប្រើ WAL-delta អ្នកប្រហែលជាពឹងផ្អែកខ្លាំងលើការសរសេរពេញទំព័រ។ ហើយ​ប្រសិន​បើ​ដូច្នេះ​តើ​អ្នក​បាន​រត់​ការ​ធ្វើ​តេ​ស្ត​? អ្នកបានបង្ហាញក្រាហ្វដ៏ស្រស់ស្អាត។ តើ​វា​កាន់​តែ​ស្រស់​ស្អាត​ប៉ុណ្ណា​បើ FPW ត្រូវ​បាន​បិទ?

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

អរគុណសម្រាប់របាយការណ៍! ខ្ញុំមានសំណួរពីរ។ សំណួរទីមួយគឺ តើនឹងមានអ្វីកើតឡើងចំពោះតារាងតុ?

យើងកំពុងរង់ចាំការស្នើសុំទាញ។ មូលដ្ឋានទិន្នន័យរបស់យើងរស់នៅលើថាស SSD និង NMVE ហើយយើងពិតជាមិនត្រូវការមុខងារនេះទេ។ ខ្ញុំមិនទាន់ត្រៀមខ្លួនរួចរាល់ក្នុងការចំណាយពេលវេលាធ្ងន់ធ្ងរនៅពេលនេះដើម្បីធ្វើវាឱ្យបានល្អនោះទេ។ ខ្ញុំតស៊ូមតិដោយអស់ពីចិត្តថាយើងគាំទ្ររឿងនេះ។ មាន​មនុស្ស​ដែល​បាន​គាំទ្រ ប៉ុន្តែ​បាន​គាំទ្រ​វា​ក្នុង​របៀប​ដែល​សម​នឹង​ពួកគេ។ ពួក​គេ​បាន​ធ្វើ​ការ​ដង្ហែ ប៉ុន្តែ​ពួក​គេ​មិន​ធ្វើ​ការ​ស្នើ​សុំ​ទាញ​។ (បន្ថែមក្នុងកំណែ 0.2.13)

ហើយសំណួរទីពីរ។ អ្នកបាននិយាយនៅដើមដំបូងថា WAL-G សន្មត់ថាវាដំណើរការតែឯង ហើយមិនត្រូវការរុំទេ។ ខ្ញុំប្រើកន្សែងរុំខ្លួនឯង។ ហេតុអ្វីបានជាពួកគេមិនគួរប្រើ?

យើងចង់ឱ្យវាមានលក្ខណៈសាមញ្ញដូចបាឡាឡាកា។ នេះមានន័យថាអ្នកមិនត្រូវការអ្វីទាំងអស់ លើកលែងតែ balalaika ប៉ុណ្ណោះ។ យើងចង់ឱ្យប្រព័ន្ធមានភាពសាមញ្ញ។ ប្រសិនបើអ្នកមានមុខងារដែលអ្នកត្រូវធ្វើនៅក្នុងស្គ្រីប បន្ទាប់មកមកប្រាប់យើង - យើងនឹងធ្វើវានៅក្នុង Go ។

រាត្រីសួស្តី! អរគុណសម្រាប់របាយការណ៍! យើងមិនអាចយក WAL-G ដើម្បីធ្វើការជាមួយការឌិគ្រីប GPG បានទេ។ វាអ៊ិនគ្រីបជាធម្មតា ប៉ុន្តែមិនចង់ឌិគ្រីបទេ។ តើ​វា​ជា​អ្វី​ដែល​មិន​បាន​សម្រេច​សម្រាប់​យើង? ស្ថានភាពកំពុងធ្លាក់ទឹកចិត្ត។

បង្កើតបញ្ហានៅលើ GitHub ហើយតោះដោះស្រាយវា។

នោះគឺអ្នកមិនទាន់បានជួបរឿងនេះទេ?

មានលក្ខណៈពិសេសមួយនៃរបាយការណ៍កំហុសដែលនៅពេលដែល WAL-G មិនយល់ពីប្រភេទនៃឯកសារនោះវាសួរថា "ប្រហែលជាវាត្រូវបានអ៊ិនគ្រីប?" ប្រហែលជាបញ្ហាមិនមែនជាការអ៊ិនគ្រីបទាល់តែសោះ។ ខ្ញុំចង់កែលម្អការកត់ត្រាលើប្រធានបទនេះ។ គាត់ត្រូវតែបកស្រាយវា។ បច្ចុប្បន្ន យើងកំពុងធ្វើការលើប្រធានបទនេះ ក្នុងន័យថាយើងមិនចូលចិត្តរបៀបដែលប្រព័ន្ធសម្រាប់ការទទួលបានសោសាធារណៈ និងឯកជនត្រូវបានរៀបចំឡើង។ ដោយសារតែយើងហៅ GPG ខាងក្រៅដូច្នេះវាផ្តល់ឱ្យយើងនូវសោរបស់វា។ ហើយបន្ទាប់មកយើងយកសោទាំងនេះហើយផ្ទេរវាទៅ GPG ខាងក្នុង ដែលជា PGP បើក ដែលត្រូវបានចងក្រងសម្រាប់យើងនៅខាងក្នុង WAL-G ហើយនៅទីនោះយើងហៅថាការអ៊ិនគ្រីប។ ក្នុងន័យនេះ យើងចង់កែលម្អប្រព័ន្ធ និងចង់គាំទ្រការអ៊ិនគ្រីប Libsodium (បន្ថែមក្នុងកំណែ 0.2.15)។ ជាការពិតណាស់ ការឌិកូដគួរតែដំណើរការ ចូរយើងដោះស្រាយវា - អ្នកត្រូវការរោគសញ្ញាច្រើនជាងពាក្យពីរបី។ អ្នកអាចប្រមូលផ្តុំនៅក្នុងបន្ទប់របស់អ្នកនិយាយពេលខ្លះ ហើយមើលប្រព័ន្ធ។ (ការអ៊ិនគ្រីប PGP ដោយគ្មាន GPG ខាងក្រៅ - v0.2.9)

សួស្តី! អរគុណសម្រាប់របាយការណ៍! ខ្ញុំមានសំណួរពីរ។ ខ្ញុំមានបំណងប្រាថ្នាចម្លែកដើម្បីធ្វើ pg_basebackup និង WAL ចូលអ្នកផ្តល់សេវាពីរ ពោលគឺខ្ញុំចង់ធ្វើពពកមួយ និងមួយទៀត។ តើ​មាន​វិធី​ធ្វើ​បែប​នេះ​ទេ?

វាមិនមានទេឥឡូវនេះ ប៉ុន្តែវាជាគំនិតគួរឱ្យចាប់អារម្មណ៍មួយ។

ខ្ញុំគ្រាន់តែមិនទុកចិត្តអ្នកផ្តល់សេវាមួយទេ ខ្ញុំចង់មានដូចគ្នានៅក្នុងមួយផ្សេងទៀត នៅក្នុងករណី។

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

អូប្រាកដ។

ហើយបន្ទាប់មក នៅពេលដែលសិស្សមក Google Summer of Code យើងនឹងបន្ថែមវាទៅក្នុងគម្រោងដើម្បីឱ្យមានការងារបន្ថែមទៀតដើម្បីទទួលបានអត្ថប្រយោជន៍កាន់តែច្រើនពីពួកគេ។

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

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

គ្មាន SLA? តើវាត្រូវបានសរសេរសម្រាប់ពួកគេពីរបៀបដែលពួកគេអនុញ្ញាតឱ្យខ្លួនគេធ្វើទារុណកម្មឬ?

ចំនុចនោះគឺថាមនុស្សដែលមកសួរសំណួរនេះជាធម្មតាមានតុដេកផ្ទាល់ខ្លួន។ នោះគឺគ្មាននរណាម្នាក់មកពី Amazon ឬ Google Cloud ឬ Yandex Object Storage ទេ។

ប្រហែលជាសំណួរលែងសម្រាប់អ្នក?

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

នេះគឺជារឿងដែលកើតឡើងនៅក្នុង Mail cloud។

បើ​អាច​បង្កើត​ការ​បន្ត​ពូជ...

វាត្រូវបានបន្តពូជជាបន្តបន្ទាប់ ...

ប្រសិនបើមានការផលិតឡើងវិញ នោះខ្ញុំគិតថាយើងនឹងពិសោធន៍ជាមួយយុទ្ធសាស្រ្តព្យាយាមម្តងទៀត ហើយរកវិធីព្យាយាមម្តងទៀត និងយល់ពីអ្វីដែលពពកទាមទារពីយើង។ ប្រហែលជាវានឹងមានស្ថេរភាពសម្រាប់យើងនៅលើការតភ្ជាប់បីហើយនឹងមិនធ្វើឱ្យខូចការតភ្ជាប់ទេបន្ទាប់មកយើងនឹងឈានដល់បីយ៉ាងប្រុងប្រយ័ត្ន។ ដោយសារតែឥឡូវនេះ យើងទម្លាក់ការតភ្ជាប់យ៉ាងលឿន ឧ. ប្រសិនបើយើងចាប់ផ្តើមការងើបឡើងវិញជាមួយនឹង 16 threads បន្ទាប់មកបន្ទាប់ពីការព្យាយាមម្តងទៀតលើកដំបូងនឹងមាន 8 threads, 4 threads, 2 threads និងមួយ។ ហើយបន្ទាប់មកវានឹងទាញឯកសារចូលទៅក្នុងស្ទ្រីមមួយ។ ប្រសិនបើមានតម្លៃវេទមន្តមួយចំនួនដូចជា 7,5 ខ្សែស្រឡាយគឺល្អបំផុតសម្រាប់ការបូមនោះយើងនឹងរស់នៅលើពួកវាហើយព្យាយាមបង្កើតខ្សែស្រឡាយ 7,5 ផ្សេងទៀត។ នេះជាគំនិតមួយ។

អរគុណសម្រាប់របាយការណ៍! តើលំហូរការងារពេញលេញសម្រាប់ធ្វើការជាមួយ WAL-G មើលទៅដូចអ្វី? ឧទាហរណ៍ក្នុងករណីឆោតល្ងង់នៅពេលដែលគ្មានដីសណ្តឆ្លងកាត់ទំព័រ។ ហើយ​យើង​យក​និង​លុប​ការ​បម្រុង​ទុក​ដំបូង​បន្ទាប់​មក​ទុក​ក្នុង​ប័ណ្ណសារ​រហូត​ដល់​យើង​មាន​ពណ៌​ខៀវ​នៅ​លើ​មុខ​។ ត្រង់​នេះ​តាម​ខ្ញុំ​យល់​វា​មាន​ការ​បែក​បាក់។ នៅចំណុចខ្លះ អ្នកត្រូវធ្វើការបម្រុងទុក delta នៃទំព័រ ពោលគឺដំណើរការខាងក្រៅមួយចំនួនកំពុងជំរុញវា ឬតើវាកើតឡើងដោយរបៀបណា?

API បម្រុងទុក delta គឺសាមញ្ញណាស់។ មានលេខនៅទីនោះ - ជំហានដីសណ្តអតិបរមា នោះហើយជាអ្វីដែលគេហៅថា។ វាកំណត់លំនាំដើមទៅសូន្យ។ នេះមានន័យថារាល់ពេលដែលអ្នកធ្វើការ backup-push វាទាញយកការបម្រុងទុកពេញលេញ។ ប្រសិនបើអ្នកប្តូរវាទៅជាលេខវិជ្ជមានណាមួយ ឧទាហរណ៍ 3 បន្ទាប់មកពេលបន្ទាប់ដែលអ្នកធ្វើ backup-push វាមើលប្រវត្តិនៃការបម្រុងទុកពីមុន។ គាត់​មើល​ឃើញ​ថា​អ្នក​មិន​លើស​ខ្សែ​សង្វាក់​នៃ 3 deltas និង​បង្កើត​ជា delta មួយ​។

នោះគឺរាល់ពេលដែលយើងបើកដំណើរការ WAL-G វាព្យាយាមធ្វើការបម្រុងទុកពេញលេញ?

ទេ យើងដំណើរការ WAL-G ហើយវាព្យាយាមបង្កើតតំបន់ដីសណ្ត ប្រសិនបើគោលការណ៍របស់អ្នកអនុញ្ញាត។

និយាយដោយប្រយោល ប្រសិនបើអ្នកដំណើរការវាជាមួយសូន្យរាល់ពេល តើវានឹងមានឥរិយាបទដូច pg_basebackup ដែរឬទេ?

ទេ វានឹងនៅតែដំណើរការលឿនជាងមុន ព្រោះវាប្រើការបង្ហាប់ និងប៉ារ៉ាឡែល។ Pg_basebackup នឹងដាក់ shaft នៅក្បែរអ្នក។ WAL-G សន្មត់ថាអ្នកបានកំណត់រចនាសម្ព័ន្ធប័ណ្ណសារ។ ហើយវានឹងចេញការព្រមាន ប្រសិនបើវាមិនត្រូវបានកំណត់រចនាសម្ព័ន្ធ។

Pg_basebackup អាច​ដំណើរការ​បាន​ដោយ​មិន​ចាំ​បាច់​ចាំ​បាច់។

បាទ / ចាសបន្ទាប់មកពួកគេនឹងមានអាកប្បកិរិយាស្ទើរតែដូចគ្នា។ Pg_basebackup ចម្លងទៅប្រព័ន្ធឯកសារ។ និយាយអីញ្ចឹង យើងមានមុខងារថ្មីដែលខ្ញុំភ្លេចប្រាប់។ ឥឡូវនេះយើងអាចបម្រុងទុកទៅប្រព័ន្ធឯកសារពី pg_basebackup ។ ខ្ញុំ​មិន​ដឹង​ថា​ហេតុ​អ្វី​បាន​ជា​ត្រូវ​ការ​នេះ​ទេ ប៉ុន្តែ​វា​នៅ​ទីនោះ។

ឧទាហរណ៍នៅលើ CephFS ។ មិនមែនគ្រប់គ្នាចង់កំណត់រចនាសម្ព័ន្ធការផ្ទុកវត្ថុទេ។

បាទ/ចាស នោះប្រហែលជាមូលហេតុដែលពួកគេសួរសំណួរអំពីមុខងារនេះ ដើម្បីយើងអាចធ្វើវាបាន។ ហើយយើងបានធ្វើវា។

អរគុណសម្រាប់របាយការណ៍! មានតែសំណួរអំពីការចម្លងទៅប្រព័ន្ធឯកសារប៉ុណ្ណោះ។ ចេញពីប្រអប់ ឥឡូវនេះ តើអ្នកគាំទ្រការចម្លងទៅកន្លែងផ្ទុកពីចម្ងាយទេ ឧទាហរណ៍ ប្រសិនបើមានធ្នើខ្លះនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ ឬអ្វីផ្សេងទៀត?

ក្នុង​ការ​បង្កើត​នេះ​ជា​សំណួរ​ពិបាក។ បាទ/ចាស យើងគាំទ្រ ប៉ុន្តែមុខងារនេះមិនទាន់បានរួមបញ្ចូលនៅក្នុងការចេញផ្សាយណាមួយនៅឡើយទេ។ នោះ​គឺ​ការ​ចេញ​ផ្សាយ​មុន​ទាំង​អស់​គាំទ្រ​វា ប៉ុន្តែ​កំណែ​ចេញ​មិន​មាន។ មុខងារនេះត្រូវបានបន្ថែមនៅក្នុងកំណែ 0.2 ។ វាច្បាស់ជានឹងត្រូវបានចេញផ្សាយក្នុងពេលឆាប់ៗនេះ នៅពេលដែលយើងជួសជុលកំហុសដែលគេស្គាល់ទាំងអស់។ ប៉ុន្តែឥឡូវនេះ នេះអាចត្រូវបានធ្វើតែនៅក្នុងការចេញផ្សាយមុនប៉ុណ្ណោះ។ មានកំហុសពីរនៅក្នុងការចេញផ្សាយមុននេះ។ បញ្ហាជាមួយនឹងការស្តារ WAL-E យើងមិនបានជួសជុលវាទេ។ ហើយនៅក្នុងការចេញផ្សាយមុនចុងក្រោយបំផុត កំហុសអំពីការបម្រុងទុក delta ត្រូវបានបន្ថែម។ ដូច្នេះ យើងសូមណែនាំអ្នកគ្រប់គ្នាឱ្យប្រើកំណែដែលបានចេញផ្សាយ។ ដរាបណាមិនមានកំហុសទៀតទេនៅក្នុងការចេញផ្សាយមុន យើងអាចនិយាយបានថាយើងគាំទ្រ Google Cloud, S3-compatible things and file storage។

សួស្តី អរគុណសម្រាប់របាយការណ៍។ ដូចដែលខ្ញុំយល់ហើយ WAL-G មិនមែនជាប្រភេទនៃប្រព័ន្ធកណ្តាលដូចជា barmen ទេ? តើអ្នកមានគម្រោងផ្លាស់ទីក្នុងទិសដៅនេះទេ?

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

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

PS កំណែថ្មីត្រូវបានចេញផ្សាយ 0.2.15ដែលអ្នកអាចប្រើឯកសារកំណត់រចនាសម្ព័ន្ធ .walg.json ដែលមានទីតាំងនៅក្នុងថតផ្ទះ postgres តាមលំនាំដើម។ អ្នកអាចបោះបង់ចោលស្គ្រីប bash ។ ឧទាហរណ៍ .walg.json គឺនៅក្នុងបញ្ហានេះ https://github.com/wal-g/wal-g/issues/545

វីដេអូ:

ប្រភព: www.habr.com