શા માટે તમને અર્ધ-સિંક્રનસ પ્રતિકૃતિની જરૂર પડી શકે છે?

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

પરિચય

હકીકત એ છે કે HDD પ્રતિ સેકન્ડ માત્ર 400-700 ઓપરેશન્સ કરી શકે છે (જે ઉચ્ચ-લોડ સિસ્ટમ માટે લાક્ષણિક આરપીએસ સાથે અતુલ્ય છે), ક્લાસિક ડિસ્ક ડેટાબેઝ એ આર્કિટેક્ચરની અડચણ છે. તેથી, આ સંગ્રહની સ્કેલિંગ પેટર્ન પર વિશેષ ધ્યાન આપવું જરૂરી છે.

હાલમાં, 2 ડેટાબેઝ સ્કેલિંગ પેટર્ન છે: પ્રતિકૃતિ અને શાર્ડિંગ. શાર્ડિંગ તમને લેખન કામગીરીને માપવા માટે પરવાનગી આપે છે, અને પરિણામે, તમારા ક્લસ્ટરમાં સર્વર દીઠ લેખન દીઠ આરપીએસ ઘટાડે છે. પ્રતિકૃતિ તમને તે જ વસ્તુ કરવાની મંજૂરી આપે છે, પરંતુ રીડ ઑપરેશન્સ સાથે. તે આ પેટર્ન છે જેને આ લેખ સમર્પિત છે.

પ્રતિકૃતિ

જો તમે પ્રતિકૃતિને ખૂબ ઊંચા સ્તરે જુઓ છો, તો તે એક સરળ બાબત છે: તમારી પાસે એક સર્વર હતું, તેના પર ડેટા હતો, અને પછી આ સર્વર હવે આ ડેટા વાંચવાના ભારનો સામનો કરી શકશે નહીં. તમે થોડા વધુ સર્વર્સ ઉમેરો, બધા સર્વર પર ડેટા સિંક્રનાઇઝ કરો, અને વપરાશકર્તા તમારા ક્લસ્ટરમાંના કોઈપણ સર્વરમાંથી વાંચી શકે છે.

તેની સ્પષ્ટ સરળતા હોવા છતાં, આ યોજનાના વિવિધ અમલીકરણોને વર્ગીકૃત કરવા માટે ઘણા વિકલ્પો છે:

• ક્લસ્ટરમાં ભૂમિકાઓ દ્વારા (માસ્ટર-માસ્ટર અથવા માસ્ટર-સ્લેવ)
• મોકલેલ ઑબ્જેક્ટ્સ દ્વારા (પંક્તિ-આધારિત, નિવેદન-આધારિત અથવા મિશ્ર)
• નોડ સિંક્રનાઇઝેશન મિકેનિઝમ અનુસાર

આજે આપણે બિંદુ 3 સાથે વ્યવહાર કરીશું.

ટ્રાન્ઝેક્શન કમિટ કેવી રીતે થાય છે?

આ વિષય પ્રતિકૃતિ સાથે સીધો સંબંધ ધરાવતો નથી; તેના પર એક અલગ લેખ લખી શકાય છે, પરંતુ ટ્રાન્ઝેક્શન કમિટ મિકેનિઝમને સમજ્યા વિના આગળ વાંચવું નકામું હોવાથી, હું તમને સૌથી મૂળભૂત બાબતોની યાદ અપાવીશ. ટ્રાન્ઝેક્શન કમિટ 3 તબક્કામાં થાય છે:

1. ડેટાબેઝ લોગમાં ટ્રાન્ઝેક્શન લોગિંગ.
2. ડેટાબેઝ એન્જિનમાં ટ્રાન્ઝેક્શનનો ઉપયોગ કરવો.
3. ક્લાયન્ટને પુષ્ટિ પરત કરવી કે વ્યવહાર સફળતાપૂર્વક લાગુ કરવામાં આવ્યો હતો.

જુદા જુદા ડેટાબેઝમાં, આ અલ્ગોરિધમમાં ઘોંઘાટ હોઈ શકે છે: ઉદાહરણ તરીકે, MySQL ડેટાબેઝના InnoDB એન્જિનમાં 2 લોગ છે: એક પ્રતિકૃતિ (દ્વિસંગી લોગ) માટે અને બીજો ACID (અનડૂ/રિડો લોગ) જાળવવા માટે, જ્યારે PostgreSQL માં ત્યાં એક લોગ છે જે બંને કાર્યો કરે છે (આગળ લોગ = WAL લખો). પરંતુ ઉપર જે રજૂ કરવામાં આવ્યું છે તે ચોક્કસપણે સામાન્ય ખ્યાલ છે, જે આવા ઘોંઘાટને ધ્યાનમાં લેવાની મંજૂરી આપે છે.

સિંક્રનસ (સમન્વયન) પ્રતિકૃતિ

ચાલો ટ્રાન્ઝેક્શન કમિટ અલ્ગોરિધમમાં પ્રાપ્ત ફેરફારોની નકલ કરવા માટે તર્ક ઉમેરીએ:

1. ડેટાબેઝ લોગમાં ટ્રાન્ઝેક્શન લોગિંગ.
2. ડેટાબેઝ એન્જિનમાં ટ્રાન્ઝેક્શનનો ઉપયોગ કરવો.
3. બધી પ્રતિકૃતિઓને ડેટા મોકલી રહ્યું છે.
4. તમામ પ્રતિકૃતિઓ પાસેથી પુષ્ટિ મેળવવી કે તેમના પર વ્યવહાર પૂર્ણ થઈ ગયો છે.
5. ક્લાયન્ટને પુષ્ટિ પરત કરવી કે વ્યવહાર સફળતાપૂર્વક લાગુ કરવામાં આવ્યો હતો.

આ અભિગમ સાથે અમને સંખ્યાબંધ ગેરફાયદા મળે છે:

• ક્લાયન્ટ તમામ પ્રતિકૃતિઓ પર ફેરફારો લાગુ કરવા માટે રાહ જુએ છે.
• જેમ જેમ ક્લસ્ટરમાં નોડ્સની સંખ્યામાં વધારો થાય છે, અમે લખવાની કામગીરી સફળ થવાની સંભાવના ઘટાડીએ છીએ.

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

શું આપણે માત્ર ચોક્કસ ટકાવારી નોડ્સમાંથી પુષ્ટિની રાહ જોઈ શકીએ છીએ, ઉદાહરણ તરીકે, 51% (કોરમ) થી? હા, અમે કરી શકીએ છીએ, પરંતુ ક્લાસિક સંસ્કરણમાં, તમામ ગાંઠોમાંથી પુષ્ટિ જરૂરી છે, કારણ કે આ રીતે આપણે ક્લસ્ટરમાં સંપૂર્ણ ડેટા સુસંગતતાની ખાતરી કરી શકીએ છીએ, જે આ પ્રકારની પ્રતિકૃતિનો અસંદિગ્ધ લાભ છે.

અસુમેળ (અસિંક) પ્રતિકૃતિ

ચાલો અગાઉના અલ્ગોરિધમમાં ફેરફાર કરીએ. અમે પ્રતિકૃતિઓને "થોડી વાર પછી" ડેટા મોકલીશું, અને "ક્યારેક પછી" ફેરફારો પ્રતિકૃતિઓ પર લાગુ થશે:

1. ડેટાબેઝ લોગમાં ટ્રાન્ઝેક્શન લોગિંગ.
2. ડેટાબેઝ એન્જિનમાં ટ્રાન્ઝેક્શનનો ઉપયોગ કરવો.
3. ક્લાયન્ટને પુષ્ટિ પરત કરવી કે વ્યવહાર સફળતાપૂર્વક લાગુ કરવામાં આવ્યો હતો.
4. પ્રતિકૃતિઓમાં ડેટા મોકલવો અને તેમાં ફેરફારો લાગુ કરવા.

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

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

સેમીસિંક પ્રતિકૃતિ

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

ચાલો 2 અગાઉના અભિગમોને જોડવાનો પ્રયાસ કરીએ. અમે ક્લાયંટને લાંબા સમય સુધી રાખીશું નહીં, પરંતુ અમને જરૂરી રહેશે કે ડેટાની નકલ કરવામાં આવે:

1. ડેટાબેઝ લોગમાં ટ્રાન્ઝેક્શન લોગિંગ.
2. ડેટાબેઝ એન્જિનમાં ટ્રાન્ઝેક્શનનો ઉપયોગ કરવો.
3. પ્રતિકૃતિઓ પર ડેટા મોકલી રહ્યું છે.
4. પ્રતિકૃતિમાંથી પુષ્ટિ પ્રાપ્ત કરવી કે ફેરફારો પ્રાપ્ત થયા છે (તેઓ "ક્યારેક પછી" લાગુ કરવામાં આવશે).
5. ક્લાયન્ટને પુષ્ટિ પરત કરવી કે વ્યવહાર સફળતાપૂર્વક લાગુ કરવામાં આવ્યો હતો.

મહેરબાની કરીને નોંધ કરો કે આ અલ્ગોરિધમ સાથે, ટ્રાન્ઝેક્શન નુકસાન ત્યારે જ થાય છે જો ફેરફારો પ્રાપ્ત કરનાર નોડ અને પ્રતિકૃતિ નોડ બંને નિષ્ફળ જાય. આવી નિષ્ફળતાની સંભાવના ઓછી માનવામાં આવે છે, અને આ જોખમો સ્વીકારવામાં આવે છે.

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

લુઝ-લેસ સેમિસિંક પ્રતિકૃતિ

જો તમે થોડો વિચાર કરો, તો તમે અલ્ગોરિધમના પગલાંને ઉલટાવી શકો છો અને આ દૃશ્યમાં ફેન્ટમ રીડની સમસ્યાને ઠીક કરી શકો છો:

1. ડેટાબેઝ લોગમાં ટ્રાન્ઝેક્શન લોગિંગ.
2. પ્રતિકૃતિ ડેટા મોકલી રહ્યું છે.
3. પ્રતિકૃતિમાંથી પુષ્ટિ પ્રાપ્ત કરવી કે ફેરફારો પ્રાપ્ત થયા છે (તેઓ "ક્યારેક પછી" લાગુ કરવામાં આવશે).
4. ડેટાબેઝ એન્જિનમાં ટ્રાન્ઝેક્શનનો ઉપયોગ કરવો.
5. ક્લાયન્ટને પુષ્ટિ પરત કરવી કે વ્યવહાર સફળતાપૂર્વક લાગુ કરવામાં આવ્યો હતો.

હવે અમે ફેરફારો ત્યારે જ કરીએ છીએ જો તેઓની નકલ કરવામાં આવી હોય.

નિષ્કર્ષ

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

બસ એટલું જ. પર મળીએ કોર્સ!

સોર્સ: www.habr.com