របៀបដែលយើងប្រើការចម្លងខ្ជិលសម្រាប់ការសង្គ្រោះគ្រោះមហន្តរាយជាមួយ PostgreSQL

ការចម្លងមិនមែនជាការបម្រុងទុកទេ។ ឬ​មិន​មែន? នេះជារបៀបដែលយើងបានប្រើការចម្លងដែលបានពន្យាពេលដើម្បីសង្គ្រោះពីការលុបផ្លូវកាត់ដោយចៃដន្យ។

អ្នកជំនាញផ្នែកហេដ្ឋារចនាសម្ព័ន្ធ GitLab ទទួលខុសត្រូវចំពោះការងារ GitLab.com - ឧទាហរណ៍ GitLab ដ៏ធំបំផុតនៅក្នុងធម្មជាតិ។ ជាមួយនឹងអ្នកប្រើប្រាស់ 3 លាននាក់ និងគម្រោងជិត 7 លាននាក់ វាគឺជាគេហទំព័រ SaaS ប្រភពបើកចំហដ៏ធំបំផុតមួយដែលមានស្ថាបត្យកម្មពិសេស។ បើគ្មានប្រព័ន្ធមូលដ្ឋានទិន្នន័យ PostgreSQL ទេ ហេដ្ឋារចនាសម្ព័ន្ធ GitLab.com នឹងមិនទៅណាឆ្ងាយទេ ហើយតើយើងកំពុងធ្វើអ្វីដើម្បីធានាការអត់ឱនចំពោះកំហុសក្នុងករណីមានការបរាជ័យនៅពេលដែលទិន្នន័យអាចបាត់បង់។ វាមិនទំនងថាគ្រោះមហន្តរាយបែបនេះនឹងកើតឡើងនោះទេ ប៉ុន្តែយើងត្រូវបានរៀបចំយ៉ាងល្អ និងស្តុកទុកជាមួយនឹងយន្តការបម្រុងទុក និងការចម្លងផ្សេងៗ។

ការចម្លងមិនមែនជាមធ្យោបាយនៃការបម្រុងទុកមូលដ្ឋានទិន្នន័យ (មើល​ខាង​ក្រោម) ប៉ុន្តែឥឡូវនេះយើងនឹងឃើញពីរបៀបដើម្បីសង្គ្រោះទិន្នន័យដែលបានលុបដោយចៃដន្យយ៉ាងឆាប់រហ័សដោយប្រើការចម្លងខ្ជិល៖ បើក GitLab.com អ្នកប្រើ។ បានលុបផ្លូវកាត់ សម្រាប់គម្រោង gitlab-ce និងបាត់បង់ការតភ្ជាប់ជាមួយនឹងសំណើ និងកិច្ចការបញ្ចូលគ្នា។

ជាមួយនឹងការចម្លងដែលបានពន្យារពេល យើងបានទាញយកទិន្នន័យឡើងវិញក្នុងរយៈពេលត្រឹមតែ 1,5 ម៉ោង។ មើលថាតើវាកើតឡើងយ៉ាងដូចម្តេច។

ចង្អុលនៅក្នុងការងើបឡើងវិញពេលវេលាជាមួយ PostgreSQL

PostgreSQL មានមុខងារដែលភ្ជាប់មកជាមួយដែលស្ដារស្ថានភាពនៃមូលដ្ឋានទិន្នន័យទៅចំណុចជាក់លាក់មួយក្នុងពេលវេលា។ វា​ហៅថា ការងើបឡើងវិញតាមពេលវេលា (PITR) និងប្រើយន្តការដូចគ្នាដែលរក្សាការចម្លងឱ្យទាន់សម័យ៖ ចាប់ផ្តើមជាមួយនឹងរូបថតដែលអាចទុកចិត្តបាននៃចង្កោមមូលដ្ឋានទិន្នន័យទាំងមូល (ការបម្រុងទុកមូលដ្ឋាន) យើងអនុវត្តការផ្លាស់ប្តូររដ្ឋជាបន្តបន្ទាប់រហូតដល់ចំណុចជាក់លាក់មួយក្នុងពេលវេលា។

ដើម្បីប្រើមុខងារនេះសម្រាប់ការបម្រុងទុកត្រជាក់ យើងធ្វើការបម្រុងទុកមូលដ្ឋានទិន្នន័យជាប្រចាំ ហើយរក្សាទុកវានៅក្នុងបណ្ណសារ (បណ្ណសារ GitLab រស់នៅក្នុង ឃ្លាំងផ្ទុកពពក Google) យើងក៏ត្រួតពិនិត្យការផ្លាស់ប្តូរនៅក្នុងស្ថានភាពនៃមូលដ្ឋានទិន្នន័យដោយការរក្សាទុកកំណត់ហេតុសរសេរជាមុន (កំណត់ហេតុសរសេរជាមុន, WAL) ។ ហើយជាមួយនឹងអ្វីៗទាំងអស់នេះនៅនឹងកន្លែង យើងអាចធ្វើ PITR សម្រាប់ការសង្គ្រោះគ្រោះមហន្តរាយ៖ ចាប់ផ្តើមជាមួយរូបថតដែលបានថតមុនពេលបរាជ័យ ហើយអនុវត្តការផ្លាស់ប្តូរពីបណ្ណសារ WAL រហូតដល់ការបរាជ័យ។

តើការចម្លងពន្យាពេលគឺជាអ្វី?

Lazy replication គឺជាការអនុវត្តការផ្លាស់ប្តូរពី WAL ជាមួយនឹងការពន្យាពេល។ នោះគឺប្រតិបត្តិការបានកើតឡើងក្នុងរយៈពេលមួយម៉ោង Xប៉ុន្តែវានឹងបង្ហាញនៅក្នុងការចម្លងជាមួយនឹងការពន្យាពេល d ក្នុងរយៈពេល​មួយ​ម៉ោង X + d.

PostgreSQL មានវិធី 2 យ៉ាងក្នុងការដំឡើងការចម្លងមូលដ្ឋានទិន្នន័យរូបវន្តៈ ការសង្គ្រោះការបម្រុងទុក និងការចម្លងស្ទ្រីម។ ការស្ដារឡើងវិញពីប័ណ្ណសារដំណើរការយ៉ាងសំខាន់ដូចជា PITR ប៉ុន្តែបន្ត៖ យើងទាញយកការផ្លាស់ប្តូរជាបន្តបន្ទាប់ពីបណ្ណសារ WAL ហើយអនុវត្តពួកវាទៅការចម្លង។ ក ការចម្លងស្ទ្រីម ទាញយកស្ទ្រីម WAL ដោយផ្ទាល់ពីម៉ាស៊ីនមូលដ្ឋានទិន្នន័យខាងលើ។ យើងចូលចិត្តការស្ដារបណ្ណសារឡើងវិញ - វាកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រង និងមានដំណើរការធម្មតាដែលបន្តជាមួយនឹងក្រុមផលិតកម្ម។

របៀបរៀបចំការសង្គ្រោះដែលបានពន្យារពេលពីប័ណ្ណសារ

ជម្រើសនៃការស្តារឡើងវិញ បានពិពណ៌នានៅក្នុងឯកសារ recovery.conf។ ឧទាហរណ៍ៈ

standby_mode = 'on'
restore_command = '/usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-fetch -p 4 "%f" "%p"'
recovery_min_apply_delay = '8h'
recovery_target_timeline = 'latest'

ជាមួយនឹងប៉ារ៉ាម៉ែត្រទាំងនេះ យើងបានកំណត់រចនាសម្ព័ន្ធចម្លងដែលបានពន្យាពេលជាមួយនឹងការសង្គ្រោះការបម្រុងទុក។ នៅទីនេះវាត្រូវបានគេប្រើ វ៉ាល់-អ៊ី ដើម្បីទាញយកផ្នែក WAL (restore_command) ពីបណ្ណសារ ហើយការផ្លាស់ប្តូរនឹងត្រូវបានអនុវត្តបន្ទាប់ពីប្រាំបីម៉ោង (recovery_min_apply_delay) ការចម្លងនឹងមើលសម្រាប់ការផ្លាស់ប្តូរពេលវេលានៅក្នុងបណ្ណសារ ឧទាហរណ៍ដោយសារការខកខានរបស់ចង្កោម (recovery_target_timeline).

С recovery_min_apply_delay អ្នកអាចរៀបចំការចម្លងការផ្សាយឡើងវិញដោយមានការពន្យាពេល ប៉ុន្តែមានឧបសគ្គមួយចំនួននៅទីនេះ ដែលទាក់ទងនឹងរន្ធចម្លង មតិកែលម្អរង់ចាំក្តៅ។ល។ ប័ណ្ណសារ WAL អនុញ្ញាតឱ្យអ្នកជៀសវាងពួកគេ។

ប៉ារ៉ាម៉ែត្រ recovery_min_apply_delay បានបង្ហាញខ្លួនតែនៅក្នុង PostgreSQL 9.3 ប៉ុណ្ណោះ។ នៅក្នុងកំណែមុន សម្រាប់ការចម្លងដែលបានពន្យារពេល អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធបន្សំ មុខងារគ្រប់គ្រងការងើបឡើងវិញ (pg_xlog_replay_pause(), pg_xlog_replay_resume()) ឬសង្កត់ផ្នែក WAL នៅក្នុងប័ណ្ណសារសម្រាប់រយៈពេលនៃការពន្យារពេល។

តើ PostgreSQL ធ្វើបែបនេះដោយរបៀបណា?

វាគួរឱ្យចាប់អារម្មណ៍ក្នុងការមើលពីរបៀបដែល PostgreSQL អនុវត្តការងើបឡើងវិញខ្ជិល។ តោះមើល recoveryApplyDelay(XlogReaderState). វាត្រូវបានគេហៅថាមកពី រង្វិលជុំសំខាន់ សម្រាប់ធាតុនីមួយៗពី WAL ។

static bool
recoveryApplyDelay(XLogReaderState *record)
{
    uint8       xact_info;
    TimestampTz xtime;
    long        secs;
    int         microsecs;

    /* nothing to do if no delay configured */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* no delay is applied on a database not yet consistent */
    if (!reachedConsistency)
        return false;

    /*
     * Is it a COMMIT record?
     *
     * We deliberately choose not to delay aborts since they have no effect on
     * MVCC. We already allow replay of records that don't have a timestamp,
     * so there is already opportunity for issues caused by early conflicts on
     * standbys.
     */
    if (XLogRecGetRmid(record) != RM_XACT_ID)
        return false;

    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;

    if (xact_info != XLOG_XACT_COMMIT &&
        xact_info != XLOG_XACT_COMMIT_PREPARED)
        return false;

    if (!getRecordTimestamp(record, &xtime))
        return false;

    recoveryDelayUntilTime =
        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);

    /*
     * Exit without arming the latch if it's already past time to apply this
     * record
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Shortened:
        // Use WaitLatch until we reached recoveryDelayUntilTime
        // and then
        break;
    }
    return true;
}

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

របៀបប្រើការចម្លងដែលពន្យារពេលដើម្បីស្ដារទិន្នន័យ

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

នៅពេលដែលយើងរៀនពីបញ្ហា យើង ការស្ដារបណ្ណសារត្រូវបានផ្អាក សម្រាប់ការចម្លងដែលបានពន្យារពេល៖

SELECT pg_xlog_replay_pause();

ជាមួយនឹងការផ្អាកមួយ យើងមិនមានហានិភ័យដែលការចម្លងនឹងស្នើសុំម្តងទៀតនោះទេ។ DELETE. រឿងមានប្រយោជន៍ ប្រសិនបើអ្នកត្រូវការពេលវេលាដើម្បីដោះស្រាយអ្វីៗគ្រប់យ៉ាង។

ចំនុចនោះគឺថាការចម្លងដែលបានពន្យារត្រូវតែឈានដល់ពេលមុនពេលស្នើសុំ DELETE. យើងប្រហែលដឹងពីពេលវេលានៃការដកយកចេញ។ យើង​បាន​លុប recovery_min_apply_delay និងបានបន្ថែម recovery_target_time в recovery.conf. នេះជារបៀបដែលការចម្លងឈានដល់ពេលត្រឹមត្រូវដោយមិនបង្អង់យូរ៖

recovery_target_time = '2018-10-12 09:25:00+00'

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

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

SELECT
  -- current location in WAL
  pg_last_xlog_replay_location(),
  -- current transaction timestamp (state of the replica)
  pg_last_xact_replay_timestamp(),
  -- current physical time
  now(),
  -- the amount of time still to be applied until recovery_target_time has been reached
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

ប្រសិនបើត្រាពេលវេលាលែងផ្លាស់ប្តូរ ការស្តារឡើងវិញបានបញ្ចប់។ សកម្មភាពអាចត្រូវបានប្ដូរតាមបំណង recovery_target_actionដើម្បីបិទ ផ្សព្វផ្សាយ ឬផ្អាកឧទាហរណ៍ បន្ទាប់ពីព្យាយាមម្តងទៀត (វាត្រូវបានផ្អាកតាមលំនាំដើម)។

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

ជំនួសឱ្យការត្រាពេលវេលា វាជាការប្រសើរក្នុងការប្រើលេខសម្គាល់ប្រតិបត្តិការ។ វាមានប្រយោជន៍ក្នុងការកត់ត្រាលេខសម្គាល់ទាំងនេះ ជាឧទាហរណ៍ សម្រាប់សេចក្តីថ្លែងការណ៍ DDL (ដូចជា DROP TABLE) ដោយប្រើ log_statements = 'ddl'. ប្រសិនបើយើងមានលេខសម្គាល់ប្រតិបត្តិការ យើងនឹងយក recovery_target_xid ហើយដំណើរការអ្វីគ្រប់យ៉ាងចុះទៅប្រតិបត្តិការមុនពេលសំណើ DELETE.

ការត្រលប់ទៅធ្វើការវិញគឺសាមញ្ញណាស់៖ លុបការផ្លាស់ប្តូរទាំងអស់ចេញពី recovery.conf ហើយចាប់ផ្តើម Postgres ឡើងវិញ។ ការចម្លងនឹងមានការពន្យារពេលប្រាំបីម៉ោងម្តងទៀតក្នុងពេលឆាប់ៗនេះ ហើយយើងបានរៀបចំសម្រាប់បញ្ហានាពេលអនាគត។

អត្ថប្រយោជន៍នៃការស្តារឡើងវិញ

ជាមួយនឹងការចម្លងដែលបានពន្យារពេលជំនួសឱ្យការបម្រុងទុកត្រជាក់ អ្នកមិនចាំបាច់ចំណាយពេលច្រើនម៉ោងដើម្បីស្ដាររូបភាពទាំងមូលពីបណ្ណសារនោះទេ។ ជាឧទាហរណ៍ យើងចំណាយពេលប្រាំម៉ោងដើម្បីទទួលបានការបម្រុងទុកមូលដ្ឋាន 2 TB ទាំងមូល។ ហើយបន្ទាប់មកអ្នកនៅតែត្រូវអនុវត្ត WAL ប្រចាំថ្ងៃទាំងមូលដើម្បីស្តារស្ថានភាពដែលចង់បាន (ក្នុងករណីដ៏អាក្រក់បំផុត) ។

ការចម្លងដែលបានពន្យារពេលគឺប្រសើរជាងការបម្រុងទុកត្រជាក់តាមពីរវិធី៖

1. មិនចាំបាច់លុបការបម្រុងទុកមូលដ្ឋានទាំងមូលចេញពីប័ណ្ណសារទេ។
2. មានបង្អួចរយៈពេលប្រាំបីម៉ោងថេរនៃផ្នែក WAL ដែលត្រូវតែធ្វើម្តងទៀត។

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

ក្នុងឧទាហរណ៍នេះ វាបានចំណាយពេល 50 នាទីដើម្បីស្ដារ មានន័យថាល្បឿនគឺ 110 GB នៃទិន្នន័យ WAL ក្នុងមួយម៉ោង (ប័ណ្ណសារនៅតែបើក អេស។ អេស ៣) សរុបមក យើងបានដោះស្រាយបញ្ហា និងបានយកទិន្នន័យមកវិញក្នុងរយៈពេល 1,5 ម៉ោង។

លទ្ធផល៖ កន្លែងដែលការចម្លងដែលបានពន្យារមានប្រយោជន៍ (និងកន្លែងដែលវាមិនមាន)

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

ប៉ុន្តែ​ត្រូវ​ចាំ​ថា​៖ ការ​ចម្លង​មិន​មែន​ជា​ការ​បម្រុង​ទុក​ទេ។

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

ទោះបីជាមានការចម្លងដែលបានពន្យារពេលក៏ដោយ ពេលខ្លះយើងពិតជាត្រូវការការបម្រុងទុកត្រជាក់នៅក្នុងកន្លែងសុវត្ថិភាព ប្រសិនបើមជ្ឈមណ្ឌលទិន្នន័យបរាជ័យ ការខូចខាតដែលលាក់ ឬព្រឹត្តិការណ៍ផ្សេងទៀតដែលមិនគួរឱ្យកត់សម្គាល់កើតឡើងភ្លាមៗ។ ការចម្លងតែមួយគត់គឺគ្មានប្រយោជន៍នៅទីនេះទេ។

ការកត់សម្គាល់។ បើក GitLab.com បច្ចុប្បន្ននេះ យើងការពារតែការបាត់បង់ទិន្នន័យនៅកម្រិតប្រព័ន្ធប៉ុណ្ណោះ និងមិនសង្គ្រោះទិន្នន័យនៅកម្រិតអ្នកប្រើប្រាស់នោះទេ។

ប្រភព: www.habr.com