Ang pagkopya dili usa ka backup. O dili? Ania kung giunsa namon gigamit ang tapulan nga pagkopya alang sa pagbawi pinaagi sa aksidente nga pagtangtang sa mga shortcut.
Ang GitLab maoy responsable sa trabaho - ang pinakadako nga pananglitan sa GitLab sa kinaiyahan. Uban sa 3 milyon nga tiggamit ug hapit 7 milyon nga mga proyekto, kini usa sa labing kadaghan nga bukas nga gigikanan nga mga site sa SaaS nga adunay gipahinungod nga arkitektura. Kung wala ang sistema sa database sa PostgreSQL, ang imprastraktura sa GitLab.com dili moadto sa layo, ug kung unsa ang wala namon buhaton alang sa pagtugot sa sayup kung adunay bisan unsang mga kapakyasan kung mawala ang datos. Dili tingali nga mahitabo ang ingon nga katalagman, apan nangandam kami og maayo ug gitipigan ang lainlaing mga mekanismo sa pag-backup ug pagkopya.
Ang pagkopya dili imong database backup tool (). Apan karon atong tan-awon kon sa unsang paagi sa madali mabawi aksidenteng natangtang data sa paggamit sa tapulan replikasyon: sa ang tiggamit alang sa proyekto ug nawad-an sa mga koneksyon sa paghiusa sa mga hangyo ug mga buluhaton.
Uban sa nalangan nga replika, nabawi namo ang datos sulod lang sa 1,5 ka oras. Tan-awa kung giunsa kini.
Point-in-time nga pagbawi sa PostgreSQL
Ang PostgreSQL adunay built-in nga function nga nagpahiuli sa kahimtang sa usa ka database sa usa ka piho nga punto sa oras. Gitawag kini (PITR) ug naggamit sa parehas nga mga mekanismo nga nagpadayon sa usa ka replika nga labing bag-o: sugod sa usa ka kasaligan nga snapshot sa tibuuk nga cluster sa database (base backup), nag-aplay kami usa ka serye sa mga pagbag-o sa estado hangtod sa usa ka piho nga punto sa oras.
Aron magamit kini nga bahin alang sa usa ka bugnaw nga backup, kanunay kaming maghimo usa ka base nga backup sa database ug itago kini sa usa ka archive (ang GitLab archive nagpuyo sa ). Among gimonitor usab ang mga kausaban sa estado sa database pinaagi sa pag-archive sa usa ka write-ahead log (, WAL). Ug sa tanan niini, mahimo naton ang PITR alang sa pagbawi sa katalagman: magsugod kita sa usa ka snapshot nga gikuha sa wala pa ang sayup ug i-apply ang mga pagbag-o gikan sa archive sa WAL hangtod sa pagkahagsa.
Unsa ang delayed replication?
Ang nalangan nga pagkopya mao ang pagpadapat sa mga pagbag-o gikan sa WAL nga adunay pagkalangan. Sa ato pa, ang transaksyon nahitabo sa oras X, apan kini makita sa replika nga adunay paglangan d sa oras X + d.
Adunay 2 nga mga paagi sa pag-set up sa usa ka pisikal nga replika sa database sa PostgreSQL: pag-uli sa archive ug pag-streaming nga kopya. , esensya naglihok sama sa PITR, apan padayon: kanunay namong gikuha ang mga pagbag-o gikan sa archive sa WAL ug gipadapat kini sa replica. A Gikuha ang WAL stream direkta gikan sa upstream database host. Gipalabi namo ang pag-uli gikan sa usa ka archive - mas sayon ββang pagdumala ug adunay normal nga pasundayag, nga dili malangan sa usa ka grupo sa produksiyon.
Giunsa ang pag-set up sa nalangan nga backup recovery
gihulagway sa file recovery.conf. Usa ka pananglitan:
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'Uban niini nga mga setting, among gi-configure ang usa ka nalangan nga replika nga adunay pag-uli sa archive. Gigamit dinhi aron makuha ang mga bahin sa WAL (restore_command) gikan sa archive, ug ang mga pagbag-o magamit pagkahuman sa walo ka oras (recovery_min_apply_delay). Ang replika magtan-aw sa mga pagbag-o sa timeline sa archive, sama sa tungod sa usa ka cluster failover (recovery_target_timeline).
Π‘ recovery_min_apply_delay mahimo nimong i-set up ang latency streaming replication, apan adunay pipila ka mga pitfalls nga nalangkit sa replication slots, init nga ekstrang feedback, ug uban pa. Ang WAL archive naglikay kanila.
Parameter recovery_min_apply_delay nagpakita lamang sa PostgreSQL 9.3. Sa miaging mga bersyon, ang nalangan nga pagkopya nanginahanglan usa ka kombinasyon sa (pg_xlog_replay_pause(), pg_xlog_replay_resume()) o hupti ang mga bahin sa WAL sa archive sa gidugayon sa paglangan.
Giunsa kini pagbuhat sa PostgreSQL?
Makapainteres nga tan-awon kung giunsa pagpatuman sa PostgreSQL ang lazy restore. Atong tan-awon . Gitawag kini gikan sa alang sa matag entry gikan sa 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, µsecs);
if (secs <= 0 && microsecs <= 0)
return false;
while (true)
{
// Shortened:
// Use WaitLatch until we reached recoveryDelayUntilTime
// and then
break;
}
return true;
}Ang hinungdan mao nga ang paglangan gibase sa pisikal nga oras nga natala sa timestamp sa transaksyon nga nahimo (xtime). Sama sa imong makita, ang paglangan magamit lamang sa mga commit ug dili makaapekto sa ubang mga rekord - ang tanan nga mga pagbag-o direkta nga gipadapat, ug ang pasalig nalangan, mao nga atong makita ang mga pagbag-o pagkahuman sa gi-configure nga paglangan.
Giunsa paggamit ang tapolan nga kopya alang sa pagbawi sa datos
Ingnon ta nga kita adunay database cluster sa produksiyon ug usa ka replika nga adunay walo ka oras nga paglangan. Atong tan-awon kung giunsa pagbawi ang datos gamit ang usa ka pananglitan .
Sa dihang nahibal-an namo ang problema, kami alang sa nalangan nga kopya:
SELECT pg_xlog_replay_pause();Uban sa usa ka paghunong, kami walay risgo nga ang replika magsubli sa hangyo DELETE. Mapuslanon nga butang kung kinahanglan nimo ang oras aron mahibal-an ang tanan.
Ang hinungdan mao nga ang nalangan nga replika kinahanglan nga maabot sa takna sa wala pa ang hangyo DELETE. Gibanabana nga nahibal-an namon ang pisikal nga oras sa pagtangtang. Gitangtang namo recovery_min_apply_delay ug gidugang recovery_target_time Π² recovery.conf. Busa ang replika nakaabot sa saktong higayon nga walay paglangan:
recovery_target_time = '2018-10-12 09:25:00+00'Sa mga timestamp, mas maayo nga pakunhuran ang sobra aron dili masipyat. Tinuod, kon mas dako ang pagkunhod, mas daghang data ang mawala kanato. Pag-usab, kung atong laktawan ang hangyo DELETE, ang tanan matangtang pag-usab ug kinahanglan ka nga magsugod pag-usab (o bisan magkuha usa ka bugnaw nga backup alang sa PITR).
Among gisugdan pag-usab ang nalangan nga Postgres nga pananglitan ug ang mga bahin sa WAL gisubli hangtod sa gitakdang oras. Mahimo nimong masubay ang pag-uswag niini nga yugto pinaagi sa pagpangutana:
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;Kung dili na mausab ang timestamp, kompleto na ang pag-uli. Mahimo nimong ipasibo ang aksyon aron isira, i-promote, o ihunong ang instance pagkahuman sa pagsulay pag-usab (kini mohunong pinaagi sa default).
Ang database miabot sa estado sa wala pa kana nga dili maayo nga hangyo. Karon mahimo nimo, pananglitan, pag-eksport sa datos. Gi-eksport namo ang data sa hilit nga label ug ang tanang mga link sa mga isyu ug gihiusa ang mga hangyo ug gibalhin kini sa database sa produksiyon. Kung ang mga kapildihan dako, mahimo nimong i-promote ang replika ug gamiton kini ingon nga panguna. Apan unya ang tanan nga mga pagbag-o mawala pagkahuman sa higayon nga kami nakabawi.
Mas maayo nga gamiton ang mga transaction ID kaysa mga timestamp. Mapuslanon ang pagrekord niini nga mga ID, pananglitan, alang sa mga pahayag sa DDL (sama sa DROP TABLE), pinaagi sa paggamit log_statements = 'ddl'. Kung naa miy transaction ID, among kuhaon recovery_target_xid ug gipadagan ang tanan ngadto sa transaksyon sa wala pa ang hangyo DELETE.
Ang pagbalik sa trabaho yano ra kaayo: kuhaa ang tanan nga mga pagbag-o gikan sa recovery.conf ug i-restart ang mga postgres. Sa dili madugay ang cue adunay pag-usab sa walo ka oras nga paglangan, ug kami andam na alang sa umaabot nga mga kasamok.
Mga Benepisyo sa Pagbawi
Uban sa usa ka nalangan nga kopya, imbis nga usa ka bugnaw nga backup, dili nimo kinahanglan nga mogugol ug daghang oras aron mapasig-uli ang tibuuk nga snapshot gikan sa archive. Pananglitan, kinahanglan namon ang lima ka oras aron makuha ang tibuuk nga 2 TB base backup. Ug unya kinahanglan nimo nga i-apply ang tibuuk nga adlaw-adlaw nga WAL aron mabawi ang gusto nga kahimtang (sa labing grabe nga kaso).
Ang usa ka nalangan nga kopya mas maayo kaysa usa ka bugnaw nga backup sa duha ka paagi:
- Dili nimo kinahanglan nga makuha ang tibuuk nga base backup gikan sa archive.
- Adunay usa ka piho nga walo ka oras nga bintana sa mga bahin sa WAL nga kinahanglan nga balikon.
Usab, kanunay namong gisusi kung ang WAL mahimo bang PITRed, ug makamatikod dayon kami sa korapsyon o uban pang problema sa WAL archive pinaagi sa pagmonitor sa backlog sa nalangan nga replika.
Sa kini nga pananglitan, gikuha namon ang 50 minuto aron mapasig-uli, nga mao, ang katulin mao ang 110 GB nga datos sa WAL matag oras (ang archive nagpadayon ). Sa kinatibuk-an, nasulbad namo ang problema ug gipahiuli ang datos sulod sa 1,5 ka oras.
Summary: diin ang usa ka nalangan nga kopya mapuslanon (ug kung dili)
Gamita ang nalangan nga replikasyon isip usa ka first aid kung wala ka tuyoa nga mawad-an sa datos ug makamatikod niini nga katalagman sulod sa gi-configure nga paglangan.
Apan hinumdomi: ang pagkopya dili usa ka backup.
Ang pag-backup ug pagkopya adunay lainlaing katuyoan. Ang usa ka bugnaw nga backup mahimong magamit kung wala nimo tuyoa DELETE o DROP TABLE. Naghimo kami usa ka backup gikan sa bugnaw nga pagtipig ug gipahiuli ang miaging kahimtang sa usa ka lamesa o usa ka tibuuk nga database. Apan sa samang higayon ang hangyo DROP TABLE halos diha-diha dayon nga gipadaghan sa tanan nga mga replika sa nagtrabaho nga cluster, mao nga ang regular nga pagkopya dili makatipig dinhi. Ang pagkopya mismo nagpugong sa database nga magamit kung ang indibidwal nga mga server giabangan ug giapod-apod ang load.
Bisan sa usa ka nalangan nga replika, usahay kinahanglan gyud namon ang usa ka bugnaw nga backup sa usa ka luwas nga lugar, kung kalit adunay usa ka pagkapakyas sa data center, natago nga kadaot, o uban pang mga panghitabo nga dili nimo mamatikdan dayon. Dinhi gikan sa usa ka replikasyon walay kahulogan.
ΠΡΠΈΠΌΠ΅ΡΠ°Π½ΠΈΠ΅. Sa kami sa pagkakaron nanalipod lamang batok sa pagkawala sa datos sa lebel sa sistema ug dili ibalik ang datos sa lebel sa user.
Source: www.habr.com