როგორ გამოვიყენეთ Lazy Replication კატასტროფის აღდგენისთვის PostgreSQL-ით

რეპლიკაცია არ არის სარეზერვო. Თუ არა? აი, როგორ გამოვიყენეთ გადადებული რეპლიკაცია მალსახმობების შემთხვევით წაშლისგან გამოსასწორებლად.

ინფრასტრუქტურის სპეციალისტები GitLab პასუხისმგებელია სამუშაოზე GitLab.com - ყველაზე დიდი GitLab-ის მაგალითი ბუნებაში. 3 მილიონი მომხმარებლის და თითქმის 7 მილიონი პროექტით, ეს არის ერთ-ერთი ყველაზე დიდი ღია კოდის SaaS საიტი განსაკუთრებული არქიტექტურით. PostgreSQL მონაცემთა ბაზის სისტემის გარეშე, GitLab.com ინფრასტრუქტურა შორს არ წავა და რას ვაკეთებთ შეცდომების ტოლერანტობის უზრუნველსაყოფად ნებისმიერი წარუმატებლობის შემთხვევაში, როდესაც მონაცემები შეიძლება დაიკარგოს. ნაკლებად სავარაუდოა, რომ ასეთი კატასტროფა მოხდეს, მაგრამ ჩვენ კარგად ვართ მომზადებული და მომარაგებული სხვადასხვა სარეზერვო და რეპლიკაციის მექანიზმებით.

რეპლიკაცია არ არის მონაცემთა ბაზის სარეზერვო საშუალება (იხილეთ ქვემოთ). მაგრამ ახლა ჩვენ ვნახავთ, თუ როგორ სწრაფად აღვადგინოთ შემთხვევით წაშლილი მონაცემები ზარმაცი რეპლიკაციის გამოყენებით: ჩართულია GitLab.com მომხმარებელი წაშალა მალსახმობი პროექტისთვის gitlab-ce და დაკარგული კავშირები შერწყმის მოთხოვნებთან და ამოცანებთან.

გადავადებული რეპლიკით, ჩვენ აღვადგინეთ მონაცემები მხოლოდ 1,5 საათში. შეხედე როგორ მოხდა.

მიუთითეთ დროში აღდგენა PostgreSQL-ით

PostgreSQL-ს აქვს ჩაშენებული ფუნქცია, რომელიც აღადგენს მონაცემთა ბაზის მდგომარეობას დროის კონკრეტულ მომენტში. მას ეძახიან დროში აღდგენა (PITR) და იყენებს იგივე მექანიზმებს, რომლებიც განაახლებს რეპლიკას: დაწყებული მონაცემთა მთელი კლასტერის საიმედო სნეპშოტით (ბაზის სარეზერვო), ჩვენ ვიყენებთ მდგომარეობის ცვლილებების სერიას დროის გარკვეულ მომენტამდე.

ამ ფუნქციის ცივი სარეზერვო ასლის გამოსაყენებლად, ჩვენ რეგულარულად ვაკეთებთ მონაცემთა ბაზის სარეზერვო ასლს და ვინახავთ მას არქივში (GitLab არქივები ცხოვრობს Google ღრუბლოვანი საცავი). ჩვენ ასევე ვაკვირდებით მონაცემთა ბაზის მდგომარეობის ცვლილებებს წინასწარ ჩაწერის ჟურნალის დაარქივებით (წინასწარ ჩაწერის ჟურნალი, უოლ). და ამ ყველაფრის გათვალისწინებით, ჩვენ შეგვიძლია გავაკეთოთ PITR კატასტროფის აღდგენისთვის: დაწყებული წარუმატებლობის წინ გადაღებული სნეპშოტით და WAL არქივიდან ცვლილებების გამოყენება მარცხამდე.

რა არის გადადებული რეპლიკაცია?

ზარმაცი რეპლიკაცია არის 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ინსტანციის დახურვა, პოპულარიზაცია ან დაპაუზება ხელახალი ცდის შემდეგ (ის ნაგულისხმევად შეჩერებულია).

მონაცემთა ბაზა დაუბრუნდა თავის მდგომარეობას ამ სამწუხარო მოთხოვნამდე. ახლა შეგიძლიათ, მაგალითად, მონაცემების ექსპორტი. ჩვენ ექსპორტირებულია ლეიბლის წაშლილი მონაცემები და ყველა ბმული საკითხებთან და გაერთიანების მოთხოვნებთან და გადავიტანეთ ისინი წარმოების მონაცემთა ბაზაში. თუ დანაკარგები ფართომასშტაბიანია, შეგიძლიათ უბრალოდ დააწინაუროთ რეპლიკა და გამოიყენოთ იგი, როგორც მთავარი. მაგრამ შემდეგ ყველა ცვლილება იმ წერტილის შემდეგ, რომელსაც ჩვენ აღვადგენთ, დაიკარგება.

დროის ანაბეჭდების ნაცვლად, უმჯობესია გამოიყენოთ ტრანზაქციის ID-ები. სასარგებლოა ამ ID-ების ჩაწერა, მაგალითად, DDL განცხადებებისთვის (როგორიცაა DROP TABLE), გამოყენებით log_statements = 'ddl'. ტრანზაქციის ID რომ გვქონდეს, ვიღებდით recovery_target_xid და გაიქცა ყველაფერი ტრანზაქციამდე თხოვნამდე DELETE.

სამუშაოზე დაბრუნება ძალიან მარტივია: წაშალეთ ყველა ცვლილება recovery.conf და გადატვირთეთ Postgres. რეპლიკას მალე ისევ რვა საათის დაგვიანება ექნება და ჩვენ მზად ვართ მომავალი პრობლემებისთვის.

აღდგენის უპირატესობები

ცივი სარეზერვო ასლის ნაცვლად დაგვიანებული რეპლიკით, თქვენ არ გჭირდებათ საათების დახარჯვა არქივიდან მთელი სურათის აღდგენისთვის. მაგალითად, 2 ტბ მთლიანი სარეზერვო ასლის მისაღებად ხუთი საათი გვჭირდება. და შემდეგ თქვენ კვლავ უნდა გამოიყენოთ მთელი ყოველდღიური WAL სასურველ მდგომარეობამდე აღსადგენად (უარეს შემთხვევაში).

გადადებული რეპლიკა უკეთესია, ვიდრე ცივი სარეზერვო ორი გზით:

1. არ არის საჭირო არქივიდან მთლიანი სარეზერვო ასლის ამოღება.
2. არსებობს WAL სეგმენტების ფიქსირებული რვა საათიანი ფანჯარა, რომელიც უნდა განმეორდეს.

ჩვენ ასევე მუდმივად ვამოწმებთ, შესაძლებელია თუ არა PITR-ის დამზადება WAL-დან და ჩვენ სწრაფად შევამჩნევთ კორუფციას ან სხვა პრობლემებს WAL-ის არქივთან დაკავშირებით, გადავადებული რეპლიკის შეფერხების მონიტორინგით.

ამ მაგალითში, აღდგენას 50 წუთი დაგვჭირდა, რაც ნიშნავს, რომ სიჩქარე იყო 110 გბ WAL მონაცემები საათში (არქივი ჯერ კიდევ ჩართული იყო AWS S3). საერთო ჯამში, პრობლემა მოვაგვარეთ და მონაცემები 1,5 საათში აღვადგინეთ.

შედეგები: სადაც დაგვიანებული რეპლიკა სასარგებლოა (და სად არა)

გამოიყენეთ დაგვიანებული რეპლიკაცია, როგორც პირველადი დახმარება, თუ შემთხვევით დაკარგეთ მონაცემები და შენიშნეთ ეს პრობლემა კონფიგურირებული დაგვიანებით.

მაგრამ გახსოვდეთ: რეპლიკაცია არ არის სარეზერვო.

სარეზერვო და რეპლიკაციას სხვადასხვა დანიშნულება აქვს. ცივი სარეზერვო საშუალება გამოგადგებათ, თუ შემთხვევით გააკეთეთ DELETE ან DROP TABLE. ჩვენ ვაკეთებთ სარეზერვო ასლს ცივი საცავიდან და აღვადგენთ ცხრილის ან მთელი მონაცემთა ბაზის წინა მდგომარეობას. მაგრამ ამავე დროს თხოვნა DROP TABLE თითქმის მყისიერად მრავლდება სამუშაო კლასტერზე ყველა რეპლიკაში, ამიტომ ჩვეულებრივი რეპლიკაცია აქ არ დაგვეხმარება. რეპლიკაცია თავისთავად ინახავს მონაცემთა ბაზას, როდესაც ცალკეული სერვერები ქირავდება და ანაწილებს დატვირთვას.

გადადებული ასლის შემთხვევაშიც კი, ზოგჯერ ნამდვილად გვჭირდება ცივი სარეზერვო საშუალება უსაფრთხო ადგილას, თუ მოხდება მონაცემთა ცენტრის უკმარისობა, ფარული დაზიანება ან სხვა მოვლენები, რომლებიც დაუყოვნებლივ არ არის შესამჩნევი. მარტო გამეორება აქ არაფერ შუაშია.

შენიშვნა. წლის GitLab.com ჩვენ ამჟამად ვიცავთ მონაცემთა დაკარგვისგან მხოლოდ სისტემის დონეზე და არ აღვადგენთ მონაცემებს მომხმარებლის დონეზე.

წყარო: www.habr.com