Patroni નિષ્ફળતા વાર્તાઓ અથવા તમારા PostgreSQL ક્લસ્ટરને કેવી રીતે ક્રેશ કરવું. એલેક્સી લેસોવ્સ્કી

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

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

અને 2018 ના અંતમાં, અમે ધીમે ધીમે Patroni નો ઉપયોગ કરવાનું શરૂ કર્યું. અને થોડો અનુભવ સંચિત કરવામાં આવ્યો છે. અમે કોઈક રીતે તેનું નિદાન કર્યું, તેને ટ્યુન કર્યું, અમારી શ્રેષ્ઠ પદ્ધતિઓ પર આવ્યા. અને આ અહેવાલમાં હું તેમના વિશે વાત કરીશ.

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

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

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

અને અમે અમારો અહેવાલ શરૂ કરીએ તે પહેલાં એક નાનો અસ્વીકરણ.

આ બધી સમસ્યાઓ કે જે અમે અનુભવી, અમે તે ઓપરેશનના પ્રથમ 6-7-8 મહિનામાં આવી. સમય જતાં, અમે અમારી આંતરિક શ્રેષ્ઠ પદ્ધતિઓ પર આવ્યા. અને અમારી સમસ્યાઓ અદૃશ્ય થઈ ગઈ. તેથી, અહેવાલ લગભગ છ મહિના પહેલા જાહેર કરવામાં આવ્યો હતો, જ્યારે તે બધું મારા મગજમાં તાજું હતું અને મને તે બધું બરાબર યાદ હતું.

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

Patroni શું છે?

• આ HA બનાવવાનો નમૂનો છે. તે દસ્તાવેજીકરણમાં શું કહે છે તે છે. અને મારા દૃષ્ટિકોણથી, આ એક ખૂબ જ સાચી સ્પષ્ટતા છે. પેટ્રોની એ સિલ્વર બુલેટ નથી જે તમારી બધી સમસ્યાઓનું નિરાકરણ લાવે, એટલે કે, તમારે તેને કામ કરવા અને લાભો લાવવા માટે પ્રયાસ કરવાની જરૂર છે.
• આ એક એજન્ટ સેવા છે જે દરેક ડેટાબેઝ સેવા પર ઇન્સ્ટોલ કરેલી છે અને તે તમારા પોસ્ટગ્રેસ માટે એક પ્રકારની ઇનિટ સિસ્ટમ છે. તે પોસ્ટગ્રેસ શરૂ કરે છે, અટકે છે, પુનઃપ્રારંભ કરે છે, પુનઃરૂપરેખાંકિત કરે છે અને તમારા ક્લસ્ટરની ટોપોલોજીમાં ફેરફાર કરે છે.
• તદનુસાર, ક્લસ્ટરની સ્થિતિને સંગ્રહિત કરવા માટે, તેની વર્તમાન રજૂઆત, જેમ તે દેખાય છે, અમુક પ્રકારના સ્ટોરેજની જરૂર છે. અને આ દૃષ્ટિકોણથી, પટ્રોનીએ રાજ્યને બાહ્ય સિસ્ટમમાં સંગ્રહિત કરવાનો માર્ગ અપનાવ્યો. તે વિતરિત રૂપરેખાંકન સંગ્રહ સિસ્ટમ છે. તે Etcd, Consul, ZooKeeper અથવા kubernetes Etcd હોઈ શકે છે, એટલે કે આ વિકલ્પોમાંથી એક.
• અને પેટ્રોનીની એક વિશેષતા એ છે કે તમે ઓટોફાઈલરને બોક્સમાંથી બહાર કાઢો છો, ફક્ત તેને સેટ કરીને. જો આપણે સરખામણી માટે Repmgr લઈએ, તો ત્યાં ફાઇલરનો સમાવેશ થાય છે. Repmgr સાથે, અમને સ્વિચઓવર મળે છે, પરંતુ જો અમને ઑટોફિલર જોઈએ છે, તો અમારે તેને વધુમાં ગોઠવવાની જરૂર છે. Patroni પાસે પહેલાથી જ ઓટોફાઈલર આઉટ ઓફ બોક્સ છે.
• અને બીજી ઘણી વસ્તુઓ છે. ઉદાહરણ તરીકે, રૂપરેખાંકનોની જાળવણી, નવી પ્રતિકૃતિઓ રેડવાની, બેકઅપ વગેરે. પરંતુ આ અહેવાલના અવકાશની બહાર છે, હું તેના વિશે વાત કરીશ નહીં.

અને એક નાનું પરિણામ એ છે કે પેટ્રોનીનું મુખ્ય કાર્ય ઓટોફાઈલને સારી રીતે અને વિશ્વસનીય રીતે કરવાનું છે જેથી કરીને અમારું ક્લસ્ટર કાર્યરત રહે અને એપ્લિકેશન ક્લસ્ટર ટોપોલોજીમાં ફેરફારોને ધ્યાનમાં ન લે.

પરંતુ જ્યારે અમે Patroni નો ઉપયોગ કરવાનું શરૂ કરીએ છીએ, ત્યારે અમારી સિસ્ટમ થોડી વધુ જટિલ બની જાય છે. જો અગાઉ અમારી પાસે પોસ્ટગ્રેસ હતું, તો પછી Patroni નો ઉપયોગ કરતી વખતે અમને Patroni જ મળે છે, અમને DCS મળે છે જ્યાં રાજ્ય સંગ્રહિત છે. અને તે બધાને કોઈક રીતે કામ કરવું પડશે. તો શું ખોટું થઈ શકે?

તૂટી શકે છે:

• પોસ્ટગ્રેસ તૂટી શકે છે. તે માસ્ટર અથવા પ્રતિકૃતિ હોઈ શકે છે, તેમાંથી એક નિષ્ફળ થઈ શકે છે.
• પટ્રોની પોતે તૂટી શકે છે.
• DCS જ્યાં રાજ્ય સંગ્રહિત છે તે તૂટી શકે છે.
• અને નેટવર્ક તૂટી શકે છે.

આ તમામ મુદ્દાઓ હું અહેવાલમાં ધ્યાનમાં લઈશ.

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

અને પ્રથમ કેસ સૌથી સરળ છે. જ્યારે અમે ડેટાબેઝ ક્લસ્ટર લીધું અને તે જ ક્લસ્ટર પર અમારું DCS સ્ટોરેજ જમાવ્યું ત્યારે આ કેસ છે. આ સૌથી સામાન્ય ભૂલ છે. આર્કિટેક્ચર બનાવવામાં આ એક ભૂલ છે, એટલે કે, એક જગ્યાએ વિવિધ ઘટકોનું સંયોજન.

તેથી, ત્યાં એક ફાઇલર હતો, ચાલો શું થયું તેની સાથે વ્યવહાર કરવા જઈએ.

અને અહીં અમને રસ છે કે ફાઇલર ક્યારે થયું. એટલે કે, જ્યારે ક્લસ્ટર સ્થિતિ બદલાઈ ત્યારે અમને આ ક્ષણમાં રસ છે.

પરંતુ ફાઇલર હંમેશા તાત્કાલિક હોતું નથી, એટલે કે તે સમયનો કોઈ એકમ લેતો નથી, તે વિલંબિત થઈ શકે છે. તે લાંબા સમય સુધી ટકી શકે છે.

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

અને પ્રથમ વસ્તુ, જ્યારે ફાઇલર થયું, ત્યારે અમે શું થયું તેનું કારણ શોધીએ છીએ, ફાઇલર તરફ દોરી જવાનું કારણ શું હતું.

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

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

જો આપણે ફાઇલર પહેલાની ઘટનાઓ પર નજર કરીએ, તો આપણે ત્યાં તે જ કારણો જોઈ શકીએ છીએ જે વિઝાર્ડ ચાલુ રાખવા માટે સમસ્યા હતી.

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

અને અહીં સમસ્યા એ છે કે Patroni અને ડેટાબેઝ એક જ હોસ્ટ પર ચાલી રહ્યા છે. અને કોન્સ્યુલ સર્વર્સ એ જ નોડ પર શરૂ કરવામાં આવ્યા હતા. સર્વર પર લોડ બનાવીને, અમે કોન્સલ સર્વર્સ માટે પણ સમસ્યાઓ ઊભી કરી છે. તેઓ યોગ્ય રીતે વાતચીત કરી શકતા ન હતા.

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

અને આને ખોટા એલાર્મ તરીકે ગણી શકાય, અથવા એવું ગણી શકાય કે પેટ્રોનીએ બધું બરાબર કર્યું. એટલે કે, તેને સમજાયું કે તે ક્લસ્ટરની સ્થિતિ જાળવી શકશે નહીં અને તેની સત્તા દૂર કરી.

અને અહીં સમસ્યા એ હકીકતને કારણે ઊભી થઈ છે કે કોન્સ્યુલ સર્વર્સ પાયા જેવા જ હાર્ડવેર પર છે. તદનુસાર, કોઈપણ લોડ: ભલે તે ડિસ્ક અથવા પ્રોસેસર્સ પરનો ભાર હોય, તે કોન્સ્યુલ ક્લસ્ટર સાથેની ક્રિયાપ્રતિક્રિયાને પણ અસર કરે છે.

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

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

પ્રથમ સમસ્યા, જેમ તમે સમજો છો, તે સરળ છે. અમે આધાર સાથે DCS લીધો અને મૂક્યો, અમને સમસ્યા આવી.

બીજી સમસ્યા પ્રથમ જેવી જ છે. તે સમાન છે કે અમને ફરીથી DCS સિસ્ટમ સાથે આંતરસંચાલનક્ષમતા સમસ્યાઓ છે.

જો આપણે લોગ્સ પર નજર નાખીએ, તો આપણે જોશું કે આપણી પાસે ફરી એક કોમ્યુનિકેશન એરર છે. અને પેટ્રોની કહે છે કે હું DCS સાથે સંપર્ક કરી શકતો નથી તેથી વર્તમાન માસ્ટર પ્રતિકૃતિ મોડમાં જાય છે.

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

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

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

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

ફાઈલરના સમય અને કોન્સ્યુલ લોગમાંના સમયની આશરે સરખામણી કરતા, આપણે જોઈએ છીએ કે કોન્સ્યુલ ક્લસ્ટરમાં અમારા પડોશીઓ કોન્સ્યુલ ક્લસ્ટરના અન્ય સભ્યોના અસ્તિત્વ પર શંકા કરવા લાગ્યા.

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

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

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

વિકલ્પો છે:

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

મને લાગે છે કે પેટ્રોનીનો ઉપયોગ કરતા ઘણા લોકો આ આદેશથી પરિચિત છે.

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

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

આ કિસ્સામાં, બીજી પ્રતિકૃતિ માસ્ટર બની હતી. અહીં બધું બરાબર છે.

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

આ કિસ્સામાં, અમારી પાસે ટ્રાન્ઝેક્શન લોગ નથી અને પ્રતિકૃતિ શરૂ થઈ શકતી નથી. તદનુસાર, અમે પોસ્ટગ્રેસને ભૂલ સાથે બંધ કરીએ છીએ. અને તેથી તે ક્લસ્ટરમાં નથી.

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

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

વિકલ્પો શું છે?

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

પરંતુ અહીં એક સમસ્યા છે, કે જ્યારે માસ્ટર પ્રતિકૃતિ પર જાય છે, ત્યારે તે સ્લોટ્સને કાઢી નાખે છે અને સ્લોટ્સની સાથે WAL સેગમેન્ટને પણ કાઢી નાખે છે. અને આ સમસ્યાને દૂર કરવા માટે, અમે wal_keep_segments પરિમાણ વધારવાનું નક્કી કર્યું છે. તે 8 સેગમેન્ટમાં ડિફોલ્ટ છે. અમે તેને વધારીને 1 કર્યો અને અમારી પાસે કેટલી ખાલી જગ્યા છે તે જોયું. અને અમે wal_keep_segments માટે 000 ગીગાબાઇટ્સ દાનમાં આપ્યા છે. એટલે કે, સ્વિચ કરતી વખતે, અમારી પાસે હંમેશા તમામ નોડ્સ પર 16 ગીગાબાઇટ્સ ટ્રાન્ઝેક્શન લોગનો અનામત હોય છે.

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

અમારી પાસે ઉત્પાદન આધાર છે. ત્યાં પહેલેથી જ પ્રોજેક્ટ્સ પ્રગતિમાં છે.

એક ફાઇલર હતો. અમે અંદર ગયા અને જોયું - બધું વ્યવસ્થિત છે, પ્રતિકૃતિઓ સ્થાને છે, પ્રતિકૃતિમાં કોઈ અંતર નથી. લૉગ્સમાં પણ કોઈ ભૂલો નથી, બધું ક્રમમાં છે.

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

તે સ્પષ્ટ છે કે pg_rewind તેમને ચૂકી ગયો. અમે તરત જ આ સમજી ગયા, પરંતુ શું થઈ રહ્યું છે તે જોવા ગયા.

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

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

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

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

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

પરંતુ આપણે આપણા માટે શું શોધી કાઢ્યું છે?

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

અને તે પછી જ આપણે નક્કી કરવું જોઈએ કે શું આપણે આ ડેટાને કાઢી નાખી શકીએ કે આપણે તેને પુનઃસ્થાપિત કરી શકીએ, આ નોડને પ્રતિકૃતિ તરીકે અમારા ક્લસ્ટર સાથે જોડી શકીએ.

વધુમાં, "મહત્તમ_લેગ_ઓન_ફેઈલઓવર" પેરામીટર છે. મૂળભૂત રીતે, જો મારી મેમરી મને સેવા આપે છે, તો આ પરિમાણનું મૂલ્ય 1 મેગાબાઈટ છે.

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

પરંતુ તેમાં એક સમસ્યા છે કે પેટ્રોની ક્લસ્ટર અને ડીસીએસમાં રેપ્લિકેશન લેગ ચોક્કસ અંતરાલ પર અપડેટ થાય છે. મને લાગે છે કે 30 સેકન્ડ એ ડિફોલ્ટ ttl મૂલ્ય છે.

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

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

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

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

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

આ હોસ્ટને રીબૂટ કરવાની ફરજ પડી હતી. રીબૂટને કારણે, ઓટો-ફાઈલ થઈ, જો કે મેન્યુઅલ ઓટો-ફાઈલ કરવું શક્ય હતું, જેમ હું હવે સમજું છું. અને રીબૂટ કર્યા પછી, અમે પહેલાથી જ જોઈશું કે વર્તમાન માસ્ટર સાથે અમારી પાસે શું હતું.

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

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

અમે સિસ્ટમ dmesg (કર્નલ લોગ) માં જોયું. અને અમે જોયું કે અમને એક ડિસ્ક સાથે સમસ્યા છે. ડિસ્ક સબસિસ્ટમ સોફ્ટવેર રેઇડ હતી. અમે /proc/mdstat પર જોયું અને જોયું કે અમારી એક ડ્રાઇવ ખૂટે છે. એટલે કે, 8 ડિસ્કનો દરોડો છે, અમે એક ખૂટે છે. જો તમે સ્લાઇડને ધ્યાનથી જોશો, તો આઉટપુટમાં તમે જોઈ શકશો કે અમારી પાસે ત્યાં sde નથી. અમારા પર, શરતી રીતે કહીએ તો, ડિસ્ક બહાર નીકળી ગઈ છે. આનાથી ડિસ્ક સમસ્યાઓ શરૂ થઈ, અને પોસ્ટગ્રેસ ક્લસ્ટર સાથે કામ કરતી વખતે એપ્લિકેશનોએ પણ સમસ્યાઓ અનુભવી.

અને આ કિસ્સામાં, Patroni અમને કોઈપણ રીતે મદદ કરશે નહીં, કારણ કે Patroni પાસે સર્વરની સ્થિતિ, ડિસ્કની સ્થિતિનું નિરીક્ષણ કરવાનું કાર્ય નથી. અને આપણે બાહ્ય દેખરેખ દ્વારા આવી પરિસ્થિતિઓનું નિરીક્ષણ કરવું જોઈએ. અમે બાહ્ય દેખરેખમાં ઝડપથી ડિસ્ક મોનિટરિંગ ઉમેર્યું.

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

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

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

અને તે બધું કેવી રીતે શરૂ થયું? તે અગાઉની સમસ્યાની જેમ, ડિસ્ક બ્રેક્સ સાથે શરૂ થયું હતું. અમે એક સેકન્ડ, બે માટે કમિટ કરી હતી.

કનેક્શનમાં વિરામ હતા, એટલે કે, ક્લાયન્ટ ફાટી ગયા હતા.

વિવિધ તીવ્રતાના અવરોધો હતા.

અને, તે મુજબ, ડિસ્ક સબસિસ્ટમ ખૂબ જ પ્રતિભાવશીલ નથી.

અને મારા માટે સૌથી રહસ્યમય વસ્તુ એ તાત્કાલિક શટડાઉન વિનંતી છે જે આવી છે. પોસ્ટગ્રેસમાં ત્રણ શટડાઉન મોડ્સ છે:

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

આ સિગ્નલ કોણે મોકલ્યો? પોસ્ટગ્રેસ પૃષ્ઠભૂમિ પ્રક્રિયાઓ એકબીજાને આવા સંકેતો મોકલતી નથી, એટલે કે આ કિલ-9 છે. તેઓ આવી વસ્તુઓ એકબીજાને મોકલતા નથી, તેઓ ફક્ત આવી વસ્તુઓ પર જ પ્રતિક્રિયા આપે છે, એટલે કે આ પોસ્ટગ્રેસની કટોકટી પુનઃપ્રારંભ છે. કોણે મોકલ્યું, મને ખબર નથી.

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

આગળ જોતાં, મેં જોયું કે પેટ્રોનીએ ઘણા લાંબા સમય સુધી લોગ પર લખ્યું ન હતું - 54 સેકન્ડ. અને જો આપણે બે ટાઈમસ્ટેમ્પની સરખામણી કરીએ તો લગભગ 54 સેકન્ડ સુધી કોઈ સંદેશા નહોતા.

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

અમારી પાસે એક પ્રતિકૃતિ છે જે માસ્ટર બની ગઈ છે. અને બીજો પ્રતિભાવ છે. અને બીજી પ્રતિકૃતિ સાથે સમસ્યાઓ હતી. તેણીએ ફરીથી ગોઠવવાનો પ્રયાસ કર્યો. જેમ હું તેને સમજું છું, તેણીએ recovery.conf બદલવા, પોસ્ટગ્રેસને પુનઃપ્રારંભ કરવાનો અને નવા માસ્ટર સાથે કનેક્ટ કરવાનો પ્રયાસ કર્યો. તેણી દર 10 સેકન્ડે સંદેશા લખે છે જેનો તેણી પ્રયાસ કરી રહી છે, પરંતુ તે સફળ થતી નથી.

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

અમુક સમયે, તે કામ કરે છે, પરંતુ પ્રતિકૃતિ શરૂ થઈ નથી.

મારું એકમાત્ર અનુમાન છે કે recovery.conf માં જૂનું મુખ્ય સરનામું હતું. અને જ્યારે એક નવો માસ્ટર દેખાયો, ત્યારે બીજી પ્રતિકૃતિએ હજુ પણ જૂના માસ્ટર સાથે કનેક્ટ કરવાનો પ્રયાસ કર્યો.

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

તે જ સમયે, જો તમે લખેલા લોગ પર નજર નાખો, તો તમે જોઈ શકશો કે ટ્રાન્ઝેક્શન લોગ અલગ હોવાને કારણે નકલ શરૂ થઈ શકી નથી. અને તે ટ્રાન્ઝેક્શન લોગ કે જે માસ્ટર ઓફર કરે છે, જે recovery.conf માં ઉલ્લેખિત છે, તે ફક્ત અમારા વર્તમાન નોડમાં ફિટ થતા નથી.

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

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

પ્રતિકૃતિ શરૂ થઈ ગઈ છે. પરંતુ એક મિનિટ પછી તેણી એક ભૂલ સાથે પડી ગઈ કે ટ્રાન્ઝેક્શન લોગ તેના માટે યોગ્ય નથી.

મેં વિચાર્યું કે હું ફરી શરૂ કરીશ. મેં Patroni ને ફરીથી શરૂ કર્યું, અને મેં Postgres ને પુનઃશરૂ કર્યું નથી, પરંતુ Patroni ને એવી આશામાં પુનઃશરૂ કર્યું છે કે તે જાદુઈ રીતે ડેટાબેઝ શરૂ કરશે.

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

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

મેં પેટ્રોનીને પુનઃપ્રારંભ કર્યો, માસ્ટર પર કેટલાક ચેકપોઇન્ટ કર્યા, જ્યારે તે ખુલી ત્યારે પ્રતિકૃતિ પર કેટલાક પુનઃપ્રારંભ બિંદુઓ. અને તે મદદ કરી. મેં લાંબા સમય સુધી વિચાર્યું કે તે શા માટે મદદ કરે છે અને તે કેવી રીતે કામ કરે છે. અને પ્રતિકૃતિ શરૂ કરી. અને પ્રતિકૃતિ હવે ફાટી ન હતી.

મારા માટે આવી સમસ્યા એ સૌથી વધુ રહસ્યમય સમસ્યાઓમાંની એક છે, જેના પર હું હજી પણ ત્યાં ખરેખર શું થયું તે અંગે કોયડા કરું છું.

અહીંની અસરો શું છે? Patroni હેતુ મુજબ અને કોઈપણ ભૂલ વિના કામ કરી શકે છે. પરંતુ તે જ સમયે, આ 100% ગેરેંટી નથી કે અમારી સાથે બધું બરાબર છે. પ્રતિકૃતિ શરૂ થઈ શકે છે, પરંતુ તે અર્ધ-કાર્યકારી સ્થિતિમાં હોઈ શકે છે, અને એપ્લિકેશન આવી પ્રતિકૃતિ સાથે કામ કરી શકતી નથી, કારણ કે ત્યાં જૂનો ડેટા હશે.

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

અને જેમ જેમ આપણે આ મુદ્દાઓમાંથી પસાર થઈશું, હું ભલામણો કરીશ. મેં તેમને બે સ્લાઇડ્સમાં જોડવાનો પ્રયાસ કર્યો. સંભવતઃ, બધી વાર્તાઓને બે સ્લાઇડ્સમાં જોડી શકાય છે અને ફક્ત કહેવામાં આવે છે.

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

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

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

અને પટ્રોની સિલ્વર બુલેટ નથી. પોસ્ટગ્રેસ કેવી રીતે કામ કરે છે, પ્રતિકૃતિ કેવી રીતે કામ કરે છે અને પેટ્રોની પોસ્ટગ્રેસ સાથે કેવી રીતે કાર્ય કરે છે અને નોડ્સ વચ્ચે કેવી રીતે સંચાર પ્રદાન કરવામાં આવે છે તે સમજવાની જરૂર છે. તમારા હાથથી સમસ્યાઓને ઠીક કરવામાં સક્ષમ થવા માટે આ જરૂરી છે.

હું નિદાનની સમસ્યાનો સંપર્ક કેવી રીતે કરી શકું? એવું બન્યું કે અમે જુદા જુદા ક્લાયન્ટ્સ સાથે કામ કરીએ છીએ અને કોઈની પાસે ELK સ્ટેક નથી, અને અમારે 6 કન્સોલ અને 2 ટૅબ ખોલીને લૉગ્સ સૉર્ટ કરવા પડશે. એક ટૅબમાં, આ દરેક નોડ માટે પેટ્રોની લૉગ્સ છે, બીજી ટૅબમાં, આ કૉન્સ્યુલ લૉગ્સ છે, અથવા જો જરૂરી હોય તો પોસ્ટગ્રેસ છે. આનું નિદાન કરવું ખૂબ મુશ્કેલ છે.

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

આગળ, હું ફાઇલર પહેલાંની ઘટનાઓ માટેના લૉગમાં જોઉં છું, જે ફાઇલર પહેલાંની છે, એટલે કે ફાઇલર શા માટે થયું તેના કારણો હું શોધું છું.

અને આ શું થયું અને ભવિષ્યમાં શું કરી શકાય તે સમજવાનું ચિત્ર આપે છે જેથી આવા સંજોગો ન આવે (અને પરિણામે, કોઈ ફાઇલર નથી).

અને આપણે સામાન્ય રીતે ક્યાં જોઈએ છીએ? હું જોઉં છું:

• પ્રથમ, Patroni લોગ માટે.
• આગળ, પેટ્રોની લૉગ્સમાં શું મળ્યું તેના આધારે હું પોસ્ટગ્રેસ લૉગ્સ અથવા DCS લૉગ્સ જોઉં છું.
• અને સિસ્ટમ લૉગ્સ પણ ક્યારેક ફાઇલરનું કારણ શું છે તેની સમજ આપે છે.

પટ્રોની વિશે મને કેવું લાગે છે? પટ્રોની સાથે મારો ઘણો સારો સંબંધ છે. મારા મતે, આ આજે શ્રેષ્ઠ છે. હું બીજા ઘણા ઉત્પાદનો જાણું છું. આ Stolon, Repmgr, Pg_auto_failover, PAF છે. 4 સાધનો. મેં તે બધાનો પ્રયાસ કર્યો. પટ્રોની મારી પ્રિય છે.

જો તેઓ મને પૂછે: "શું હું પેટ્રોનીની ભલામણ કરું છું?". હું હા કહીશ, કારણ કે મને પટ્રોની ગમે છે. અને મને લાગે છે કે મેં તેને કેવી રીતે રાંધવું તે શીખી લીધું.

જો તમે પેટ્રોનીમાં મેં ઉલ્લેખિત સમસ્યાઓ ઉપરાંત અન્ય કઈ સમસ્યાઓ છે તે જોવામાં રસ ધરાવો છો, તો તમે હંમેશા પૃષ્ઠને તપાસી શકો છો મુદ્દાઓ GitHub પર. ત્યાં ઘણી જુદી જુદી વાર્તાઓ છે અને ઘણા રસપ્રદ મુદ્દાઓ વિશે ચર્ચા કરવામાં આવી છે. અને પરિણામે, કેટલીક ભૂલો રજૂ કરવામાં આવી હતી અને ઉકેલાઈ હતી, એટલે કે, આ એક રસપ્રદ વાંચન છે.

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

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

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

બસ એટલું જ. જો તમને પ્રશ્નો હોય, તો પૂછો.

પ્રશ્નો

રિપોર્ટ માટે આભાર! જો ફાઇલર પછી પણ તમારે ત્યાં ખૂબ જ કાળજીપૂર્વક જોવાની જરૂર છે, તો પછી અમને ઓટોમેટિક ફાઇલરની જરૂર શા માટે છે?

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

ઉદાહરણ તરીકે, અમે સવારે ગયા અને જોયું, બરાબર ને?

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

આભાર!

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

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

એટલે કે, શું હું યોગ્ય રીતે સમજી શક્યો છું કે યજમાનો સાથે કંઈપણ કરતા પહેલા મારે Patroniને અક્ષમ કરવાની, ફાઇલરને અક્ષમ કરવાની, બધું જ અક્ષમ કરવાની જરૂર છે?

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

ખુબ ખુબ આભાર!

તમારા અહેવાલ માટે ખૂબ ખૂબ આભાર! ડેટા ગુમ થવા વિશે પ્રોડક્ટ ટીમને કેવું લાગે છે?

ઉત્પાદન ટીમો કાળજી લેતી નથી, અને ટીમ લીડ્સ ચિંતિત છે.

ત્યાં શું ગેરંટી છે?

ગેરંટી ખૂબ મુશ્કેલ છે. એલેક્ઝાન્ડર કુકુશ્કિન પાસે "આરપીઓ અને આરટીઓની ગણતરી કેવી રીતે કરવી", એટલે કે પુનઃપ્રાપ્તિ સમય અને આપણે કેટલો ડેટા ગુમાવી શકીએ તે અંગેનો અહેવાલ છે. મને લાગે છે કે આપણે આ સ્લાઇડ્સ શોધીને તેનો અભ્યાસ કરવાની જરૂર છે. જ્યાં સુધી મને યાદ છે, આ વસ્તુઓની ગણતરી કેવી રીતે કરવી તેના પર ચોક્કસ પગલાં છે. આપણે કેટલા વ્યવહારો ગુમાવી શકીએ છીએ, કેટલો ડેટા ગુમાવી શકીએ છીએ. એક વિકલ્પ તરીકે, અમે પેટ્રોની સ્તરે સિંક્રનસ પ્રતિકૃતિનો ઉપયોગ કરી શકીએ છીએ, પરંતુ આ બેધારી તલવાર છે: અમારી પાસે કાં તો ડેટા વિશ્વસનીયતા છે, અથવા અમે ઝડપ ગુમાવીએ છીએ. સિંક્રનસ પ્રતિકૃતિ છે, પરંતુ તે ડેટા નુકશાન સામે 100% રક્ષણની બાંયધરી પણ આપતું નથી.

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

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

બીજા પ્રશ્નના સંદર્ભમાં, અમે ઐતિહાસિક કારણોસર Repmgr નો ઉપયોગ કર્યો છે અને હજુ પણ કેટલાક ગ્રાહકો સાથે કરીએ છીએ. શું કહી શકાય? Patroni બૉક્સની બહાર ઑટોફિલર સાથે આવે છે, Repmgr ઑટોફિલર સાથે વધારાની સુવિધા તરીકે આવે છે જેને સક્ષમ કરવાની જરૂર છે. આપણે દરેક નોડ પર Repmgr ડિમન ચલાવવાની જરૂર છે અને પછી આપણે ઓટોફાઈલરને ગોઠવી શકીએ છીએ.

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

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

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

સામાન્ય રીતે કહીએ તો, DCS એ આપણા માટે આધાર જેટલી જ મહત્વપૂર્ણ સેવા બની જાય છે?

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

આભાર!

સોર્સ: www.habr.com