WAL-G તરફથી બેકઅપ. 2019 માં શું છે? આન્દ્રે બોરોડિન

હું સૂચન કરું છું કે તમે 2019 ની શરૂઆતથી આન્દ્રે બોરોદિન દ્વારા "બેકઅપ્સ વિથ WAL-G. 2019 માં શું છે?"

કેમ છો બધા! મારું નામ આન્દ્રે બોરોડિન છે. હું યાન્ડેક્ષમાં વિકાસકર્તા છું. મને 2016 થી PostgreSQL માં રસ છે, મેં વિકાસકર્તાઓ સાથે વાત કરી અને તેઓએ કહ્યું કે બધું સરળ છે - તમે સ્રોત કોડ લો અને તેને બનાવો, અને બધું કામ કરશે. અને ત્યારથી હું રોકી શકતો નથી - હું તમામ પ્રકારની વિવિધ વસ્તુઓ લખું છું.

હું જેના પર કામ કરી રહ્યો છું તેમાંની એક બેકઅપ સિસ્ટમ છે. WAL-G. સામાન્ય રીતે, યાન્ડેક્ષ પર અમે પોસ્ટગ્રેએસક્યુએલમાં બેકઅપ સિસ્ટમ્સ પર ઘણા લાંબા સમયથી કામ કરી રહ્યા છીએ. અને અમે કેવી રીતે બેકઅપ સિસ્ટમ્સ બનાવીએ છીએ તેના પર તમે છ અહેવાલોની શ્રેણી ઇન્ટરનેટ પર શોધી શકો છો. અને દર વર્ષે તેઓ થોડો વિકાસ કરે છે, થોડો વિકાસ કરે છે અને વધુ વિશ્વસનીય બને છે.

પરંતુ આજે અહેવાલ ફક્ત અમે શું કર્યું છે તે વિશે જ નહીં, પણ તે કેટલું સરળ છે અને શું છે તે વિશે પણ છે. તમારામાંથી કેટલાએ WAL-G વિશેના મારા અહેવાલો પહેલેથી જ જોયા છે? તે સારું છે કે ઘણા લોકોએ જોયું નથી, કારણ કે હું સૌથી સરળ વસ્તુથી શરૂઆત કરીશ.

જો અચાનક તમારી પાસે PostgreSQL ક્લસ્ટર હોય, અને મને લાગે છે કે દરેક વ્યક્તિ પાસે તેમાંથી એક દંપતિ છે, અને અચાનક હજી સુધી કોઈ બેકઅપ સિસ્ટમ નથી, તો તમારે કોઈપણ S3 સ્ટોરેજ અથવા Google Cloud સુસંગત સ્ટોરેજ મેળવવાની જરૂર છે.

ઉદાહરણ તરીકે, તમે અમારા સ્ટેન્ડ પર આવી શકો છો અને યાન્ડેક્સ ઑબ્જેક્ટ સ્ટોરેજ માટે પ્રમોશનલ કોડ લઈ શકો છો, જે S3 સુસંગત છે.

પછી એક બકેટ બનાવો. તે માત્ર માહિતી માટેનું કન્ટેનર છે.

સેવા વપરાશકર્તા બનાવો.

સેવા વપરાશકર્તા માટે ઍક્સેસ કી બનાવો: aws-s3-key.

WAL-G નું નવીનતમ સ્થિર પ્રકાશન ડાઉનલોડ કરો.

અમારી પ્રી-રીલીઝ રીલીઝથી કેવી રીતે અલગ છે? મને ઘણીવાર વહેલા રિલીઝ કરવાનું કહેવામાં આવે છે. અને જો પૂરતા સમય માટે સંસ્કરણમાં કોઈ બગ નથી, ઉદાહરણ તરીકે, એક મહિના, તો હું તેને પ્રકાશિત કરું છું. નવેમ્બરની આ રિલીઝ અહીં છે. અને આનો અર્થ એ છે કે દર મહિને અમને અમુક પ્રકારની ભૂલો જોવા મળે છે, સામાન્ય રીતે બિન-નિર્ણાયક કાર્યક્ષમતામાં, પરંતુ અમે હજી સુધી કોઈ પ્રકાશન બહાર પાડ્યું નથી. અગાઉનું સંસ્કરણ ફક્ત નવેમ્બરનું છે. તેમાં અમને કોઈ ભૂલો જાણીતી નથી, એટલે કે જેમ જેમ પ્રોજેક્ટ આગળ વધતો ગયો તેમ તેમ બગ્સ ઉમેરવામાં આવ્યા.

એકવાર તમે WAL-G ડાઉનલોડ કરી લો તે પછી, તમે પર્યાવરણ વેરીએબલ્સમાં પસાર કરીને, એક સરળ "બેકઅપ સૂચિ" આદેશ ચલાવી શકો છો. અને તે ઑબ્જેક્ટ સ્ટોરેજ સાથે કનેક્ટ થશે અને તમને જણાવશે કે તમારી પાસે કયા બેકઅપ છે. શરૂઆતમાં, અલબત્ત, તમારી પાસે બેકઅપ હોવું જોઈએ નહીં. આ સ્લાઇડનો મુદ્દો એ બતાવવાનો છે કે બધું એકદમ સરળ છે. આ કન્સોલ આદેશ છે જે પર્યાવરણ ચલોને સ્વીકારે છે અને સબકમાન્ડ ચલાવે છે.

આ પછી, તમે તમારું પ્રથમ બેકઅપ લઈ શકો છો. WAL-G માં "બેકઅપ-પુશ" કહો અને WAL-G માં તમારા ક્લસ્ટરના pgdata સ્થાનનો ઉલ્લેખ કરો. અને મોટે ભાગે, PostgreSQL તમને કહેશે, જો તમારી પાસે પહેલેથી બેકઅપ સિસ્ટમ નથી, તો તમારે "આર્કાઇવ-મોડ" ને સક્ષમ કરવાની જરૂર છે.

આનો અર્થ એ છે કે તમારે સેટિંગ્સમાં જઈને "આર્કાઇવ_મોડ = ચાલુ" ચાલુ કરવાની અને "આર્કાઇવ_કમાન્ડ" ઉમેરવાની જરૂર છે, જે WAL-G માં સબકમાન્ડ પણ છે. પરંતુ કેટલાક કારણોસર લોકો વારંવાર આ વિષય પર બાર સ્ક્રિપ્ટનો ઉપયોગ કરે છે અને તેને WAL-G ની આસપાસ લપેટી લે છે. મહેરબાની કરીને આ ન કરો. WAL-G માં મળેલ કાર્યક્ષમતાનો ઉપયોગ કરો. જો તમારી પાસે કંઈક ખૂટે છે, તો તેને લખો GitHub. WAL-G ધારે છે કે તે એકમાત્ર પ્રોગ્રામ છે જે archive_command માં ચાલે છે.

અમે WAL-G નો ઉપયોગ મુખ્યત્વે Yandex Database Management માં ઉચ્ચ ઉપલબ્ધતા ક્લસ્ટર બનાવવા માટે કરીએ છીએ.

અને તેનો ઉપયોગ સામાન્ય રીતે એક માસ્ટરની ટોપોલોજી અને અનેક નકલોમાં થાય છે. તે જ સમયે, તે યાન્ડેક્સ ઑબ્જેક્ટ સ્ટોરેજમાં બેકઅપ કૉપિ બનાવે છે.

પોઈન્ટ ઇન ટાઇમ રિકવરીનો ઉપયોગ કરીને ક્લસ્ટરની નકલો બનાવવાની સૌથી સામાન્ય સ્થિતિ છે. પરંતુ આ કિસ્સામાં, બેકઅપ સિસ્ટમનું પ્રદર્શન અમારા માટે એટલું મહત્વનું નથી. અમારે ફક્ત બેકઅપમાંથી એક નવું ક્લસ્ટર અપલોડ કરવાની જરૂર છે.

સામાન્ય રીતે, નવો નોડ ઉમેરતી વખતે અમને બેકઅપ સિસ્ટમ કામગીરીની જરૂર હોય છે. શા માટે તે મહત્વનું છે? સામાન્ય રીતે લોકો ક્લસ્ટરમાં નવો નોડ ઉમેરે છે કારણ કે હાલનું ક્લસ્ટર રીડ લોડને હેન્ડલ કરી શકતું નથી. તેમને નવી પ્રતિકૃતિ ઉમેરવાની જરૂર છે. જો આપણે pg_basebackup થી માસ્ટર પર લોડ ઉમેરીએ, તો માસ્ટર તૂટી શકે છે. તેથી, અમારા માટે તે ખૂબ જ મહત્વપૂર્ણ હતું કે અમે માસ્ટર પર ન્યૂનતમ લોડ બનાવીને, આર્કાઇવમાંથી એક નવો નોડ ઝડપથી અપલોડ કરી શકીએ.

અને બીજી સમાન પરિસ્થિતિ. આ ડેટા સેન્ટરમાંથી ક્લસ્ટર માસ્ટરને સ્વિચ કર્યા પછી જૂના માસ્ટરને ફરીથી શરૂ કરવાની જરૂર છે જેની સાથે કનેક્ટિવિટી ખોવાઈ ગઈ હતી.

• પરિણામે, કૉપિ સિસ્ટમ માટેની જરૂરિયાતો ઘડતી વખતે, અમને સમજાયું કે pg_basebackup ક્લાઉડમાં ઑપરેટ કરતી વખતે અમારા માટે યોગ્ય નથી.
• અમે અમારા ડેટાને સંકુચિત કરવામાં સક્ષમ બનવા માગીએ છીએ. પરંતુ બૉક્સમાં જે આવે છે તે સિવાય લગભગ કોઈપણ બેકઅપ સિસ્ટમ ડેટા કમ્પ્રેશન પ્રદાન કરશે.
• અમે દરેક વસ્તુને સમાંતર બનાવવા માંગીએ છીએ કારણ કે ક્લાઉડમાં વપરાશકર્તા મોટી સંખ્યામાં પ્રોસેસર કોરો ખરીદે છે. પરંતુ જો આપણી પાસે અમુક કામગીરીમાં સમાનતા ન હોય, તો મોટી સંખ્યામાં કોરો નકામા બની જાય છે.
• અમને એન્ક્રિપ્શનની જરૂર છે કારણ કે ઘણીવાર ડેટા આપણો નથી અને સ્પષ્ટ ટેક્સ્ટમાં સંગ્રહિત કરી શકાતો નથી. માર્ગ દ્વારા, WAL-G માં અમારું યોગદાન એન્ક્રિપ્શનથી શરૂ થયું. અમે WAL-G માં એન્ક્રિપ્શન પૂર્ણ કર્યું, જે પછી અમને પૂછવામાં આવ્યું: "કદાચ આપણામાંથી કોઈ પ્રોજેક્ટ વિકસાવશે?" અને ત્યારથી હું એક વર્ષથી વધુ સમયથી WAL-G સાથે કામ કરી રહ્યો છું.
• અમને સંસાધન થ્રોટલિંગની પણ જરૂર હતી, કારણ કે સમય જતાં ક્લાઉડનો ઉપયોગ કરીને, અમને જાણવા મળ્યું કે કેટલીકવાર લોકો પર રાત્રિના સમયે મહત્વપૂર્ણ કરિયાણાનો ભાર હોય છે અને આ ભારમાં દખલ કરી શકાતી નથી. તેથી જ અમે સંસાધન થ્રોટલિંગ ઉમેર્યું છે.
• તેમજ લિસ્ટિંગ અને મેનેજમેન્ટ.
• અને ચકાસણી.

અમે ઘણાં વિવિધ સાધનો જોયા. સદભાગ્યે, અમારી પાસે PostgreSQL માં વિશાળ પસંદગી છે. અને દરેક જગ્યાએ અમે કંઈક ખૂટતા હતા, કોઈ એક નાનું કાર્ય, કોઈ એક નાનું લક્ષણ.

અને હાલની પ્રણાલીઓની તપાસ કર્યા પછી, અમે નિષ્કર્ષ પર આવ્યા કે અમે WAL-G વિકસાવીશું. ત્યારે તે નવો પ્રોજેક્ટ હતો. બેકઅપ સિસ્ટમના ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચર તરફના વિકાસને પ્રભાવિત કરવું એકદમ સરળ હતું.

મુખ્ય વિચારધારા કે જેનું આપણે પાલન કરીએ છીએ તે એ છે કે WAL-G એ બલાલિકા જેટલું સરળ હોવું જોઈએ.

WAL-G પાસે 4 આદેશો છે. આ:

WAL-PUSH - શાફ્ટને આર્કાઇવ કરો.

WAL-FETCH - એક શાફ્ટ મેળવો.

બેકઅપ-પુશ - બેકઅપ બનાવો.

BACKUP-FETCH - બેકઅપ સિસ્ટમમાંથી બેકઅપ મેળવો.

વાસ્તવમાં, WAL-G પાસે આ બેકઅપ્સનું સંચાલન પણ છે, એટલે કે ઇતિહાસમાં રેકોર્ડ્સ અને બેકઅપ્સની યાદી અને કાઢી નાખવી કે જેની અત્યારે જરૂર નથી.

અમારા માટે મહત્વપૂર્ણ કાર્યોમાંનું એક ડેલ્ટા નકલો બનાવવાનું કાર્ય છે.

ડેલ્ટા કોપીનો અર્થ એ છે કે અમે સમગ્ર ક્લસ્ટરનો સંપૂર્ણ બેકઅપ બનાવતા નથી, પરંતુ ક્લસ્ટરમાં બદલાયેલી ફાઇલોના ફક્ત બદલાયેલા પૃષ્ઠો બનાવીએ છીએ. એવું લાગે છે કે કાર્યાત્મક રીતે આ WAL નો ઉપયોગ કરીને પુનઃપ્રાપ્ત કરવાની ક્ષમતા જેવું જ છે. પરંતુ અમે સમાંતરમાં WAL સિંગલ-થ્રેડેડ ડેલ્ટા બેકઅપ રોલ અપ કરી શકીએ છીએ. તદનુસાર, જ્યારે અમારી પાસે શનિવારે બેઝિક બેકઅપ હોય છે, ડેલ્ટા બેકઅપ દરરોજ હોય ​​છે અને ગુરુવારે અમે નિષ્ફળ જઈએ છીએ, તો અમારે 4 ડેલ્ટા બેકઅપ અને WAL ના 10 કલાક રોલ અપ કરવાની જરૂર છે. તે લગભગ સમાન સમય લેશે કારણ કે ડેલ્ટા બેકઅપ સમાંતર રોલ કરે છે.

LSN-આધારિત ડેલ્ટા - આનો અર્થ એ છે કે બેકઅપ બનાવતી વખતે, આપણે દરેક પૃષ્ઠને જોડવું પડશે અને તે બદલાયું છે તે સમજવા માટે અગાઉના બેકઅપના LSN સાથે તેના LSNને તપાસવું પડશે. કોઈપણ પૃષ્ઠ કે જે સંભવિતપણે બદલાયેલ ડેટા સમાવી શકે છે તે ડેલ્ટા બેકઅપમાં હાજર હોવું જોઈએ.

મેં કહ્યું તેમ, સમાનતા પર ઘણું ધ્યાન આપવામાં આવ્યું હતું.

પરંતુ PostgreSQL માં આર્કાઇવ API સુસંગત છે. PostgreSQL એક WAL ફાઇલને આર્કાઇવ કરે છે અને જ્યારે તે પુનઃસ્થાપિત કરે છે ત્યારે એક WAL ફાઇલની વિનંતી કરે છે. પરંતુ જ્યારે ડેટાબેઝ "WAL-FETCH" આદેશનો ઉપયોગ કરીને એક WAL ફાઇલની વિનંતી કરે છે, ત્યારે અમે "WAL-PREFETCH" આદેશને કૉલ કરીએ છીએ, જે સમાંતરમાં ઑબ્જેક્ટ સ્ટોરમાંથી ડેટા મેળવવા માટે આગામી 8 ફાઇલોને તૈયાર કરે છે.

અને જ્યારે ડેટાબેઝ અમને એક ફાઈલને આર્કાઈવ કરવા માટે કહે છે, ત્યારે અમે archive_status જોઈએ છીએ અને જોઈએ છીએ કે શું અન્ય WAL ફાઈલો છે. અને અમે સમાંતર WAL ડાઉનલોડ કરવાનો પણ પ્રયાસ કરી રહ્યા છીએ. આ નોંધપાત્ર પ્રભાવ લાભ પૂરો પાડે છે અને અનઆર્કાઇવ કરેલ WAL ની સંખ્યામાં નોંધપાત્ર રીતે અંતર ઘટાડે છે. ઘણા બેકઅપ સિસ્ટમ ડેવલપર્સ માને છે કે આ એક જોખમી સિસ્ટમ છે કારણ કે અમે કોડના ઇન્ટરનલ્સના અમારા જ્ઞાન પર આધાર રાખીએ છીએ જે PostgreSQL API નથી. PostgreSQL અમારા માટે આર્કાઇવ_સ્ટેટસ ફોલ્ડરની હાજરીની બાંયધરી આપતું નથી અને અર્થશાસ્ત્રની, ત્યાં WAL ફાઇલો માટે રેડીનેસ સિગ્નલની હાજરીની બાંયધરી આપતું નથી. તેમ છતાં, અમે સ્રોત કોડનો અભ્યાસ કરી રહ્યા છીએ, અમે જોયું કે આ આવું છે અને અમે તેનો ઉપયોગ કરવાનો પ્રયાસ કરી રહ્યા છીએ. અને અમે PostgreSQL જે દિશામાં વિકાસ કરી રહ્યું છે તેને નિયંત્રિત કરીએ છીએ; જો અચાનક આ મિકેનિઝમ તૂટી જાય, તો અમે તેનો ઉપયોગ કરવાનું બંધ કરીશું.

તેના શુદ્ધ સ્વરૂપમાં, LSN-આધારિત WAL ડેલ્ટાને કોઈપણ ક્લસ્ટર ફાઇલ વાંચવાની જરૂર છે જેનો ફાઇલ સિસ્ટમમાં મોડ-ટાઇમ અગાઉના બેકઅપથી બદલાઈ ગયો છે. અમે આ સાથે લાંબા સમય સુધી જીવ્યા, લગભગ એક વર્ષ. અને અંતે અમે નિષ્કર્ષ પર આવ્યા કે અમારી પાસે WAL ડેલ્ટા છે.

આનો અર્થ એ છે કે દરેક વખતે જ્યારે આપણે માસ્ટર પર WAL ને આર્કાઇવ કરીએ છીએ, ત્યારે અમે તેને માત્ર સંકુચિત કરીએ છીએ, તેને એન્ક્રિપ્ટ કરીએ છીએ અને નેટવર્ક પર મોકલીએ છીએ, પરંતુ તે જ સમયે અમે તેને વાંચીએ છીએ. અમે તેમાંના રેકોર્ડનું વિશ્લેષણ અને વાંચન કરીએ છીએ. અમે સમજીએ છીએ કે કયા બ્લોક્સ બદલાયા છે અને ડેલ્ટા ફાઇલો એકત્રિત કરીએ છીએ.

ડેલ્ટા ફાઇલ WAL ફાઇલોની ચોક્કસ શ્રેણીનું વર્ણન કરે છે, WAL ની આ શ્રેણીમાં કયા બ્લોક બદલાયા છે તે વિશેની માહિતીનું વર્ણન કરે છે. અને પછી આ ડેલ્ટા ફાઇલો પણ આર્કાઇવ કરવામાં આવે છે.

અહીં આપણે એ હકીકતનો સામનો કરી રહ્યા છીએ કે આપણે બધું જ ઝડપથી સમાંતર કર્યું છે, પરંતુ આપણે ક્રમિક ઇતિહાસને સમાંતર રીતે વાંચી શકતા નથી, કારણ કે ચોક્કસ સેગમેન્ટમાં આપણે અગાઉના WAL રેકોર્ડના અંતનો સામનો કરી શકીએ છીએ, જેની સાથે જોડાવા માટે અમારી પાસે હજી કંઈ નથી, કારણ કે સમાંતર વાંચન એ તરફ દોરી જાય છે કે આપણે સૌ પ્રથમ ભવિષ્યનું વિશ્લેષણ કરીએ છીએ, જેનો હજી ભૂતકાળ નથી.

પરિણામે, અમારે _delta_partial ફાઇલોમાં અગમ્ય ટુકડાઓ મૂકવા પડ્યા. પરિણામે, જ્યારે આપણે ભૂતકાળમાં પાછા ફરીશું, ત્યારે આપણે WAL રેકોર્ડના ટુકડાઓને એકમાં ગુંદર કરીશું, તે પછી આપણે તેનું વિશ્લેષણ કરીશું અને સમજીશું કે તેમાં શું બદલાયું છે.

જો અમારા શાફ્ટ પાર્સિંગના ઇતિહાસમાં ઓછામાં ઓછું એક બિંદુ છે જ્યાં આપણે સમજી શકતા નથી કે શું થઈ રહ્યું છે, તો પછી, તે મુજબ, આગામી બેકઅપ દરમિયાન અમને આખું ક્લસ્ટર ફરીથી વાંચવાની ફરજ પાડવામાં આવશે, જેમ આપણે નિયમિત LSN સાથે કર્યું હતું. -આધારિત ડેલ્ટા.

પરિણામે, અમારી બધી વેદના એ હકીકત તરફ દોરી ગઈ કે અમે WAL-G પાર્સિંગ લાઇબ્રેરી ખોલી. જ્યાં સુધી હું જાણું છું, હજી સુધી કોઈ તેનો ઉપયોગ કરતું નથી, પરંતુ જો કોઈ તેને લખવા અને વાપરવા માંગે છે, તો તે જાહેર ડોમેનમાં છે. (અપડેટ કરેલ લિંક https://github.com/wal-g/wal-g/tree/master/internal/walparser)

પરિણામે, તમામ માહિતી પ્રવાહ તદ્દન જટિલ લાગે છે. અમારા માસ્ટર શાફ્ટને આર્કાઇવ કરે છે અને ડેલ્ટા ફાઇલોને આર્કાઇવ કરે છે. અને પ્રતિકૃતિ કે જે બેકઅપ નકલ બનાવે છે તે બેકઅપ વચ્ચે પસાર થયેલા સમય દરમિયાન ડેલ્ટા ફાઇલો પ્રાપ્ત કરવી આવશ્યક છે. આ કિસ્સામાં, ઇતિહાસના ભાગોને જથ્થામાં ઉમેરવાની અને વિશ્લેષિત કરવાની જરૂર પડશે, કારણ કે સમગ્ર ઇતિહાસ મોટા ભાગોમાં બંધબેસતો નથી. અને આ પછી જ પ્રતિકૃતિ સંપૂર્ણ ડેલ્ટા બેકઅપને આર્કાઇવ કરી શકે છે.

આલેખ પર બધું ખૂબ સરળ લાગે છે. આ અમારા વાસ્તવિક ક્લસ્ટરોમાંથી એક ડાઉનલોડ છે. અમારી પાસે LSN-આધારિત છે, જે એક દિવસમાં બનાવેલ છે. અને આપણે જોઈએ છીએ કે LSN-આધારિત ડેલ્ટા બેકઅપ સવારના ત્રણ વાગ્યાથી સવારના પાંચ વાગ્યા સુધી ચાલતું હતું. આ પ્રોસેસર કોરોની સંખ્યામાં લોડ છે. WAL-ડેલ્ટાએ અમને અહીં લગભગ 20 મિનિટ લીધી. એટલે કે, તે નોંધપાત્ર રીતે ઝડપી બન્યું, પરંતુ તે જ સમયે નેટવર્ક પર વધુ તીવ્ર વિનિમય થયો.

ડેટાબેઝના ઇતિહાસમાં કયા બ્લોક્સ અને કયા સમયે બદલાયા તેની માહિતી અમારી પાસે હોવાથી, અમે વધુ આગળ વધીને કાર્યક્ષમતાને એકીકૃત કરવાનું નક્કી કર્યું - પોસ્ટગ્રેએસક્યુએલ એક્સ્ટેંશન જેને "pg_prefaulter" કહેવાય છે.

આનો અર્થ એ છે કે જ્યારે સ્ટેન્ડ-બાય બેઝ પુનઃસ્થાપિત આદેશ ચલાવે છે, ત્યારે તે WAL-G ને આગલી WAL ફાઇલ લાવવા માટે કહે છે. અમે લગભગ સમજીએ છીએ કે નજીકના ભવિષ્યમાં WAL પુનઃપ્રાપ્તિ પ્રક્રિયા કયા ડેટા બ્લોક્સને ઍક્સેસ કરશે અને આ બ્લોક્સ પર રીડ ઑપરેશન શરૂ કરશે. આ SSD નિયંત્રકોની કામગીરી વધારવા માટે કરવામાં આવ્યું હતું. કારણ કે WAL રોલ એ પેજ પર પહોંચશે જેને બદલવાની જરૂર છે. આ પૃષ્ઠ ડિસ્ક પર છે અને પૃષ્ઠ કેશમાં નથી. અને તે આ પૃષ્ઠના આગમન માટે સિંક્રનસ રીતે રાહ જોશે. પરંતુ નજીકમાં WAL-G છે, જે જાણે છે કે આગામી કેટલાક સો મેગાબાઇટ્સ WALમાં આપણને ચોક્કસ પૃષ્ઠોની જરૂર પડશે અને તે જ સમયે તેમને ગરમ કરવાનું શરૂ કરે છે. બહુવિધ ડિસ્ક એક્સેસ શરૂ કરે છે જેથી તે સમાંતર રીતે ચલાવવામાં આવે. આ SSD ડ્રાઇવ્સ પર સારી રીતે કાર્ય કરે છે, પરંતુ, કમનસીબે, તે હાર્ડ ડ્રાઈવ માટે બિલકુલ લાગુ પડતું નથી, કારણ કે અમે ફક્ત અમારા પ્રોમ્પ્ટ્સ સાથે તેની સાથે દખલ કરીએ છીએ.

આ હવે કોડમાં છે.

એવી સુવિધાઓ છે જે અમે ઉમેરવા માંગીએ છીએ.

આ ચિત્ર બતાવે છે કે WAL-ડેલ્ટા પ્રમાણમાં ઓછો સમય લે છે. અને આ દિવસ દરમિયાન ડેટાબેઝમાં થયેલા ફેરફારોને વાંચી રહ્યું છે. અમે WAL-ડેલ્ટા માત્ર રાત્રે જ કરી શકતા નથી, કારણ કે તે હવે ભારનો નોંધપાત્ર સ્ત્રોત નથી. અમે દર મિનિટે WAL-ડેલ્ટા વાંચી શકીએ છીએ કારણ કે તે સસ્તું છે. એક મિનિટમાં આપણે ક્લસ્ટરમાં થયેલા તમામ ફેરફારોને સ્કેન કરી શકીએ છીએ. અને આને "ઇન્સ્ટન્ટ WAL-ડેલ્ટા" કહી શકાય.

મુદ્દો એ છે કે જ્યારે આપણે ક્લસ્ટરને પુનઃસ્થાપિત કરીએ છીએ, ત્યારે આપણે વાર્તાઓની સંખ્યા ઘટાડીએ છીએ જેને આપણે ક્રમિક રીતે રોલ અપ કરવાની હોય છે. એટલે કે, પોસ્ટગ્રેએસક્યુએલ રોલ કરે છે તે WAL નું પ્રમાણ ઘટાડવું જોઈએ, કારણ કે તે નોંધપાત્ર સમય લે છે.

પરંતુ તે બધુ જ નથી. જો આપણે જાણીએ છીએ કે કેટલાક બ્લોકને બેકઅપ સુસંગતતાના બિંદુ પર બદલવામાં આવશે, તો અમે તેને ભૂતકાળમાં બદલી શકતા નથી. એટલે કે, હવે અમારી પાસે WAL-ડેલ્ટા ફોરવર્ડિંગનું ફાઇલ-બાય-ફાઇલ ઑપ્ટિમાઇઝેશન છે. આનો અર્થ એ છે કે જો, ઉદાહરણ તરીકે, મંગળવારે કોઈ ટેબલ સંપૂર્ણપણે કાઢી નાખવામાં આવ્યું હતું અથવા કેટલીક ફાઇલો ટેબલમાંથી સંપૂર્ણપણે કાઢી નાખવામાં આવી હતી, તો જ્યારે સોમવારે ડેલ્ટા રોલ ઓવર થાય છે અને શનિવારે pg_basebackup પુનઃસ્થાપિત થાય છે, તો અમે આ ડેટા પણ બનાવીશું નહીં.

અમે આ ટેક્નોલોજીને પેજ લેવલ સુધી વિસ્તારવા માંગીએ છીએ. એટલે કે, જો ફાઇલનો અમુક ભાગ સોમવારે બદલાય છે, પરંતુ બુધવારે ફરીથી લખવામાં આવશે, તો ગુરુવારે કોઈ બિંદુ પર પુનઃસ્થાપિત કરતી વખતે, અમારે ડિસ્ક પર પૃષ્ઠોના પ્રથમ થોડા સંસ્કરણો લખવાની જરૂર નથી.

પરંતુ આ હજી પણ એક વિચાર છે જેની અમારી અંદર સક્રિયપણે ચર્ચા થઈ રહી છે, પરંતુ તે હજી સુધી કોડ સુધી પહોંચી નથી.

અમે WAL-G માં વધુ એક સુવિધા બનાવવા માંગીએ છીએ. અમે તેને એક્સ્ટેન્સિબલ બનાવવા માંગીએ છીએ કારણ કે અમારે વિવિધ ડેટાબેસેસને સપોર્ટ કરવાની જરૂર છે અને તે જ રીતે બેકઅપ મેનેજમેન્ટનો સંપર્ક કરવા માટે સક્ષમ બનવા માંગીએ છીએ. પરંતુ સમસ્યા એ છે કે MySQL API ધરમૂળથી અલગ છે. MySQL માં, PITR ભૌતિક WAL લોગ પર આધારિત નથી, પરંતુ બિનલોગ પર આધારિત છે. અને અમારી પાસે MySQL માં આર્કાઇવિંગ સિસ્ટમ નથી જે અમુક બાહ્ય સિસ્ટમને કહેશે કે આ બિનલોગ સમાપ્ત થઈ ગયો છે અને તેને આર્કાઇવ કરવાની જરૂર છે. આપણે ડેટાબેઝ સાથે ક્રોનમાં ક્યાંક ઊભા રહેવાની જરૂર છે અને તપાસવાની જરૂર છે કે શું ત્યાં કંઈક તૈયાર છે?

અને તે જ રીતે, MySQL પુનઃસ્થાપના દરમિયાન, ત્યાં કોઈ પુનઃસ્થાપિત આદેશ નથી જે સિસ્ટમને કહી શકે કે મને આવી અને આવી ફાઇલોની જરૂર છે. તમે તમારા ક્લસ્ટરને ફરીથી બનાવવાનું શરૂ કરો તે પહેલાં, તમારે જાણવાની જરૂર છે કે તમને કઈ ફાઇલોની જરૂર પડશે. તમારે જાતે જ અનુમાન લગાવવાની જરૂર છે કે તમને કઈ ફાઇલોની જરૂર પડશે. પરંતુ આ સમસ્યાઓને કોઈક રીતે દૂર કરી શકાય છે. (સ્પષ્ટતા: MySQL પહેલેથી જ સપોર્ટેડ છે)

રિપોર્ટમાં, હું એવા કિસ્સાઓ વિશે પણ વાત કરવા માંગતો હતો જ્યારે WAL-G તમારા માટે યોગ્ય નથી.

જો તમારી પાસે સિંક્રનસ પ્રતિકૃતિ નથી, તો WAL-G બાંહેધરી આપતું નથી કે છેલ્લો સેગમેન્ટ સાચવવામાં આવશે. અને જો આર્કાઇવિંગ ઇતિહાસના છેલ્લા કેટલાક ભાગો પાછળ રહે છે, તો તે જોખમ છે. જો ત્યાં કોઈ સિંક્રનસ પ્રતિકૃતિ નથી, તો હું WAL-G નો ઉપયોગ કરવાની ભલામણ કરીશ નહીં. તેમ છતાં, તે મુખ્યત્વે ક્લાઉડ ઇન્સ્ટોલેશન માટે રચાયેલ છે, જે સિંક્રનસ પ્રતિકૃતિ સાથે ઉચ્ચ ઉપલબ્ધતા ઉકેલ સૂચવે છે, જે પ્રતિબદ્ધ છેલ્લા બાઈટ્સની સલામતી માટે જવાબદાર છે.

હું વારંવાર જોઉં છું કે લોકો એક જ સમયે WAL-G અને WAL-E બંને ચલાવવાનો પ્રયાસ કરે છે. અમે પછાત સુસંગતતાને એ અર્થમાં સમર્થન આપીએ છીએ કે WAL-G WAL-E માંથી ફાઇલને પુનઃસ્થાપિત કરી શકે છે અને WAL-E માં બનાવેલ બેકઅપને પુનઃસ્થાપિત કરી શકે છે. પરંતુ આ બંને સિસ્ટમો સમાંતર વોલ-પુશનો ઉપયોગ કરતી હોવાથી, તેઓ એકબીજા પાસેથી ફાઇલો ચોરી કરવાનું શરૂ કરે છે. જો આપણે તેને WAL-G માં ઠીક કરીએ, તો તે હજુ પણ WAL-E માં રહેશે. WAL-E માં, તે આર્કાઇવ-સ્ટેટસ જુએ છે, ફિનિશ્ડ ફાઇલો જુએ છે અને તેને આર્કાઇવ કરે છે, જ્યારે અન્ય સિસ્ટમો ફક્ત જાણશે નહીં કે આ WAL ફાઇલ અસ્તિત્વમાં છે, કારણ કે PostgreSQL તેને બીજી વખત આર્કાઇવ કરવાનો પ્રયાસ કરશે નહીં.

અમે અહીં WAL-G બાજુએ શું ઠીક કરવા જઈ રહ્યા છીએ? અમે PostgreSQL ને જાણ કરીશું નહીં કે આ ફાઇલ સમાંતર રીતે ટ્રાન્સફર કરવામાં આવી હતી, અને જ્યારે PostgreSQL અમને તેને આર્કાઇવ કરવાનું કહેશે, ત્યારે અમને પહેલેથી જ ખબર પડશે કે આ મોડ-ટાઇમ અને આ md5 સાથે આવી ફાઇલ પહેલેથી જ આર્કાઇવ કરવામાં આવી છે અને અમે ફક્ત પોસ્ટગ્રેએસક્યુએલ કહીશું - ઠીક છે, અનિવાર્યપણે કંઈપણ કર્યા વિના બધું તૈયાર છે.

પરંતુ આ સમસ્યા WAL-E બાજુ પર ઠીક થવાની શક્યતા નથી, તેથી WAL-G અને WAL-E બંનેમાં ફાઇલને આર્કાઇવ કરી શકે તેવો આર્કાઇવ આદેશ બનાવવો હાલમાં અશક્ય છે.

વધુમાં, એવા કિસ્સાઓ છે કે જ્યાં WAL-G હવે તમારા માટે યોગ્ય નથી, પરંતુ અમે ચોક્કસપણે તેને ઠીક કરીશું.

પ્રથમ, અમારી પાસે હાલમાં બિલ્ટ-ઇન બેકઅપ ચકાસણી નથી. બેકઅપ અથવા પુનઃપ્રાપ્તિ દરમિયાન અમારી પાસે ચકાસણી નથી. અલબત્ત, આ ક્લાઉડમાં લાગુ કરવામાં આવે છે. પરંતુ આ ફક્ત પૂર્વ-તપાસ દ્વારા, ફક્ત ક્લસ્ટરને પુનઃસ્થાપિત કરીને અમલમાં મૂકવામાં આવે છે. હું વપરાશકર્તાઓને આ કાર્યક્ષમતા આપવા માંગુ છું. પરંતુ ચકાસણી દ્વારા, હું માનું છું કે WAL-G માં ક્લસ્ટરને પુનઃસ્થાપિત કરવું અને તેને શરૂ કરવું અને સ્મોક પરીક્ષણો ચલાવવાનું શક્ય બનશે: pg_dumpall to /dev/null અને amcheck ઇન્ડેક્સ વેરિફિકેશન.

હાલમાં WAL-G માં WAL તરફથી એક બેકઅપ મુલતવી રાખવાનો કોઈ રસ્તો નથી. એટલે કે, અમે અમુક વિન્ડોને સપોર્ટ કરીએ છીએ. ઉદાહરણ તરીકે, છેલ્લા સાત દિવસનો સંગ્રહ, છેલ્લા દસ બેકઅપને સંગ્રહિત કરવા, છેલ્લા ત્રણ સંપૂર્ણ બેકઅપને સંગ્રહિત કરવા. ઘણી વાર લોકો આવે છે અને કહે છે: "અમને નવા વર્ષમાં જે બન્યું તેના બેકઅપની જરૂર છે અને અમે તેને કાયમ રાખવા માંગીએ છીએ." WAL-G ને હજુ સુધી ખબર નથી કે આ કેવી રીતે કરવું. (નોંધ - આ પહેલેથી જ સુધારેલ છે. વધુ વાંચો - માં બેકઅપ-માર્ક વિકલ્પ https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

અને અમારી પાસે PITR ને માન્ય કરતી વખતે તમામ શાફ્ટ સેગમેન્ટ્સ માટે પેજ ચેકસમ અને અખંડિતતાની તપાસ નથી.

આ બધામાંથી મેં ગૂગલ સમર ઓફ કોડ માટે એક પ્રોજેક્ટ મૂક્યો. જો તમે એવા સ્માર્ટ વિદ્યાર્થીઓને જાણો છો કે જેઓ Go માં કંઈક લખવા અને “G” અક્ષર સાથે એક કંપનીમાંથી હજારો ડોલર મેળવવા ઈચ્છે છે, તો તેમને અમારા પ્રોજેક્ટની ભલામણ કરો. હું આ પ્રોજેક્ટ માટે માર્ગદર્શક તરીકે કામ કરીશ, તેઓ કરી શકે છે. જો ત્યાં કોઈ વિદ્યાર્થીઓ ન હોય, તો હું તેને લઈશ અને ઉનાળામાં તે જાતે કરીશ.

અને અમારી પાસે બીજી ઘણી નાની સમસ્યાઓ છે જેના પર અમે ધીમે ધીમે કામ કરી રહ્યા છીએ. અને કેટલીક ખૂબ વિચિત્ર વસ્તુઓ થાય છે.

ઉદાહરણ તરીકે, જો તમે WAL-G ને ખાલી બેકઅપ આપો છો, તો તે ખાલી પડી જશે. ઉદાહરણ તરીકે, જો તમે તેને કહો કે તેને ખાલી ફોલ્ડરનો બેકઅપ લેવાની જરૂર છે. pg_control ફાઇલ ત્યાં હશે નહીં. અને તે વિચારશે કે તે કંઈક સમજી શકતો નથી. સિદ્ધાંતમાં, આ કિસ્સામાં તમારે વપરાશકર્તાને સાધનનો ઉપયોગ કેવી રીતે કરવો તે સમજાવવા માટે તેને સામાન્ય સંદેશ લખવાની જરૂર છે. પરંતુ આ પ્રોગ્રામિંગનું લક્ષણ પણ નથી, પરંતુ સારી, સમજદાર ભાષાનું લક્ષણ છે.

ઑફલાઇન બેકઅપ કેવી રીતે કરવું તે અમને ખબર નથી. જો ડેટાબેઝ જૂઠું બોલે છે, તો અમે તેનો બેકઅપ લઈ શકતા નથી. પરંતુ અહીં બધું ખૂબ જ સરળ છે. જ્યારે તે શરૂ થયું ત્યારે અમે LSN દ્વારા બેકઅપને કૉલ કરીએ છીએ. અંતર્ગત આધારનો LSN કંટ્રોલ ફાઇલમાંથી વાંચવો આવશ્યક છે. અને આ એક અવાસ્તવિક લક્ષણ છે. ઘણી બેકઅપ સિસ્ટમ્સ અંતર્ગત ડેટાબેઝનો બેકઅપ લઈ શકે છે. અને તે અનુકૂળ છે.

અમે હાલમાં બેકઅપ જગ્યાના અભાવને યોગ્ય રીતે હેન્ડલ કરી શકતા નથી. કારણ કે અમે સામાન્ય રીતે ઘરે મોટા બેકઅપ સાથે કામ કરીએ છીએ. અને તેઓ તેની આસપાસ ન આવ્યા. પરંતુ જો કોઈ વ્યક્તિ અત્યારે ગોમાં પ્રોગ્રામ કરવા માંગે છે, તો બકેટમાં જગ્યાની બહારની ભૂલો માટે હેન્ડલિંગ ઉમેરો. હું ચોક્કસપણે પુલ વિનંતી પર ધ્યાન આપીશ.

અને મુખ્ય વસ્તુ જે આપણને ચિંતા કરે છે તે એ છે કે આપણે શક્ય તેટલા ડોકર એકીકરણ પરીક્ષણો જોઈએ છે જે વિવિધ દૃશ્યો તપાસે છે. અત્યારે અમે ફક્ત મૂળભૂત દૃશ્યોનું પરીક્ષણ કરી રહ્યા છીએ. દરેક કમિટ પર, પરંતુ અમે કમિટ-બાય-કમિટ તમામ કાર્યક્ષમતાને અમે સપોર્ટ કરીએ છીએ તે તપાસવા માંગીએ છીએ. ખાસ કરીને, ઉદાહરણ તરીકે, અમારી પાસે PostgreSQL 9.4-9.5 માટે પૂરતો આધાર હશે. અમે તેમને સમર્થન આપીએ છીએ કારણ કે સમુદાય PostgreSQL ને સપોર્ટ કરે છે, પરંતુ અમે ખાતરી કરવા માટે કમિટ-બાય-કમિટ તપાસતા નથી કે બધું તૂટી ન જાય. અને મને લાગે છે કે આ એક ગંભીર જોખમ છે.

અમારી પાસે યાન્ડેક્સ ડેટાબેઝ મેનેજમેન્ટમાં એક હજારથી વધુ ક્લસ્ટરો પર WAL-G ચાલી રહ્યું છે. અને તે દરરોજ કેટલાક સો ટેરાબાઇટ ડેટાનો બેકઅપ લે છે.

અમારી પાસે અમારા કોડમાં ઘણા બધા TODO છે. જો તમારે પ્રોગ્રામ કરવો હોય તો આવો, અમે પુલ વિનંતીઓની રાહ જોઈ રહ્યા છીએ, અમે પ્રશ્નોની રાહ જોઈ રહ્યા છીએ.

પ્રશ્નો

શુભ સાંજ! આભાર! મારું અનુમાન છે કે જો તમે WAL-delta નો ઉપયોગ કરી રહ્યાં છો, તો તમે કદાચ પૂર્ણ-પૃષ્ઠના લખાણો પર ખૂબ આધાર રાખશો. અને જો એમ હોય, તો શું તમે પરીક્ષણો ચલાવ્યા? તમે સુંદર આલેખ બતાવ્યો. જો FPW બંધ કરવામાં આવે તો તે કેટલું સુંદર બનશે?

આખા પાનાના લખાણો અમારા માટે સક્ષમ છે, અમે તેને નિષ્ક્રિય કરવાનો પ્રયાસ કર્યો નથી. એટલે કે, મેં, વિકાસકર્તા તરીકે, તેને બંધ કરવાનો પ્રયાસ કર્યો નથી. સિસ્ટમ એડમિનિસ્ટ્રેટર્સ કે જેમણે સંશોધન કર્યું છે તે કદાચ આ મુદ્દા પર સંશોધન કર્યું છે. પરંતુ અમને FPW ની જરૂર છે. લગભગ કોઈ પણ તેને અક્ષમ કરતું નથી, કારણ કે અન્યથા પ્રતિકૃતિમાંથી બેકઅપ લેવાનું અશક્ય છે.

રિપોર્ટ માટે આભાર! મારા બે પ્રશ્નો છે. પહેલો પ્રશ્ન એ છે કે ટેબલસ્પેસનું શું થશે?

અમે પુલ વિનંતીની રાહ જોઈ રહ્યા છીએ. અમારા ડેટાબેઝ SSD અને NMVE ડિસ્ક પર રહે છે અને અમને ખરેખર આ સુવિધાની જરૂર નથી. હું તેને સારી રીતે કરવા માટે અત્યારે ગંભીર સમય પસાર કરવા તૈયાર નથી. હું પૂરા દિલથી હિમાયત કરું છું કે અમે આને સમર્થન આપીએ છીએ. એવા લોકો છે જેમણે તેને ટેકો આપ્યો છે, પરંતુ તેને અનુકૂળ રીતે સમર્થન આપ્યું છે. તેઓએ કાંટો બનાવ્યો, પરંતુ તેઓ પુલ વિનંતીઓ કરતા નથી. (સંસ્કરણ 0.2.13 માં ઉમેરાયેલ)

અને બીજો પ્રશ્ન. તમે શરૂઆતમાં જ કહ્યું હતું કે WAL-G ધારે છે કે તે એકલા કામ કરે છે અને કોઈ રેપરની જરૂર નથી. હું જાતે રેપરનો ઉપયોગ કરું છું. શા માટે તેઓનો ઉપયોગ ન કરવો જોઈએ?

અમે ઇચ્છીએ છીએ કે તે બલાલિકાની જેમ સરળ હોય. આનો અર્થ એ છે કે તમારે બલાલિકા સિવાય કંઈપણની જરૂર નથી. અમે સિસ્ટમ સરળ બનાવવા માંગીએ છીએ. જો તમારી પાસે કાર્યક્ષમતા છે જે તમારે સ્ક્રિપ્ટમાં કરવાની જરૂર છે, તો આવો અને અમને કહો - અમે તે ગોમાં કરીશું.

શુભ સાંજ! રિપોર્ટ માટે આભાર! અમે GPG ડિક્રિપ્શન સાથે કામ કરવા માટે WAL-G મેળવવામાં અસમર્થ હતા. તે સામાન્ય રીતે એન્ક્રિપ્ટ કરે છે, પરંતુ ડિક્રિપ્ટ કરવા માંગતા નથી. શું તે કંઈક છે જે આપણા માટે કામ કરતું નથી? પરિસ્થિતિ નિરાશાજનક છે.

GitHub પર સમસ્યા બનાવો અને ચાલો તેને શોધી કાઢીએ.

એટલે કે, તમે આનો સામનો કર્યો નથી?

એરર રિપોર્ટની એક વિશેષતા છે કે જ્યારે WAL-G ને સમજાતું નથી કે તે કેવા પ્રકારની ફાઇલ છે, ત્યારે તે પૂછે છે: "કદાચ તે એન્ક્રિપ્ટેડ છે?" કદાચ સમસ્યા એ એન્ક્રિપ્શનની નથી. હું આ વિષય પર લોગીંગ સુધારવા માંગુ છું. તેણે તેને ડિસાયફર કરવું જોઈએ. અમે હાલમાં આ વિષય પર એ અર્થમાં કામ કરી રહ્યા છીએ કે સાર્વજનિક અને ખાનગી કી મેળવવા માટેની સિસ્ટમ કેવી રીતે ગોઠવવામાં આવે છે તે અમને ખરેખર ગમતું નથી. કારણ કે આપણે બાહ્ય GPG કહીએ છીએ જેથી તે આપણને તેની ચાવીઓ આપે. અને પછી આપણે આ કીઓ લઈએ છીએ અને તેને આંતરિક GPG પર સ્થાનાંતરિત કરીએ છીએ, જે ખુલ્લું PGP છે, જે WAL-G ની અંદર આપણા માટે સંકલિત છે, અને ત્યાં આપણે એન્ક્રિપ્શન કહીએ છીએ. આ સંદર્ભમાં, અમે સિસ્ટમમાં સુધારો કરવા માંગીએ છીએ અને લિબસોડિયમ એન્ક્રિપ્શનને સમર્થન આપવા માંગીએ છીએ (સંસ્કરણ 0.2.15 માં ઉમેરાયેલ). અલબત્ત, ડીકોડિંગ કામ કરવું જોઈએ, ચાલો તેને શોધી કાઢીએ - તમારે થોડા શબ્દો કરતાં લક્ષણોની વધુ જરૂર છે. તમે ક્યારેક સ્પીકરના રૂમમાં ભેગા થઈને સિસ્ટમ જોઈ શકો છો. (બાહ્ય GPG વિના PGP એન્ક્રિપ્શન - v0.2.9)

નમસ્તે! રિપોર્ટ માટે આભાર! મારા બે પ્રશ્નો છે. મને pg_basebackup અને WAL લૉગ ઇન બે પ્રદાતાઓ કરવાની વિચિત્ર ઇચ્છા છે, એટલે કે હું એક ક્લાઉડ અને બીજું કરવા માંગુ છું. આ કરવા માટે કોઈ રીત છે?

આ હવે અસ્તિત્વમાં નથી, પરંતુ તે એક રસપ્રદ વિચાર છે.

હું ફક્ત એક પ્રદાતા પર વિશ્વાસ કરતો નથી, હું બીજામાં પણ તે જ રાખવા માંગુ છું, માત્ર કિસ્સામાં.

વિચાર રસપ્રદ છે. તકનીકી રીતે, આ અમલમાં મૂકવું મુશ્કેલ નથી. વિચારને ખોવાઈ જવાથી રોકવા માટે, શું હું તમને GitHub પર મુદ્દો બનાવવા માટે કહી શકું?

હા અલબત્ત.

અને પછી, જ્યારે વિદ્યાર્થીઓ Google સમર ઓફ કોડ પર આવે છે, ત્યારે અમે તેમને પ્રોજેક્ટમાં ઉમેરીશું જેથી કરીને તેમાંથી વધુ મેળવવા માટે વધુ કાર્ય થાય.

અને બીજો પ્રશ્ન. GitHub પર એક સમસ્યા છે. મને લાગે છે કે તે પહેલેથી જ બંધ છે. પુનઃસ્થાપન દરમિયાન ગભરાટ છે. અને તેને હરાવવા માટે તમે એક અલગ એસેમ્બલી બનાવી. તે મુદ્દાઓમાં યોગ્ય છે. અને એક થ્રેડમાં વેરીએબલ એન્વાયરમેન્ટ કરવાનો વિકલ્પ છે. અને તેથી જ તે ખૂબ જ ધીરે ધીરે કામ કરે છે. અને અમે આ સમસ્યાનો સામનો કર્યો, અને તે હજી સુધી ઠીક કરવામાં આવ્યો નથી.

સમસ્યા એ છે કે કેટલાક કારણોસર સ્ટોરેજ (CEPH) કનેક્શનને રીસેટ કરે છે જ્યારે અમે તેની પાસે ઉચ્ચ સંમતિ સાથે આવીએ છીએ. આ વિશે શું કરી શકાય? ફરીથી પ્રયાસ તર્ક આના જેવો દેખાય છે. અમે ફરીથી ફાઇલ ડાઉનલોડ કરવાનો પ્રયાસ કરી રહ્યા છીએ. એક પાસમાં, અમારી પાસે સંખ્યાબંધ ફાઇલો ડાઉનલોડ થઈ ન હતી, અમે લોગ ઇન ન થયા હોય તેવા તમામ લોકો માટે બીજી ફાઇલ બનાવીશું. અને જ્યાં સુધી ઓછામાં ઓછી એક ફાઇલ પુનરાવૃત્તિ દીઠ લોડ થાય છે, અમે પુનરાવર્તન કરીએ છીએ અને પુનરાવર્તન કરીએ છીએ અને પુનરાવર્તન કરીએ છીએ. અમે ફરીથી પ્રયાસ કરવાના તર્કમાં સુધારો કર્યો - ઘાતાંકીય બેકઓફ. પરંતુ તે હકીકત સાથે શું કરવું તે સંપૂર્ણપણે સ્પષ્ટ નથી કે કનેક્શન ફક્ત સ્ટોરેજ સિસ્ટમ બાજુ પર તૂટી જાય છે. એટલે કે, જ્યારે આપણે એક સ્ટ્રીમ પર અપલોડ કરીએ છીએ, ત્યારે તે આ જોડાણોને તોડતું નથી. આપણે અહીં શું સુધારી શકીએ? અમારી પાસે નેટવર્ક થ્રોટલિંગ છે, અમે દરેક કનેક્શનને તે મોકલે છે તે બાઇટ્સની સંખ્યા દ્વારા મર્યાદિત કરી શકીએ છીએ. નહિંતર, મને ખબર નથી કે ઑબ્જેક્ટ સ્ટોરેજ અમને તેમાંથી સમાંતર ડાઉનલોડ અથવા ડાઉનલોડ કરવાની મંજૂરી આપતું નથી તે હકીકત સાથે કેવી રીતે વ્યવહાર કરવો.

SLA નથી? શું તે તેમના માટે લખાયેલું નથી કે તેઓ કેવી રીતે પોતાને ત્રાસ આપવા દે છે?

મુદ્દો એ છે કે જે લોકો આ પ્રશ્ન સાથે આવે છે તેમની પાસે સામાન્ય રીતે તેમની પોતાની તિજોરી હોય છે. એટલે કે, એમેઝોન અથવા ગૂગલ ક્લાઉડ અથવા યાન્ડેક્સ ઑબ્જેક્ટ સ્ટોરેજમાંથી કોઈ આવતું નથી.

કદાચ પ્રશ્ન હવે તમારા માટે નથી?

આ કિસ્સામાં અહીં પ્રશ્ન કોના માટે વાંધો નથી. જો આનો સામનો કેવી રીતે કરવો તે અંગે કોઈ વિચારો હોય, તો ચાલો તેને WAL-G માં કરીએ. પરંતુ હજી સુધી મને આનો સામનો કેવી રીતે કરવો તે અંગે કોઈ સારા વિચારો નથી. કેટલાક ઑબ્જેક્ટ સ્ટોરેજ છે જે લિસ્ટિંગ બેકઅપને અલગ રીતે સપોર્ટ કરે છે. તમે તેમને ઑબ્જેક્ટ્સની સૂચિ બનાવવા માટે કહો છો, અને તેઓ ત્યાં ફોલ્ડર ઉમેરે છે. WAL-G આનાથી ડરી જાય છે - અહીં કેટલીક એવી વસ્તુ છે જે ફાઇલ નથી, હું તેને પુનઃસ્થાપિત કરી શકતો નથી, જેનો અર્થ છે કે બેકઅપ પુનઃસ્થાપિત થયું નથી. એટલે કે, વાસ્તવમાં, તમારી પાસે સંપૂર્ણપણે પુનઃસ્થાપિત ક્લસ્ટર છે, પરંતુ તે તમને એક ભૂલભરેલું સ્ટેટસ આપે છે કારણ કે ઑબ્જેક્ટ સ્ટોરેજે કેટલીક વિચિત્ર માહિતી પરત કરી હતી જે તે સંપૂર્ણપણે સમજી શકતી નથી.

આ એક વસ્તુ છે જે મેઇલ ક્લાઉડમાં થાય છે.

જો તમે પ્રજનન બનાવી શકો તો...

તે સતત પુનઃઉત્પાદિત થાય છે ...

જો ત્યાં પુનઃઉત્પાદન હોય, તો મને લાગે છે કે અમે ફરીથી પ્રયાસ કરવાની વ્યૂહરચનાઓ સાથે પ્રયોગ કરીશું અને ફરીથી પ્રયાસ કેવી રીતે કરવો અને ક્લાઉડને આપણા માટે શું જરૂરી છે તે સમજીશું. કદાચ તે ત્રણ જોડાણો પર અમારા માટે સ્થિર હશે અને જોડાણ તોડશે નહીં, પછી અમે કાળજીપૂર્વક ત્રણ સુધી પહોંચીશું. કારણ કે હવે અમે ખૂબ જ ઝડપથી કનેક્શન છોડી દઈએ છીએ, એટલે કે જો અમે 16 થ્રેડો સાથે પુનઃપ્રાપ્તિ શરૂ કરીએ છીએ, તો પ્રથમ પુનઃપ્રયાસ પછી 8 થ્રેડો, 4 થ્રેડો, 2 થ્રેડો અને એક હશે. અને પછી તે ફાઇલને એક પ્રવાહમાં ખેંચશે. જો ત્યાં કેટલાક જાદુઈ મૂલ્યો છે જેમ કે 7,5 થ્રેડો પમ્પિંગ માટે શ્રેષ્ઠ છે, તો અમે તેના પર ધ્યાન આપીશું અને બીજા 7,5 થ્રેડો બનાવવાનો પ્રયાસ કરીશું. અહીં એક વિચાર છે.

રિપોર્ટ માટે આભાર! WAL-G સાથે કામ કરવા માટેનો સંપૂર્ણ વર્કફ્લો કેવો દેખાય છે? ઉદાહરણ તરીકે, મૂર્ખ કિસ્સામાં જ્યારે પૃષ્ઠો પર કોઈ ડેલ્ટા નથી. અને અમે પ્રારંભિક બેકઅપ લઈએ છીએ અને દૂર કરીએ છીએ, પછી જ્યાં સુધી આપણે ચહેરા પર વાદળી ન થઈએ ત્યાં સુધી શાફ્ટને આર્કાઇવ કરીએ છીએ. અહીં, જેમ હું તેને સમજું છું, ત્યાં એક ભંગાણ છે. અમુક સમયે તમારે પૃષ્ઠોનો ડેલ્ટા બેકઅપ લેવાની જરૂર છે, એટલે કે કેટલીક બાહ્ય પ્રક્રિયા આને ચલાવી રહી છે અથવા આ કેવી રીતે થાય છે?

ડેલ્ટા બેકઅપ API એકદમ સરળ છે. ત્યાં એક સંખ્યા છે - મહત્તમ ડેલ્ટા પગલાં, તેને તે કહેવામાં આવે છે. તે ડિફોલ્ટ શૂન્ય છે. આનો અર્થ એ છે કે જ્યારે પણ તમે બેકઅપ-પુશ કરો છો, ત્યારે તે સંપૂર્ણ બેકઅપ ડાઉનલોડ કરે છે. જો તમે તેને કોઈપણ સકારાત્મક સંખ્યામાં બદલો છો, ઉદાહરણ તરીકે, 3, તો આગલી વખતે જ્યારે તમે બેકઅપ-પુશ કરો છો, તો તે અગાઉના બેકઅપના ઇતિહાસને જુએ છે. તે જુએ છે કે તમે 3 ડેલ્ટાની સાંકળને ઓળંગતા નથી અને ડેલ્ટા બનાવે છે.

એટલે કે, જ્યારે પણ આપણે WAL-G લોન્ચ કરીએ છીએ, ત્યારે તે સંપૂર્ણ બેકઅપ લેવાનો પ્રયાસ કરે છે?

ના, અમે WAL-G ચલાવીએ છીએ અને જો તમારી નીતિઓ તેને મંજૂરી આપે તો તે ડેલ્ટા બનાવવાનો પ્રયાસ કરે છે.

સામાન્ય રીતે કહીએ તો, જો તમે તેને દર વખતે શૂન્ય સાથે ચલાવો છો, તો શું તે pg_basebackup જેવું વર્તન કરશે?

ના, તે હજુ પણ ઝડપથી ચાલશે કારણ કે તે કમ્પ્રેશન અને સમાંતરનો ઉપયોગ કરે છે. Pg_basebackup તમારી બાજુમાં શાફ્ટ મૂકશે. WAL-G ધારે છે કે તમે આર્કાઇવિંગ ગોઠવેલ છે. અને જો તે રૂપરેખાંકિત ન હોય તો તે ચેતવણી જારી કરશે.

Pg_basebackup શાફ્ટ વિના ચલાવી શકાય છે.

હા, પછી તેઓ લગભગ સમાન વર્તન કરશે. Pg_basebackup ફાઇલ સિસ્ટમમાં નકલો. માર્ગ દ્વારા, અમારી પાસે એક નવી સુવિધા છે જેનો હું ઉલ્લેખ કરવાનું ભૂલી ગયો છું. હવે આપણે pg_basebackup થી ફાઈલ સિસ્ટમમાં બેકઅપ લઈ શકીએ છીએ. મને ખબર નથી કે આ શા માટે જરૂરી છે, પરંતુ તે ત્યાં છે.

ઉદાહરણ તરીકે, CephFS પર. દરેક વ્યક્તિ ઑબ્જેક્ટ સ્ટોરેજને ગોઠવવા માંગતી નથી.

હા, કદાચ તેથી જ તેઓએ આ સુવિધા વિશે પ્રશ્ન પૂછ્યો જેથી કરીને અમે તે કરી શકીએ. અને અમે તે કર્યું.

રિપોર્ટ માટે આભાર! ફાઇલ સિસ્ટમ પર કૉપિ કરવા વિશે માત્ર એક પ્રશ્ન છે. બૉક્સની બહાર, શું તમે હવે રિમોટ સ્ટોરેજ પર કૉપિ કરવાનું સમર્થન કરો છો, ઉદાહરણ તરીકે, જો ડેટા સેન્ટરમાં અમુક શેલ્ફ હોય કે બીજું કંઈક?

આ રચનામાં, આ એક મુશ્કેલ પ્રશ્ન છે. હા, અમે સમર્થન કરીએ છીએ, પરંતુ આ કાર્યક્ષમતા હજી સુધી કોઈપણ પ્રકાશનમાં શામેલ નથી. એટલે કે, તમામ પૂર્વ-પ્રકાશન આને સમર્થન આપે છે, પરંતુ પ્રકાશન સંસ્કરણો નથી. આ કાર્યક્ષમતા આવૃત્તિ 0.2 માં ઉમેરવામાં આવી હતી. તે ચોક્કસપણે ટૂંક સમયમાં રિલીઝ થશે, જલદી અમે બધી જાણીતી ભૂલોને ઠીક કરીશું. પરંતુ અત્યારે આ ફક્ત પ્રી-રીલીઝમાં જ થઈ શકે છે. પ્રી-રીલીઝમાં બે ભૂલો છે. WAL-E પુનઃપ્રાપ્તિ સાથે સમસ્યા, અમે તેને ઠીક કરી નથી. અને નવીનતમ પૂર્વ-પ્રકાશનમાં ડેલ્ટા-બેકઅપ વિશેની ભૂલ ઉમેરવામાં આવી હતી. તેથી, અમે દરેકને પ્રકાશન સંસ્કરણોનો ઉપયોગ કરવાની ભલામણ કરીએ છીએ. જલદી જ પ્રી-રિલીઝમાં કોઈ વધુ બગ્સ નથી, અમે કહી શકીએ કે અમે Google Cloud, S3-સુસંગત વસ્તુઓ અને ફાઇલ સ્ટોરેજને સપોર્ટ કરીએ છીએ.

હેલો, રિપોર્ટ માટે આભાર. જેમ હું સમજું છું તેમ, WAL-G એ બાર્મેન જેવી કોઈ પ્રકારની કેન્દ્રિય પ્રણાલી નથી? શું તમે આ દિશામાં આગળ વધવાની યોજના ઘડી રહ્યા છો?

સમસ્યા એ છે કે આપણે આ દિશામાંથી દૂર થઈ ગયા છીએ. WAL-G બેઝ હોસ્ટ પર, ક્લસ્ટર હોસ્ટ પર અને ક્લસ્ટરમાંના તમામ હોસ્ટ પર રહે છે. જ્યારે અમે ઘણા હજાર ક્લસ્ટરોમાં ગયા, ત્યારે અમારી પાસે ઘણા બારટેન્ડર ઇન્સ્ટોલેશન હતા. અને જ્યારે પણ તેમનામાં કંઈક અલગ પડે છે, ત્યારે તે એક મોટી સમસ્યા છે. કારણ કે તેમને રિપેર કરવાની જરૂર છે, તમારે સમજવાની જરૂર છે કે કયા ક્લસ્ટરમાં હવે બેકઅપ નથી. હું બેકઅપ સિસ્ટમ્સ માટે ભૌતિક હાર્ડવેરની દિશામાં WAL-G વિકસાવવાની યોજના ધરાવતો નથી. જો સમુદાયને અહીં કેટલીક કાર્યક્ષમતા જોઈતી હોય, તો મને જરાય વાંધો નથી.

અમારી પાસે ટીમો છે જે સ્ટોરેજ માટે જવાબદાર છે. અને અમને એટલું સારું લાગે છે કે તે અમે નથી, કે ત્યાં ખાસ લોકો છે જે અમારી ફાઇલો જ્યાં ફાઇલો સુરક્ષિત છે ત્યાં મૂકે છે. તેઓ ચોક્કસ સંખ્યામાં ફાઈલોની ખોટનો સામનો કરવા માટે ત્યાં તમામ પ્રકારના હોંશિયાર કોડિંગ કરે છે. તેઓ નેટવર્ક બેન્ડવિડ્થ માટે જવાબદાર છે. જ્યારે તમારી પાસે બારટેન્ડર હોય, ત્યારે તમને અચાનક ખબર પડી શકે છે કે એક જ સર્વર પર ઘણા બધા ટ્રાફિકવાળા નાના ડેટાબેસેસ ભેગા થયા છે. તમારી પાસે તેના પર ઘણી જગ્યા હોય તેવું લાગે છે, પરંતુ કેટલાક કારણોસર બધું નેટવર્ક દ્વારા બંધબેસતું નથી. તે બીજી રીતે બહાર ચાલુ કરી શકે છે. ત્યાં ઘણા બધા નેટવર્ક્સ છે, ત્યાં પ્રોસેસર કોરો છે, પરંતુ અહીં કોઈ ડિસ્ક નથી. અને અમે કંઈક હલ કરવાની આ જરૂરિયાતથી કંટાળી ગયા, અને અમે એ હકીકત તરફ આગળ વધ્યા કે ડેટા સ્ટોરેજ એ એક અલગ સેવા છે, જેના માટે અલગ વિશેષ લોકો જવાબદાર છે.

પીએસ એક નવું સંસ્કરણ બહાર પાડવામાં આવ્યું છે 0.2.15, જેમાં તમે .walg.json રૂપરેખાંકન ફાઇલનો ઉપયોગ કરી શકો છો, જે ડિફોલ્ટ રૂપે postgres હોમ ડિરેક્ટરીમાં સ્થિત છે. તમે bash સ્ક્રિપ્ટો છોડી શકો છો. ઉદાહરણ .walg.json આ અંકમાં છે https://github.com/wal-g/wal-g/issues/545

વિડિઓ:

સોર્સ: www.habr.com