Ez ji we re pêşniyar dikim ku hûn ji destpêka sala 2019-an ve ji hêla Andrey Borodin ve bixwînin "Backups with WAL-G. Di sala 2019-an de çi heye?"
Silav hemû! Navê min Andrey Borodin e. Ez pêşdebirek li Yandex im. Ez ji sala 2016-an vir ve bi PostgreSQL re eleqedar dibim, piştî ku min bi pêşdebiran re peyivî û wan got ku her tişt hêsan e - hûn koda çavkaniyê digirin û wê ava dikin, û her tişt dê biqede. Û ji hingê ve ez nikarim rawestim - ez her cûreyên cûda dinivîsim.
Yek ji tiştên ku ez li ser dixebitim pergalek hilanînê ye. . Bi gelemperî, li Yandex em ji bo demek pir dirêj li ser pergalên hilanînê yên li PostgreSQL dixebitin. Û hûn dikarin li ser Înternetê rêzek şeş raportan bibînin ka em çawa pergalên paşvekêşanê çêdikin. Û her sal ew piçekî pêş dikevin, piçek pêşve diçin û pêbawertir dibin.
Lê îro rapor ne tenê li ser tiştên ku me kirine, di heman demê de li ser wê yekê ye ku ew çiqas hêsan e û çi ye. Çend ji we berê li raporên min ên di derbarê WAL-G de temaşe kirine? Pir baş e ku çend kesan temaşe nekirine, ji ber ku ez ê bi tiştê herî hêsan dest pê bikim.
Ger ji nişkê ve we komeke PostgreSQL heye, û ez difikirim ku her kes çend ji wan bi wan re heye, û ji nişkê ve hîn pergalek paşvekêşanê tune, wê hingê hûn hewce ne ku hilanîna S3 an hilanîna lihevhatî ya Google Cloud bistînin.
Mînakî, hûn dikarin werin standa me û ji bo Yandex Object Storage, ku S3 lihevhatî ye, kodek danasînê bistînin.
Piştre Bucketek çêbikin. Ew tenê konteynirek ji bo agahdariyê ye.
Bikarhênerek karûbarê biafirîne.
Ji bo bikarhênerê karûbarê mifteyek gihîştinê biafirînin: aws-s3-key.
Daxuyaniya herî paşîn a WAL-G dakêşin.
Berhemên me ji weşanên çawa cûda ne? Gelek caran ji min tê xwestin ku ez zû berdim. Û heke ji bo demek têr di guhertoyê de xeletiyek tune, mînakî mehek, wê hingê ez wê berdim. Li vir ev serbestberdana ji Mijdarê ye. Û ev tê vê wateyê ku her meh me cûreyek xeletiyek dît, bi gelemperî di fonksiyonên ne-krîtîk de, lê me hîna serbestberdanek dernexistiye. Guhertoya berê tenê Mijdar e. Di wê de tu xeletiyên ku ji me re têne zanîn tune ne, ango her ku proje pêşve çû xeletî lê zêde bûn.
Piştî ku we WAL-G dakêşand, hûn dikarin fermanek "lîsteya hilanînê" ya hêsan bimeşînin, ku di guherbarên hawîrdorê de derbas bibin. Û ew ê bi Object Storage ve girêbide û ji we re bêje ka çi paşkêşên we hene. Di destpêkê de, bê guman, divê hûn paşvekêşan nebin. Mebesta vê slaytê ev e ku nîşan bide ku her tişt pir hêsan e. Ev fermanek konsolê ye ku guhêrbarên jîngehê qebûl dike û jêrfermanan pêk tîne.
Piştî vê yekê, hûn dikarin paşîna xweya yekem çêbikin. Di WAL-G de "piştgir-push" bibêjin û di WAL-G de cîhê pgdata koma xwe diyar bikin. Û bi îhtîmaleke mezin, PostgreSQL dê ji we re bêje, heke we jixwe pergalek hilanînê tune, ku hûn hewce ne ku "arşîv-mode" çalak bikin.
Ev tê vê wateyê ku hûn hewce ne ku hûn biçin mîhengan û "archive_mode = on" vekin û "archive_command" lê zêde bikin, ku ew jî di WAL-G de fermanek jêrîn e. Lê ji ber hin sedeman mirov bi gelemperî li ser vê mijarê nivîsên bar bikar tînin û wê li dora WAL-G dipêçin. Ji kerema xwe vê yekê nekin. Karbidestiya ku di WAL-G de tê dîtin bikar bînin. Ger we tiştek winda kir, binivîsin . WAL-G texmîn dike ku ew tenê bername ye ku di archive_command de dimeşe.
Em WAL-G-ê bi piranî bikar tînin da ku di rêveberiya Daneya Daneya Yandex de komek Hebûna Bilind biafirînin.
Û ew bi gelemperî di topolojiya yek Master û çend dubareyan de tê bikar anîn. Di heman demê de, ew kopiyek hilanînê li Yandex Object Storage çêdike.
Senaryoyên herî gelemperî çêkirina kopiyên komekê bi karanîna Point di dema vegerandinê de ne. Lê di vê rewşê de, performansa pergala hilanînê ji bo me ne ew qas girîng e. Em tenê hewce ne ku komek nû ji hilanînê bar bikin.
Bi gelemperî, dema ku girêkek nû lê zêde dikin, pêdivî ye ku em performansa pergala paşvekêşanê ne. Çima girîng e? Bi gelemperî mirov girêkek nû li komekê zêde dikin ji ber ku koma heyî nikare barkirina xwendinê bi rê ve bibe. Pêdivî ye ku ew kopiyek nû lê zêde bikin. Ger em barkirina pg_basebackup li Master zêde bikin, wê hingê dibe ku Master hilweşe. Ji ber vê yekê, ji bo me pir girîng bû ku em bi lez girêkek nû ji arşîvê bar bikin, barkirina hindiktirîn li ser Master biafirînin.
Û rewşeke din a bi vî rengî. Ev pêdivî ye ku piştî guheztina Master Cluster ji Navenda Daneyê ya ku pêwendiya pê re winda bû, Mastera kevn ji nû ve bidin destpêkirin.
- Wekî encamek, dema ku hewcedariyên pergala kopîkirinê formule dike, me fêm kir ku pg_basebackup dema ku di ewr de xebitîne ji me re ne maqûl e.
- Me xwest ku em karibin daneyên xwe berhev bikin. Lê hema hema her pergalek hilanînê ji bilî ya ku di nav qutikê de tê dê berhevkirina daneyê peyda bike.
- Me dixwest ku her tiştî paralel bikin ji ber ku bikarhênerek di ewr de hejmareke mezin ji navgînên pêvajoyê bikire. Lê heke di hin operasyonan de paralelîzma me tune be, wê hingê hejmareke mezin a koran bêkêr dibe.
- Pêdiviya me bi şîfrekirinê heye ji ber ku pir caran dane ne ya me ne û di nivîsa zelal de nayê hilanîn. Bi awayê, beşdariya me ya WAL-G bi şîfrekirinê dest pê kir. Me şîfrekirina di WAL-G de qedand, piştî ku ji me hat pirsîn: "Dibe ku yek ji me projeyê pêşve bibe?" Û ji hingê ve ez zêdetirî salekê bi WAL-G re dixebitim.
- Di heman demê de hewcedariya me bi qutkirina çavkaniyê hebû, ji ber ku bi demê re bi karanîna ewr re, me fêhm kir ku carinan carinan mirov bi şev xwedan bargiraniyek girîng a kirrûbirrê ye û ev bar nikare were asteng kirin. Ji ber vê yekê me qutkirina çavkaniyê lê zêde kir.
- Her weha navnîş û rêveberî.
- Û verastkirin.
Me li gelek amûrên cihê nihêrî. Xwezî, me di PostgreSQL de hilbijartinek mezin heye. Û li her derê me tiştek winda dikir, hin fonksiyonek piçûk, hin taybetmendiyek piçûk.
Û piştî ku pergalên heyî lêkolîn kirin, em gihîştin vê encamê ku em ê WAL-G pêşve bibin. Wê demê ew projeyek nû bû. Pir hêsan bû ku bandor li pêşkeftina berbi binesaziya ewr a pergala paşvekêşanê bike.
Îdeolojiya sereke ya ku em pê dipejirînin ev e ku WAL-G divê wekî balalaika hêsan be.
WAL-G 4 ferman hene. Ev:
WAL-PUSH - şaftê arşîv bike.
WAL-FETCH - şaftek bistînin.
BACKUP-PUSH - hilanînê çêbikin.
BACKUP-FETCH - ji pergala hilanînê hilanînê bistînin.
Di rastiyê de, WAL-G di heman demê de rêveberiya van paşkêşan jî heye, ango navnîşkirin û jêbirina tomar û paşkêşên di dîrokê de yên ku êdî hewce ne hewce ne.
Yek ji fonksiyonên girîng ji bo me fonksiyona afirandina kopiyên delta ye.
Kopiyên Delta tê vê wateyê ku em ji tevahiya komê kopiyek tam naafirînin, lê tenê rûpelên guheztin ên pelên guhertî yên di komê de çêdikin. Wusa dixuye ku ji hêla fonksiyonel ve ev pir dişibe şiyana ku bi karanîna WAL-ê vegere. Lê em dikarin pabendek delta-ya yek-têl a WAL-ê bi paralelî vekin. Li gorî vê yekê, dema ku roja şemiyê paşvekêşek bingehîn a me hatî çêkirin, rojane paşvekêşana delta, û roja Pêncşemê em têk diçin, wê hingê pêdivî ye ku em 4 paşkêşên delta û 10 demjimêrên WAL-ê berhev bikin. Ew ê di heman demê de bigire ji ber ku paşvekêşên delta bi hev re dizivirin.
Deltayên-based LSN - ev tê vê wateyê ku dema hilanînê çêdikin, em ê hewce bikin ku her rûpelê bi hev re bikin û LSN-ya wê bi LSN-ya paşvekêşana berê re kontrol bikin da ku fêm bikin ku ew guheriye. Her rûpelek ku bi potansiyel dikare daneya guhertî hebe, divê di hilgirtina deltayê de hebe.
Weke ku min got, pir girîngî dan paralelîzmê.
Lê arşîva API-ya li PostgreSQL domdar e. PostgreSQL pelek WAL-ê arşîv dike û dema ku nûve dike pelek WAL daxwaz dike. Lê gava ku databas bi karanîna fermana "WAL-FETCH" pelek WAL-ê daxwaz dike, em gazî fermana "WAL-PREFETCH" dikin, ku 8 pelên din amade dike da ku daneyan ji depoya objeyê bi paralelî bigire.
Û gava ku databas ji me dipirse ku em pelek arşîv bikin, em li archive_status dinêrin û dibînin ka pelên WAL yên din hene. Û em jî hewl didin ku WAL paralel dakêşin. Ev qezencek performansê ya girîng peyda dike û bi girîngî dûrahiya di hejmara WAL-ên nearşîv de kêm dike. Pir pêşdebirên pergala paşvekişandinê bawer dikin ku ev pergalek wusa xeternak e ji ber ku em xwe dispêrin zanîna xwe ya hundurê kodê ku ne PostgreSQL API ye. PostgreSQL hebûna peldanka archive_status ji bo me garantî nake û semantîk, hebûna îşaretên amadebûnê ji bo pelên WAL li wir garantî nake. Lêbelê, em koda çavkaniyê dixwînin, em dibînin ku wusa ye û em hewl didin ku wê îstismar bikin. Û em rêça ku PostgreSQL tê de pêş dikeve kontrol dikin; heke ji nişka ve ev mekanîzma têk biçe, em ê dev ji karanîna wê berdin.
Di forma xweya paqij de, deltaya WAL-a-based LSN hewce dike ku pelê komê ku moda-dema wê di pergala pelê de ji paşvekêşana berê ve hatî guhertin were xwendin. Em demek dirêj, hema salek bi vê re jiyan. Û di dawiyê de em gihîştin vê encamê ku me deltayên WAL hene.
Ev tê wê wateyê ku her gava ku em WAL-ê li ser Master arşîv dikin, em ne tenê wê kom dikin, şîfre dikin û dişînin torê, lê em di heman demê de jî dixwînin. Em qeydên tê de analîz dikin û dixwînin. Em fêm dikin ka kîjan blokan hatine guhertin û pelên delta berhev dikin.
Pelek delta rêzek pelên WAL-ê vedibêje, agahdariya li ser kîjan blokan di vê rêza WAL-ê de hatine guheztin diyar dike. Û paşê ev pelên delta jî têne arşîv kirin.
Li vir em bi vê rastiyê re rû bi rû ne ku me her tişt zû paralel kir, lê em nekarin dîrokek rêzdar bi paralelî bixwînin, ji ber ku di beşek diyarkirî de dibe ku em bi dawiya qeyda WAL-ê ya berê re rûbirû bibin, ku hêj tiştek me tune ku pê ve girêbidin, ji ber ku xwendina paralel bû sedem ku em pêşî paşeroja ku hîna paşeroja wê tune ye analîz bikin.
Wekî encamek, me neçar ma ku perçeyên nefêmkirî bixin nav pelên _delta_partial. Wekî encamek, gava ku em vegerin paşerojê, em ê perçeyên tomara WAL-ê bixin yek, pişt re em ê wê parsek bikin û fêm bikin ka çi tê de guherî.
Ger di dîroka parskirina şafta me de bi kêmanî xalek hebe ku em fêm nakin ka çi diqewime, wê hingê, li gorî vê yekê, di dema paşvekişandina din de em ê neçar bimînin ku dîsa tevahî komê bixwînin, mîna ku me bi LSN-ya birêkûpêk kir. -based delta.
Wekî encamek, hemî êşên me rê li ber vê yekê vekir ku me pirtûkxaneya parskirina WAL-G-çavkaniyê vekir. Bi qasê ku ez dizanim, heta niha kes bikar nayîne, lê eger kesek bixwaze, binivîse û bikar bîne, di nav raya giştî de ye. (Girêdana nûvekirî )
Wekî encamek, hemî herikîna agahdariyê pir tevlihev xuya dikin. Masterê me şaft û pelên delta arşîv dike. Û kopyaya ku kopiya hilanînê çêdike divê pelên deltayê di dema ku di navbera hilanînê de derbas bûye werbigire. Di vê rewşê de, dê beşên dîrokê bi girseyî werin zêdekirin û parkirin, ji ber ku tevahiya dîrok di beşên mezin de cih nagire. Û tenê piştî vê yekê replica dikare kopiyek delta ya tevahî arşîv bike.
Li ser grafikan her tişt pir hêsan xuya dike. Ev dakêşînek ji yek ji komên me yên rastîn e. Me bingeha LSN-ê heye, ku di rojekê de hatî çêkirin. Û em dibînin ku paşvekêşana delta ya LSN-ê ji sê sibehê heya pêncê sibehê dimeşiya. Ev bargiraniya di hejmara navikên pêvajoyê de ye. WAL-delta li vir 20 hûrdeman me girt, Ango ew pir zûtir bû, lê di heman demê de li ser torê danûstendinek tundtir hebû.
Ji ber ku me agahdarî di derheqê kîjan blokan de guherand û di kîjan wextê de di dîroka databasê de heye, me pêş de çû û me biryar da ku fonksiyonê yek bikin - pêvekek PostgreSQL bi navê "pg_prefaulter"
Ev tê vê wateyê ku dema ku bingeha stand-by fermana vegerandinê pêk tîne, ew ji WAL-G re dibêje ku pelê WAL-a din bîne. Em bi qasî fêm dikin ka kîjan daneyan asteng dike ku pêvajoya vegerandina WAL-ê dê di pêşerojek nêzîk de bigihîje û li ser van blokan xebatek xwendinê bide destpêkirin. Ev ji bo zêdekirina performansa kontrolkerên SSD hate kirin. Ji ber ku pelika WAL dê bigihîje rûpela ku divê were guheztin. Ev rûpel li ser dîskê ye û ne di cache ya rûpelê de ye. Û ew ê bi hevdemî li benda gihîştina vê rûpelê bimîne. Lê nêzîkê WAL-G ye, ku dizane ku di çend sed megabaytên din ên WAL-ê de em ê hewceyê hin rûpelan bin û di heman demê de dest bi germkirina wan dike. Gelek gihîştina dîskê dest pê dike da ku ew bi paralelî bêne darve kirin. Ev li ser ajokarên SSD-ê baş dixebite, lê, mixabin, ew ji bo ajokerek hişk bi tevahî nayê sepandin, ji ber ku em tenê bi daxwazên xwe re mudaxele dikin.
Ya ku niha di kodê de ye ev e.
Taybetmendiyên ku em dixwazin lê zêde bikin hene.
Ev wêne nîşan dide ku WAL-delta demek hindik kurt digire. Û ev xwendina guhertinên ku di nav rojê de di databasê de qewimîne ye. Em dikarin WAL-delta ne tenê bi şev bikin, ji ber ku ew êdî çavkaniyek girîng a barkirinê ye. Em dikarin her hûrdem WAL-delta bixwînin ji ber ku ew erzan e. Di yek hûrdemê de em dikarin hemî guhertinên ku di komê de qewimîne bişopînin. Û ev dikare were gotin "WAL-delta tavilê".
Mesele ev e ku dema ku em komê nûve dikin, em hejmara çîrokên ku divê em bi dû hev bicivînin kêm dikin. Ango, mîqdara WAL-a ku PostgreSQL dirijîne divê were kêm kirin, ji ber ku ew demek girîng digire.
Lê ev ne hemû ye. Ger em zanibin ku hin blok dê heya xala domdariya paşvekêşanê were guheztin, em nikanin wê di paşerojê de biguhezînin. Ango, naha me xweşbîniya pel-bi-pelê ya şandina WAL-delta heye. Ev tê vê wateyê ku heke, bo nimûne, roja Sêşemê hin tablo bi tevahî hate jêbirin an hin pel bi tevahî ji tabloyê hatin jêbirin, wê hingê gava ku delta roja Duşem û Şemiyê were vegerandin pg_basebackup, em ê vê daneyê jî neafirînin.
Em dixwazin vê teknolojiyê di asta rûpelê de dirêj bikin. Ango, heke hin beşek pelê roja Duşemê biguhere, lê dê roja Çarşemê were nivîsandin, wê hingê dema ku roja Pêncşemê li xalek vegere, ne hewce ye ku em çend guhertoyên yekem ên rûpelan li ser dîskê binivîsin.
Lê ev hîn jî fikrek e ku di nava me de bi awayekî aktîf tê nîqaşkirin, lê hîn negihîştiye kodê.
Em dixwazin di WAL-G de taybetmendiyek din çêbikin. Em dixwazin wê berfireh bikin ji ber ku em hewce ne ku em databasên cihêreng piştgirî bikin û em dixwazin bi heman awayî nêzikî rêveberiya hilanînê bibin. Lê pirsgirêk ev e ku MySQL API-yên radîkal cuda ne. Di MySQL de, PITR ne li ser têketina WAL a laşî, lê li ser binlogê ye. Û me di MySQL de pergalek arşîvkirinê tune ku ji hin pergalên derveyî re bibêje ku ev binlog qediya ye û pêdivî ye ku were arşîvkirin. Pêdivî ye ku em li cîhek di nav databasê de bisekinin û kontrol bikin ka tiştek amade heye?
Û bi heman awayî, di dema nûvekirina MySQL-ê de, fermanek vegerandinê tune ku dikare ji pergalê re bibêje ku ez hewceyê pelên wusa û wusa ne. Berî ku hûn dest bi avakirina koma xwe bikin, hûn hewce ne ku hûn zanibin ka hûn ê hewceyê kîjan pelan bikin. Hûn bi xwe hewce ne ku texmîn bikin ka hûn ê çi pelan hewce bikin. Lê dibe ku ev pirsgirêk bi rengekî werin dorpêç kirin. (Raşkirin: MySQL jixwe piştgirî ye)
Di raporê de, min jî xwest ku behsa wan rewşan bikim ku WAL-G ji we re ne guncaw e.
Heke we kopiyek hevdem tune be, WAL-G garantî nake ku dê beşa paşîn were parastin. Û heke arşîvkirin li paş çend beşên dawî yên dîrokê bimîne, ew xeterek e. Ger kopiyek hevdem tune, ez ê WAL-G bikar neynin pêşniyar bikim. Dîsa jî, ew bi piranî ji bo sazkirina ewr hatî sêwirandin, ku tê vê wateyê ku çareseriyek Berdestbûna Bilind bi kopiyek hevdemî re, ku ji ewlehiya baytên paşîn ên ku hatine peywirdarkirin berpirsiyar e.
Ez gelek caran dibînim ku mirovên ku hewl didin di heman demê de hem WAL-G û hem jî WAL-E bimeşînin. Em piştgirî didin lihevhatina paşverû di vê wateyê de ku WAL-G dikare pelek ji WAL-E vegerîne û dikare hilanînê ku di WAL-E de hatî çêkirin vegerîne. Lê ji ber ku van her du pergalên wal-push paralel bikar tînin, ew dest bi dizîna pelan ji hev dikin. Ger em wê di WAL-G de rast bikin, ew ê hîn jî di WAL-E de bimîne. Di WAL-E de, ew li arşîv-statûyê dinêre, pelên qedandî dibîne û wan arşîv dike, dema ku pergalên din bi hêsanî nizanin ku ev pelê WAL heye, ji ber ku PostgreSQL dê carek din hewl nede ku wê arşîv bike.
Em ê li vir li aliyê WAL-G çi rast bikin? Em ê ji PostgreSQL re agahdar nekin ku ev pel bi paralelî hate veguheztin, û gava PostgreSQL ji me bixwaze ku wê arşîv bikin, em ê jixwe zanibin ku pelek weha bi vê mod-demê û bi vê md5-ê jixwe hatî arşîv kirin û em ê bi tenê bibêjin PostgreSQL - OK, her tişt amade ye bêyî ku bi bingehîn tiştek bikin.
Lê ev pirsgirêk ne mimkûn e ku li alîyê WAL-E were çareser kirin, ji ber vê yekê ne gengaz e ku meriv fermanek arşîvê biafirîne ku pelê hem di WAL-G û hem jî di WAL-E de arşîv bike.
Wekî din, rewş hene ku WAL-G naha ji we re ne maqûl e, lê em ê bê guman wê rast bikin.
Pêşîn, me niha verastkirina hilanînê ya çêkirî tune. Em ne di dema hilanînê û ne jî verastkirinê de verastkirin tune. Bê guman, ev di ewr de tête kirin. Lê ev bi tenê bi pêş-kontrolkirinê, bi tenê bi vegerandina komê tê pêkanîn. Ez dixwazim vê fonksiyonê bidim bikarhêneran. Lê ji hêla verastkirinê ve, ez texmîn dikim ku di WAL-G de ew ê gengaz be ku komê vegerîne û dest pê bike, û ceribandinên dûmanê bimeşîne: pg_dumpall li /dev/null û verastkirina navnîşê amcheck.
Heya niha di WAL-G de rê tune ku yek paşvekêşana ji WAL were paşxistin. Ango, em hin pencereyê piştgirî dikin. Mînakî, hilanîna heft rojên paşîn, hilanîna deh paşkêşên paşîn, hilanîna sê paşkêşên paşîn ên tevahî. Pir caran mirov têne û dibêjin: "Pêdiviya me bi paşvekişandina tiştê ku di sersalê de qewimî û em dixwazin wê her û her bihêlin." WAL-G hîn nikare vê yekê bike. (Têbînî - Ev jixwe hatî rast kirin. Zêdetir bixwînin - Vebijarka Backup-markê tê de )
Û dema ku PITR-ê rast dikin, ji bo hemî beşên şaftê vekolînên rûpelê û kontrolên yekrêziyê tune.
Ji van hemîyan min ji bo Google Summer of Code projeyek berhev kir. Ger hûn xwendekarên jîr dizanin ku dixwazin di Go de tiştek binivîsin û ji yek pargîdaniyek bi tîpa "G" çend hezar dolar bistînin, wê hingê projeya me ji wan re pêşniyar bikin. Ez ê ji bo vê projeyê wekî şêwirmendê bikim, ew dikarin bikin. Ger xwendekar nebin, wê demê ez ê bigirim û havînê bi xwe bikim.
Û gelek pirsgirêkên me yên din ên piçûk hene ku em gav bi gav li ser dixebitin. Û hin tiştên pir ecêb diqewimin.
Mînakî, heke hûn WAL-G paşgirek vala bidin, ew ê bi hêsanî têkeve. Mînakî, heke hûn jê re bibêjin ku ew pêdivî ye ku peldankek vala paşvekişîne. Pelê pg_control ê tune be. Û ew ê bifikire ku ew tiştek fêm nake. Di teoriyê de, di vê rewşê de hûn hewce ne ku ji bikarhêner re peyamek normal binivîsin da ku jê re rave bikin ka meriv çawa amûrê bikar tîne. Lê ev jî ne taybetmendiya bernamesaziyê ye, lê taybetmendiya zimanekî baş û têgihîştî ye.
Em nizanin çawa paşvekêşana offline bikin. Ger databas derew be, em nikanin wê piştgir bikin. Lê her tişt li vir pir hêsan e. Dema ku ew dest pê kir em ji hêla LSN-ê ve piştgiran vedixwînin. Pêdivî ye ku LSN-ya bingeha bingehîn ji pelê kontrolê were xwendin. Û ev taybetmendiyek wusa nenas e. Gelek pergalên hilanînê dikarin databasek bingehîn paşve bikin. Û ew hêsan e.
Em niha nikarin kêmbûna cîhê paşvekêşanê bi rêkûpêk bi rê ve bibin. Ji ber ku em bi gelemperî li malê bi paşkêşên mezin re dixebitin. Û li dora wê neçûn. Lê heke kesek bixwaze niha di Go de bername bike, ji bo xeletiyên derveyî cîhê hilanînê li kekê zêde bike. Ez ê bê guman li daxwaza kişandinê bigerim.
Tişta sereke ya ku me ditirsîne ev e ku em bi qasî ku gengaz ceribandinên entegrasyona docker dixwazin ku senaryoyên cihêreng kontrol dikin. Naha em tenê senaryoyên bingehîn diceribînin. Li ser her commit, lê em dixwazin commit-by-commit hemî fonksiyonên ku em piştgirî dikin kontrol bikin. Bi taybetî, mînakî, em ê ji bo PostgreSQL 9.4-9.5 bi têra xwe piştgirî bin. Em piştgirîya wan dikin ji ber ku civak piştgirî dide PostgreSQL, lê em commit-by-commit kontrol nakin da ku pê ewle bibin ku her tişt neşikestî ye. Û ji min re xuya dike ku ev xeterek cidî ye.
Me WAL-G heye ku di rêveberiya Database ya Yandex de li ser zêdetirî hezar koman dixebitin. Û ew her roj çend sed terabytes daneyê piştguh dike.
Di koda me de gelek TODO hene. Ger hûn dixwazin bername bikin, werin, em li benda daxwazên kişandinê ne, em li benda pirsan in.
Pirsên
Êvar baş! Sipas ji were! Texmîna min ev e ku heke hûn WAL-delta bikar tînin, dibe ku hûn bi giranî xwe bispêrin nivîsên tev-rûpel. Û heke wusa be, we ceribandinan kir? Te grafikek xweş nîşan da. Ger FPW were girtin çiqas xweştir dibe?
Nivîsandina tev-rûpel ji bo me çalak e, me hewl nedaye ku wê neçalak bikin. Ango, min wekî pêşvebirek, hewl nedaye ku wê qut bikim. Rêvebirên pergalê yên ku lêkolîn kirine belkî vê mijarê lêkolîn kirine. Lê pêwîstiya me bi FPW heye. Hema tu kes wê neçalak nake, ji ber ku wekî din ne gengaz e ku meriv ji kopiyek paşvekêşanê bigire.
Spas ji bo raporê! Du pirsên min hene. Pirsa yekem ev e ku dê çi bibe serê sifrê?
Em li benda daxwaza vekişînê ne. Databasên me li ser dîskên SSD û NMVE dijîn û em bi rastî ne hewceyê vê taybetmendiyê ne. Ez ne amade me ku niha ji bo başkirina wê demek ciddî derbas bikim. Ez bi dil û can piştgirî didim vê yekê. Kesên ku piştgirî dan wê hene, lê bi rengekî ku li gorî wan tê piştgirî kirin. Çalek çêkirine, lê daxwazên kişandinê nakin. (Di guhertoya 0.2.13 de hate zêdekirin)
Û pirsa duyemîn. We di destpêkê de got ku WAL-G dihesibîne ku ew bi tena serê xwe dixebite û pêçan hewce nake. Ez bixwe pêçanan bikar tînim. Çima neyên bikaranîn?
Em dixwazin ku ew wekî balalaika hêsan be. Ev tê vê wateyê ku hûn ji bilî balalaika qet tiştek ne hewce ne. Em dixwazin sîstem sade be. Ger fonksiyonên we hene ku hûn hewce ne ku di skrîptekê de bikin, wê hingê werin û ji me re bibêjin - em ê di Go de bikin.
Êvar baş! Spas ji bo raporê! Me nekarî ku WAL-G bi deşîfrekirina GPG re bixebite. Ew bi gelemperî şîfre dike, lê naxwaze şîfre bike. Ma ew tiştek ku ji me re nekiriye? Rewş xemgîn e.
Pirsgirêkek li ser GitHub biafirînin û werin em wê fêhm bikin.
Ango, hûn bi vê yekê re rû bi rû nebûn?
Taybetmendiyek rapora xeletiyê heye ku gava WAL-G fam nake ka pelek çi ye, dipirse: "Dibe ku ew şîfrekirî ye?" Dibe ku pirsgirêk qet ne şîfrekirin e. Ez dixwazim têketinê li ser vê mijarê baştir bikim. Divê ew deşîfre bike. Em niha li ser vê mijarê dixebitin di vê wateyê de ku em bi rastî hez nakin ka pergala wergirtina mifteyên giştî û taybet çawa tê organîze kirin. Ji ber ku em ji derve re dibêjin GPG da ku ew mifteyên xwe bide me. Dûv re em van kilîtan digirin û wan vediguhezînin GPG-ya hundurîn, ku PGP-ya vekirî ye, ku ji bo me di hundurê WAL-G-ê de hatî berhev kirin, û li wir em jê re dibêjin şîfrekirin. Di vî warî de, em dixwazin pergalê baştir bikin û dixwazin şîfrekirina Libsodium piştgirî bikin (Di guhertoya 0.2.15 de hatî zêdekirin). Bê guman, deşîfrekirin divê bixebite, ka em wê fêhm bikin - hûn ji çend peyvan bêtir nîşanek hewce ne. Hûn dikarin carinan li odeya axaftvan kom bibin û li pergalê binêrin. (Şîfrekirina PGP bêyî GPG-ya derveyî - v0.2.9)
Slav! Spas ji bo raporê! Du pirsên min hene. Daxwazek min a xerîb heye ku ez pg_basebackup bikim û WAL têkevim du pêşkêşvanan, ango ez dixwazim yek ewr û ya din bikim. Ma rêyek ji bo vê yekê heye?
Ev niha tune, lê ew ramanek balkêş e.
Ez tenê ji pêşkêşvanek bawer nakim, ez dixwazim di yekî din de heman tiştî hebe, tenê di rewşê de.
Fikir balkêş e. Ji hêla teknîkî ve, pêkanîna vê yekê qet ne dijwar e. Ji bo ku raman winda nebe, ez dikarim ji we bipirsim ku hûn li ser GitHub pirsgirêkek çêbikin?
Erê, bê guman.
Û paşê, gava ku xwendekar werin Google Summer of Code, em ê wan li projeyê zêde bikin da ku bêtir kar hebe ku bêtir ji wan bistînin.
Û pirsa duyemîn. Pirsgirêkek li ser GitHub heye. Ez difikirim ku ew jixwe girtî ye. Di dema restorekirinê de panîk heye. Û ji bo têkbirina wê, we meclîsek cuda çêkir. Di mijaran de rast e. Û vebijarkek heye ku meriv jîngehek guhêrbar di yek mijarê de bike. Û ji ber vê yekê ew pir hêdî dixebite. Û em rastî vê pirsgirêkê hatin, û ew hîn nehatiye çareser kirin.
Pirsgirêk ev e ku ji ber hin sedeman hilanînê (CEPH) dema ku em bi hevdemîyek bilind ve werin pêwendiyê ji nû ve vedike. Di derbarê vê de çi dikare were kirin? Mantiqa ji nû ve ceribandinê wiha xuya dike. Em hewl didin ku pelê dîsa dakêşin. Di yek derbasbûnê de, me gelek pelên ku nehatine dakêşandin hebûn, em ê ji bo hemî kesên ku têketî nebûn yeka duyemîn çêbikin. Û heta ku bi kêmanî yek pel di her dubarekirinê de were barkirin, em dubare dikin û dubare dikin û dubare dikin. Me mantiqa ji nû ve ceribandinê baştir kir - paşvekêşana berbiçav. Lê bi tevahî ne diyar e ku meriv bi vê yekê re çi bike ku pêwendiya bi tenê li aliyê pergala hilanînê têk diçe. Ango dema ku em li yek çemekî bar dikin, ew van têkiliyan qut nake. Em dikarin li vir çi çêtir bikin? Di me de qutkirina torê heye, em dikarin her pêwendiyê bi hejmara baytên ku ew dişîne sînordar bikin. Wekî din, ez nizanim meriv çawa bi vê yekê re mijûl dibe ku hilanîna tiştan rê nade me ku em jê paralel dakêşin an dakêşin.
SLA tune? Ma ji wan re nehatiye nivîsandin ku ew çawa destûr didin ku xwe biêşînin?
Mesele ev e ku kesên ku vê pirsê tînin serê xwe bi gelemperî xwedan kavilek xwe ne. Ango, kes ji Amazon an Google Cloud an Storage Object Yandex nayê.
Dibe ku pirs êdî ne ji bo we be?
Pirsa li vir di vê rewşê de ji kê re ne girîng e. Ger ramanek li ser meriv çawa bi vê yekê re mijûl bibe hene, bila di WAL-G de bikin. Lê heta niha min fikrên baş tune ku meriv çawa bi vê yekê re mijûl bibe. Hin Depoyên Objekt hene ku paşgirên navnîşê bi rengek cûda piştgirî dikin. Hûn ji wan dipirsin ku tiştan navnîş bikin, û ew peldankê li wir zêde dikin. WAL-G ji vê yekê ditirse - li vir celebek tiştek heye ku ne pelek e, ez nikarim wê vegerînim, ku tê vê wateyê ku paşvekişandin nehatiye sererast kirin. Ango, bi rastî, we komek bi tevahî hatî vegerandin heye, lê ew ji we re rewşek xelet vedigerîne ji ber ku Object Storage hin agahdariya ecêb ên ku ew bi tevahî fêm nekir vedigere.
Ev tiştek e ku di ewrê Mail de diqewime.
Heke hûn dikarin ji nû ve hilberandinê ava bikin ...
Ew bi domdarî tê nûve kirin ...
Ger nûvekirinek hebe, wê hingê ez difikirim ku em ê bi stratejiyên dubare ceribandinê biceribînin û fêr bibin ka meriv çawa ji nû ve biceribîne û fam bike ka ewr ji me çi hewce dike. Dibe ku ew ji me re li ser sê girêdanan îstîqrar be û pêwendiyê qut neke, wê hingê em ê bi baldarî bigihîjin sê girêdan. Ji ber ku naha em pir zû pêwendiyê davêjin, ango heke me bi 16 mijaran vesaziyek da destpêkirin, wê hingê piştî ceribandina yekem dê 8 têl, 4 têl, 2 têl û yek hebin. Û paşê ew ê pelê bikişîne nav yek stream. Ger hin nirxên efsûnî hebin, wekî 7,5 têlên ji bo pompkirinê çêtirîn in, wê hingê em ê li ser wan bisekinin û hewl bidin ku 7,5 têlên din çêbikin. Li vir ramanek heye.
Spas ji bo raporê! Xebatek bêkêmasî ya ji bo xebata bi WAL-G re çawa xuya dike? Mînakî, di bûyera ehmeqî de dema ku li seranserê rûpelan delta tune. Û em paşgira destpêkê digirin û jê radikin, dûv re şaftê arşîv dikin heya ku em di rûyê xwe de şîn bin. Li vir, bi qasî ku ez têdigihim, şikestinek heye. Di hin xalan de hûn hewce ne ku ji rûpelan vekêşana delta çêbikin, ango hin pêvajoyek derveyî vê yekê dimeşîne an ev çawa dibe?
API-ya hilanînê ya delta pir hêsan e. Li wir jimarek heye - gavên delta ya herî zêde, ya ku jê re tê gotin ev e. Ew ji bo sifirê ye. Ev tê vê wateyê ku her gava ku hûn paşvekêşek-pushek dikin, ew hilanînê tam dadixe. Ger hûn wê bi jimareyek erênî biguhezînin, mînakî, 3, wê hingê gava ku hûn paşvekêşek-push bikin, ew li dîroka paşkêşên berê dinêre. Ew dibîne ku hûn ji zincîra 3 deltayan derbas nabin û deltayekê çêdike.
Ango, her gava ku em WAL-G-ê dest pê dikin, ew hewl dide ku paşvekêşek tevahî çêbike?
Na, em WAL-G-ê dimeşînin, û ger polîtîkayên we destûrê bidin ew hewl dide ku deltayek çêbike.
Bi gelemperî, heke hûn her carê wê bi sifirê bimeşînin, ew ê mîna pg_basebackup tevbigere?
Na, ew ê dîsa jî zûtir bimeşîne ji ber ku ew çewisandin û paralelîzmê bikar tîne. Pg_basebackup dê mîlî li tenişta we bike. WAL-G texmîn dike ku we arşîvkirin mîheng kiriye. Û heke ew neyê mîheng kirin dê hişyariyek bide.
Pg_basebackup dikare bêyî şaftan were meşandin.
Erê, wê hingê ew ê hema hema bi heman rengî tevbigerin. Pg_basebackup li pergala pelê kopî dike. Bi awayê, me taybetmendiyek nû heye ku min ji bîr kir ku behs bikim. Naha em dikarin ji pg_basebackup li pergala pelan paşve bikin. Ez nizanim çima ev hewce ye, lê ew li wir e.
Mînakî, li ser CephFS. Ne her kes naxwaze ku Object Storage mîheng bike.
Erê, dibe ku ji ber vê yekê wan pirsek li ser vê taybetmendiyê pirsî da ku em wiya bikin. Û me ew kir.
Spas ji bo raporê! Tenê pirsek li ser kopîkirina pergala pelan heye. Ji derveyî qutiyê, ma hûn naha piştgirî didin kopîkirina li hilanîna dûr, mînakî, heke di navenda daneyê de refikek hebe an tiştek din?
Di vê formulasyonê de, ev pirsek dijwar e. Erê, em piştgirî dikin, lê ev fonksiyon hîn di tu serbestberdanê de tune ye. Ango, hemî pêşdibistanên vê yekê piştgirî dikin, lê guhertoyên berdanê nakin. Ev fonksiyon di guhertoya 0.2 de hate zêdekirin. Ew ê bê guman di demek nêzîk de were berdan, gava ku em hemî xeletiyên naskirî rast bikin. Lê aniha ev tenê di pêş-serbestberdanê de dikare were kirin. Di pêşbirkê de du xeletî hene. Pirsgirêka başkirina WAL-E, me ew rast nekiriye. Û di pêş-serbestberdana herî dawî de xeletiyek di derbarê delta-backup de hate zêdekirin. Ji ber vê yekê, em ji her kesî re pêşniyar dikin ku guhertoyên berdanê bikar bînin. Mîna ku di pêş-serbestberdanê de bêtir xeletî tune ne, em dikarin bibêjin ku em piştgirî didin Google Cloud, tiştên S3-lihevhatî û hilanîna pelan.
Silav, spas ji bo raporê. Wekî ku ez jê fam dikim, WAL-G ne cûreyek pergala navendîparêz e mîna barmen? Ma hûn plan dikin ku di vî alî de bimeşin?
Pirsgirêk ev e ku em ji vê rêyê dûr ketine. WAL-G li ser mêvandarê bingehîn, li ser mêvandarê komê, û li ser hemî mêvandarên di komê de dijî. Dema ku em çûn çend hezar koman, me gelek sazgehên barman hebûn. Û her cara ku tiştek di nav wan de hilweşe, ew pirsgirêkek mezin e. Ji ber ku ew hewce ne ku werin tamîr kirin, hûn hewce ne ku fêm bikin ka kîjan kom naha paşvekêşan tune. Ez plan nakim ku WAL-G di rêça hardware ya laşî de ji bo pergalên paşvekêşanê pêşve bixim. Ger civak li vir hin fonksiyonan bixwaze, ez qet aciz nabim.
Tîmên me hene ku ji hilanînê berpirsiyar in. Û em xwe ew qas baş hîs dikin ku ew ne em in, ku mirovên taybetî hene ku pelên me dixin cihê ku pelan ewle ne. Ew li wir her cûre kodkirina jîr dikin da ku li ber windabûna hejmarek pelan bisekinin. Ew ji berfirehiya torê berpirsiyar in. Gava ku we bartenderek heye, dibe ku hûn ji nişkê ve fêr bibin ku databasên piçûk ên bi seyrûseferek pir li ser heman serverê kom bûne. Wusa dixuye ku hûn li ser wê pir cîh heye, lê ji ber hin sedeman her tişt bi torê re derbas nabe. Dibe ku ew bi awayekî din derkeve holê. Li wir gelek torgilok hene, navgînên pêvajoyê hene, lê li vir dîsk tune. Û em ji vê hewcedariya ku em tiştek bişopînin westiyan, û me ber bi vê yekê ve çû ku hilanîna daneyê karûbarek cihê ye, ku ji bo wê kesên taybetî yên cihê berpirsiyar in.
PS Guhertoyek nû derket , ku tê de hûn dikarin pelê veavakirinê .walg.json bikar bînin, ku ji hêla xwerû ve di pelrêça malê ya postgres de cih digire. Hûn dikarin skrîptên bash berdin. Mînak .walg.json di vê hejmarê de ye
Video:
Source: www.habr.com