כיצד השתמשנו בשכפול עצלן להתאוששות מאסון עם PostgreSQL

שכפול אינו גיבוי. או שלא? כך השתמשנו בשכפול דחוי כדי להתאושש ממחיקת קיצורי דרך בטעות.

מומחי תשתיות GitLab אחראית על העבודה GitLab.com - מופע GitLab הגדול ביותר בטבע. עם 3 מיליון משתמשים וכמעט 7 מיליון פרויקטים, זהו אחד מאתרי ה-SaaS הגדולים בקוד פתוח עם ארכיטקטורה ייעודית. ללא מערכת מסד הנתונים PostgreSQL, תשתית GitLab.com לא תגיע רחוק, ומה אנחנו עושים כדי להבטיח סובלנות לתקלות במקרה של תקלות כלשהן כאשר נתונים יכולים ללכת לאיבוד. לא סביר שיקרה אסון כזה, אבל אנחנו ערוכים היטב ומצוידים במנגנוני גיבוי ושכפול שונים.

שכפול אינו אמצעי לגיבוי מסדי נתונים (ראה להלן). אבל עכשיו נראה כיצד לשחזר במהירות נתונים שנמחקו בטעות באמצעות שכפול עצלן: על GitLab.com משתמש מחק את קיצור הדרך לפרויקט gitlab-ce ואיבדו קשרים עם בקשות מיזוג ומשימות.

עם העתק דחוי, שחזרנו נתונים תוך 1,5 שעות בלבד. תראה איך זה קרה.

התאוששות בנקודת זמן עם PostgreSQL

ל-PostgreSQL פונקציה מובנית המשחזרת את מצב מסד הנתונים לנקודת זמן מסוימת. זה נקרא שחזור נקודת זמן (PITR) ומשתמש באותם מנגנונים שמעדכנים את העתק: החל מתמונת מצב אמינה של כל אשכול מסד הנתונים (גיבוי בסיס), אנו מיישמים סדרה של שינויי מצב עד לנקודת זמן מסוימת.

כדי להשתמש בתכונה זו לגיבוי קר, אנו עורכים באופן קבוע גיבוי בסיסי של מסד נתונים ומאחסנים אותו בארכיון (ארכיון GitLab פעיל ב אחסון בענן של גוגל). אנו גם עוקבים אחר שינויים במצב מסד הנתונים על ידי ארכיון יומן הכתיבה קדימה (יומן כתיבה קדימה, WAL). ועם כל זה במקום, אנחנו יכולים לעשות 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-e לחלץ מקטעי 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). כפי שניתן לראות, ההשהיה חלה רק על commits ואינה משפיעה על ערכים אחרים - כל השינויים מוחלים ישירות, וה-commit מעוכב, כך שנראה את השינויים רק לאחר ההשהיה שהוגדרה.

כיצד להשתמש בהעתק מושהה כדי לשחזר נתונים

נניח שיש לנו אשכול מסד נתונים והעתק עם עיכוב של שמונה שעות בייצור. בואו נראה כיצד לשחזר נתונים באמצעות דוגמה מחיקת קיצורי דרך בטעות.

כאשר למדנו על הבעיה, אנחנו שחזור הארכיון הושהה עבור העתק דחוי:

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 לשעה (הארכיון עדיין פועל AWS S3). בסך הכל פתרנו את הבעיה ושחזרנו את הנתונים תוך 1,5 שעות.

תוצאות: היכן העתק דחוי שימושי (והיכן לא)

השתמש בשכפול מושהה כעזרה ראשונה אם איבדת בטעות נתונים והבחנת בבעיה זו בתוך השהיה שהוגדר.

אבל זכור: שכפול אינו גיבוי.

לגיבוי ולשכפול יש מטרות שונות. גיבוי קר יהיה שימושי אם עשית בטעות DELETE או DROP TABLE. אנו עושים גיבוי מאחסון קר ומשחזרים את המצב הקודם של הטבלה או כל מסד הנתונים. אבל במקביל הבקשה DROP TABLE משוכפל כמעט באופן מיידי בכל ההעתקים באשכול העבודה, כך שכפול רגיל לא יעזור כאן. השכפול עצמו שומר על מסד הנתונים זמין כאשר שרתים בודדים מושכרים ומחלק את העומס.

אפילו עם העתק דחוי, לפעמים אנחנו באמת צריכים גיבוי קר במקום בטוח אם מתרחשים כשל במרכז הנתונים, נזק נסתר או אירועים אחרים שאינם מורגשים מיד. שכפול לבדו אינו מועיל כאן.

שים לב. על GitLab.com כרגע אנחנו מגנים רק מפני אובדן נתונים ברמת המערכת ולא משחזרים נתונים ברמת המשתמש.

מקור: www.habr.com