Patroni අසාර්ථක කතන්දර හෝ ඔබේ PostgreSQL පොකුර බිඳ දමන්නේ කෙසේද. ඇලෙක්සි ලෙසොව්ස්කි

Patroni හි ප්‍රධාන ඉලක්කය වන්නේ PostgreSQL සඳහා ඉහළ උපයෝගිතා සැපයීමයි. නමුත් Patroni යනු සැකිල්ලක් පමණි, සූදානම් කළ මෙවලමක් නොවේ (සාමාන්‍යයෙන්, ලේඛනගත කිරීමෙහි සඳහන් වේ). මුලින්ම බැලූ බැල්මට, පරීක්ෂණ රසායනාගාරයේ Patroni පිහිටුවීමෙන් පසු, එය කෙතරම් විශිෂ්ට මෙවලමක්ද යන්න සහ එය පොකුර බිඳ දැමීමට අපගේ උත්සාහයන් කෙතරම් පහසුවෙන් හසුරුවන්නේද යන්න ඔබට දැක ගත හැකිය. කෙසේ වෙතත්, ප්රායෝගිකව, නිෂ්පාදන පරිසරයක් තුළ, සෑම දෙයක්ම සෑම විටම පරීක්ෂණාගාරයක මෙන් අලංකාරව හා අලංකාර ලෙස සිදු නොවේ.

මම මම ගැන ටිකක් කියන්නම්. මම පද්ධති පරිපාලකයෙකු ලෙස ආරම්භ කළෙමි. වෙබ් සංවර්ධනයේ වැඩ කළා. මම 2014 ඉඳන් Data Egret එකේ වැඩ කරනවා. සමාගම Postgres ක්ෂේත්රයේ උපදේශන කටයුතුවල නියැලී සිටී. තවද අපි හරියටම Postgres සේවය කරන අතර, අපි සෑම දිනකම Postgres සමඟ වැඩ කරන්නෙමු, එබැවින් අපට මෙහෙයුමට අදාළ විවිධ විශේෂඥතාවන් ඇත.

2018 අවසානයේ අපි සෙමෙන් පැට්‍රෝනි භාවිතා කිරීමට පටන් ගත්තෙමු. ඒ වගේම සමහර අත්දැකීම් සමුච්චය කර ඇත. අපි එය කෙසේ හෝ හඳුනාගෙන, එය සුසර කර, අපගේ හොඳම භාවිතයන්ට පැමිණියෙමු. මේ වාර්තාවේ මම ඔවුන් ගැන කතා කරන්නම්.

Postgres හැර, මම Linux වලට ආදරෙයි. මම එය වටා ගොස් ගවේෂණය කිරීමට කැමතියි, මම හරය එකතු කිරීමට කැමතියි. මම අථත්‍යකරණය, බහාලුම්, ඩොකර්, කුබර්නෙටස් වලට කැමතියි. මේ සියල්ල මට උනන්දු වන්නේ පැරණි පරිපාලක පුරුදු බලපාන බැවිනි. මම අධීක්ෂණය සමඟ කටයුතු කිරීමට කැමතියි. මම පරිපාලනයට අදාළ postgres දේවල් වලට කැමතියි, එනම් අනුකරණය, උපස්ථය. ඒ වගේම මගේ විවේක කාලය තුළ මම Go වලින් ලියනවා. මම Software Engineer කෙනෙක් නෙවෙයි, මම මටම ලියන්නේ Go වලින්. ඒ වගේම එය මට සතුටක් ගෙන දෙනවා.

• Postgres හි කොටුවෙන් පිටත HA (High Availability) නොමැති බව ඔබ බොහෝ දෙනෙක් දන්නවා යැයි සිතමි. HA ලබා ගැනීමට, ඔබ යමක් ස්ථාපනය කර එය වින්‍යාස කර, උත්සාහයක් ගෙන එය ලබා ගත යුතුය.
• මෙවලම් කිහිපයක් ඇති අතර Patroni ඒවායින් එකක් වන අතර එය HA ඉතා සිසිල් සහ ඉතා හොඳින් විසඳයි. නමුත් ඒ සියල්ල පරීක්ෂණ රසායනාගාරයකට දමා එය ක්‍රියාත්මක කිරීමෙන් අපට පෙනෙන්නේ ඒ සියල්ල ක්‍රියාත්මක වන බවයි, අපට යම් යම් ගැටලු ප්‍රතිනිෂ්පාදනය කළ හැකිය, පේට්‍රෝනි ඒවාට සේවය කරන්නේ කෙසේදැයි බලන්න. ඒ සියල්ල හොඳින් ක්‍රියාත්මක වන බව අපට පෙනෙනු ඇත.
• නමුත් ප්‍රායෝගිකව අපි විවිධ ගැටලුවලට මුහුණ දුන්නා. ඒ වගේම මම මේ ගැටලු ගැන කතා කරන්නම්.
• අපි එය හඳුනාගත් ආකාරය, අපි වෙනස් කළ දේ - එය අපට උදව් කළත් නැතත් මම ඔබට කියමි.

• Patroni ස්ථාපනය කරන්නේ කෙසේදැයි මම ඔබට නොකියමි, මන්ද ඔබට අන්තර්ජාලයේ ගූගල් කළ හැකි බැවින්, එය සියල්ල ආරම්භ වන්නේ කෙසේද, එය වින්‍යාස කර ඇති ආකාරය තේරුම් ගැනීමට ඔබට වින්‍යාස ගොනු දෙස බැලිය හැකිය. යෝජනා ක්රම, ගෘහ නිර්මාණ ශිල්පය, අන්තර්ජාලයේ ඒ පිළිබඳ තොරතුරු සොයා ගැනීම ඔබට තේරුම් ගත හැකිය.
• මම වෙනත් කෙනෙකුගේ අත්දැකීම් ගැන කතා නොකරමි. අපි මුහුණ දුන් ගැටළු ගැන පමණක් මම කතා කරමි.
• මම Patroni සහ PostgreSQL වලින් පිටත ඇති ගැටළු ගැන කතා නොකරමි. උදාහරණයක් ලෙස, සමතුලිතතාවය සම්බන්ධ ගැටළු තිබේ නම්, අපගේ පොකුර කඩා වැටී ඇති විට, මම ඒ ගැන කතා නොකරමි.

අපි අපගේ වාර්තාව ආරම්භ කිරීමට පෙර කුඩා වියාචනයක්.

අපි මුහුණ දුන් මේ සියලු ගැටලු, අපි මෙහෙයුමේ පළමු මාස ​​6-7-8 තුළ ඒවා තිබුණා. කාලයාගේ ඇවෑමෙන්, අපි අපගේ අභ්‍යන්තර හොඳම භාවිතයන් වෙත පැමිණියෙමු. ඒ වගේම අපේ ප්‍රශ්න නැති වුණා. එමනිසා, වාර්තාව නිවේදනය කළේ මාස හයකට පමණ පෙර, ඒ සියල්ල මගේ හිසෙහි නැවුම් වූ විට සහ මට ඒ සියල්ල හොඳින් මතක ඇති විටය.

වාර්තාව සකස් කිරීමේදී, මම දැනටමත් පැරණි පශ්චාත් මරණ පරීක්ෂණ මතු කර, ලඝු-සටහන් දෙස බැලුවෙමි. තවද ගැටළු විශ්ලේෂණය කිරීමේදී සමහර විස්තර අමතක විය හැකිය, නැතහොත් සමහර විස්තර සම්පූර්ණයෙන් විමර්ශනය කළ නොහැක, එබැවින් සමහර අවස්ථාවලදී ගැටළු සම්පූර්ණයෙන් සලකා බලා නොමැති බව හෝ යම් තොරතුරු හිඟයක් ඇති බවක් පෙනෙන්නට තිබේ. ඒ නිසා මේ මොහොතට මට සමාවෙන්න කියලා මම ඔබෙන් ඉල්ලා සිටිනවා.

Patroni යනු කුමක්ද?

• මෙය HA ගොඩනැගීම සඳහා සැකිල්ලකි. ලියකියවිලිවල සඳහන් වන්නේ එයයි. තවද මගේ දෘෂ්ටි කෝණයෙන් මෙය ඉතා නිවැරදි පැහැදිලි කිරීමකි. Patroni යනු ඔබේ සියලු ගැටලු විසඳන රිදී උණ්ඩයක් නොවේ, එනම්, එය ක්‍රියාත්මක කර ප්‍රතිලාභ ගෙන ඒමට ඔබ උත්සාහ කළ යුතුය.
• මෙය සෑම දත්ත සමුදා සේවාවකම ස්ථාපනය කර ඇති නියෝජිත සේවාවක් වන අතර ඔබේ Postgres සඳහා වන init පද්ධතියකි. එය Postgres ආරම්භ කරයි, නතර කරයි, නැවත ආරම්භ කරයි, නැවත සකස් කරයි, සහ ඔබේ පොකුරේ ස්ථලකය වෙනස් කරයි.
• ඒ අනුව, පොකුරේ තත්වය ගබඩා කිරීම සඳහා, එහි වත්මන් නිරූපණය, පෙනෙන පරිදි, යම් ආකාරයක ගබඩාවක් අවශ්ය වේ. මෙම දෘෂ්ටි කෝණයෙන්, Patroni බාහිර පද්ධතියක රාජ්ය ගබඩා කිරීමේ මාවත ගත්තේය. එය බෙදා හරින ලද මානකරන ගබඩා පද්ධතියකි. එය Etcd, Consul, ZooKeeper, හෝ kubernetes Etcd, එනම් මෙම විකල්පයන්ගෙන් එකක් විය හැක.
• සහ Patroni හි එක් විශේෂාංගයක් නම්, ඔබ ස්වයංක්‍රීය ගොනුව පෙට්ටියෙන් ඉවත් කර ගැනීම, එය සැකසීමෙන් පමණි. අපි Repmgr සංසන්දනය සඳහා ගතහොත්, ගොනුකරු එහි ඇතුළත් වේ. Repmgr සමඟින්, අපට මාරුවීමක් ලැබේ, නමුත් අපට ස්වයංක්‍රීය ගොනුවක් අවශ්‍ය නම්, අපි එය අතිරේකව වින්‍යාසගත කළ යුතුය. Patroni සතුව දැනටමත් ස්වයංක්‍රීය ගොනුවක් ඇත.
• ඒ වගේම තව ගොඩක් දේවල් තියෙනවා. උදාහරණයක් ලෙස, වින්‍යාසයන් නඩත්තු කිරීම, නව අනුරූ වත් කිරීම, උපස්ථ යනාදිය. නමුත් මෙය වාර්තාවේ විෂය පථයෙන් ඔබ්බට ය, මම ඒ ගැන කතා නොකරමි.

තවද කුඩා ප්‍රතිඵලයක් නම් Patroni හි ප්‍රධාන කාර්යය වන්නේ අපගේ පොකුර ක්‍රියාත්මක වන පරිදි ස්වයංක්‍රීය ගොනුවක් හොඳින් සහ විශ්වාසදායක ලෙස සිදු කිරීමයි.

නමුත් අපි Patroni භාවිතා කිරීමට පටන් ගන්නා විට, අපගේ පද්ධතිය ටිකක් සංකීර්ණ වේ. කලින් අපිට Postgres තිබුනා නම් Patroni භාවිතා කරනකොට අපිට ලැබෙන්නේ Patroni ම තමයි, අපිට ලැබෙනවා රාජ්‍යය ගබඩා කරලා තියෙන තැන DCS. ඒ වගේම ඒ සියල්ල කෙසේ හෝ ක්‍රියාත්මක විය යුතුයි. ඉතින් වැරදි විය හැක්කේ කුමක් ද?

බිඳිය හැක:

• Postgres කැඩී යා හැක. එය ස්වාමියා හෝ අනුරුවක් විය හැකිය, ඔවුන්ගෙන් එක් අයෙකු අසමත් විය හැක.
• Patroni ම කැඩී යා හැක.
• තත්වය ගබඩා කර ඇති DCS බිඳී යා හැක.
• තවද ජාලය කැඩී යා හැක.

මෙම සියලු කරුණු මම වාර්තාවේ සලකා බලමි.

මම නඩු සලකා බලන්නේ ඒවා සංකීර්ණ වන විට, නඩුවට බොහෝ සංරචක ඇතුළත් වන දෘෂ්ටි කෝණයෙන් නොවේ. ආත්මීය හැඟීම්වල දෘෂ්ටි කෝණයෙන්, මෙම නඩුව මට අපහසු විය, එය විසුරුවා හැරීම දුෂ්කර විය ... සහ අනෙක් අතට, සමහර නඩුව සැහැල්ලු වූ අතර එය විසුරුවා හැරීමට පහසු විය.

සහ පළමු නඩුව පහසුම වේ. අපි ඩේටාබේස් පොකුරක් ගෙන අපේ ඩීසීඑස් ආචයනය එම පොකුරේ යෙදවූ විට මෙය සිදු වේ. මෙය වඩාත් පොදු වැරැද්දයි. ගෘහ නිර්මාණ ශිල්පය ගොඩනැගීමේදී මෙය දෝෂයකි, එනම් එක් ස්ථානයක විවිධ සංරචක ඒකාබද්ධ කිරීම.

ඉතින්, ෆයිලර් කෙනෙක් හිටියා, අපි සිදු වූ දේ සමඟ කටයුතු කරමු.

ගොනුකරු සිදු වූ විට අපි මෙහිදී උනන්දු වෙමු. එනම්, පොකුරු තත්ත්වය වෙනස් වූ මේ මොහොතේ අපි උනන්දු වෙමු.

නමුත් ගොනු කරන්නා සෑම විටම ක්ෂණික නොවේ, එනම් එය කාලය කිසිදු ඒකකයක් ගත නොවේ, එය ප්රමාද විය හැක. එය දිගු කල් පැවතිය හැකිය.

එබැවින්, එයට ආරම්භක වේලාවක් සහ අවසාන වේලාවක් ඇත, එනම් එය අඛණ්ඩ සිදුවීමකි. තවද අපි සියලුම සිදුවීම් කාල අන්තර තුනකට බෙදන්නෙමු: අපට ගොනු කරන්නාට පෙර, ගොනු කරන්නා අතරතුර සහ ගොනු කරන්නාට පසු කාලය තිබේ. එනම්, අපි මෙම කාලරාමුව තුළ සියලු සිදුවීම් සලකා බලමු.

පළමු දෙය නම්, ගොනුකරුවෙකු සිදු වූ විට, අපි සොයන්නේ සිදු වූ දෙයට හේතුව, ගොනු කරන්නාට තුඩු දුන් දෙයට හේතුව කුමක්ද යන්නයි.

අපි ලඝු-සටහන් දෙස බැලුවහොත්, ඒවා සම්භාව්‍ය Patroni logs වනු ඇත. සේවාදායකයා මාස්ටර් බවට පත් වී ඇති බවත්, ස්වාමියාගේ භූමිකාව මෙම නෝඩයට ගොස් ඇති බවත් ඔහු ඔවුන් තුළ අපට කියයි. මෙන්න එය ඉස්මතු කර ඇත.

ඊළඟට, ගොනුකරු සිදු වූයේ මන්දැයි අප තේරුම් ගත යුතුය, එනම් ප්රධාන භූමිකාව එක් නෝඩයකින් තවත් නෝඩයකට මාරු වීමට හේතු වූ සිදුවීම් මොනවාද. තවද මෙම අවස්ථාවේ දී, සියල්ල සරල ය. ගබඩා පද්ධතිය සමඟ අන්තර් ක්‍රියා කිරීමේදී අපට දෝෂයක් ඇත. ඔහුට DCS සමඟ වැඩ කළ නොහැකි බව මාස්ටර්ට වැටහුණි, එනම් අන්තර්ක්‍රියාකාරිත්වයේ යම් ආකාරයක ගැටලුවක් ඇති බව. ඒ වගේම තමාට තවදුරටත් ස්වාමියෙකු විය නොහැකි බවත් ඉල්ලා අස්වෙනවා. මෙම රේඛාව "තමන්ව පහත හෙලීම" හරියටම කියයි.

අපි ගොනු කරන්නාට පෙර සිදු වූ සිදුවීම් දෙස බැලුවහොත්, විශාරදයා දිගටම කරගෙන යාමට ගැටළුව වූ හේතු අපට දැකගත හැකිය.

Patroni logs බැලුවොත් අපිට පෙනෙයි අපිට ගොඩක් errors, timeouts, ඒ කියන්නේ Patroni agent ට DCS එක්ක වැඩ කරන්න බෑ. මෙම අවස්ථාවේදී, මෙය 8500 වරායේ සන්නිවේදනය කරන කොන්සල් නියෝජිතයා වේ.

තවද මෙහි ඇති ගැටළුව වන්නේ Patroni සහ දත්ත සමුදාය එකම ධාරකයක ක්‍රියාත්මක වීමයි. කොන්සල් සේවාදායකයන් එකම නෝඩයේ දියත් කරන ලදී. සේවාදායකයේ බරක් නිර්මාණය කිරීමෙන්, අපි කොන්සල් සේවාදායකයන්ටද ගැටළු ඇති කළෙමු. ඔවුන්ට නිසි ලෙස සන්නිවේදනය කළ නොහැකි විය.

ටික වේලාවකට පසු, බර අඩු වූ විට, අපගේ පැට්‍රෝනිට නැවත නියෝජිතයින් සමඟ සන්නිවේදනය කිරීමට හැකි විය. සාමාන්‍ය වැඩ නැවත ආරම්භ විය. එම Pgdb-2 සේවාදායකය නැවතත් ප්‍රධානියා බවට පත් විය. එනම්, කුඩා පෙරලීමක් ඇති වූ අතර, එම නිසා නෝඩය ස්වාමියාගේ බලතල ඉල්ලා අස් කර, පසුව ඒවා නැවත පවරා ගත්තේය, එනම් සියල්ල තිබූ ආකාරයටම ආපසු පැමිණියේය.

මෙය ව්‍යාජ අනතුරු ඇඟවීමක් ලෙස සැලකිය හැකිය, නැතහොත් පැට්‍රෝනි සියල්ල නිවැරදිව කළ බව සැලකිය හැකිය. එනම් තමාට පොකුරු තත්ත්වය පවත්වා ගැනීමට නොහැකි බව වටහාගෙන තම අධිකාරිය ඉවත් කර ගැනීමයි.

කොන්සල් සේවාදායකයන් පදනම් ලෙස එකම දෘඩාංග මත තිබීම නිසා මෙහි ගැටළුව ඇති විය. ඒ අනුව, ඕනෑම බරක්: එය තැටි හෝ ප්‍රොසෙසර මත පැටවීම වේවා, එය කොන්සල් පොකුර සමඟ අන්තර්ක්‍රියා කිරීමට ද බලපායි.

එය එකට ජීවත් නොවිය යුතු බව අපි තීරණය කළෙමු, අපි කොන්සල් සඳහා වෙනම පොකුරක් වෙන් කළෙමු. පැට්‍රෝනි දැනටමත් වෙනම කොන්සල්වරයෙකු සමඟ වැඩ කරමින් සිටියේය, එනම් වෙනම පෝස්ට්ග්‍රෙස් පොකුරක්, වෙනම කොන්සල් පොකුරක් විය. මේ සියල්ල එකට ජීවත් නොවන පරිදි රැගෙන යා යුතු ආකාරය සහ තබා ගන්නේ කෙසේද යන්න පිළිබඳ මූලික උපදෙස් මෙයයි.

විකල්පයක් ලෙස, ඔබට ttl, loop_wait, retry_timeout යන පරාමිති twist කළ හැක, එනම් මෙම පරාමිති වැඩි කිරීමෙන් මෙම කෙටි කාලීන load peaks වලින් බේරීමට උත්සාහ කරන්න. නමුත් මෙය වඩාත්ම සුදුසු විකල්පය නොවේ, මන්ද මෙම භාරය දිගු කලක් ගත විය හැකිය. තවද අපි මෙම පරාමිතීන්ගේ මෙම සීමාවන් ඉක්මවා යමු. එය ඇත්ත වශයෙන්ම උදව් නොකරනු ඇත.

පළමු ගැටළුව, ඔබ තේරුම් ගත් පරිදි, සරල ය. අපි අරගෙන DCS එක බේස් එකත් එක්ක දැම්මා, අපිට ප්‍රශ්නයක් ආවා.

දෙවන ගැටළුව පළමු එකට සමාන වේ. අපට නැවතත් DCS පද්ධතිය සමඟ අන්තර් ක්‍රියාකාරීත්ව ගැටළු ඇති වීම සමාන වේ.

අපි ලඝු-සටහන් දෙස බැලුවහොත්, අපට නැවතත් සන්නිවේදන දෝෂයක් ඇති බව පෙනේ. ඒ වගේම Patroni කියනවා මට DCS සමඟ අන්තර් ක්‍රියා කළ නොහැකි නිසා වත්මන් මාස්ටර් අනුරූ මාදිලියට යයි.

පැරණි ස්වාමියා අනුරුවක් බවට පත්වේ, මෙන්න පැට්‍රෝනි එය විය යුතු පරිදි ක්‍රියා කරයි. එය ගණුදෙණු ලොගය රිවයින්ඩ් කිරීමට pg_rewind ධාවනය කර පසුව නව මාස්ටර් සමඟ සම්බන්ධ වීමට නව මාස්ටර් වෙත සම්බන්ධ වේ. මෙන්න Patroni ඔහුට කළ යුතු පරිදි වැඩ කරයි.

මෙහිදී අපි ගොනු කරන්නාට පෙර ඇති ස්ථානය සොයා ගත යුතුය, එනම් අපට ගොනු කරන්නෙකු ඇති වීමට හේතු වූ දෝෂ. මේ සම්බන්ධයෙන්, Patroni ලොග් සමඟ වැඩ කිරීමට තරමක් පහසුය. ඔහු යම් කාල පරතරයකින් එකම පණිවිඩ ලියයි. අපි ඉක්මනින් මෙම ලොග් හරහා අනුචලනය කිරීමට පටන් ගන්නේ නම්, එවිට ලොග් වෙනස් වී ඇති බව අපට පෙනෙනු ඇත, එනම් සමහර ගැටළු ආරම්භ වී ඇති බවයි. අපි ඉක්මනින් මෙම ස්ථානයට ආපසු පැමිණෙන්නේ කුමක්දැයි බලන්න.

සාමාන්‍ය තත්වයකදී, ලොග මේ වගේ දෙයක් පෙනේ. අගුලේ හිමිකරු පරීක්ෂා කරනු ලැබේ. උදාහරණයක් ලෙස අයිතිකරු වෙනස් වී ඇත්නම්, පැට්‍රෝනි ප්‍රතිචාර දැක්විය යුතු සමහර සිදුවීම් සිදුවිය හැකිය. නමුත් මේ අවස්ථාවේ දී, අපි හොඳින්. දෝෂ ආරම්භ වූ ස්ථානය අපි සොයන්නෙමු.

දෝෂ දර්ශනය වීමට පටන් ගත් ස්ථානයට අනුචලනය කිරීමෙන් පසු, අපට ස්වයංක්‍රීය ගොනුවක් ඇති බව අපට පෙනේ. අපගේ දෝෂ DCS සමඟ අන්තර්ක්‍රියා හා සම්බන්ධ වූ බැවින් සහ අපගේ නඩුවේදී අපි කොන්සල් භාවිතා කළ නිසා, අපි කොන්සල් ලොග් ද බලන්නෙමු, එහි සිදු වූ දේ.

ගොනු කරන්නාගේ කාලය සහ කොන්සල් ලොග් වල කාලය දළ වශයෙන් සංසන්දනය කිරීමේදී, කොන්සල් පොකුරේ සිටින අපගේ අසල්වැසියන් කොන්සල් පොකුරේ අනෙකුත් සාමාජිකයින්ගේ පැවැත්ම සැක කිරීමට පටන් ගත් බව අපට පෙනේ.

තවද ඔබ අනෙකුත් කොන්සල් නියෝජිතයින්ගේ ලඝු-සටහන් දෙස බැලුවහොත්, එහි යම් ආකාරයක ජාල බිඳවැටීමක් සිදු වන බව ද ඔබට දැක ගත හැකිය. කොන්සල් පොකුරේ සියලුම සාමාජිකයන් එකිනෙකාගේ පැවැත්ම සැක කරති. තවද මෙය ගොනු කරන්නාට උත්තේජනයක් විය.

ඔබ මෙම දෝෂ වලට පෙර සිදු වූ දේ දෙස බැලුවහොත්, ඔබට පෙනෙන්නේ සියලු ආකාරයේ දෝෂ ඇති බවයි, උදාහරණයක් ලෙස, අවසාන දිනය, RPC පහත වැටුණි, එනම්, කොන්සල් පොකුරු සාමාජිකයින් එකිනෙකා සමඟ අන්තර් ක්‍රියා කිරීමේදී යම් ආකාරයක ගැටලුවක් පැහැදිලිවම තිබේ. .

සරලම පිළිතුර වන්නේ ජාලය අලුත්වැඩියා කිරීමයි. නමුත් වේදිකාවේ සිටගෙන සිටින මට මෙය පැවසීම පහසුය. නමුත් සෑම විටම පාරිභෝගිකයාට ජාලය අලුත්වැඩියා කිරීමට නොහැකි වන තත්ත්වයන් පවතී. ඔහු DC එකක ජීවත් විය හැකි අතර ජාලය අලුත්වැඩියා කිරීමට නොහැකි විය හැකිය, උපකරණවලට බලපායි. එබැවින් වෙනත් විකල්ප කිහිපයක් අවශ්ය වේ.

විකල්ප ඇත:

• මගේ මතය අනුව, ලියකියවිලි වල පවා ලියා ඇති සරලම විකල්පය වන්නේ කොන්සල් චෙක්පත් අක්‍රිය කිරීමයි, එනම් හිස් අරාවක් සම්මත කිරීමයි. ඒ වගේම අපි කොන්සල් නියෝජිතයාට කියනවා කිසිම චෙක්පතක් පාවිච්චි කරන්න එපා කියලා. මෙම චෙක්පත් සමඟ, අපට මෙම ජාල කුණාටු නොසලකා හැර ගොනුකරුවෙකු ආරම්භ නොකළ හැකිය.
• තවත් විකල්පයක් වන්නේ raft_multiplier දෙවරක් පරීක්ෂා කිරීමයි. මෙය කොන්සල් සේවාදායකයේම පරාමිතියකි. පෙරනිමියෙන්, එය 5 ලෙස සකසා ඇත. මෙම අගය වේදිකා පරිසරයන් සඳහා ලියකියවිලි මගින් නිර්දේශ කෙරේ. ඇත්ත වශයෙන්ම, මෙය කොන්සල් ජාලයේ සාමාජිකයින් අතර පණිවිඩ යැවීමේ වාර ගණනට බලපායි. ඇත්ත වශයෙන්ම, මෙම පරාමිතිය කොන්සල් පොකුරේ සාමාජිකයින් අතර සේවා සන්නිවේදනයේ වේගය බලපායි. නිෂ්පාදනය සඳහා, නෝඩ් බොහෝ විට පණිවිඩ හුවමාරු කර ගැනීම සඳහා එය අඩු කිරීමට දැනටමත් නිර්දේශ කර ඇත.
• අප විසින් ඉදිරිපත් කර ඇති තවත් විකල්පයක් වන්නේ මෙහෙයුම් පද්ධතියේ ක්‍රියාවලි කාලසටහන සඳහා අනෙකුත් ක්‍රියාවලි අතර කොන්සල් ක්‍රියාවලීන්හි ප්‍රමුඛතාවය වැඩි කිරීමයි. එවැනි "ලස්සන" පරාමිතියක් ඇත, එය උපලේඛනගත කිරීමේදී OS උපලේඛකයා විසින් සැලකිල්ලට ගනු ලබන ක්රියාවලීන්ගේ ප්රමුඛතාවය තීරණය කරයි. අපි කොන්සල් නියෝජිතයින් සඳහා හොඳ වටිනාකමක් ද අඩු කර ඇත, i.e. මෙහෙයුම් පද්ධතිය කොන්සල් ක්‍රියාවලීන්ට වැඩ කිරීමට සහ ඔවුන්ගේ කේතය ක්‍රියාත්මක කිරීමට වැඩි කාලයක් ලබා දෙන පරිදි ප්‍රමුඛතාවය වැඩි කරන ලදී. අපගේ නඩුවේදී, මෙය අපගේ ගැටලුව විසඳා ඇත.
• තවත් විකල්පයක් වන්නේ කොන්සල් භාවිතා නොකිරීමයි. මට Etcd වලට ලොකු සහයෝගයක් දෙන යාලුවෙක් ඉන්නවා. ඒවගේම අපි නිතරම ඔහු සමඟ වාද කරන්නේ වඩා හොඳ Etcd හෝ Consul යනු කුමක්ද යන්නයි. නමුත් වඩා හොඳ කුමක්ද යන්න සම්බන්ධයෙන්, අපි සාමාන්‍යයෙන් ඔහු සමඟ එකඟ වන්නේ කොන්සල්ට දත්ත සමුදායක් සමඟ එක් එක් නෝඩය මත ක්‍රියාත්මක විය යුතු නියෝජිතයෙකු සිටින බවයි. එනම්, කොන්සල් පොකුර සමඟ Patroni අන්තර්ක්‍රියා මෙම නියෝජිතයා හරහා සිදු වේ. තවද මෙම නියෝජිතයා බාධකයක් බවට පත්වේ. නියෝජිතයාට යමක් සිදුවුවහොත්, පැට්‍රෝනිට තවදුරටත් කොන්සල් පොකුර සමඟ වැඩ කළ නොහැක. අනික මේක තමයි ගැටලුව. Etcd සැලැස්මෙහි නියෝජිතයෙකු නොමැත. Patroni හට Etcd සේවාදායක ලැයිස්තුවක් සමඟ කෙලින්ම වැඩ කළ හැකි අතර දැනටමත් ඔවුන් සමඟ සන්නිවේදනය කළ හැකිය. මේ සම්බන්ධයෙන්, ඔබ ඔබේ සමාගම තුළ Etcd භාවිතා කරන්නේ නම්, Etcd බොහෝ විට කොන්සල්ට වඩා හොඳ තේරීමක් වනු ඇත. නමුත් අපගේ ගනුදෙනුකරුවන් වන අපි සෑම විටම සේවාදායකයා තෝරාගෙන භාවිතා කරන දේට සීමා වෙමු. තවද සියලුම ගනුදෙනුකරුවන් සඳහා බොහෝ දුරට කොන්සල් අප සතුව ඇත.
• අවසාන කරුණ වන්නේ පරාමිති අගයන් සංශෝධනය කිරීමයි. අපගේ කෙටි කාලීන ජාල ගැටළු කෙටි වන අතර මෙම පරාමිතිවල පරාසයෙන් පිටතට නොපැමිණෙනු ඇතැයි අපේක්ෂාවෙන් අපට මෙම පරාමිතීන් ඉහළ නැංවිය හැකිය. මේ ආකාරයෙන් සමහර ජාල ගැටළු ඇති වුවහොත් Patroni ස්වයංක්‍රීය ගොනු කිරීමට ඇති ආක්‍රමණශීලී බව අඩු කළ හැකිය.

මම හිතන්නේ Patroni භාවිතා කරන බොහෝ දෙනෙක් මෙම විධානය හුරුපුරුදුය.

මෙම විධානය පොකුරේ වත්මන් තත්වය පෙන්වයි. සහ මුලින්ම බැලූ බැල්මට, මෙම පින්තූරය සාමාන්ය දෙයක් විය හැකිය. අපට ස්වාමියෙක් ඇත, අපට අනුරුවක් ඇත, අනුරූ ප්‍රමාදයක් නොමැත. නමුත් මෙම පොකුරේ නෝඩ් දෙකක් නොව නෝඩ් තුනක් තිබිය යුතු බව අප දන්නා තෙක් මෙම පින්තූරය සාමාන්‍ය වේ.

ඒ අනුව ඔටෝෆයිල් එකක් තිබුණා. මෙම ස්වයංක්‍රීය ගොනුවෙන් පසුව, අපගේ අනුරුව අතුරුදහන් විය. ඇය අතුරුදහන් වූයේ මන්දැයි සොයා බලා ඇයව නැවත ගෙන්වා ගෙන නැවත යථා තත්ත්වයට පත් කළ යුතුය. අපි නැවතත් ලොග් වෙත ගොස් අපට ස්වයංක්‍රීය ගොනුවක් තිබුනේ මන්දැයි බලමු.

මෙම නඩුවේදී, දෙවන අනුරුව මාස්ටර් බවට පත් විය. මෙතන ඔක්කොම හරි.

ඒවගේම අපි බලන්න ඕන ගැලවී ගිය සහ පොකුරේ නැති අනුරුව. අපි Patroni logs විවෘත කර pg_rewind අදියරේදී පොකුරට සම්බන්ධ කිරීමේ ක්‍රියාවලියේදී අපට ගැටලුවක් ඇති බව දකිමු. පොකුරට සම්බන්ධ වීමට, ඔබ ගණුදෙණු ලොගය පෙරලා, අවශ්‍ය ගනුදෙනු ලොගය ප්‍රධානියාගෙන් ඉල්ලා සිටිය යුතු අතර, එය ප්‍රධානියා සමඟ සම්බන්ධ වීමට භාවිත කළ යුතුය.

මෙම අවස්ථාවේදී, අපට ගනුදෙනු ලොගයක් නොමැති අතර අනුරුව ආරම්භ කළ නොහැක. ඒ අනුව, අපි දෝෂයක් සමඟ Postgres නවත්වන්නෙමු. එබැවින් එය පොකුරේ නොමැත.

එය පොකුරේ නැත්තේ ඇයි සහ ලඝු-සටහන් නොතිබුනේ මන්දැයි අප තේරුම් ගත යුතුය. අපි නව මාස්ටර් වෙත ගොස් ඔහු ලඝු-සටහන් වල ඇති දේ දෙස බලමු. pg_rewind කළ විට, මුරපොලක් සිදු වූ බව පෙනේ. තවද සමහර පැරණි ගනුදෙනු ලොග් සරලව නැවත නම් කරන ලදී. පැරණි මාස්ටර් නව මාස්ටර් වෙත සම්බන්ධ වී මෙම ලඝු-සටහන් විමසීමට උත්සාහ කළ විට, ඒවා දැනටමත් නැවත නම් කර ඇත, ඒවා නොතිබුණි.

මෙම සිදුවීම් සිදු වූ විට මම වේලා මුද්දර සංසන්දනය කළෙමි. එහි වෙනස වචනාර්ථයෙන් මිලි තත්පර 150 කි, එනම් මිලි තත්පර 369 කින් නිම කරන ලද මුරපොල, WAL කොටස් නැවත නම් කරන ලදී. සහ වචනාර්ථයෙන් 517 දී, මිලි තත්පර 150 කට පසු, පැරණි අනුරුව මත ආපසු හැරීම ආරම්භ විය. එනම්, අනුරුව සම්බන්ධ වී උපයා ගැනීමට නොහැකි වන පරිදි වචනාර්ථයෙන් මිලි තත්පර 150ක් අපට ප්‍රමාණවත් විය.

විකල්ප මොනවාද?

අපි මුලින් ප්‍රතිනිර්මාණ කට්ට භාවිතා කළා. අපි හිතුවා ඒක හොඳයි කියලා. මෙහෙයුමේ පළමු අදියරේදී අපි තව් අක්‍රිය කළද. අපිට පෙනුනේ slots වල WAL segment ගොඩක් එකතු උනොත් අපිට master එක අතාරින්න පුළුවන් කියලයි. ඔහු වැටෙනු ඇත. අපි කාලයක් කට්ට නැතිව දුක් වින්දා. අපට තව් අවශ්‍ය බව අපට වැටහුණි, අපි තව් නැවත ලබා දුන්නෙමු.

නමුත් මෙතන ප්‍රශ්නයක් තියෙනවා, master එක replica එකට ගියාම slots මකලා, slots එක්කම WAL segments මකනවා. තවද මෙම ගැටළුව තුරන් කිරීම සඳහා, අපි wal_keep_segments පරාමිතිය ඉහළ නැංවීමට තීරණය කළෙමු. එය කොටස් 8කට පෙරනිමි වේ. අපි එය 1 දක්වා වැඩි කර අපට කොපමණ නිදහස් ඉඩක් තිබේද යන්න සොයා බැලුවෙමු. තවද අපි wal_keep_segments සඳහා ගිගාබයිට් 000ක් පරිත්‍යාග කළෙමු. එනම්, මාරු කිරීමේදී, අපි සෑම විටම සියලුම නෝඩ් වල ගනුදෙනු ලොග් ගිගාබයිට් 16 ක සංචිතයක් ඇත.

සහ ප්ලස් - දිගුකාලීන නඩත්තු කටයුතු සඳහා එය තවමත් අදාළ වේ. අපි හිතමු අපිට රෙප්ලිකා එකක් අප්ඩේට් කරන්න ඕන කියලා. ඒ වගේම අපි එය අක්රිය කිරීමට අවශ්යයි. අපි මෘදුකාංගය යාවත්කාලීන කළ යුතුයි, සමහර විට මෙහෙයුම් පද්ධතිය, වෙනත් දෙයක්. ඒවගේම අපි රෙප්ලිකා එකක් ඕෆ් කරනකොට ඒ රෙප්ලිකා එකේ ස්ලොට් එකත් අයින් වෙනවා. තවද අපි කුඩා wal_keep_segments භාවිතා කරන්නේ නම්, දිගු කාලයක් අනුරුවක් නොමැති වීමත් සමඟ ගනුදෙනු ලොග් නැති වී යයි. අපි අනුරුවක් ඔසවන්නෙමු, එය නතර වූ ස්ථානයේ එම ගනුදෙනු ලොග් ඉල්ලා සිටින නමුත් ඒවා මාස්ටර් මත නොතිබිය හැකිය. තවද අනුරුවට සම්බන්ධ වීමටද නොහැකි වනු ඇත. එමනිසා, අපි සඟරා විශාල තොගයක් තබා ගන්නෙමු.

අපට නිෂ්පාදන පදනමක් තිබේ. දැනටමත් ව්‍යාපෘති ක්‍රියාත්මක වෙමින් පවතී.

ෆයිලර් කෙනෙක් හිටියා. අපි ඇතුලට ගිහින් බැලුවා - හැම දෙයක්ම පිළිවෙලට තියෙනවා, අනුරූවල තියෙනවා, අනුරූ ප්‍රමාදයක් නැහැ. ලොග් වල ද දෝෂ නොමැත, සියල්ල පිළිවෙලට තිබේ.

නිෂ්පාදන කණ්ඩායම පවසන්නේ යම් දත්ත තිබිය යුතු බවයි, නමුත් අපි එය එක් මූලාශ්‍රයකින් දකින නමුත් අපි එය දත්ත සමුදායේ නොදකිමු. ඒ වගේම අපි තේරුම් ගන්න ඕන ඒ අයට මොකද වුණේ කියලා.

pg_rewind ඒවා මග හැරුණු බව පැහැදිලිය. අපි මෙය වහාම තේරුම් ගත්තෙමු, නමුත් සිදුවන්නේ කුමක්දැයි බැලීමට ගියෙමු.

ලඝු-සටහන් වල, ගොනු කරන්නා සිදු වූ විට, ප්‍රධානියා වූයේ කවුරුන්ද යන්න අපට සැමවිටම සොයා ගත හැකි අතර, පැරණි ස්වාමියා කවුද සහ ඔහුට අනුරුවක් වීමට අවශ්‍ය වූයේ කවදාද යන්න අපට තීරණය කළ හැකිය, එනම් ගනුදෙනු ලොග් ප්‍රමාණය සොයා ගැනීමට අපට මෙම ලොග් අවශ්‍ය වේ. අහිමි වුණා.

අපේ පැරණි මාස්ටර් නැවත ආරම්භ කර ඇත. සහ Patroni autorun හි ලියාපදිංචි විය. Patroni දියත් කළේය. පසුව ඔහු Postgres ආරම්භ කළේය. වඩාත් නිවැරදිව, Postgres ආරම්භ කිරීමට පෙර සහ එය අනුරුවක් කිරීමට පෙර, Patroni pg_rewind ක්‍රියාවලිය දියත් කළේය. ඒ අනුව ඔහු ගනුදෙනු ලොග් වලින් කොටසක් මකා අලුත් ඒවා බාගත කර සම්බන්ධ කළේය. මෙහිදී Patroni දක්ෂ ලෙස, එනම් බලාපොරොත්තු වූ පරිදි වැඩ කළේය. පොකුර යථා තත්ත්වයට පත් කර ඇත. අපට නෝඩ් 3 ක් තිබුනා, ෆයිලර් නෝඩ් 3 ට පසුව - සියල්ල සිසිල් ය.

අපට සමහර දත්ත නැති වී ඇත. ඒ වගේම අපිට කොච්චර පාඩුවක් වෙලාද කියලා තේරුම් ගන්න ඕන. අපි සොයන්නේ අපට රිවයින්ඩ් වූ මොහොත පමණි. එවැනි සඟරා සටහන් වලින් අපට එය සොයාගත හැකිය. Rewind පටන් අරන් එතනම මොකක් හරි කරලා ඉවරයි.

අපි ගනුදෙනු ලොගයේ පැරණි ස්වාමියා නතර කළ ස්ථානය සොයා ගත යුතුයි. මෙම අවස්ථාවේදී, මෙය ලකුණකි. අපට දෙවන ලකුණක් අවශ්‍ය වේ, එනම් පැරණි ස්වාමියා අලුත් එකට වඩා වෙනස් වන දුරයි.

අපි සුපුරුදු pg_wal_lsn_diff ගෙන මෙම ලකුණු දෙක සංසන්දනය කරමු. තවද මෙම අවස්ථාවේදී, අපට මෙගාබයිට් 17 ක් ලැබේ. ගොඩක් හෝ ටිකක්, සෑම කෙනෙකුම තමාටම තීරණය කරයි. මක්නිසාද යත් යමෙකුට මෙගාබයිට් 17 ක් බොහෝ නොවේ, යමෙකුට එය බොහෝ හා පිළිගත නොහැකි ය. මෙහිදී, එක් එක් පුද්ගලයා ව්‍යාපාරයේ අවශ්‍යතා අනුව තමාටම තීරණය කරයි.

නමුත් අපි අප වෙනුවෙන්ම සොයාගෙන ඇත්තේ කුමක්ද?

පළමුව, අප විසින්ම තීරණය කළ යුතුය - පද්ධතිය නැවත ආරම්භ කිරීමෙන් පසු ස්වයංක්‍රීයව ආරම්භ කිරීමට අපට සැමවිටම Patroni අවශ්‍යද? එය බොහෝ විට සිදු වන්නේ අප පැරණි ස්වාමියා වෙත යා යුතු බවයි, ඔහු කොපමණ දුරක් ගොස් ඇත්දැයි බලන්න. සමහර විට ගනුදෙනු ලොගයේ කොටස් පරීක්ෂා කරන්න, එහි ඇති දේ බලන්න. තවද අපට මෙම දත්ත නැති විය හැකිද නැතහොත් මෙම දත්ත පිටතට ඇද ගැනීමට පැරණි මාස්ටර් ස්වාධීන මාදිලියේ ධාවනය කිරීමට අවශ්‍යද යන්න තේරුම් ගැනීමට.

ඉන් පසුව පමණක් අපට මෙම දත්ත ඉවත දැමිය හැකිද නැතහොත් අපට එය ප්‍රතිස්ථාපනය කළ හැකිද යන්න තීරණය කළ යුතුය, මෙම නෝඩය අපගේ පොකුරට අනුරුවක් ලෙස සම්බන්ධ කරන්න.

ඊට අමතරව, "maximum_lag_on_failover" පරාමිතියක් ඇත. පෙරනිමියෙන්, මගේ මතකය මට සේවය කරන්නේ නම්, මෙම පරාමිතිය මෙගාබයිට් 1 ක අගයක් ඇත.

ඔහු වැඩ කරන්නේ කෙසේද? අනුරූ ප්‍රමාදයේ දත්ත මෙගාබයිට් 1කින් අපගේ අනුරුව පිටුපසින් තිබේ නම්, මෙම අනුරුව මැතිවරණවලට සහභාගී නොවේ. හදිසියේ ගොනු කිරීමක් සිදුවුවහොත්, පැට්‍රෝනි බලන්නේ කුමන අනුරූ පසුගාමීද යන්නයි. ගණුදෙණු ලොග් විශාල සංඛ්‍යාවකින් ඔවුන් පිටුපස සිටින්නේ නම්, ඔවුන්ට ස්වාමියෙකු විය නොහැක. මෙය ඉතා හොඳ ආරක්ෂක අංගයක් වන අතර එමඟින් ඔබට දත්ත විශාල ප්‍රමාණයක් අහිමි වීම වළක්වයි.

නමුත් Patroni cluster සහ DCS වල replication lag එක යම් කාල පරතරයකින් update වීම ගැටළුවක්. මම හිතන්නේ තත්පර 30 යනු පෙරනිමි ttl අගයයි.

ඒ අනුව, DCS හි අනුරූ සඳහා එක් අනුරූ ප්‍රමාදයක් ඇති තත්වයක් තිබිය හැකිය, නමුත් ඇත්ත වශයෙන්ම සම්පූර්ණයෙන්ම වෙනස් ප්‍රමාදයක් තිබිය හැකිය, නැතහොත් කිසිසේත් ප්‍රමාදයක් නොතිබිය හැකිය, එනම් මෙය තත්‍ය කාලීන නොවේ. තවද එය සෑම විටම සැබෑ පින්තූරය පිළිබිඹු නොකරයි. ඒවගේම ඒ ගැන විචිත්‍රවත් තර්ක කිරීම වටින්නේ නැහැ.

සහ අහිමි වීමේ අවදානම සැමවිටම පවතී. නරකම අවස්ථාවක, එක් සූත්‍රයක් සහ සාමාන්‍ය අවස්ථාවක, තවත් සූත්‍රයක්. එනම්, අපි Patroni ක්‍රියාත්මක කිරීම සැලසුම් කරන විට සහ අපට කොපමණ දත්ත අහිමි විය හැකිද යන්න තක්සේරු කරන විට, අප මෙම සූත්‍ර මත විශ්වාසය තැබිය යුතු අතර අපට කොපමණ දත්ත ප්‍රමාණයක් අහිමි විය හැකිද යන්න දළ වශයෙන් සිතාගත යුතුය.

ඒ වගේම සුබ ආරංචියක් තියෙනවා. පැරණි මාස්ටර් ඉදිරියට ගිය විට, යම් පසුබිම් ක්රියාවලීන් නිසා ඔහුට ඉදිරියට යා හැකිය. එනම්, යම් ආකාරයක ස්වයංක්‍රීය රික්තයක් තිබුණි, ඔහු දත්ත ලිවීය, ඒවා ගනුදෙනු ලොගයට සුරැකීය. තවද අපට මෙම දත්ත පහසුවෙන් නොසලකා හැර නැති කර ගත හැක. මේකේ කිසිම ප්‍රශ්නයක් නැහැ.

උපරිම_lag_on_failover සකසා ගොනුවක් සිදුවී ඇත්නම් සහ ඔබට නව මාස්ටර් එකක් තෝරා ගැනීමට අවශ්‍ය නම් ලොග් පෙනෙන්නේ එලෙසයි. අනුරුව මැතිවරණවලට සහභාගී වීමට නොහැකි බව තක්සේරු කරයි. තවද ඇය නායකයා සඳහා වන තරඟයට සහභාගී වීම ප්‍රතික්ෂේප කරයි. ඇය නව මාස්ටර් කෙනෙකු තෝරා ගන්නා තෙක් බලා සිටී, එවිට ඇයට එයට සම්බන්ධ විය හැක. මෙය දත්ත නැතිවීමට එරෙහිව අතිරේක පියවරකි.

ඔවුන්ගේ නිෂ්පාදනයට Postgres සමඟ ගැටලු ඇති බව ලියා ඇති නිෂ්පාදන කණ්ඩායමක් මෙහි ඇත. ඒ අතරම, එය SSH හරහා ලබා ගත නොහැකි නිසා, ස්වාමියාටම ප්‍රවේශ විය නොහැක. තවද ස්වයංක්‍රීය ගොනුව ද සිදු නොවේ.

මෙම ධාරකය නැවත පණගැන්වීමට බල කරන ලදී. Reboot එක නිසා auto-file එකක් වුනා, ඒක manual auto-file කරන්න පුළුවන් වුනාට, මට දැන් තේරෙන විදියට. නැවත පණගැන්වීමෙන් පසු, අපි දැනටමත් වත්මන් මාස්ටර් සමඟ ඇති දේ බැලීමට යන්නෙමු.

ඒ අතරම, අපට තැටි සමඟ ගැටළු ඇති බව අපි කල්තියා දැන සිටියෙමු, එනම්, කැණීම් කළ යුත්තේ කොතැනද සහ සොයා බැලිය යුතු දේ නිරීක්ෂණය කිරීමෙන් අපි දැනටමත් දැන සිටියෙමු.

අපි postgres ලොගයට ඇතුළු වී එහි සිදුවන්නේ කුමක්දැයි බැලීමට පටන් ගත්තෙමු. සාමාන්‍ය දෙයක් නොවන තත්පර එකයි දෙකයි තුනයි කැපවීම් අපි දැක්කා. අපගේ autovacuum ඉතා සෙමින් හා අමුතු ලෙස ආරම්භ වන බව අපි දුටුවෙමු. තවද අපි තැටියේ තාවකාලික ගොනු දුටුවෙමු. එනම්, මේ සියල්ල තැටි සමඟ ඇති ගැටළු පිළිබඳ දර්ශක වේ.

අපි පද්ධතිය dmesg (කර්නල් ලොගය) දෙස බැලුවා. තවද අපට එක් තැටි සමඟ ගැටළු ඇති බව අපි දුටුවෙමු. තැටි උප පද්ධතිය මෘදුකාංග Raid විය. අපි /proc/mdstat දෙස බැලූ විට අපට එක් ධාවකයක් මග හැරී ඇති බව දුටුවෙමු. එනම්, තැටි 8 ක වැටලීමක් ඇත, අපට එකක් මග හැරී ඇත. ඔබ ස්ලයිඩය දෙස හොඳින් බැලුවහොත්, ප්‍රතිදානයේදී අපට එහි sde නොමැති බව ඔබට පෙනෙනු ඇත. අප තුළ, කොන්දේසි සහිතව, තැටිය පහත වැටී ඇත. මෙය තැටි ගැටළු ඇති කළ අතර, Postgres පොකුර සමඟ වැඩ කිරීමේදී යෙදුම් ද ගැටළු වලට මුහුණ දුන්නේය.

තවද මෙම අවස්ථාවේදී, Patroni අපට කිසිදු ආකාරයකින් උදව් නොකරනු ඇත, මන්ද සේවාදායකයේ තත්වය, තැටියේ තත්වය නිරීක්ෂණය කිරීමේ කාර්යය Patroni සතුව නොමැත. තවද අප එවැනි තත්ත්වයන් බාහිර නිරීක්ෂණ මගින් නිරීක්ෂණය කළ යුතුය. අපි ඉක්මනින් තැටි නිරීක්‍ෂණය බාහිර නිරීක්‍ෂණයට එකතු කළෙමු.

එවැනි සිතුවිල්ලක් තිබුණි - වැටවල් හෝ මුරකරු මෘදුකාංග අපට උදව් කළ හැකිද? ගැටළු අතරතුර Patroni DCS පොකුර සමඟ දිගටම කටයුතු කළ අතර කිසිදු ගැටළුවක් නොදුටු නිසා ඔහු මෙම නඩුවේදී අපට උදව් නොකරනු ඇතැයි අපි සිතුවෙමු. එනම්, DCS සහ Patroni හි දෘෂ්ටි කෝණයෙන්, පොකුරු සමඟ සෑම දෙයක්ම හොඳයි, ඇත්ත වශයෙන්ම තැටියේ ගැටළු ඇති වුවද, දත්ත සමුදාය ලබා ගැනීමේ ගැටළු ඇති විය.

මගේ මතය අනුව, මම බොහෝ කාලයක් තිස්සේ පර්යේෂණ කර ඇති අමුතුම ගැටලුවකි, මම බොහෝ ලොග් කියවා, නැවත තෝරාගෙන එය පොකුරු සිමියුලේටරය ලෙස හැඳින්වේ.

ගැටලුව වූයේ පැරණි මාස්ටර්ට සාමාන්‍ය අනුරුවක් වීමට නොහැකි වීමයි, එනම් එය ආරම්භ කළේ පැට්‍රෝනි, මෙම නෝඩය අනුරුවක් ලෙස පවතින බව පැට්‍රෝනි පෙන්වූ නමුත් ඒ සමඟම එය සාමාන්‍ය අනුරුවක් නොවීය. දැන් ඔබට පෙනෙනු ඇත ඇයි? එම ගැටලුව පිළිබඳ විග්‍රහයෙන් මා තබා ඇත්තේ මෙයයි.

සහ ඒ සියල්ල ආරම්භ වූයේ කෙසේද? එය පෙර ගැටලුවේදී මෙන් තැටි තිරිංග සමඟ ආරම්භ විය. අපිට තත්පරයක් දෙකක් කැපවීම් තිබුණා.

සම්බන්ධතා වල බිඳීම් ඇති විය, එනම්, ගනුදෙනුකරුවන් ඉරා දැමීය.

විවිධ තීව්‍රතාවයේ අවහිරතා ඇති විය.

තවද, ඒ අනුව, තැටි උප පද්ධතිය ඉතා ප්රතිචාර නොදක්වයි.

මට වඩාත්ම අද්භූත දෙය නම් පැමිණි වහාම වසා දැමීමේ ඉල්ලීමයි. Postgres හි වසා දැමීමේ ආකාර තුනක් ඇත:

• සියලුම ගනුදෙනුකරුවන් තනිවම විසන්ධි වන තෙක් අපි බලා සිටින විට එය ඉතා අලංකාරයි.
• අපි වසා දැමීමට යන නිසා අපි සේවාලාභීන්ට විසන්ධි කිරීමට බල කරන විට වේගවත් වේ.
• සහ වහාම. මෙම අවස්ථාවේ දී, ක්ෂණිකව සේවාලාභීන්ට වසා දැමීමට පවා නොකියයි, එය අනතුරු ඇඟවීමකින් තොරව වසා දමයි. තවද සියලුම සේවාලාභීන්ට, මෙහෙයුම් පද්ධතිය දැනටමත් RST පණිවිඩයක් යවයි (සම්බන්ධතාවයට බාධා ඇති වන අතර සේවාදායකයාට අල්ලා ගැනීමට තවත් කිසිවක් නොමැති බවට TCP පණිවිඩයක්).

මෙම සංඥාව එව්වේ කවුද? Postgres පසුබිම් ක්රියාවලීන් එවැනි සංඥා එකිනෙකින් එවන්නේ නැත, එනම් මෙය kill-9 වේ. ඔවුන් එවැනි දේවල් එකිනෙකාට යවන්නේ නැත, ඔවුන් එවැනි දේවලට පමණක් ප්රතික්රියා කරයි, එනම් මෙය Postgres හි හදිසි නැවත ආරම්භ කිරීමකි. කවුද එව්වේ, මම දන්නේ නැහැ.

මම "අවසාන" විධානය දෙස බැලූ අතර, අප සමඟ මෙම සේවාදායකයට ලොග් වූ එක් අයෙක් මම දුටුවෙමි, නමුත් මම ප්‍රශ්නයක් ඇසීමට ලැජ්ජා විය. සමහර විට එය ඝාතනය -9 විය. මම ලොග් වල කිල් -9 දකිමි, මන්ද පෝස්ට්ග්‍රෙස් පවසන්නේ එය කිල් -9 ගත් බවයි, නමුත් මම එය ලඝු-සටහන් වල දුටුවේ නැත.

තව දුරටත් බැලූ විට, මම දුටුවේ පැට්‍රෝනි සෑහෙන වේලාවක් ලොගයට ලියා නැති බවයි - තත්පර 54 යි. අපි වේලා මුද්දර දෙකක් සංසන්දනය කළහොත්, තත්පර 54 ක් පමණ පණිවිඩ කිසිවක් නොතිබුණි.

තවද මෙම කාලය තුළ ස්වයංක්‍රීය ගොනුවක් විය. පැට්රෝනි නැවතත් මෙහි විශිෂ්ට කාර්යයක් කළා. අපේ පරණ ස්වාමියා සිටියේ නැත, ඔහුට යමක් සිදු විය. නව ස්වාමියා තෝරා ගැනීම ආරම්භ විය. මෙහි සෑම දෙයක්ම හොඳින් සිදු විය. අපගේ pgsql01 නව නායකයා වී ඇත.

අපට මාස්ටර් බවට පත් වූ අනුරුවක් තිබේ. ඒ වගේම දෙවැනි ප්‍රතිචාරයක් තියෙනවා. දෙවන අනුරුව සමඟ ගැටළු ඇති විය. ඇය නැවත සකස් කිරීමට උත්සාහ කළාය. මට තේරෙන පරිදි, ඇය recovery.conf වෙනස් කිරීමට උත්සාහ කළා, Postgres නැවත ආරම්භ කර නව මාස්ටර් වෙත සම්බන්ධ කරන්න. ඇය උත්සාහ කරන සෑම තත්පර 10 කට වරක් පණිවිඩ ලියයි, නමුත් ඇය සාර්ථක නොවේ.

මෙම උත්සාහයන් අතරතුර, ක්ෂණික වසා දැමීමේ සංඥාවක් පැරණි මාස්ටර් වෙත පැමිණේ. ස්වාමියා නැවත ආරම්භ කර ඇත. පැරණි මාස්ටර් නැවත පණගැන්වීමට යන නිසා ප්‍රතිසාධනය නතර වේ. එනම්, එය වසා දැමීමේ මාදිලියේ ඇති බැවින්, අනුරුව එයට සම්බන්ධ විය නොහැක.

යම් අවස්ථාවක, එය ක්‍රියාත්මක විය, නමුත් අනුකරණය ආරම්භ නොවීය.

මගේ එකම අනුමානය නම් recovery.conf හි පැරණි මාස්ටර් ලිපිනයක් තිබූ බවයි. නව මාස්ටර් පෙනී සිටි විට, දෙවන අනුරුව තවමත් පැරණි මාස්ටර් සමඟ සම්බන්ධ වීමට උත්සාහ කළේය.

Patroni දෙවන අනුරුව මත ආරම්භ වූ විට, නෝඩය ආරම්භ වූ නමුත් අනුකරණය කිරීමට නොහැකි විය. තවද අනුරූ ප්‍රමාදයක් ඇති වූ අතර එය මේ වගේ දෙයක් විය. එනම්, නෝඩ් තුනම ස්ථානයේ තිබූ නමුත් දෙවන නෝඩය පසුගාමී විය.

ඒ සමගම, ඔබ ලියා ඇති ලඝු-සටහන් දෙස බැලුවහොත්, ගනුදෙනු ලොග් වෙනස් වූ නිසා replication ආරම්භ කළ නොහැකි බව ඔබට පෙනෙනු ඇත. Recovery.conf හි නිශ්චිතව දක්වා ඇති, master විසින් පිරිනමනු ලබන එම ගනුදෙනු ලොග් අපගේ වත්මන් නෝඩයට නොගැලපේ.

අනික මෙතන මට වැරදුනා. අපි වැරදි මාස්ටර්ට සම්බන්ධ වන බවට මගේ උපකල්පනය පරීක්ෂා කිරීමට මට පැමිණ recovery.conf හි ඇති දේ බැලීමට සිදු විය. නමුත් පසුව මම මේ සමඟ කටයුතු කරමින් සිටි අතර එය මට සිදු නොවීය, නැතහොත් අනුරුව ප්‍රමාද වී ඇති බවත් නැවත පිරවිය යුතු බවත් මම දුටුවෙමි, එනම් මම කෙසේ හෝ නොසැලකිලිමත් ලෙස වැඩ කළෙමි. මෙය මගේ ඒකාබද්ධ විය.

මිනිත්තු 30 කට පසු, පරිපාලක දැනටමත් පැමිණ ඇත, එනම් මම අනුරුව මත Patroni නැවත ආරම්භ කළෙමි. මම දැනටමත් එය අවසන් කර ඇත, එය නැවත පිරවිය යුතු යැයි මම සිතුවෙමි. මම හිතුවා - මම Patroni නැවත ආරම්භ කරන්නම්, සමහර විට හොඳ දෙයක් සිදුවනු ඇත. ප්‍රතිසාධනය ආරම්භ විය. පදනම පවා විවෘත විය, එය සම්බන්ධතා පිළිගැනීමට සූදානම් විය.

අනුකරණය ආරම්භ කර ඇත. නමුත් මිනිත්තුවකට පසු, ගනුදෙනු ලොග් ඇයට සුදුසු නොවන බවට දෝෂයක් සමඟ ඇය වැටුණාය.

මම හිතුවා ආයෙත් පටන් ගන්න. මම නැවතත් Patroni නැවත ආරම්භ කළ අතර, මම Postgres නැවත ආරම්භ නොකළ නමුත්, දත්ත සමුදාය ඉන්ද්‍රජාලික ලෙස ආරම්භ කරනු ඇතැයි යන බලාපොරොත්තුවෙන් Patroni නැවත ආරම්භ කළෙමි.

අනුකරණය නැවත ආරම්භ විය, නමුත් ගනුදෙනු ලොගයේ ලකුණු වෙනස් විය, ඒවා පෙර ආරම්භක උත්සාහයට සමාන නොවේ. නැවත අනුවර්තනය වීම නතර විය. තවද පණිවිඩය දැනටමත් තරමක් වෙනස් විය. තවද එය මට එතරම් තොරතුරු නොවේ.

එවිට එය මට සිදුවේ - මම Postgres නැවත ආරම්භ කළහොත්, මෙම අවස්ථාවේදී මම ගනුදෙනු ලොගයේ ලක්ෂ්‍යය මඳක් ඉදිරියට ගෙනයාමට වත්මන් මාස්ටර් මත මුරපොලක් සාදන අතර එවිට ප්‍රතිසාධනය තවත් මොහොතකින් ආරම්භ වේ. ඊට අමතරව, අපට තවමත් WAL තොග තිබුණි.

මම Patroni නැවත ආරම්භ කළා, මාස්ටර් මත මුරපොලවල් කිහිපයක් කළා, එය විවෘත කරන විට අනුරුව මත නැවත ආරම්භ කිරීමේ ස්ථාන කිහිපයක් කළා. ඒ වගේම උදව් කළා. එය උදව් කළේ ඇයි සහ එය ක්‍රියාත්මක වන්නේ කෙසේද යන්න මම බොහෝ කාලයක් තිස්සේ සිතුවෙමි. සහ අනුරුව ආරම්භ විය. තවද අනුකරණය තවදුරටත් ඉරී ගියේ නැත.

මට එවැනි ගැටලුවක් වඩාත් අද්භූත එකක් වන අතර, එහි ඇත්ත වශයෙන්ම සිදුවූයේ කුමක්ද යන්න පිළිබඳව මම තවමත් ප්‍රහේලිකාවකි.

මෙහි ඇඟවුම් මොනවාද? පැට්‍රෝනිට අදහස් කළ පරිදි සහ කිසිදු දෝෂයකින් තොරව ක්‍රියා කළ හැකිය. නමුත් ඒ සමඟම, මෙය අප සමඟ සෑම දෙයක්ම හොඳින් පවතින බවට 100% සහතිකයක් නොවේ. අනුරුව ආරම්භ විය හැක, නමුත් එය අර්ධ-වැඩ කරන තත්වයක විය හැකි අතර, පැරණි දත්ත පවතිනු ඇති නිසා යෙදුමට එවැනි අනුරුවක් සමඟ වැඩ කළ නොහැක.

ගොනු කරන්නාට පසුව, ඔබ සෑම විටම පොකුර සමඟ සියල්ල පිළිවෙලට තිබේදැයි පරීක්ෂා කළ යුතුය, එනම් අවශ්‍ය අනුරූ සංඛ්‍යාව තිබේ, අනුරූ ප්‍රමාදයක් නොමැත.

අපි මෙම ගැටළු හරහා යන විට, මම නිර්දේශ ඉදිරිපත් කරමි. මම ඒවා ස්ලයිඩ දෙකකට ඒකාබද්ධ කිරීමට උත්සාහ කළෙමි. බොහෝ විට, සියලුම කථා විනිවිදක දෙකකට ඒකාබද්ධ කර පමණක් පැවසිය හැකිය.

ඔබ Patroni භාවිතා කරන විට, ඔබට අධීක්ෂණය තිබිය යුතුය. ස්වයංක්‍රීය ගොනුවක් සිදු වූ විට ඔබ සැම විටම දැන සිටිය යුතුය, මන්ද ඔබට ස්වයංක්‍රීය ගොනුවක් ඇති බව ඔබ නොදන්නේ නම්, ඔබට පොකුර පාලනය කළ නොහැක. ඒ වගේම නරකයි.

එක් එක් ගොනු කරන්නාට පසුව, අපි සෑම විටම පොකුර අතින් පරීක්ෂා කළ යුතුය. අප සතුව සෑම විටම යාවත්කාලීන සංඛ්‍යාවක් ඇති බවට සහතික විය යුතුය, අනුරූ ප්‍රමාදයක් නොමැත, ප්‍රවාහ අනුවර්තනයට අදාළ ලඝු-සටහන් වල දෝෂ නොමැත, Patroni සමඟ, DCS පද්ධතිය සමඟ.

ස්වයංක්රීයකරණය සාර්ථකව ක්රියා කළ හැකිය, Patroni ඉතා හොඳ මෙවලමක් වේ. එය වැඩ කළ හැකි නමුත්, මෙය පොකුර අපේක්ෂිත තත්වයට ගෙන එන්නේ නැත. ඒවගේම අපි ඒ ගැන සොයා බැලුවේ නැත්නම් අපි අමාරුවේ වැටෙනවා.

අනික Patroni රිදී උණ්ඩයක් නෙවෙයි. Postgres ක්‍රියා කරන්නේ කෙසේද, අනුකරණය ක්‍රියා කරන්නේ කෙසේද සහ Patroni Postgres සමඟ ක්‍රියා කරන්නේ කෙසේද සහ නෝඩ් අතර සන්නිවේදනය සපයන්නේ කෙසේද යන්න අප තවමත් තේරුම් ගත යුතුය. ඔබේ දෑත් සමඟ ගැටලු විසඳා ගැනීමට හැකි වන පරිදි මෙය අවශ්ය වේ.

රෝග විනිශ්චය කිරීමේ ගැටලුවට මා ප්‍රවේශ වන්නේ කෙසේද? අපි විවිධ සේවාදායකයින් සමඟ වැඩ කරන අතර කිසිවෙකුට ELK තොගයක් නොමැති අතර කොන්සෝල 6 ක් සහ ටැබ් 2 ක් විවෘත කිරීමෙන් අපට ලඝු-සටහන් නිරාකරණය කළ යුතුය. එක් ටැබ් එකක, මේවා එක් එක් නෝඩය සඳහා වන Patroni ලොග් වේ, අනෙක් ටැබ් එකේ, මේවා කොන්සල් ලොග් හෝ අවශ්‍ය නම් Postgres වේ. මෙය රෝග විනිශ්චය කිරීම ඉතා අපහසුය.

මා ගෙන ඇති ප්‍රවේශයන් මොනවාද? පළමුව, මම නිතරම බලන්නේ ගොනුකරු පැමිණි විටය. අනික මට මේක දිය පොදක්. ගොනු කරන්නාට පෙර, ගොනු කිරීමේදී සහ ගොනු කරන්නාට පසුව සිදු වූ දේ මම බලමි. ගොනුවට ලකුණු දෙකක් ඇත: මෙය ආරම්භක සහ අවසන් කාලයයි.

ඊළඟට, මම ගොනු කරන්නාට පෙර සිදුවීම් සඳහා ලොගයන් දෙස බලමි, එය ගොනු කරන්නාට පෙර, එනම් ගොනු කරන්නා සිදු වීමට හේතු සොයමි.

තවද මෙය සිදු වූ දේ සහ අනාගතයේදී කළ හැකි දේ අවබෝධ කර ගැනීමේ පින්තූරයක් ලබා දෙයි, එවිට එවැනි තත්වයන් ඇති නොවන පරිදි (සහ එහි ප්රතිඵලයක් වශයෙන්, ගොනු කරන්නෙකු නොමැත).

සහ අපි සාමාන්‍යයෙන් බලන්නේ කොහේද? මම බලන්නේ:

• පළමුව, Patroni ලඝු-සටහන් වෙත.
• ඊළඟට, මම Patroni ලඝු-සටහන් වල සොයාගත් දේ මත පදනම්ව Postgres ලඝු-සටහන් හෝ DCS ලොග් දෙස බලමි.
• තවද පද්ධති ලඝු-සටහන් සමහර විට ගොනු කරන්නාට හේතුව කුමක්ද යන්න පිළිබඳ අවබෝධයක් ලබා දෙයි.

මට Patroni ගැන හැඟෙන්නේ කෙසේද? මට පැට්‍රෝනි සමඟ ඉතා හොඳ සම්බන්ධයක් තිබෙනවා. මගේ මතය අනුව, අද ඇති හොඳම දේ මෙයයි. මම තවත් බොහෝ නිෂ්පාදන දනිමි. ඒවා නම් Stolon, Repmgr, Pg_auto_failover, PAF. මෙවලම් 4 ක්. මම ඒවා සියල්ලම උත්සාහ කළා. Patroni මගේ ප්රියතම.

ඔවුන් මගෙන් ඇසුවොත්: "මම Patroni නිර්දේශ කරනවාද?". මම Patroni කැමති නිසා මම ඔව් කියන්නම්. ඒ වගේම මම හිතන්නේ මම එය පිසීමට ඉගෙන ගත්තා.

මා සඳහන් කළ ගැටළු වලට අමතරව Patroni සමඟ ඇති වෙනත් ගැටළු මොනවාදැයි බැලීමට ඔබ කැමති නම්, ඔබට සැමවිටම පිටුව පරීක්ෂා කළ හැකිය ගැටලු GitHub මත. එහි විවිධ කතාන්දර ඇති අතර රසවත් කරුණු රාශියක් එහි සාකච්ඡා කෙරේ. එහි ප්‍රතිඵලයක් වශයෙන්, සමහර දෝෂ හඳුන්වා දී විසඳා ඇත, එනම් මෙය රසවත් කියවීමකි.

මිනිසුන් තම පාදයට වෙඩි තබා ගැනීම ගැන රසවත් කතා කිහිපයක් තිබේ. ඉතා තොරතුරු සහිතයි. එසේ කිරීම අනවශ්‍ය බව ඔබ කියවා තේරුම් ගන්න. මම මටම ටික් ගැහුවා.

මෙම ව්‍යාපෘතිය සංවර්ධනය කිරීම ගැන මම Zalando ට, එනම් Alexander Kukushkin සහ Alexey Klyukin ට විශාල ස්තූතියක් කියන්නට කැමැත්තෙමි. Aleksey Klyukin යනු සම කර්තෘවරුන්ගෙන් කෙනෙකි, ඔහු තවදුරටත් Zalando හි වැඩ කරන්නේ නැත, නමුත් මෙම නිෂ්පාදනය සමඟ වැඩ කිරීමට පටන් ගත් පුද්ගලයන් දෙදෙනෙක්.

ඒ වගේම මම හිතන්නේ Patroni කියන්නේ හරිම අපූරු දෙයක්. ඇය සිටීම ගැන මම සතුටු වෙමි, එය ඇය සමඟ සිත්ගන්නා සුළුය. ඒ වගේම Patroni ට පැච් ලියන සියලුම දායකයින්ට ගොඩක් ස්තුතියි. වයසත් සමඟ පැට්‍රෝනි වඩාත් පරිණත, සිසිල් සහ කාර්යක්ෂම වනු ඇතැයි මම බලාපොරොත්තු වෙමි. එය දැනටමත් ක්‍රියාත්මකයි, නමුත් එය තවත් හොඳ වනු ඇතැයි මම බලාපොරොත්තු වෙමි. එමනිසා, ඔබ Patroni භාවිතා කිරීමට අදහස් කරන්නේ නම්, බිය නොවන්න. මෙය හොඳ විසඳුමක්, එය ක්රියාත්මක කර භාවිතා කළ හැකිය.

එච්චරයි. ඔබට ප්‍රශ්න ඇත්නම් අසන්න.

ඔබගේ ප්රශ්න

වාර්තාවට ස්තූතියි! ගොනුකරුවෙකුගෙන් පසුව ඔබ තවමත් එහි ඉතා පරිස්සමින් බැලිය යුතු නම්, අපට ස්වයංක්‍රීය ගොනුකරුවෙකු අවශ්‍ය වන්නේ ඇයි?

මොකද ඒක අලුත් දේවල්. අපි ඇය සමඟ සිටින්නේ අවුරුද්දක් පමණි. ආරක්ෂිතව සිටීම වඩා හොඳය. අපට අවශ්‍ය වන්නේ ඇතුළට පැමිණ සියල්ල සැබවින්ම සිදුවිය යුතු ආකාරයට ක්‍රියාත්මක වන බව දැකීමටයි. මෙය වැඩිහිටි අවිශ්වාසයේ මට්ටමයි - දෙවරක් පරීක්ෂා කර බැලීම වඩා හොඳය.

උදාහරණයක් විදියට අපි උදේ ගිහින් බැලුවා නේද?

උදෑසන නොවේ, අපි සාමාන්‍යයෙන් ස්වයංක්‍රීය ගොනුව ගැන වහාම ඉගෙන ගනිමු. අපට දැනුම්දීම් ලැබේ, ස්වයංක්‍රීය ගොනුවක් සිදුවී ඇති බව අපට පෙනේ. අපි වහාම පාහේ ගොස් බලන්නෙමු. නමුත් මේ සියලුම චෙක්පත් අධීක්ෂණ මට්ටමට ගෙන ආ යුතුයි. ඔබ REST API හරහා Patroni වෙත පිවිසෙන්නේ නම්, ඉතිහාසයක් ඇත. ඉතිහාසය අනුව ඔබට ගොනුකරු සිදු වූ කාල මුද්දර දැකිය හැකිය. මේ මත පදනම්ව, නිරීක්ෂණය කළ හැකිය. ඔබට ඉතිහාසය බලන්න පුළුවන්, සිදුවීම් කීයක් තිබුණාද කියලා. අපට තවත් සිදුවීම් තිබේ නම්, ස්වයංක්‍රීය ගොනුවක් සිදුවී ඇත. ගිහින් බලන්න පුළුවන්. නැතහොත් අපගේ අධීක්ෂණ ස්වයංක්‍රීයකරණය පරීක්ෂා කළේ අප සතුව සියලුම අනුරූ ඇති බවත්, ප්‍රමාදයක් නොමැති බවත් සියල්ල හොඳින් බවත්ය.

ස්තුතියි!

නියම කතාවට බොහොම ස්තුතියි! අපි DCS පොකුර පෝස්ට්ග්‍රෙස් පොකුරෙන් ඈත කොතැනකට හෝ ගෙන ගියහොත්, මෙම පොකුරද වරින් වර සේවා කළ යුතුද? DCS පොකුරේ සමහර කෑලි ක්‍රියාවිරහිත කිරීමට අවශ්‍ය හොඳම භාවිතයන් මොනවාද, ඒවා සමඟ කළ යුතු දෙයක්, යනාදිය. මෙම සම්පූර්ණ ව්යුහය පවතින්නේ කෙසේද? අනික මේ දේවල් කරන්නේ කොහොමද?

එක් සමාගමක් සඳහා, එක් සංරචකයක් හෝ සංරචක කිහිපයක් අසමත් වුවහොත් කුමක් සිදුවේද යන්න ගැටළු න්‍යාසයක් සෑදීම අවශ්‍ය විය. මෙම න්‍යාසයට අනුව, අපි අනුපිළිවෙලින් සියලුම සංරචක හරහා ගොස් මෙම සංරචක අසාර්ථක වූ විට අවස්ථා ගොඩනඟමු. ඒ අනුව, එක් එක් අසාර්ථක අවස්ථාව සඳහා, ඔබට යථා තත්ත්වයට පත් කිරීම සඳහා ක්රියාකාරී සැලැස්මක් තිබිය හැකිය. DCS සම්බන්ධයෙන් ගත් කල, එය සම්මත යටිතල ව්‍යුහයේ කොටසක් ලෙස පැමිණේ. තවද පරිපාලක විසින් එය පරිපාලනය කරන අතර, අපි දැනටමත් එය පරිපාලනය කරන පරිපාලකයින් සහ හදිසි අනතුරු වලදී එය නිවැරදි කිරීමට ඔවුන්ට ඇති හැකියාව මත රඳා සිටිමු. කිසිසේත්ම DCS නොමැති නම්, අපි එය යොදවන්නෙමු, නමුත් ඒ සමඟම අපි එය විශේෂයෙන් අධීක්ෂණය නොකරමු, මන්ද යටිතල පහසුකම් සඳහා අප වගකිව යුතු නොවන නමුත් නිරීක්ෂණය කරන්නේ කෙසේද සහ කුමක් ද යන්න පිළිබඳව අපි නිර්දේශ ලබා දෙන්නෙමු.

එනම්, සත්කාරකයින් සමඟ යමක් කිරීමට පෙර මට පැට්‍රෝනි අක්‍රිය කිරීමට, ගොනුකරු අක්‍රීය කිරීමට, සියල්ල අක්‍රීය කිරීමට අවශ්‍ය බව මා නිවැරදිව තේරුම් ගත්තාද?

එය DCS පොකුරේ ඇති nodes කීයක් මත රඳා පවතී. බොහෝ නෝඩ් තිබේ නම් සහ අපි එක් නෝඩ් එකක් පමණක් අක්‍රිය කරන්නේ නම් (අනුරුව), එවිට පොකුර ගණපූරණයක් පවත්වා ගනී. සහ Patroni ක්රියාත්මක වේ. තවද කිසිවක් අවුලුවනු නොලැබේ. අපට වැඩි නෝඩ් වලට බලපාන සංකීර්ණ මෙහෙයුම් කිහිපයක් තිබේ නම්, ඒවා නොමැතිකම ගණපූරණය විනාශ කළ හැකිය, එවිට - ඔව්, පැට්‍රෝනිට විරාමයක් තැබීම අර්ථවත් විය හැකිය. එයට අනුරූප විධානයක් ඇත - patronictl pause, patronictl resume. අපි නවත්වනවා පමණක් වන අතර එම අවස්ථාවේ ස්වයංක්‍රීය ගොනුව ක්‍රියා නොකරයි. අපි DCS පොකුරේ නඩත්තු කරන්නෙමු, පසුව අපි විරාමය ඉවත් කර දිගටම ජීවත් වෙමු.

බොහොම ස්තූතියි!

ඔබගේ වාර්තාවට බොහොම ස්තුතියි! දත්ත නැතිවීම ගැන නිෂ්පාදන කණ්ඩායමට හැඟෙන්නේ කෙසේද?

නිෂ්පාදන කණ්ඩායම් ගණන් නොගන්නා අතර කණ්ඩායම් නායකයින් කනස්සල්ලට පත්ව සිටිති.

එහි ඇති සහතික මොනවාද?

ඇපකර ඉතා අපහසුයි. ඇලෙක්සැන්ඩර් කුකුෂ්කින් "RPO සහ RTO ගණනය කරන්නේ කෙසේද" යන වාර්තාවක් ඇත, එනම් ප්රතිසාධන කාලය සහ අපට කොපමණ දත්ත අහිමි විය හැකිද යන්නයි. මම හිතන්නේ අපි මේ විනිවිදක සොයාගෙන ඒවා අධ්‍යයනය කළ යුතුයි. මට මතක හැටියට මේ දේවල් ගණනය කරන්නේ කොහොමද කියලා නිශ්චිත පියවර තියෙනවා. අපට කොපමණ ගනුදෙනු අහිමි විය හැකිද, අපට කොපමණ දත්ත අහිමි විය හැකිද. විකල්පයක් ලෙස, අපට Patroni මට්ටමින් සමමුහුර්ත අනුවර්තනය භාවිතා කළ හැකිය, නමුත් මෙය දෙබිඩි කඩුවකි: අපට දත්ත විශ්වසනීයත්වය ඇත, නැතහොත් අපට වේගය නැති වේ. සමමුහුර්ත පිටපත් කිරීමක් ඇත, නමුත් එය දත්ත නැතිවීමෙන් 100% ආරක්ෂාවක් සහතික නොකරයි.

ඇලෙක්සි, විශිෂ්ට වාර්තාවට ස්තූතියි! ශුන්‍ය මට්ටමේ ආරක්ෂාව සඳහා Patroni භාවිතා කිරීමේ අත්දැකීමක් තිබේද? එනම්, සමමුහුර්ත ස්ථාවරය සමඟ ඒකාබද්ධව? මෙය පළමු ප්‍රශ්නයයි. සහ දෙවන ප්රශ්නය. ඔබ විවිධ විසඳුම් භාවිතා කර ඇත. අපි Repmgr භාවිතා කළෙමු, නමුත් ස්වයංක්‍රීය ගොනුවක් නොමැතිව, දැන් අපි ස්වයංක්‍රීය ගොනු ඇතුළත් කිරීමට සැලසුම් කරමු. අපි විකල්ප විසඳුමක් ලෙස Patroni සලකමු. Repmgr හා සසඳන විට ඔබට වාසි ලෙස කිව හැක්කේ කුමක්ද?

පළමු ප්‍රශ්නය වූයේ සමමුහුර්ත අනුරූ ගැන ය. කිසිවෙකු මෙහි සමමුහුර්ත අනුවර්තනය භාවිතා නොකරයි, මන්ද සෑම කෙනෙකුම බියට පත් වී ඇත (සේවාදායකයින් කිහිප දෙනෙකු දැනටමත් එය භාවිතා කරයි, ප්‍රතිපත්තිමය වශයෙන්, කාර්ය සාධන ගැටළු ඔවුන් දුටුවේ නැත - කථානායක සටහන) නමුත් සමමුහුර්ත අනුවර්තන පොකුරක අවම වශයෙන් නෝඩ් තුනක්වත් තිබිය යුතු බවට අපි රීතියක් ගොඩනඟා ගෙන ඇත, මන්ද අපට නෝඩ් දෙකක් තිබේ නම් සහ ප්‍රධාන හෝ අනුරුව අසමත් වුවහොත්, පැට්‍රෝනි මෙම නෝඩය ස්වාධීන ප්‍රකාරයට මාරු කරයි, එවිට යෙදුම දිගටම පවතී. කාර්යය. මෙම අවස්ථාවේදී, දත්ත අහිමි වීමේ අවදානමක් ඇත.

දෙවන ප්‍රශ්නය සම්බන්ධයෙන්, අපි Repmgr භාවිතා කර ඇති අතර ඓතිහාසික හේතූන් මත සමහර සේවාදායකයින් සමඟ තවමත් කරන්නෙමු. කුමක් කිව හැකිද? Patroni ස්වයංක්‍රීය ගොනුවක් සමඟ පැමිණේ, Repmgr සක්‍රිය කළ යුතු අමතර විශේෂාංගයක් ලෙස ස්වයංක්‍රීය ගොනුවක් සමඟ පැමිණේ. අපි එක් එක් node මත Repmgr deemon ධාවනය කළ යුතු අතර පසුව අපට ස්වයංක්‍රීය ගොනුව වින්‍යාසගත කළ හැකිය.

Repmgr Postgres නෝඩ් ජීවමාන දැයි පරීක්ෂා කරයි. Repmgr ක්‍රියාවලීන් එකිනෙකාගේ පැවැත්ම පරීක්ෂා කරයි, මෙය ඉතා කාර්යක්ෂම ප්‍රවේශයක් නොවේ. විශාල Repmgr පොකුරක් කුඩා ඒවා කිහිපයකට කඩා වැටී දිගටම වැඩ කළ හැකි ජාල හුදකලා වීමේ සංකීර්ණ අවස්ථා තිබිය හැක. මම දිගු කලක් Repmgr අනුගමනය කළේ නැත, සමහර විට එය නිවැරදි කර ඇත ... නැතහොත් සමහර විට නොවේ. නමුත් Stolon, Patroni කරන පරිදි DCS හි පොකුරේ තත්ත්වය පිළිබඳ තොරතුරු ඉවත් කිරීම වඩාත් ශක්ය විකල්පය වේ.

ඇලෙක්සි, මට ප්‍රශ්නයක් තියෙනවා, සමහරවිට ලාමක එකක්. පළමු උදාහරණ වලින් එකක, ඔබ DCS දේශීය යන්ත්‍රයෙන් දුරස්ථ ධාරකයකට ගෙන ගියා. ජාලය යනු තමන්ගේම ලක්ෂණ ඇති දෙයක් බව අපි තේරුම් ගනිමු, එය තනිවම ජීවත් වේ. යම් හේතුවක් නිසා DCS පොකුර ලබාගත නොහැකි වුවහොත් කුමක් සිදුවේද? මම හේතු නොකියමි, ඒවායින් බොහොමයක් තිබිය හැකිය: ජාලකරුවන්ගේ වංක අත්වල සිට සැබෑ ගැටළු දක්වා.

මම එය ශබ්ද නඟා කීවේ නැත, නමුත් ගණපූරණයක් සපුරාලීම සඳහා DCS පොකුර ද අසාර්ථක විය යුතුය, එනම් එය ඔත්තේ නෝඩ් සංඛ්‍යාවක් විය යුතුය. DCS පොකුර ලබාගත නොහැකි වුවහොත් හෝ ගණපූරණයක් සපුරාගත නොහැකි වුවහොත්, එනම් යම් ආකාරයක ජාල බෙදීමක් හෝ නෝඩ් අසාර්ථක වීමක් සිදු වුවහොත් කුමක් සිදුවේද? මෙම අවස්ථාවේදී, Patroni පොකුර කියවීමට පමණක් මාදිලියට යයි. Patroni පොකුරට පොකුරේ තත්ත්වය සහ කුමක් කළ යුතුද යන්න තීරණය කළ නොහැක. එයට DCS සම්බන්ධ කර නව පොකුරු තත්ත්වය එහි ගබඩා කළ නොහැක, එබැවින් සම්පූර්ණ පොකුර කියවීමට පමණක් යයි. ක්‍රියාකරුගේ අතින් මැදිහත් වීම හෝ DCS යථා තත්ත්වයට පත් වන තෙක් බලා සිටී.

දළ වශයෙන්, DCS අපට පදනම මෙන්ම වැදගත් සේවාවක් බවට පත් වෙයිද?

ඔව් ඔව්. බොහෝ නවීන සමාගම්වල, Service Discovery යටිතල පහසුකම්වල අනිවාර්ය අංගයකි. යටිතල පහසුකම්වල දත්ත සමුදායක් ඇති වීමටත් පෙර එය ක්‍රියාත්මක වෙමින් පවතී. සාපේක්ෂ වශයෙන් කථා කරන විට, යටිතල පහසුකම් දියත් කරන ලදී, DC හි යොදවා ඇත, සහ අපි වහාම Service Discovery ඇත. එය කොන්සල් නම්, එය මත DNS ගොඩනගා ගත හැකිය. මෙය Etcd නම්, Kubernetes පොකුරෙන් කොටසක් තිබිය හැකි අතර, එහි අනෙක් සියල්ල යොදවනු ලැබේ. Service Discovery දැනටමත් නවීන යටිතල පහසුකම්වල අනිවාර්ය අංගයක් බව මට පෙනේ. තවද ඔවුන් දත්ත සමුදායන් ගැන වඩා බොහෝ කලකට පෙර ඒ ගැන සිතති.

ස්තුතියි!

මූලාශ්රය: www.habr.com