પરિચય

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

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

હવે મેનેજમેન્ટે મંજૂરી આપી દીધી છે MIT લાયસન્સ હેઠળ ઓપન સોર્સ સમુદાય માટે પ્રોજેક્ટ ખોલો. README નું ટૂંક સમયમાં અંગ્રેજીમાં ભાષાંતર કરવામાં આવશે (કારણ કે એવી અપેક્ષા રાખવામાં આવે છે કે મુખ્ય ઉપભોક્તા પેસમેકર અને PostgreSQL વિકાસકર્તાઓ હશે), અને મેં આ લેખના રૂપમાં README નું જૂનું રશિયન સંસ્કરણ (આંશિક રીતે) રજૂ કરવાનું નક્કી કર્યું છે.

ક્લસ્ટરો વર્ચ્યુઅલ મશીનો પર જમાવવામાં આવે છે વર્ચ્યુઅલબોક્સ. કુલ 12 વર્ચ્યુઅલ મશીનો (કુલ 36GiB) તૈનાત કરવામાં આવશે, જે 4 ફોલ્ટ-ટોલરન્ટ ક્લસ્ટરો (વિવિધ વિકલ્પો) બનાવે છે. પ્રથમ બે ક્લસ્ટરમાં બે PostgreSQL સર્વરનો સમાવેશ થાય છે, જે વિવિધ ડેટા સેન્ટરોમાં સ્થિત છે અને એક સામાન્ય સર્વર છે. સાક્ષી c કોરમ ઉપકરણ (ત્રીજા ડેટા સેન્ટરમાં સસ્તા વર્ચ્યુઅલ મશીન પર હોસ્ટ કરવામાં આવે છે), જે અનિશ્ચિતતાને ઉકેલે છે 50% / 50%, તમારો મત કોઈ એક પક્ષને આપવો. ત્રણ ડેટા સેન્ટર્સમાં ત્રીજું ક્લસ્ટર: એક માસ્ટર, બે સ્લેવ, નં કોરમ ઉપકરણ. ચોથા ક્લસ્ટરમાં ચાર PostgreSQL સર્વર્સનો સમાવેશ થાય છે, બે ડેટા સેન્ટર દીઠ: એક માસ્ટર, બાકીની પ્રતિકૃતિઓ અને તેનો ઉપયોગ પણ સાક્ષી c કોરમ ઉપકરણ. ચોથું બે સર્વર અથવા એક ડેટા સેન્ટરની નિષ્ફળતાનો સામનો કરી શકે છે. જો જરૂરી હોય તો આ ઉકેલને મોટી સંખ્યામાં પ્રતિકૃતિઓ સુધી માપી શકાય છે.

ચોક્કસ સમય સેવા એનટીપીડી દોષ સહિષ્ણુતા માટે પણ પુનઃરૂપરેખાંકિત, પરંતુ તે પદ્ધતિનો ઉપયોગ કરે છે ntpd (અનાથ મોડ). વહેંચાયેલ સર્વર સાક્ષી કેન્દ્રિય NTP સર્વર તરીકે કાર્ય કરે છે, તેનો સમય તમામ ક્લસ્ટરોમાં વિતરિત કરે છે, ત્યાંથી બધા સર્વર્સને એકબીજા સાથે સુમેળ કરે છે. જો સાક્ષી નિષ્ફળ જાય છે અથવા અલગ થઈ જાય છે, પછી ક્લસ્ટર સર્વરમાંથી એક (ક્લસ્ટરની અંદર) તેનો સમય વિતરિત કરવાનું શરૂ કરશે. સહાયક કેશીંગ HTTP પ્રોક્સી સુધી પણ ઉભા કર્યા સાક્ષી, તેની મદદ સાથે, અન્ય વર્ચ્યુઅલ મશીનો પાસે Yum રીપોઝીટરીઝની ઍક્સેસ છે. વાસ્તવમાં, ચોક્કસ સમય અને પ્રોક્સી જેવી સેવાઓ મોટે ભાગે સમર્પિત સર્વર્સ પર હોસ્ટ કરવામાં આવશે, પરંતુ બૂથમાં તેઓ હોસ્ટ કરવામાં આવે છે સાક્ષી માત્ર વર્ચ્યુઅલ મશીનોની સંખ્યા અને જગ્યા બચાવવા માટે.

આવૃત્તિઓ

v0. વર્ચ્યુઅલબોક્સ 7 પર CentOS 11 અને PostgreSQL 6.1 સાથે કામ કરે છે.

ક્લસ્ટર માળખું

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

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

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

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

તુચંકા1 (કોમ્પેક્શન સાથેનું સર્કિટ)

માળખું

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

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

બે ગાંઠોના કિસ્સામાં, દોષ સહિષ્ણુતા ફક્ત અસુમેળ પ્રતિકૃતિ સાથે જ શક્ય છે, કારણ કે સિંક્રનસ પ્રતિકૃતિ સાથે, ગુલામની નિષ્ફળતા માસ્ટરના સ્ટોપ તરફ દોરી જશે.

સાક્ષી આપવામાં નિષ્ફળતા

સાક્ષી આપવામાં નિષ્ફળતા (કોરમ ઉપકરણ) હું ફક્ત Tuchanka1 ક્લસ્ટર માટે જ વિચારીશ, અન્ય તમામ સાથે તે સમાન વાર્તા હશે. જો સાક્ષી નિષ્ફળ જાય, તો ક્લસ્ટર સ્ટ્રક્ચરમાં કંઈપણ બદલાશે નહીં, બધું તે જ રીતે કામ કરવાનું ચાલુ રાખશે. પરંતુ કોરમ 2 માંથી 3 બનશે, અને તેથી પછીની કોઈપણ નિષ્ફળતા ક્લસ્ટર માટે ઘાતક હશે. તે હજુ પણ તાકીદે ઠીક કરવું પડશે.

Tuchanka1 ઇનકાર

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

તુચંકા2 (શાસ્ત્રીય)

માળખું

બે ગાંઠોની ઉત્તમ યોજના. માસ્ટર એક પર કામ કરે છે, બીજા પર ગુલામ. બંને વિનંતીઓ ચલાવી શકે છે (ગુલામ ફક્ત વાંચવામાં આવે છે), તેથી બંનેને ફ્લોટ IP દ્વારા નિર્દેશિત કરવામાં આવે છે: krogan2 એ માસ્ટર છે, krogan2s1 એ સ્લેવ છે. માલિક અને ગુલામ બંનેમાં દોષ સહનશીલતા હશે.

બે ગાંઠોના કિસ્સામાં, દોષ સહિષ્ણુતા ફક્ત અસુમેળ પ્રતિકૃતિ સાથે જ શક્ય છે, કારણ કે સિંક્રનસ પ્રતિકૃતિ સાથે, સ્લેવની નિષ્ફળતા માસ્ટરના સ્ટોપ તરફ દોરી જશે.

Tuchanka2 ઇનકાર

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

તુચંકા 4 (ઘણા ગુલામો)

માળખું

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

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

Tuchanka4 ઇનકાર

જો એક ડેટા સેન્ટર (એટલે ​​​​કે, બે સર્વર) નિષ્ફળ જાય, તો બીજા માટે સાક્ષી મત આપો. પરિણામે, બીજા ડેટા સેન્ટરમાં બે સર્વર ચાલી રહ્યા છે: એક માસ્ટર ચલાવી રહ્યું છે, અને માસ્ટર ફ્લોટ IP તેને નિર્દેશ કરે છે (વાંચવા-લેખવાની વિનંતીઓ પ્રાપ્ત કરવા માટે); અને બીજા સર્વર પર સિંક્રનસ પ્રતિકૃતિ સાથે એક સ્લેવ ચાલી રહ્યો છે, અને સ્લેવ ફ્લોટ IPમાંથી એક તેને નિર્દેશ કરે છે (ફક્ત વાંચવા માટેની વિનંતીઓ માટે).

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

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

Tuchanka3 (3 ડેટા કેન્દ્રો)

માળખું

આ એક એવી પરિસ્થિતિ માટેનું ક્લસ્ટર છે જ્યાં ત્રણ સંપૂર્ણ રીતે કાર્યરત ડેટા કેન્દ્રો છે, જેમાંના દરેકમાં સંપૂર્ણ રીતે કાર્યરત ડેટાબેઝ સર્વર છે. આ બાબતે કોરમ ઉપકરણ જરૂરી નથી. એક ડેટા સેન્ટરમાં માસ્ટરનો સ્ટાફ હોય છે, બીજા બેમાં ગુલામો હોય છે. પ્રતિકૃતિ સિંક્રનસ છે, ટાઇપ કરો ANY (slave1, slave2), એટલે કે, ક્લાયન્ટને પ્રતિબદ્ધતાની પુષ્ટિ પ્રાપ્ત થશે જ્યારે કોઈપણ સ્લેવ પ્રતિસાદ આપનાર પ્રથમ હશે કે તેણે પ્રતિબદ્ધતા સ્વીકારી છે. સંસાધનો માસ્ટર માટે એક ફ્લોટ આઇપી દ્વારા અને બે ગુલામો માટે સૂચવવામાં આવે છે. Tuchanka4 થી વિપરીત, ત્રણેય ફ્લોટ IP ફોલ્ટ-સહિષ્ણુ છે. ફક્ત-વાંચવા માટેના SQL પ્રશ્નોને સંતુલિત કરવા માટે તમે ઉપયોગ કરી શકો છો sql પ્રોક્સી (અલગ દોષ સહિષ્ણુતા સાથે), અથવા અડધા ક્લાયન્ટને એક સ્લેવ ફ્લોટ IP સોંપો, અને બીજા અડધા બીજાને.

Tuchanka3 ઇનકાર

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

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

સ્વચાલિત પરીક્ષણ સિસ્ટમ

વિવિધ ખામીઓનું અનુકરણ કરીને ક્લસ્ટરોની દોષ સહિષ્ણુતા ચકાસવા માટે, એક સ્વચાલિત પરીક્ષણ સિસ્ટમ બનાવવામાં આવી છે. સ્ક્રિપ્ટ દ્વારા લોન્ચ test/failure. સ્ક્રિપ્ટ ક્લસ્ટરોની સંખ્યાને પરિમાણો તરીકે લઈ શકે છે જે તમે પરીક્ષણ કરવા માંગો છો. ઉદાહરણ તરીકે આ આદેશ:

test/failure 2 3

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

ટર્મિનલને ચકાસાયેલ ક્લસ્ટરોની સંખ્યા અનુસાર કૉલમમાં વિભાજિત કરવામાં આવે છે; મૂળભૂત રીતે (સ્ક્રીનશોટમાં) ચાર છે. હું Tuchanka2 ના ઉદાહરણનો ઉપયોગ કરીને કૉલમની સામગ્રીનું વર્ણન કરીશ. સ્ક્રીનશોટમાંની પેનલો ક્રમાંકિત છે:

1. ટેસ્ટના આંકડા અહીં પ્રદર્શિત થાય છે. કૉલમ:
   • નિષ્ફળતા — પરીક્ષણનું નામ (સ્ક્રીપ્ટમાં કાર્ય) જે દોષનું અનુકરણ કરે છે.
   • પ્રતિક્રિયા - સેકન્ડોમાં અંકગણિત સરેરાશ સમય જે દરમિયાન ક્લસ્ટર તેની કાર્યક્ષમતા પુનઃપ્રાપ્ત કરે છે. જ્યારે ક્લસ્ટર તેની કાર્યક્ષમતાને પુનઃસ્થાપિત કરે છે અને સેવાઓ પ્રદાન કરવાનું ચાલુ રાખવામાં સક્ષમ છે ત્યાં સુધી તે ફોલ્ટનું અનુકરણ કરતી સ્ક્રિપ્ટની શરૂઆતથી માપવામાં આવે છે. જો સમય ખૂબ જ ટૂંકો હોય, ઉદાહરણ તરીકે, છ સેકન્ડ (આ ઘણા ગુલામો (તુચંકા3 અને તુચંકા4) સાથેના ક્લસ્ટરોમાં થાય છે), આનો અર્થ એ છે કે ખામી અસુમેળ સ્લેવ પર હતી અને તે કોઈપણ રીતે પ્રભાવને અસર કરતી નથી; ત્યાં કોઈ નહોતું. ક્લસ્ટર સ્ટેટ સ્વીચો.
   • વિચલન — મૂલ્યનો ફેલાવો (ચોક્કસતા) બતાવે છે પ્રતિક્રિયા પ્રમાણભૂત વિચલન પદ્ધતિનો ઉપયોગ કરીને.
   • ગણતરી - આ પરીક્ષણ કેટલી વખત કરવામાં આવ્યું હતું.
2. ટૂંકો લોગ તમને ક્લસ્ટર હાલમાં શું કરી રહ્યું છે તેનું મૂલ્યાંકન કરવાની મંજૂરી આપે છે. પુનરાવર્તન (પરીક્ષણ) નંબર, ટાઇમસ્ટેમ્પ અને ઓપરેશનનું નામ પ્રદર્શિત થાય છે. ખૂબ લાંબુ (> 5 મિનિટ) દોડવું એ સમસ્યા સૂચવે છે.
3. હૃદય (હૃદય) - વર્તમાન સમય. પ્રદર્શનના દ્રશ્ય મૂલ્યાંકન માટે માસ્ટર ફ્લોટ આઈપી માસ્ટરનો ઉપયોગ કરીને વર્તમાન સમય તેના ટેબલ પર સતત લખવામાં આવે છે. જો સફળ થાય, તો પરિણામ આ પેનલમાં પ્રદર્શિત થાય છે.
4. બીટ (પલ્સ) - "વર્તમાન સમય", જે અગાઉ સ્ક્રિપ્ટ દ્વારા રેકોર્ડ કરવામાં આવ્યો હતો હૃદય માસ્ટર કરવા માટે, હવે વાંચો ગુલામ તેના ફ્લોટ IP દ્વારા. તમને સ્લેવ અને પ્રતિકૃતિના પ્રદર્શનનું દૃષ્ટિની આકારણી કરવાની મંજૂરી આપે છે. Tuchanka1 માં ફ્લોટ IP સાથે કોઈ ગુલામ નથી (સેવાઓ પૂરી પાડતા કોઈ ગુલામો નથી), પરંતુ ત્યાં બે ઉદાહરણો (DBs) છે, તેથી તે અહીં બતાવવામાં આવશે નહીં બીટઅને હૃદય બીજો દાખલો.
5. ઉપયોગિતાનો ઉપયોગ કરીને ક્લસ્ટર આરોગ્યનું નિરીક્ષણ કરવું pcs mon. માળખું, નોડ્સમાં સંસાધનોનું વિતરણ અને અન્ય ઉપયોગી માહિતી બતાવે છે.
6. ક્લસ્ટરમાં દરેક વર્ચ્યુઅલ મશીનમાંથી સિસ્ટમ મોનિટરિંગ અહીં પ્રદર્શિત થાય છે. ક્લસ્ટરમાં કેટલા વર્ચ્યુઅલ મશીનો છે તેના આધારે આવી વધુ પેનલ્સ હોઈ શકે છે. બે ગ્રાફ CPU લોડ (વર્ચ્યુઅલ મશીનમાં બે પ્રોસેસર હોય છે), વર્ચ્યુઅલ મશીનનું નામ, સિસ્ટમ લોડ (લોડ એવરેજ નામ આપવામાં આવ્યું છે કારણ કે તે 5, 10 અને 15 મિનિટથી વધુ સરેરાશ છે), ડેટા અને મેમરી ફાળવણીની પ્રક્રિયા કરો.
7. સ્ક્રિપ્ટનું ટ્રેસ પરીક્ષણ કરી રહ્યું છે. કોઈ ખામીની ઘટનામાં - ઓપરેશનમાં અચાનક વિક્ષેપ અથવા અનંત રાહ ચક્ર - અહીં તમે આ વર્તનનું કારણ જોઈ શકો છો.

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

દરેક કસોટીમાં નીચેના ઓપરેશન્સનો સમાવેશ થાય છે:

1. ફંક્શન લોંચ કરો જે ફોલ્ટનું અનુકરણ કરે છે.
2. તૈયાર છો? — ક્લસ્ટર પુનઃસ્થાપિત થાય તેની રાહ જુઓ (જ્યારે બધી સેવાઓ પૂરી પાડવામાં આવે છે).
3. ક્લસ્ટર પુનઃપ્રાપ્તિ સમયસમાપ્તિ બતાવે છે (પ્રતિક્રિયા).
4. ફિક્સ - ક્લસ્ટરનું "રિપેરિંગ" કરવામાં આવી રહ્યું છે. જે પછી તે સંપૂર્ણ ઓપરેશનલ સ્થિતિમાં પરત આવવું જોઈએ અને આગામી ખામી માટે તૈયાર રહેવું જોઈએ.

તેઓ શું કરે છે તેના વર્ણન સાથે અહીં પરીક્ષણોની સૂચિ છે:

• ફોર્કબોમ્બ: ફોર્ક બોમ્બનો ઉપયોગ કરીને "આઉટ ઓફ મેમરી" બનાવે છે.
• જગ્યાની બહાર: હાર્ડ ડ્રાઈવ ભરાઈ ગઈ છે. પરંતુ પરીક્ષણ તેના બદલે સાંકેતિક છે; પરીક્ષણ દરમિયાન બનાવેલ નજીવા ભાર સાથે, જ્યારે હાર્ડ ડ્રાઈવ ભરેલી હોય ત્યારે PostgreSQL સામાન્ય રીતે નિષ્ફળ થતું નથી.
• પોસ્ટગ્રેસ-કિલ: આદેશ વડે PostgreSQL ને મારી નાખે છે killall -KILL postgres.
• પોસ્ટગ્રેસ-સ્ટોપ: PostgreSQL આદેશ અટકે છે killall -STOP postgres.
• પાવર બંધ: આદેશ વડે વર્ચ્યુઅલ મશીનને "ડી-એનર્જાઇઝ" કરે છે VBoxManage controlvm "виртуалка" poweroff.
• રીસેટ: આદેશ સાથે વર્ચ્યુઅલ મશીનને ઓવરલોડ કરે છે VBoxManage controlvm "виртуалка" reset.
• SBD-સ્ટોપ: આદેશ સાથે SBD રાક્ષસને સસ્પેન્ડ કરે છે killall -STOP sbd.
• બંધ કરો: SSH મારફતે વર્ચ્યુઅલ મશીનને આદેશ મોકલે છે systemctl poweroff, સિસ્ટમ આકર્ષક રીતે બંધ થાય છે.
• અનલિંક: નેટવર્ક અલગતા, આદેશ VBoxManage controlvm "виртуалка" setlinkstate1 off.

પ્રમાણભૂત tmux આદેશ "kill-window" નો ઉપયોગ કરીને પરીક્ષણ પૂર્ણ કરવું Ctrl-b &, અથવા "ડિટેચ-ક્લાયન્ટ" આદેશ Ctrl-b ડી: આ બિંદુએ પરીક્ષણ સમાપ્ત થાય છે, tmux બંધ થાય છે, વર્ચ્યુઅલ મશીનો બંધ થાય છે.

પરીક્ષણ દરમિયાન ઓળખવામાં આવેલી સમસ્યાઓ

• આ ક્ષણે વોચડોગ રાક્ષસ એસબીડી અવલોકન કરાયેલા ડિમન્સને રોકવા પર કામ કરે છે, પરંતુ તેમને સ્થિર કરવા પર નહીં. અને, પરિણામે, ખામીઓ કે જે માત્ર ઠંડું તરફ દોરી જાય છે કોરોસિંક и પેસમેકર, પરંતુ અટકી નથી sbd... ચેક માટે કોરોસિંક પહેલેથી જ છે PR#83 (ગીટહબ પર sbd), થ્રેડ માટે સ્વીકાર્યું માસ્ટર. તેઓએ વચન આપ્યું હતું (PR#83 માં) કે પેસમેકર માટે કંઈક આવું જ હશે, હું આશા રાખું છું કે રેડહટ 8 કરશે. પરંતુ આવા "ખામી" સટ્ટાકીય છે અને તેનો ઉપયોગ કરીને કૃત્રિમ રીતે સરળતાથી અનુકરણ કરી શકાય છે, ઉદાહરણ તરીકે, killall -STOP corosyncપરંતુ વાસ્તવિક જીવનમાં ક્યારેય મળતો નથી.

• У પેસમેકર માટેના સંસ્કરણમાં સેન્ટોસ 7 ખોટી રીતે સેટ કરેલ છે સમન્વયન_સમયસમાપ્ત у કોરમ ઉપકરણપરિણામે જો એક નોડ નિષ્ફળ જાય, તો થોડી સંભાવના સાથે બીજો નોડ પણ રીબૂટ થાય છે, જેમાં માસ્ટર ખસેડવાના હતા. વિસ્તરણ દ્વારા સાજો સમન્વયન_સમયસમાપ્ત у કોરમ ઉપકરણ જમાવટ દરમિયાન (સ્ક્રીપ્ટમાં setup/setup1). આ સુધારો વિકાસકર્તાઓ દ્વારા સ્વીકારવામાં આવ્યો ન હતો પેસમેકર, તેના બદલે તેઓએ ઇન્ફ્રાસ્ટ્રક્ચરને એવી રીતે ફરીથી ડિઝાઇન કરવાનું વચન આપ્યું હતું (કેટલાક અસ્પષ્ટ ભવિષ્યમાં) કે આ સમયસમાપ્તિ આપમેળે ગણતરી કરવામાં આવશે.

• જો ડેટાબેઝ રૂપરેખાંકન તે સ્પષ્ટ કરે છે LC_MESSAGES (ટેક્સ્ટ સંદેશાઓ) યુનિકોડનો ઉપયોગ કરી શકાય છે, દા.ત. ru_RU.UTF-8, પછી સ્ટાર્ટઅપ પર પોસ્ટગ્રેસ એવા વાતાવરણમાં જ્યાં લોકેલ UTF-8 નથી, ખાલી વાતાવરણમાં કહો (અહીં પેસમેકર+pgsqlms(paf) ચાલે છે પોસ્ટગ્રેસ), પછી લોગમાં UTF-8 અક્ષરોને બદલે પ્રશ્ન ચિહ્નો હશે. PostgreSQL વિકાસકર્તાઓ આ કિસ્સામાં શું કરવું તે અંગે સંમત થયા નથી. તે ખર્ચ કરે છે, તમારે ઇન્સ્ટોલ કરવાની જરૂર છે LC_MESSAGES=en_US.UTF-8 ડેટાબેઝ દાખલો ગોઠવતી વખતે (બનાવવી).

• જો wal_receiver_timeout સેટ કરેલ હોય (મૂળભૂત રીતે તે 60s છે), તો પછી tuchanka3 અને tuchanka4 ક્લસ્ટરમાં માસ્ટર પર PostgreSQL-STOP પરીક્ષણ દરમિયાન પ્રતિકૃતિ નવા માસ્ટર સાથે ફરીથી કનેક્ટ થતી નથી. ત્યાં પ્રતિકૃતિ સિંક્રનસ છે, તેથી માત્ર ગુલામ જ નહીં, પણ નવા માસ્ટર પણ અટકે છે. PostgreSQL ને ગોઠવતી વખતે wal_receiver_timeout=0 સેટ કરીને કામ કરે છે.

• પ્રસંગોપાત મેં ફોર્કબૉમ્બ ટેસ્ટ (મેમરી ઓવરફ્લો) માં પોસ્ટગ્રેએસક્યુએલમાં પ્રતિકૃતિ ફ્રીઝનું અવલોકન કર્યું. ફોર્કબોમ્બ પછી, કેટલીકવાર ગુલામો નવા માસ્ટર સાથે ફરીથી કનેક્ટ થઈ શકતા નથી. મેં આનો સામનો ફક્ત tuchanka3 અને tuchanka4 ક્લસ્ટરોમાં કર્યો છે, જ્યાં સિંક્રનસ પ્રતિકૃતિને કારણે માસ્ટર સ્થિર થઈ ગયું છે. લાંબા સમય (લગભગ બે કલાક) પછી સમસ્યા તેની જાતે જ દૂર થઈ ગઈ. આને સુધારવા માટે વધુ સંશોધનની જરૂર છે. લક્ષણો અગાઉના બગ જેવા જ છે, જે એક અલગ કારણથી થાય છે, પરંતુ સમાન પરિણામો સાથે.

ક્રોગન ચિત્ર પરથી લેવામાં આવ્યું છે વિચલિત કલા લેખકની પરવાનગી સાથે:

સોર્સ: www.habr.com