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 ఆర్కైవ్ నుండి వైఫల్యం వరకు మార్పులను వర్తింపజేయడం.

వాయిదా వేసిన ప్రతిరూపం అంటే ఏమిటి?

లేజీ రెప్లికేషన్ అనేది ఆలస్యంతో 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 కోసం కోల్డ్ బ్యాకప్ కూడా తీసుకోండి).

మేము వాయిదా వేసిన పోస్ట్‌గ్రెస్ ఉదాహరణను పునఃప్రారంభించాము మరియు పేర్కొన్న సమయం వరకు 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 TB బ్యాకప్ పొందడానికి మాకు ఐదు గంటల సమయం పడుతుంది. ఆపై మీరు కోరుకున్న స్థితికి తిరిగి రావడానికి (చెత్త సందర్భంలో) మొత్తం రోజువారీ WALని వర్తింపజేయాలి.

రెండు విధాలుగా కోల్డ్ బ్యాకప్ కంటే వాయిదా వేసిన ప్రతిరూపం ఉత్తమం:

1. ఆర్కైవ్ నుండి మొత్తం ప్రాథమిక బ్యాకప్‌ను తీసివేయవలసిన అవసరం లేదు.
2. WAL విభాగాల యొక్క స్థిర ఎనిమిది గంటల విండో ఉంది, అది తప్పనిసరిగా పునరావృతం అవుతుంది.

WAL నుండి PITR చేయడం సాధ్యమేనా అని కూడా మేము నిరంతరం తనిఖీ చేస్తాము మరియు వాయిదా వేసిన ప్రతిరూపం యొక్క లాగ్‌ని పర్యవేక్షించడం ద్వారా WAL ఆర్కైవ్‌లో అవినీతి లేదా ఇతర సమస్యలను మేము త్వరగా గమనిస్తాము.

ఈ ఉదాహరణలో, పునరుద్ధరించడానికి మాకు 50 నిమిషాలు పట్టింది, అంటే వేగం గంటకు 110 GB WAL డేటా (ఆర్కైవ్ ఇప్పటికీ ఆన్‌లో ఉంది AWS S3) మొత్తంగా, మేము సమస్యను పరిష్కరించాము మరియు 1,5 గంటల్లో డేటాను పునరుద్ధరించాము.

ఫలితాలు: వాయిదా వేసిన ప్రతిరూపం ఉపయోగపడే చోట (మరియు అది లేని చోట)

మీరు అనుకోకుండా డేటాను కోల్పోయి, కాన్ఫిగర్ చేసిన ఆలస్యంలో ఈ సమస్యను గమనించినట్లయితే, ఆలస్యమైన ప్రతిరూపణను ప్రథమ చికిత్సగా ఉపయోగించండి.

కానీ గుర్తుంచుకోండి: ప్రతిరూపం బ్యాకప్ కాదు.

బ్యాకప్ మరియు రెప్లికేషన్ వేర్వేరు ప్రయోజనాలను కలిగి ఉంటాయి. మీరు అనుకోకుండా చేసినట్లయితే చల్లని బ్యాకప్ ఉపయోగపడుతుంది DELETE లేదా DROP TABLE. మేము కోల్డ్ స్టోరేజ్ నుండి బ్యాకప్ చేస్తాము మరియు టేబుల్ యొక్క మునుపటి స్థితిని లేదా మొత్తం డేటాబేస్ను పునరుద్ధరిస్తాము. కానీ అదే సమయంలో అభ్యర్థన DROP TABLE పని చేసే క్లస్టర్‌లోని అన్ని ప్రతిరూపాలలో దాదాపు తక్షణమే పునరుత్పత్తి చేయబడుతుంది, కాబట్టి సాధారణ ప్రతిరూపం ఇక్కడ సహాయం చేయదు. వ్యక్తిగత సర్వర్‌లు డౌన్‌లో ఉన్నప్పుడు మరియు లోడ్‌ను పంపిణీ చేసినప్పుడు ప్రతిరూపణ స్వయంగా డేటాబేస్‌ను అందుబాటులో ఉంచుతుంది.

వాయిదా వేసిన ప్రతిరూపంతో కూడా, డేటా సెంటర్ వైఫల్యం, దాచిన నష్టం లేదా వెంటనే గుర్తించబడని ఇతర సంఘటనలు సంభవించినట్లయితే, మనకు కొన్నిసార్లు సురక్షితమైన స్థలంలో చల్లని బ్యాకప్ అవసరం. ప్రతిరూపం మాత్రమే ఇక్కడ పనికిరాదు.

వ్యాఖ్య. న GitLab.com మేము ప్రస్తుతం సిస్టమ్ స్థాయిలో డేటా నష్టం నుండి మాత్రమే రక్షిస్తాము మరియు వినియోగదారు స్థాయిలో డేటాను పునరుద్ధరించము.

మూలం: www.habr.com