Awgrymaf eich bod yn darllen trawsgrifiad yr adroddiad o ddechrau 2019 gan Andrey Borodin “Gwneud copïau wrth gefn gyda WAL-G. Beth sydd yna yn 2019?”
Helo pawb! Fy enw i yw Andrey Borodin. Rwy'n ddatblygwr yn Yandex. Rwyf wedi bod â diddordeb yn PostgreSQL ers 2016, ar ôl i mi siarad â'r datblygwyr a dywedasant fod popeth yn syml - rydych chi'n cymryd y cod ffynhonnell a'i adeiladu, a bydd popeth yn gweithio allan. Ac ers hynny ni allaf stopio - rwy'n ysgrifennu pob math o bethau gwahanol.
Un o'r pethau rwy'n gweithio arno yw system wrth gefn. . Yn gyffredinol, yn Yandex rydym wedi bod yn gweithio ar systemau wrth gefn yn PostgreSQL ers amser maith. A gallwch ddod o hyd i gyfres o chwe adroddiad ar y Rhyngrwyd ar sut rydym yn gwneud systemau wrth gefn. A phob blwyddyn maen nhw'n esblygu ychydig, yn datblygu ychydig, ac yn dod yn fwy dibynadwy.
Ond heddiw mae’r adroddiad nid yn unig yn ymwneud â’r hyn rydym wedi’i wneud, ond hefyd yn ymwneud â pha mor syml ydyw a beth yw. Faint ohonoch sydd eisoes wedi gwylio fy adroddiadau am WAL-G? Mae'n dda nad oedd cryn dipyn o bobl yn gwylio, oherwydd fe ddechreuaf gyda'r peth symlaf.
Os yn sydyn mae gennych glwstwr PostgreSQL, a chredaf fod gan bawb un neu ddau ohonynt gyda nhw, ac yn sydyn nid oes system wrth gefn eto, yna mae angen i chi gael unrhyw storfa S3 neu storfa gydnaws Google Cloud.
Er enghraifft, gallwch ddod i'n stondin a chymryd cod hyrwyddo ar gyfer Yandex Object Storage, sy'n gydnaws â S3.
Yna creu bwced. Dim ond cynhwysydd er gwybodaeth ydyw.
Creu defnyddiwr gwasanaeth.
Creu allwedd mynediad ar gyfer y defnyddiwr gwasanaeth: aws-s3-key.
Dadlwythwch y datganiad sefydlog diweddaraf o WAL-G.
Sut mae ein rhag-ryddiadau yn wahanol i ddatganiadau? Yn aml, gofynnir i mi ryddhau'n gynnar. Ac os nad oes nam yn y fersiwn am amser digonol, er enghraifft, mis, yna rwy'n ei ryddhau. Dyma'r datganiad hwn o fis Tachwedd. Ac mae hyn yn golygu ein bod bob mis wedi dod o hyd i ryw fath o fyg, fel arfer mewn swyddogaeth nad yw'n hanfodol, ond nid ydym wedi rhyddhau datganiad eto. Dim ond Tachwedd yw'r fersiwn flaenorol. Nid oes unrhyw fygiau yn hysbys i ni ynddo, h.y. ychwanegwyd chwilod wrth i’r prosiect fynd rhagddo.
Unwaith y byddwch wedi lawrlwytho WAL-G, gallwch redeg gorchymyn “rhestr wrth gefn” syml, gan basio'r newidynnau amgylchedd i mewn. A bydd yn cysylltu â Gwrthrych Storio ac yn dweud wrthych pa gopïau wrth gefn sydd gennych. Ar y dechrau, wrth gwrs, ni ddylai fod gennych chi gopïau wrth gefn. Pwynt y sleid hon yw dangos bod popeth yn eithaf syml. Mae hwn yn orchymyn consol sy'n derbyn newidynnau amgylchedd ac yn gweithredu is-orchmynion.
Ar ôl hyn, gallwch wneud eich copi wrth gefn cyntaf. Dywedwch “gwthio wrth gefn” yn WAL-G a nodwch yn WAL-G leoliad pgdata eich clwstwr. Ac yn fwyaf tebygol, bydd PostgreSQL yn dweud wrthych, os nad oes gennych system wrth gefn eisoes, bod angen i chi alluogi "modd archif".
Mae hyn yn golygu bod angen i chi fynd i osodiadau a throi “archive_mode = on” ymlaen ac ychwanegu “archive_command”, sydd hefyd yn is-orchymyn yn WAL-G. Ond am ryw reswm mae pobl yn aml yn defnyddio sgriptiau bar ar y pwnc hwn ac yn ei lapio o gwmpas WAL-G. Os gwelwch yn dda, peidiwch â gwneud hyn. Defnyddiwch y swyddogaeth a geir yn WAL-G. Os ydych chi'n colli rhywbeth, ysgrifennwch at . Mae WAL-G yn cymryd mai dyma'r unig raglen sy'n rhedeg yn archive_command.
Rydym yn defnyddio WAL-G yn bennaf i greu clwstwr Argaeledd Uchel ym maes rheoli Cronfa Ddata Yandex.
Ac fe'i defnyddir fel arfer mewn topoleg o un Meistr a sawl atgynhyrchiad. Ar yr un pryd, mae'n gwneud copi wrth gefn yn Yandex Object Storage.
Y senarios mwyaf cyffredin yw creu copïau o glwstwr gan ddefnyddio pwynt adfer amser. Ond yn yr achos hwn, nid yw perfformiad y system wrth gefn mor bwysig i ni. Mae angen i ni uwchlwytho clwstwr newydd o'r copi wrth gefn.
Yn nodweddiadol, mae angen perfformiad system wrth gefn arnom wrth ychwanegu nod newydd. Pam ei fod yn bwysig? Yn nodweddiadol mae pobl yn ychwanegu nod newydd i glwstwr oherwydd ni all y clwstwr presennol ymdopi â'r llwyth darllen. Mae angen iddynt ychwanegu atgynhyrchiad newydd. Os byddwn yn ychwanegu'r llwyth o pg_basebackup i'r Meistr, yna efallai y bydd y Meistr yn cwympo. Felly, roedd yn bwysig iawn i ni ein bod yn gallu llwytho nod newydd o'r archif yn gyflym, gan greu ychydig iawn o lwyth ar y Meistr.
A sefyllfa debyg arall. Dyma'r angen i ailgychwyn yr hen Feistr ar ôl newid y Meistr Clwstwr o'r Ganolfan Ddata y collwyd cysylltedd â hi.
- O ganlyniad, wrth lunio'r gofynion ar gyfer y system gopi, sylweddolom nad yw pg_basebackup yn addas i ni wrth weithredu yn y cwmwl.
- Roedden ni eisiau gallu cywasgu ein data. Ond bydd bron unrhyw system wrth gefn ac eithrio'r hyn a ddaw yn y blwch yn darparu cywasgu data.
- Roeddem am gyfochrog â phopeth oherwydd bod defnyddiwr yn y cwmwl yn prynu nifer fawr o greiddiau prosesydd. Ond os nad oes gennym gyfochrogrwydd mewn rhai gweithrediadau, yna mae nifer fawr o greiddiau yn dod yn ddiwerth.
- Mae angen amgryptio oherwydd yn aml nid yw'r data yn eiddo i ni ac ni ellir ei storio mewn testun clir. Gyda llaw, dechreuodd ein cyfraniad i WAL-G gydag amgryptio. Fe wnaethon ni gwblhau'r amgryptio yn WAL-G, ac ar ôl hynny gofynnwyd i ni: “Efallai y bydd un ohonom ni'n datblygu'r prosiect?” Ac ers hynny rwyf wedi bod yn gweithio gyda WAL-G am fwy na blwyddyn.
- Roedd angen gwthio adnoddau arnom hefyd, oherwydd dros amser wrth ddefnyddio'r cwmwl, fe wnaethom ddarganfod weithiau bod gan bobl lwyth bwyd pwysig yn y nos ac na ellir ymyrryd â'r llwyth hwn. Dyna pam y gwnaethom ychwanegu sbardun adnoddau.
- Yn ogystal â rhestru a rheoli.
- A gwirio.
Edrychon ni ar lawer o wahanol offer. Yn ffodus, mae gennym ni ddetholiad enfawr yn PostgreSQL. Ac ym mhobman roeddem yn colli rhywbeth, rhai un swyddogaeth fach, rhai un nodwedd fach.
Ac ar ôl archwilio’r systemau presennol, daethom i’r casgliad y byddwn yn datblygu WAL-G. Roedd yn brosiect newydd bryd hynny. Roedd yn eithaf hawdd dylanwadu ar y datblygiad tuag at seilwaith cwmwl y system wrth gefn.
Y brif ideoleg yr ydym yn glynu wrthi yw y dylai WAL-G fod mor syml â balalaika.
Mae gan WAL-G 4 gorchymyn. hwn:
WAL-PUSH - archifo'r siafft.
WAL-FETCH – cael siafft.
GWTHIO WRTH GEFN – gwneud copi wrth gefn.
BACKUP-FETCH - cael copi wrth gefn o'r system wrth gefn.
Mewn gwirionedd, mae gan WAL-G hefyd reolaeth ar y copïau wrth gefn hyn, h.y. rhestru a dileu cofnodion a chopïau wrth gefn mewn hanes nad oes eu hangen mwyach ar hyn o bryd.
Un o'r swyddogaethau pwysig i ni yw'r swyddogaeth o greu copïau delta.
Mae copïau Delta yn golygu nad ydym yn creu copi wrth gefn llawn o'r clwstwr cyfan, ond dim ond y tudalennau wedi'u newid o'r ffeiliau sydd wedi'u newid yn y clwstwr. Mae'n ymddangos bod hyn yn swyddogaethol yn debyg iawn i'r gallu i adfer trwy ddefnyddio CIY. Ond gallwn rolio i fyny WAL wrth gefn delta un edau ochr yn ochr. Yn unol â hynny, pan fydd gennym gopi wrth gefn sylfaenol ddydd Sadwrn, copïau wrth gefn delta bob dydd, a dydd Iau rydym yn methu, yna mae angen i ni gyflwyno 4 copi wrth gefn delta a 10 awr o WAL. Bydd yn cymryd tua'r un amser oherwydd bod y copïau wrth gefn delta yn rholio ochr yn ochr.
Deltas yn seiliedig ar LSN - mae hyn yn golygu, wrth greu copi wrth gefn, y bydd angen i ni gyfuno pob tudalen a gwirio ei LSN â LSN y copi wrth gefn blaenorol er mwyn deall ei fod wedi newid. Dylai unrhyw dudalen a allai gynnwys data wedi'i newid fod yn bresennol yn y copi wrth gefn delta.
Fel y dywedais, talwyd cryn dipyn o sylw i gyfochredd.
Ond mae'r API archif yn PostgreSQL yn gyson. Mae PostgreSQL yn archifo un ffeil WAL ac wrth ei hadfer mae'n gofyn am un ffeil WAL. Ond pan fydd y gronfa ddata yn gofyn am un ffeil WAL gan ddefnyddio'r gorchymyn "WAL-FETCH", rydym yn galw'r gorchymyn "WAL-PREFETCH", sy'n paratoi'r 8 ffeil nesaf i nôl data o'r storfa wrthrychau yn gyfochrog.
A phan fydd y gronfa ddata yn gofyn i ni archifo un ffeil, edrychwn ar archive_status a gweld a oes ffeiliau WAL eraill. Ac rydym hefyd yn ceisio lawrlwytho WAL yn gyfochrog. Mae hyn yn sicrhau cynnydd sylweddol mewn perfformiad ac yn lleihau'n sylweddol y pellter yn nifer y CIY heb eu harchifo. Mae llawer o ddatblygwyr systemau wrth gefn yn credu bod hon yn system mor beryglus oherwydd ein bod yn dibynnu ar ein gwybodaeth am fewnolion cod nad yw'n API PostgreSQL. Nid yw PostgreSQL yn gwarantu presenoldeb y ffolder archive_status i ni ac nid yw'n gwarantu'r semanteg, presenoldeb signalau parodrwydd ar gyfer ffeiliau WAL yno. Serch hynny, rydym yn astudio'r cod ffynhonnell, rydym yn gweld bod hyn yn wir ac rydym yn ceisio manteisio arno. Ac rydym yn rheoli'r cyfeiriad y mae PostgreSQL yn datblygu; os caiff y mecanwaith hwn ei dorri'n sydyn, byddwn yn rhoi'r gorau i'w ddefnyddio.
Yn ei ffurf bur, mae delta WAL sy'n seiliedig ar LSN yn gofyn am ddarllen unrhyw ffeil clwstwr y mae ei hamser modd yn y system ffeiliau wedi newid ers y copi wrth gefn blaenorol. Buom yn byw gyda hwn am amser hir, bron i flwyddyn. Ac yn y diwedd daethom i'r casgliad fod gennym WAL deltas.
Mae hyn yn golygu, bob tro rydyn ni'n archifo WAL ar y Meistr, rydyn ni nid yn unig yn ei gywasgu, ei amgryptio a'i anfon i'r rhwydwaith, ond rydyn ni hefyd yn ei ddarllen ar yr un pryd. Rydym yn dadansoddi ac yn darllen y cofnodion sydd ynddo. Rydym yn deall pa flociau sydd wedi newid ac yn casglu ffeiliau delta.
Mae ffeil delta yn disgrifio ystod benodol o ffeiliau CIY, yn disgrifio gwybodaeth am ba flociau a newidiwyd yn yr ystod hon o CIY. Ac yna mae'r ffeiliau delta hyn hefyd yn cael eu harchifo.
Yma rydym yn wynebu'r ffaith ein bod wedi cyfochrog â phopeth yn eithaf cyflym, ond ni allwn ddarllen hanes dilyniannol yn gyfochrog, oherwydd mewn segment penodol efallai y byddwn yn dod ar draws diwedd y cofnod WAL blaenorol, nad oes gennym ddim i gysylltu ag ef eto, oherwydd arweiniodd darllen cyfochrog at ddadansoddi'r dyfodol yn gyntaf, nad oes ganddo orffennol eto.
O ganlyniad, bu'n rhaid i ni roi darnau annealladwy mewn ffeiliau _delta_partial. O ganlyniad, pan fyddwn yn dychwelyd i'r gorffennol, byddwn yn gludo darnau'r cofnod WAL yn un, wedi hynny byddwn yn ei ddosrannu ac yn deall beth sydd wedi newid ynddo.
Os oes o leiaf un pwynt yn hanes ein dosrannu siafftiau lle nad ydym yn deall beth oedd yn digwydd, yna, yn unol â hynny, yn ystod y copi wrth gefn nesaf byddwn yn cael ein gorfodi i ddarllen y clwstwr cyfan eto, yn union fel y gwnaethom gyda LSN rheolaidd. - seiliedig delta.
O ganlyniad, arweiniodd ein holl ddioddefaint at y ffaith ein bod yn ffynhonnell agored o lyfrgell dosrannu WAL-G. Hyd y gwn i, nid oes neb yn ei ddefnyddio eto, ond os oes unrhyw un eisiau, ei ysgrifennu a'i ddefnyddio, mae yn y parth cyhoeddus. (Dolen wedi'i diweddaru )
O ganlyniad, mae'r holl lifau gwybodaeth yn edrych yn eithaf cymhleth. Mae ein Meistr yn archifo'r siafft ac yn archifo ffeiliau delta. Ac mae'n rhaid i'r atgynhyrchiad sy'n gwneud y copi wrth gefn dderbyn ffeiliau delta yn ystod yr amser sydd wedi mynd heibio rhwng copïau wrth gefn. Yn yr achos hwn, bydd angen ychwanegu rhannau o'r hanes mewn swmp a'u dosrannu, oherwydd nid yw'r holl hanes yn ffitio i segmentau mawr. A dim ond ar ôl hyn y gall y replica archifo copi wrth gefn delta llawn.
Ar y graffiau mae popeth yn edrych yn llawer symlach. Mae hwn yn lawrlwythiad o un o'n clystyrau go iawn. Mae gennym ni wedi'i seilio ar LSN, wedi'i wneud mewn un diwrnod. A gwelwn fod y copi wrth gefn delta yn seiliedig ar LSN yn rhedeg o dri yn y bore i bump yn y bore. Dyma'r llwyth yn nifer y creiddiau prosesydd. Cymerodd WAL-delta tua munudau 20 i ni yma, Hynny yw, daeth yn sylweddol gyflymach, ond ar yr un pryd bu cyfnewid dwysach dros y rhwydwaith.
Gan fod gennym ni wybodaeth am ba flociau sydd wedi newid a phryd yn hanes y gronfa ddata, fe aethon ni ymhellach a phenderfynu integreiddio ymarferoldeb - estyniad PostgreSQL o'r enw “pg_prefaulter”
Mae hyn yn golygu pan fydd y sylfaen wrth gefn yn gweithredu'r gorchymyn adfer, mae'n dweud wrth WAL-G i nôl y ffeil WAL nesaf. Rydym yn deall yn fras pa flociau data y bydd y broses adfer WAL yn eu cyrchu yn y dyfodol agos ac yn cychwyn gweithrediad darllen ar y blociau hyn. Gwnaethpwyd hyn er mwyn cynyddu perfformiad rheolwyr SSD. Oherwydd bydd y gofrestr WAL yn cyrraedd y dudalen sydd angen ei newid. Mae'r dudalen hon ar ddisg ac nid yw yn y celc tudalen. A bydd yn aros yn gydamserol i'r dudalen hon gyrraedd. Ond gerllaw mae WAL-G, sy'n gwybod y bydd angen tudalennau arbennig arnom yn yr ychydig gannoedd o megabeit nesaf o WAL ac ar yr un pryd yn dechrau eu cynhesu. Yn cychwyn mynediad disgiau lluosog fel eu bod yn cael eu gweithredu ochr yn ochr. Mae hyn yn gweithio'n dda ar yriannau SSD, ond, yn anffodus, nid yw'n berthnasol o gwbl ar gyfer gyriant caled, oherwydd dim ond gyda'n awgrymiadau yr ydym yn ymyrryd ag ef.
Dyma beth sydd yn y cod nawr.
Mae yna nodweddion yr hoffem eu hychwanegu.
Mae'r llun hwn yn dangos bod WAL-delta yn cymryd amser cymharol fyr. A dyma ddarllen y newidiadau a ddigwyddodd yn y gronfa ddata yn ystod y dydd. Gallem wneud WAL-delta nid yn unig yn y nos, oherwydd nid yw bellach yn ffynhonnell llwyth sylweddol. Gallwn ddarllen WAL-delta bob munud oherwydd ei fod yn rhad. Mewn un funud gallwn sganio'r holl newidiadau sydd wedi digwydd i'r clwstwr. A gellid galw hyn yn "wib WAL-delta".
Y pwynt yw, pan fyddwn yn adfer y clwstwr, ein bod yn lleihau nifer y straeon y mae’n rhaid inni eu cyflwyno’n ddilyniannol. Hynny yw, dylid lleihau faint o WAL y mae PostgreSQL yn ei rolio, oherwydd mae'n cymryd amser sylweddol.
Ond nid dyna'r cyfan. Os ydym yn gwybod y bydd rhai bloc yn cael ei newid i'r pwynt o gysondeb wrth gefn, ni allwn ei newid yn y gorffennol. Hynny yw, nawr mae gennym ni optimeiddio ffeil-wrth-ffeil o anfon ymlaen WAL-delta. Mae hyn yn golygu, er enghraifft, os cafodd tabl ei ddileu'n llwyr ddydd Mawrth neu os cafodd rhai ffeiliau eu dileu yn gyfan gwbl o'r tabl, yna pan fydd delta yn rholio drosodd ddydd Llun a dydd Sadwrn, pg_basebackup yn cael ei adfer, ni fyddwn hyd yn oed yn creu'r data hwn.
Rydym am ymestyn y dechnoleg hon i lefel y dudalen. Hynny yw, os bydd rhyw ran o'r ffeil yn newid ddydd Llun, ond yn cael ei throsysgrifo ddydd Mercher, yna wrth adfer i bwynt ddydd Iau, nid oes angen i ni ysgrifennu'r ychydig fersiynau cyntaf o dudalennau ar ddisg.
Ond mae hwn yn syniad sy'n cael ei drafod yn weithredol o fewn ni o hyd, ond nid yw wedi cyrraedd y cod eto.
Rydym am wneud un nodwedd arall yn WAL-G. Rydym am ei wneud yn estynadwy oherwydd mae angen i ni gefnogi gwahanol gronfeydd data a hoffem allu mynd at reolaeth wrth gefn yn yr un modd. Ond y broblem yw bod yr APIs MySQL yn wahanol iawn. Yn MySQL, mae PITR yn seiliedig nid ar y log WAL ffisegol, ond ar y binlog. Ac nid oes gennym system archifo yn MySQL a fyddai'n dweud wrth rai system allanol bod y binlog hwn wedi'i orffen a bod angen ei archifo. Mae angen i ni sefyll yn rhywle yn cron gyda'r gronfa ddata a gwirio a oes rhywbeth yn barod?
Ac yn yr un modd, yn ystod adferiad MySQL, nid oes gorchymyn adfer a allai ddweud wrth y system bod angen ffeiliau o'r fath ac o'r fath arnaf. Cyn i chi ddechrau ailadeiladu'ch clwstwr, mae angen i chi wybod pa ffeiliau y bydd eu hangen arnoch chi. Mae angen i chi eich hun ddyfalu pa ffeiliau fydd eu hangen arnoch chi. Ond efallai y bydd modd osgoi'r problemau hyn rywsut. (Eglurhad: mae MySQL eisoes yn cael ei gefnogi)
Yn yr adroddiad, roeddwn hefyd eisiau siarad am yr achosion hynny pan nad yw WAL-G yn addas i chi.
Os nad oes gennych atgynhyrchiad cydamserol, nid yw WAL-G yn gwarantu y bydd y segment olaf yn cael ei gadw. Ac os yw archifo yn llusgo y tu ôl i'r ychydig rannau olaf o hanes, mae hynny'n risg. Os nad oes replica cydamserol, ni fyddwn yn argymell defnyddio WAL-G. Yn dal i fod, fe'i cynlluniwyd yn bennaf ar gyfer gosodiad cwmwl, sy'n awgrymu datrysiad Argaeledd Uchel gyda replica cydamserol, sy'n gyfrifol am ddiogelwch y bytes olaf a gyflawnwyd.
Rwy'n aml yn gweld pobl yn ceisio rhedeg WAL-G a WAL-E ar yr un pryd. Rydym yn cefnogi cydweddoldeb tuag yn ôl yn yr ystyr y gall WAL-G adfer ffeil o WAL-E ac adfer copi wrth gefn a wnaed yn WAL-E. Ond gan fod y ddwy system hyn yn defnyddio wal-wthio cyfochrog, maent yn dechrau dwyn ffeiliau oddi wrth ei gilydd. Os byddwn yn ei drwsio yn WAL-G, bydd yn parhau yn WAL-E. Yn WAL-E, mae'n edrych ar statws archif, yn gweld y ffeiliau gorffenedig ac yn eu harchifo, tra na fydd systemau eraill yn gwybod bod y ffeil WAL hon yn bodoli, oherwydd ni fydd PostgreSQL yn ceisio ei harchifo yr eildro.
Beth ydyn ni'n mynd i'w drwsio yma ar ochr WAL-G? Ni fyddwn yn hysbysu PostgreSQL bod y ffeil hon wedi'i throsglwyddo'n gyfochrog, a phan fydd PostgreSQL yn gofyn inni ei harchifo, byddwn eisoes yn gwybod bod ffeil o'r fath gyda'r modd-time hwn a gyda'r md5 hwn eisoes wedi'i harchifo a byddwn yn dweud yn syml PostgreSQL - Iawn, mae popeth yn barod heb wneud dim byd yn y bôn.
Ond mae'n annhebygol y bydd y broblem hon yn sefydlog ar ochr WAL-E, felly ar hyn o bryd mae'n amhosibl creu gorchymyn archif a fydd yn archifo'r ffeil yn WAL-G a WAL-E.
Yn ogystal, mae yna achosion lle nad yw WAL-G yn addas i chi nawr, ond byddwn yn bendant yn ei drwsio.
Yn gyntaf, ar hyn o bryd nid oes gennym wiriad wrth gefn wedi'i ymgorffori. Nid oes gennym ddilysiad naill ai yn ystod copi wrth gefn neu adferiad. Wrth gwrs, mae hyn yn cael ei weithredu yn y cwmwl. Ond gweithredir hyn yn syml trwy wirio ymlaen llaw, yn syml trwy adfer y clwstwr. Hoffwn roi'r swyddogaeth hon i ddefnyddwyr. Ond trwy ddilysu, rwy'n cymryd yn WAL-G y bydd yn bosibl adfer y clwstwr a'i gychwyn, a chynnal profion mwg: pg_dumpall i /dev/null ac amcheck index verification.
Ar hyn o bryd yn WAL-G nid oes unrhyw ffordd i ohirio un copi wrth gefn o WAL. Hynny yw, rydym yn cefnogi rhyw ffenestr. Er enghraifft, storio'r saith diwrnod diwethaf, storio'r deg copi wrth gefn diwethaf, storio'r tri chopi wrth gefn llawn diwethaf. Yn aml iawn mae pobl yn dod i ddweud: “Mae angen copi wrth gefn o’r hyn ddigwyddodd ar y Flwyddyn Newydd ac rydyn ni am ei gadw am byth.” Ni all WAL-G wneud hyn eto. (Sylwer - Mae hwn eisoes wedi'i drwsio. Darllen mwy - Opsiwn marc wrth gefn yn )
Ac nid oes gennym wiriadau tudalen a gwiriadau uniondeb ar gyfer pob segment siafft wrth ddilysu PITR.
O hyn i gyd lluniais brosiect ar gyfer Google Summer of Code. Os ydych chi'n adnabod myfyrwyr craff a hoffai ysgrifennu rhywbeth yn Go a chael miloedd o ddoleri gan un cwmni gyda'r llythyren “G”, yna argymhellwch ein prosiect iddynt. Byddaf yn gweithredu fel mentor ar gyfer y prosiect hwn, gallant ei wneud. Os nad oes unrhyw fyfyrwyr, yna byddaf yn ei gymryd ac yn ei wneud fy hun yn yr haf.
Ac mae gennym lawer o broblemau bach eraill yr ydym yn gweithio arnynt yn raddol. Ac mae rhai pethau rhyfedd yn digwydd.
Er enghraifft, os ydych chi'n rhoi copi wrth gefn gwag i WAL-G, bydd yn disgyn yn syml. Er enghraifft, os dywedwch wrtho fod angen iddo wneud copi wrth gefn o ffolder wag. Ni fydd y ffeil pg_control yno. A bydd yn meddwl nad yw'n deall rhywbeth. Mewn theori, yn yr achos hwn mae angen i chi ysgrifennu neges arferol at y defnyddiwr i egluro iddo sut i ddefnyddio'r offeryn. Ond nid yw hyn hyd yn oed yn nodwedd o raglennu, ond yn nodwedd o iaith dda, ddealladwy.
Nid ydym yn gwybod sut i wneud copi wrth gefn all-lein. Os yw'r gronfa ddata yn gorwedd, ni allwn wneud copi wrth gefn ohoni. Ond mae popeth yn syml iawn yma. Rydym yn galw copïau wrth gefn gan LSN pan ddechreuodd. Rhaid darllen LSN y sylfaen waelodol o'r ffeil reoli. Ac mae hon yn nodwedd sydd heb ei gwireddu. Gall llawer o systemau wrth gefn wneud copi wrth gefn o gronfa ddata sylfaenol. Ac mae'n gyfleus.
Ar hyn o bryd ni allwn drin y diffyg lle wrth gefn yn iawn. Oherwydd rydyn ni fel arfer yn gweithio gyda chopïau wrth gefn mawr gartref. A wnaethon nhw ddim mynd o gwmpas iddo. Ond os yw rhywun eisiau rhaglennu yn Go ar hyn o bryd, ychwanegwch drin gwallau y tu allan i'r gofod i'r bwced. Byddaf yn bendant yn edrych i mewn i'r cais tynnu.
A'r prif beth sy'n ein poeni yw ein bod ni eisiau cymaint o brofion integreiddio docwyr â phosib sy'n gwirio gwahanol senarios. Ar hyn o bryd dim ond senarios sylfaenol yr ydym yn eu profi. Ar bob ymrwymiad, ond rydym am wirio ymrwymo-wrth-ymrwymiad yr holl swyddogaethau rydym yn eu cefnogi. Yn benodol, er enghraifft, bydd gennym ddigon o gefnogaeth ar gyfer PostgreSQL 9.4-9.5. Rydym yn eu cefnogi oherwydd bod y gymuned yn cefnogi PostgreSQL, ond nid ydym yn gwirio ymrwymo-wrth-ymrwymiad i sicrhau nad yw popeth wedi'i dorri. Ac mae'n ymddangos i mi fod hwn yn risg eithaf difrifol.
Mae gennym ni WAL-G yn rhedeg ar fwy na mil o glystyrau yn rheolaeth Cronfa Ddata Yandex. Ac mae'n gwneud copi wrth gefn o gannoedd o terabytes o ddata bob dydd.
Mae gennym lawer o TODO yn ein cod. Os ydych chi eisiau rhaglennu, dewch, rydym yn aros am geisiadau tynnu, rydym yn aros am gwestiynau.
cwestiynau
Noswaith dda! Diolch! Fy nyfaliad yw, os ydych chi'n defnyddio WAL-delta, mae'n debyg eich bod chi'n dibynnu'n helaeth ar ysgrifennu tudalen lawn. Ac os felly, a wnaethoch chi gynnal profion? Fe wnaethoch chi ddangos graff hardd. Faint yn fwy prydferth y daw os caiff FPW ei ddiffodd?
Mae ysgrifennu tudalen lawn wedi'i alluogi i ni, nid ydym wedi ceisio ei analluogi. Hynny yw, nid wyf fi, fel datblygwr, wedi ceisio ei ddiffodd. Mae'n debyg bod gweinyddwyr systemau sydd wedi ymchwilio wedi ymchwilio i'r mater hwn. Ond mae angen FPW arnom. Nid oes bron neb yn ei analluogi, oherwydd fel arall mae'n amhosibl cymryd copi wrth gefn o replica.
Diolch am yr adroddiad! Mae gennyf ddau gwestiwn. Y cwestiwn cyntaf yw beth fydd yn digwydd i ofodau bwrdd?
Rydym yn aros am gais tynnu. Mae ein cronfeydd data yn byw ar ddisgiau SSD ac NMVE ac nid oes gwir angen y nodwedd hon arnom. Dydw i ddim yn barod i dreulio amser difrifol ar hyn o bryd ar wneud pethau'n dda. Rwy’n dadlau’n llwyr ein bod yn cefnogi hyn. Mae yna bobl a oedd yn ei gefnogi, ond yn ei gefnogi mewn ffordd sy'n addas iddyn nhw. Gwnaethant fforc, ond nid ydynt yn gwneud ceisiadau tynnu. (Ychwanegwyd yn fersiwn 0.2.13)
A'r ail gwestiwn. Dywedasoch ar y cychwyn cyntaf fod WAL-G yn cymryd yn ganiataol ei fod yn gweithio ar ei ben ei hun ac nad oes angen unrhyw ddeunydd lapio. Rwy'n defnyddio deunydd lapio fy hun. Pam na ddylid eu defnyddio?
Rydym am iddo fod mor syml â balalaika. Mae hyn yn golygu nad oes angen unrhyw beth o gwbl arnoch chi ac eithrio balalaika. Rydym am i’r system fod yn syml. Os oes gennych chi ymarferoldeb y mae angen i chi ei wneud mewn sgript, yna dewch i ddweud wrthym - fe wnawn ni hynny yn Go.
Noswaith dda! Diolch am yr adroddiad! Nid oeddem yn gallu cael WAL-G i weithio gyda dadgryptio GPG. Mae'n amgryptio fel arfer, ond nid yw am ddadgryptio. A yw'n rhywbeth na weithiodd allan i ni? Mae'r sefyllfa'n ddigalon.
Creu problem ar GitHub a gadewch i ni ei ddarganfod.
Hynny yw, nid ydych chi wedi dod ar draws hyn?
Mae un o nodweddion yr adroddiad gwall, pan nad yw WAL-G yn deall pa fath o ffeil ydyw, mae'n gofyn: "Efallai ei bod wedi'i hamgryptio?" Efallai nad amgryptio yw'r broblem o gwbl. Rwyf am wella'r logio ar y pwnc hwn. Rhaid iddo ei ddehongli. Ar hyn o bryd rydym yn gweithio ar y pwnc hwn yn yr ystyr nad ydym yn hoff iawn o sut mae'r system ar gyfer cael allweddi cyhoeddus a phreifat wedi'i threfnu. Oherwydd ein bod yn galw GPG allanol fel ei fod yn rhoi ei allweddi i ni. Ac yna rydyn ni'n cymryd yr allweddi hyn ac yn eu trosglwyddo i'r GPG mewnol, sef PGP agored, sy'n cael ei lunio ar ein cyfer ni y tu mewn i WAL-G, ac yno rydyn ni'n galw amgryptio. Yn hyn o beth, rydym am wella'r system ac rydym am gefnogi amgryptio Libsodium (Ychwanegwyd yn fersiwn 0.2.15). Wrth gwrs, dylai dadgodio weithio, gadewch i ni ei ddarganfod - mae angen mwy o symptom arnoch chi na chwpl o eiriau. Gallwch chi gasglu yn ystafell y siaradwr rywbryd ac edrych ar y system. (Amgryptio PGP heb GPG allanol - v0.2.9)
Helo! Diolch am yr adroddiad! Mae gennyf ddau gwestiwn. Mae gen i awydd rhyfedd i wneud pg_basebackup a mewngofnodi WAL dau ddarparwr, h.y. rydw i eisiau gwneud un cwmwl ac un arall. A oes rhyw ffordd i wneud hyn?
Nid yw hyn yn bodoli nawr, ond mae'n syniad diddorol.
Dydw i ddim yn ymddiried mewn un darparwr, rydw i eisiau cael yr un peth mewn darparwr arall, rhag ofn.
Mae'r syniad yn ddiddorol. Yn dechnegol, nid yw hyn yn anodd o gwbl i'w weithredu. Er mwyn atal y syniad rhag mynd ar goll, a gaf i ofyn ichi wneud problem ar GitHub?
Ydw wrth gwrs.
Ac yna, pan fydd myfyrwyr yn dod i Google Summer of Code, byddwn yn eu hychwanegu at y prosiect fel bod mwy o waith i gael mwy allan ohonynt.
A'r ail gwestiwn. Mae problem ar GitHub. Rwy'n meddwl ei fod eisoes ar gau. Mae panig yn ystod adferiad. Ac i'w drechu, gwnaethost gynulliad ar wahân. Mae'n iawn mewn materion. Ac mae opsiwn i wneud amgylchedd amrywiol mewn un edefyn. A dyna pam ei fod yn gweithio'n araf iawn. A daethom ar draws y broblem hon, ac nid yw wedi'i datrys eto.
Y broblem yw bod y storfa (CEPH) am ryw reswm yn ailosod y cysylltiad pan fyddwn yn dod ato gyda chyfnewid uchel. Beth ellir ei wneud am hyn? Mae'r rhesymeg ailgynnig yn edrych fel hyn. Rydym yn ceisio lawrlwytho'r ffeil eto. Mewn un tocyn, roedd gennym nifer o ffeiliau heb eu llwytho i lawr, byddwn yn gwneud ail un ar gyfer pawb nad oeddent wedi mewngofnodi. A chyn belled â bod o leiaf un ffeil yn cael ei llwytho fesul iteriad, rydyn ni'n ailadrodd ac yn ailadrodd ac yn ailadrodd. Fe wnaethom wella'r rhesymeg o ailgynnig - esbonyddol wrth gefn. Ond nid yw'n gwbl glir beth i'w wneud â'r ffaith bod y cysylltiad yn torri ar ochr y system storio. Hynny yw, pan fyddwn yn uwchlwytho i un ffrwd, nid yw'n torri'r cysylltiadau hyn. Beth allwn ni ei wella yma? Mae gennym ni throtlo rhwydwaith, gallwn gyfyngu ar bob cysylltiad yn ôl nifer y beitau y mae'n eu hanfon. Fel arall, nid wyf yn gwybod sut i ddelio â'r ffaith nad yw storio gwrthrychau yn caniatáu inni lawrlwytho neu lawrlwytho ohono yn gyfochrog.
Dim CLG? Onid yw'n ysgrifenedig iddynt sut y maent yn caniatáu eu hunain i gael eu poenydio?
Y pwynt yw bod gan bobl sy'n meddwl am y cwestiwn hwn eu claddgell eu hunain fel arfer. Hynny yw, nid oes unrhyw un yn dod o Amazon neu Google Cloud neu Yandex Object Storage.
Efallai nad yw'r cwestiwn i chi bellach?
Nid yw'r cwestiwn yma yn yr achos hwn o bwys i bwy. Os oes unrhyw syniadau ar sut i ddelio â hyn, gadewch i ni wneud hynny yn WAL-G. Ond hyd yn hyn does gen i ddim syniadau da ar sut i ddelio â hyn. Mae yna rai Gwrthrych Storio sy'n cefnogi rhestru copïau wrth gefn yn wahanol. Rydych chi'n gofyn iddyn nhw restru gwrthrychau, ac maen nhw'n ychwanegu ffolder yno. Mae WAL-G yn codi ofn ar hyn - mae yna ryw fath o beth yma nad yw'n ffeil, ni allaf ei adfer, sy'n golygu na chafodd y copi wrth gefn ei adfer. Hynny yw, mewn gwirionedd, mae gennych glwstwr wedi'i adfer yn llwyr, ond mae'n dychwelyd statws gwallus i chi oherwydd dychwelodd Object Storage rywfaint o wybodaeth ryfedd nad oedd yn ei deall yn llawn.
Mae hyn yn beth sy'n digwydd yn y cwmwl Mail.
Os gallwch chi adeiladu atgynhyrchiad...
Mae'n cael ei atgynhyrchu'n gyson ...
Os oes atgenhedlu, yna rwy'n meddwl y byddwn yn arbrofi gyda strategaethau ailgynnig a chyfrif i maes sut i roi cynnig arall arni a deall yr hyn y mae'r cwmwl yn ei ofyn ohonom. Efallai y bydd yn sefydlog i ni ar dri chysylltiad ac ni fydd yn torri'r cysylltiad, yna byddwn yn cyrraedd tri yn ofalus. Oherwydd nawr rydyn ni'n gollwng y cysylltiad yn gyflym iawn, h.y. os byddwn ni'n lansio adferiad gydag 16 edefyn, yna ar ôl yr ailgynnig cyntaf bydd 8 edafedd, 4 edefyn, 2 edafedd ac un. Ac yna bydd yn tynnu'r ffeil i mewn i un ffrwd. Os oes rhai gwerthoedd hud fel 7,5 edafedd yw'r gorau ar gyfer pwmpio, yna byddwn yn aros arnynt ac yn ceisio gwneud 7,5 edafedd arall. Dyma syniad.
Diolch am yr adroddiad! Sut olwg sydd ar lif gwaith cyflawn ar gyfer gweithio gyda WAL-G? Er enghraifft, yn yr achos dwp pan nad oes delta ar draws tudalennau. Ac rydym yn cymryd ac yn tynnu'r copi wrth gefn cychwynnol, yna archifo'r siafft nes ein bod yn las yn wyneb. Yma, yn ôl a ddeallaf, mae dadansoddiad. Ar ryw adeg mae angen i chi wneud copi wrth gefn delta o dudalennau, h.y. mae rhyw broses allanol yn llywio hyn neu sut mae hyn yn digwydd?
Mae'r API wrth gefn delta yn eithaf syml. Mae yna nifer yno - uchafswm camau delta, dyna'r enw arno. Mae'n rhagosodiadau i sero. Mae hyn yn golygu bob tro y byddwch yn gwneud copi wrth gefn, mae'n lawrlwytho copi wrth gefn llawn. Os byddwch chi'n ei newid i unrhyw rif positif, er enghraifft, 3, yna y tro nesaf y byddwch chi'n gwneud gwthio wrth gefn, mae'n edrych ar hanes copïau wrth gefn blaenorol. Mae'n gweld nad ydych yn mynd dros y gadwyn o 3 deltas ac yn gwneud delta.
Hynny yw, bob tro rydyn ni'n lansio WAL-G, mae'n ceisio gwneud copi wrth gefn llawn?
Na, rydym yn rhedeg WAL-G, ac mae'n ceisio gwneud delta os yw eich polisïau yn caniatáu hynny.
Yn fras, os ydych chi'n ei redeg gyda sero bob tro, a fydd yn ymddwyn fel pg_basebackup?
Na, bydd yn dal i redeg yn gyflymach oherwydd ei fod yn defnyddio cywasgu a chyfochredd. Bydd Pg_basebackup yn rhoi'r siafft nesaf atoch chi. Mae WAL-G yn cymryd yn ganiataol bod gennych chi'r archifo wedi'i ffurfweddu. A bydd yn rhoi rhybudd os nad yw wedi'i ffurfweddu.
Gellir rhedeg pg_basebackup heb siafftiau.
Ie, yna byddant yn ymddwyn bron yr un peth. Pg_basebackup copïau i'r system ffeiliau. Gyda llaw, mae gennym nodwedd newydd yr wyf wedi anghofio sôn amdani. Gallwn nawr wneud copi wrth gefn i'r system ffeiliau o pg_basebackup. Nid wyf yn gwybod pam fod angen hyn, ond mae yno.
Er enghraifft, ar CephFS. Nid yw pawb eisiau ffurfweddu Gwrthrych Storio.
Ie, mae'n debyg mai dyna pam y gwnaethant ofyn cwestiwn am y nodwedd hon fel y gallem ei wneud. Ac fe wnaethon ni.
Diolch am yr adroddiad! Dim ond cwestiwn sydd am gopïo i'r system ffeiliau. Allan o'r bocs, a ydych chi nawr yn cefnogi copïo i storfa bell, er enghraifft, os oes rhywfaint o silff yn y ganolfan ddata neu rywbeth arall?
Yn y ffurfiad hwn, mae hwn yn gwestiwn anodd. Ydym, rydym yn cefnogi, ond nid yw'r swyddogaeth hon wedi'i chynnwys mewn unrhyw ryddhad eto. Hynny yw, mae pob rhag-ryddhad yn cefnogi hyn, ond nid yw'r fersiynau rhyddhau yn cefnogi hyn. Ychwanegwyd y swyddogaeth hon yn fersiwn 0.2. Bydd yn bendant yn cael ei ryddhau yn fuan, cyn gynted ag y byddwn yn trwsio'r holl fygiau hysbys. Ond ar hyn o bryd dim ond mewn rhag-ryddhau y gellir gwneud hyn. Mae dau fyg yn y rhag-ryddhad. Problem gydag adferiad WAL-E, nid ydym wedi ei thrwsio. Ac yn y rhag-ryddhad diweddaraf ychwanegwyd byg am delta wrth gefn. Felly, rydym yn argymell i bawb ddefnyddio'r fersiynau rhyddhau. Cyn gynted ag nad oes mwy o fygiau yn y rhag-ryddhad, gallwn ddweud ein bod yn cefnogi Google Cloud, pethau sy'n gydnaws â S3 a storio ffeiliau.
Helo, diolch am yr adroddiad. Yn ôl a ddeallaf, nid rhyw fath o system ganolog fel barmen yw WAL-G? A ydych yn bwriadu symud i'r cyfeiriad hwn?
Y broblem yw ein bod wedi symud i ffwrdd o’r cyfeiriad hwn. Mae WAL-G yn byw ar y gwesteiwr sylfaenol, ar y gwesteiwr clwstwr, ac ar bob gwesteiwr yn y clwstwr. Pan symudasom i filoedd o glystyrau, cawsom lawer o osodiadau bartender. A phob tro mae rhywbeth yn disgyn yn ddarnau ynddynt, mae'n broblem fawr. Oherwydd bod angen eu hatgyweirio, mae angen i chi ddeall pa glystyrau nad oes ganddyn nhw gopïau wrth gefn nawr. Nid wyf yn bwriadu datblygu WAL-G i gyfeiriad caledwedd ffisegol ar gyfer systemau wrth gefn. Os yw'r gymuned eisiau rhywfaint o ymarferoldeb yma, does dim ots gen i o gwbl.
Mae gennym dimau sy'n gyfrifol am storio. Ac rydyn ni'n teimlo mor dda nad ni yw hi, bod yna bobl arbennig sy'n rhoi ein ffeiliau lle mae'r ffeiliau'n ddiogel. Maent yn gwneud pob math o godio clyfar yno i wrthsefyll colli nifer penodol o ffeiliau. Maent yn gyfrifol am lled band rhwydwaith. Pan fydd gennych bartender, efallai y byddwch yn darganfod yn sydyn bod cronfeydd data bach gyda llawer o draffig wedi casglu ar yr un gweinydd. Mae'n ymddangos bod gennych chi lawer o le arno, ond am ryw reswm nid yw popeth yn ffitio trwy'r rhwydwaith. Efallai y bydd yn troi allan y ffordd arall. Mae yna lawer o rwydweithiau yno, mae creiddiau prosesydd, ond nid oes disgiau yma. Ac rydym wedi blino ar yr angen hwn i jyglo rhywbeth, a symudasom at y ffaith bod storio data yn wasanaeth ar wahân, y mae pobl arbennig ar wahân yn gyfrifol amdano.
PS Mae fersiwn newydd wedi'i rhyddhau , lle gallwch ddefnyddio'r ffeil ffurfweddu .walg.json, sydd wedi'i leoli yn y cyfeiriadur cartref postgres yn ddiofyn. Gallwch chi roi'r gorau i sgriptiau bash. Enghraifft .walg.json sydd yn y rhifyn hwn
Fideo:
Ffynhonnell: hab.com