Tsy backup ny replication. Na tsia? Toy izao ny fomba nampiasanay ny famerenana nahemotra mba hiverenana amin'ny famafana tsy nahy hitsin-dΓ lana.
GitLab no tompon'andraikitra amin'ny asa - ny ohatra GitLab lehibe indrindra amin'ny natiora. Miaraka amin'ny mpampiasa 3 tapitrisa sy tetikasa efa ho 7 tapitrisa, io no iray amin'ireo tranonkala SaaS loharano misokatra lehibe indrindra miaraka amin'ny maritrano voatokana. Raha tsy misy ny rafitra angon-drakitra PostgreSQL dia tsy ho lasa lavitra ny fotodrafitrasa GitLab.com, ary inona no ataontsika mba hiantohana ny fandeferana amin'ny fahadisoana raha misy tsy fahombiazana rehefa mety ho very ny angona. Tsy azo inoana ny hitrangan'ny loza toy izany, saingy efa miomana tsara isika ary feno fitaovana maro samihafa sy replication.
Ny replication dia tsy fomba hanohanana ny angon-drakitra (). Fa izao dia ho hitantsika ny fomba hamerenana haingana ny angon-drakitra voafafa tsy nahy mampiasa replication kamo: on ny mpampiasa ho an'ny tetikasa ary very fifandraisana amin'ny fangatahana sy ny asa fanakambanana.
Miaraka amin'ny kopia nahemotra, naverinay tao anatin'ny 1,5 ora monja. Jereo ny zava-nitranga.
Point in time recovery amin'ny PostgreSQL
PostgreSQL dia manana fiasa naorina izay mamerina ny toetry ny angon-drakitra amin'ny fotoana voafaritra. Antsoina hoe (PITR) ary mampiasa fomba fiasa mitovy amin'ny fitazonana ny dika mitovy amin'ny daty: manomboka amin'ny sary azo itokisana amin'ny cluster database manontolo (base backup), dia mampihatra andiana fanovana fanjakana izahay hatramin'ny fotoana iray.
Mba hampiasana an'io endri-javatra io ho an'ny backup mangatsiaka, dia manao backup database fototra tsy tapaka izahay ary mitahiry izany ao anaty arisiva (miaina ao amin'ny tahiry GitLab. ). Manara-maso ny fiovana amin'ny toetry ny angon-drakitra ihany koa izahay amin'ny alΓ lan'ny fitahirizana ny log-manoratra mialoha (, WAL). Ary miaraka amin'izany rehetra izany, afaka manao PITR ho an'ny fanarenana ny loza isika: manomboka amin'ny sary nalaina alohan'ny tsy fahombiazana, ary mampihatra ny fanovana avy amin'ny arisiva WAL ka hatramin'ny tsy fahombiazana.
Inona no atao hoe replication nahemotra?
Lazy replication dia ny fampiharana ny fanovana avy amin'ny WAL miaraka amin'ny fahatarana. Izany hoe tao anatinβny adiny iray no nitranganβny fifampiraharahana X, fa hiseho amin'ny kopia miaraka amin'ny fahatarana d ao anatin'ny adiny iray X + d.
PostgreSQL dia manana fomba 2 hananganana kopia angon-drakitra ara-batana: fanarenana backup sy replication streaming. , dia miasa toy ny PITR amin'ny ankapobeny, saingy mitohy: maka ireo fanovana avy amin'ny arisiva WAL izahay ary mampihatra izany amin'ny kopia. ny maka mivantana ny renirano WAL avy amin'ny mpampiantrano angona ambony. Aleonay ny fanarenana ny arsiva - mora kokoa ny mitantana ary manana fampandehanana ara-dalΓ na mifanaraka amin'ny vondron'ny famokarana.
Ahoana ny fametrahana fahatarana fanarenana avy amin'ny arisiva
voalaza ao amin'ny rakitra recovery.conf... ohatra:
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'Miaraka amin'ireo mari-pamantarana ireo, dia nanamboatra kopia nahemotra miaraka amin'ny fanarenana backup izahay. Eto no ampiasaina hanesorana ny fizarana WAL (restore_command) avy amin'ny arisiva, ary hampiharina aorian'ny adiny valo ny fanovana (recovery_min_apply_delay). Ny dika mitovy dia hijery ny fiovan'ny fandaharam-potoana ao amin'ny arisiva, ohatra noho ny tsy fahampian'ny cluster (recovery_target_timeline).
Π‘ recovery_min_apply_delay Azonao atao ny manangana replication streaming miaraka amin'ny fahatarana, saingy misy fandrika roa eto izay mifandraika amin'ny slot replication, fanehoan-kevitra mafana amin'ny standby, sy ny sisa. Ny arisiva WAL dia ahafahanao misoroka azy ireo.
fikirana recovery_min_apply_delay tao amin'ny PostgreSQL 9.3. Amin'ny dikan-teny teo aloha, ho an'ny replication nahemotra dia mila manamboatra ny fitambarana ianao (pg_xlog_replay_pause(), pg_xlog_replay_resume()) na mitazona ampahany amin'ny WAL ao anaty tahiry mandritra ny faharetan'ny fahatarana.
Ahoana no anaovan'ny PostgreSQL an'izany?
Mahaliana ny mahita ny fomba ampiharan'ny PostgreSQL ny fanarenana kamo. Andeha hojerentsika . Antsoina hoe avy amin'ny ho an'ny fidirana tsirairay avy amin'ny 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;
}Ny tsipika ambany dia ny fanemorana dia mifototra amin'ny fotoana ara-batana voarakitra ao amin'ny famantarana famantarana famantaranandro (xtime). Araka ny hitanao dia mihatra amin'ny commits ihany ny fanemorana ary tsy misy fiantraikany amin'ny fidirana hafa - ny fanovana rehetra dia ampiharina mivantana, ary ny commit dia mihemotra, noho izany dia ho hitantsika ny fiovana aorian'ny fanemorana voarindra.
Ahoana ny fampiasana kopia nahemotra hamerenana ny angona
Andeha atao hoe manana cluster database sy kopia misy fahatarana adiny valo amin'ny famokarana. Andeha hojerentsika ny fomba hamerenana ny angona mampiasa ohatra .
Rehefa nianatra momba ny olana izahay dia ho an'ny kopia nahemotra:
SELECT pg_xlog_replay_pause();Miaraka amin'ny fiatoana, tsy natahorana ny hamerina ilay fangatahana ilay kopia DELETE. Zavatra mahasoa raha mila fotoana hamantarana ny zava-drehetra ianao.
Ny tanjona dia ny tsy maintsy tonga amin'ny fotoana alohan'ny fangatahana ny kopia nahemotra DELETE. Efa fantatray ny fotoana nesorina. Nofafanay recovery_min_apply_delay ary nampiana recovery_target_time Π² recovery.conf. Toy izao ny fomba hahatongavan'ny dika mitovy amin'ny fotoana mety tsy misy hatak'andro:
recovery_target_time = '2018-10-12 09:25:00+00'Miaraka amin'ny mari-pamantarana fotoana, tsara kokoa ny mampihena ny tafahoatra mba tsy ho diso. Marina fa arakaraka ny hihena no betsaka ny angona very. Averina indray, raha diso ny fangatahana DELETE, ho voafafa indray ny zava-drehetra ary tsy maintsy manomboka indray ianao (na haka backup mangatsiaka ho an'ny PITR).
Naverinay indray ny ohatra Postgres nahemotra ary naverina ny fizarana WAL mandra-pahatongan'ny fotoana voafaritra. Azonao atao ny manara-maso ny fandrosoana amin'ity dingana ity amin'ny fanontaniana hoe:
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;Raha tsy miova intsony ny mari-pamantarana dia vita ny fanarenana. Azo amboarina ny hetsika hanakatona, hampiroborobo, na hampiato ny ohatra aorian'ny andrana indray (mihantona amin'ny alΓ lan'ny default).
Niverina tamin'ny toerany ny angon-drakitra talohan'io fangatahana mampalahelo io. Azonao atao, ohatra, ny manondrana angona. Naondranay ny angona etikety voafafa sy ny rohy rehetra amin'ny olana ary natambatra ny fangatahana ary nafindranay tao amin'ny angon-drakitra famokarana. Raha lehibe ny fatiantoka, azonao atao ny mampiroborobo ny kopia fotsiny ary mampiasa azy io ho toy ny lehibe. Fa avy eo dia ho very daholo ny fiovana rehetra taorian'ny teboka niverenantsika.
Raha tokony ho mari-pamantarana, dia tsara kokoa ny mampiasa ID momba ny varotra. Tena ilaina ny mirakitra ireo ID ireo, ohatra, ho an'ny fanambarana DDL (toy ny DROP TABLE), amin'ny fampiasana log_statements = 'ddl'. Raha manana karapanondrom-pandraharahana izahay dia haka recovery_target_xid ary nihazakazaka ny zava-drehetra ho any amin'ny fifanakalozana alohan'ny fangatahana DELETE.
Tena tsotra ny fiverenana miasa: esory ny fanovana rehetra recovery.conf ary avereno indray ny Postgres. Tsy ho ela dia hisy fahatarana adiny valo indray ilay kopia, ary miomana amin'ny olana ho avy isika.
Tombontsoa fanarenana
Miaraka amin'ny kopia nahemotra fa tsy backup mangatsiaka, tsy mila mandany ora maro amin'ny famerenana ny sary manontolo avy amin'ny arisiva ianao. Ohatra, mila adiny dimy isika vao mahazo ny backup 2 TB fototra manontolo. Ary avy eo dia mbola mila mampihatra ny WAL isan'andro ianao mba hamerenana amin'ny fanjakana tianao (amin'ny tranga ratsy indrindra).
Ny kopia nahemotra dia tsara kokoa noho ny backup mangatsiaka amin'ny fomba roa:
- Tsy ilaina ny manala ny backup fototra manontolo amin'ny arisiva.
- Misy varavarankely maharitra adiny valo amin'ny fizarana WAL izay tsy maintsy averina.
Manamarina tsy tapaka ihany koa izahay raha azo atao ny manao PITR avy amin'ny WAL, ary ho hitantsika haingana ny kolikoly na olana hafa amin'ny arisiva WAL amin'ny fanaraha-maso ny fahatarana amin'ny kopia nahemotra.
Amin'ity ohatra ity dia nilana 50 minitra izahay vao namerina, midika izany fa ny hafainganam-pandeha dia 110 GB amin'ny angona WAL isan'ora (mbola mandeha ny arsiva. ). Amin'ny fitambarany, namaha ny olana izahay ary namerina ny angon-drakitra tao anatin'ny 1,5 ora.
Vokatra: izay ilΓ na ny kopia nahemotra (ary raha tsy izany)
MampiasΓ replication nahemotra ho vonjy maika raha very data tsy nahy ianao ary nahatsikaritra ity olana ity tao anatin'ny fahatarana voarindra.
Nefa tadidio: tsy backup ny replication.
Ny backup sy ny replication dia samy manana tanjona samihafa. Ny backup mangatsiaka dia ho azo ampiasaina raha tsy nahy ianao DELETE na DROP TABLE. Manao backup avy amin'ny fitahirizana mangatsiaka isika ary mamerina ny toetry ny latabatra na ny tahiry manontolo. Saingy miaraka amin'izay koa ny fangatahana DROP TABLE dia saika averina avy hatrany amin'ny kopia rehetra ao amin'ny cluster miasa, noho izany dia tsy hanampy eto ny replication mahazatra. Ny replication mihitsy no mitazona ny angon-drakitra azo alaina rehefa manofa ny mpizara tsirairay ary mizara ny entana.
Na dia misy kopia nahemotra aza, indraindray dia tena mila backup mangatsiaka any amin'ny toerana azo antoka isika raha misy tsy fahombiazan'ny foibe data, fahasimbana miafina, na tranga hafa tsy tsikaritra avy hatrany. Tsy misy ilana azy eto ny kopia fotsiny.
fanamarihana... On Amin'izao fotoana izao izahay dia miaro amin'ny fahaverezan'ny angona eo amin'ny sehatry ny rafitra ary tsy mamerina ny angona eo amin'ny sehatry ny mpampiasa.
Source: www.habr.com