Citymobil හිදී අපි MySQL දත්ත ගබඩාවක් අපගේ ප්‍රධාන ස්ථීර දත්ත ගබඩාව ලෙස භාවිතා කරමු. විවිධ සේවා සහ අරමුණු සඳහා අපට දත්ත සමුදා පොකුරු කිහිපයක් තිබේ.

ස්වාමියාගේ නිරන්තර ලබා ගැනීම සමස්ත පද්ධතියේ සහ එහි තනි කොටස්වල කාර්ය සාධනය පිළිබඳ තීරනාත්මක දර්ශකයකි. ප්‍රධාන අසමත් වීමකදී ස්වයංක්‍රීය පොකුරු ප්‍රතිසාධනය සිද්ධි ප්‍රතිචාර කාලය සහ පද්ධතියේ අක්‍රිය කාලය බෙහෙවින් අඩු කරයි. මෙම ලිපියෙන්, මම MySQL පොකුරක් සඳහා ඉහළ ලබා ගත හැකි (HA) නිර්මාණයක් දෙස බලමි. MySQL Orchestrator සහ අතථ්‍ය IP ලිපින (VIP).

VIP මත පදනම් වූ HA විසඳුම

පළමුව, අපගේ දත්ත ගබඩා කිරීමේ පද්ධතිය කුමක්දැයි මම ඔබට කෙටියෙන් කියමි.

අපි එක් ලිවීමට ප්‍රවේශ විය හැකි මාස්ටර් සහ බහු කියවීමට පමණක් අනුරූ සහිත සම්භාව්‍ය අනුරූ ක්‍රමයක් භාවිත කරමු. පොකුරක අතරමැදි මාස්ටර් අඩංගු විය හැක - නෝඩයක් අනුරුවක් සහ අනෙක් අයට ප්‍රධාන වේ. සේවාලාභීන් HAProxy හරහා අනුපිටපත් වෙත ප්‍රවේශ වන අතර, එය ඒකාකාරව පැටවීම බෙදා හැරීමට සහ පහසුවෙන් පරිමාණය කිරීමට ඉඩ සලසයි. HAProxy භාවිතය ඓතිහාසික හේතූන් නිසා වන අතර, අපි දැනට ProxySQL වෙත සංක්‍රමණය වීමේ ක්‍රියාවලියක යෙදී සිටිමු.

මත පදනම්ව අර්ධ සමමුහුර්ත ආකාරයෙන් අනුකරණය සිදු කරනු ලැබේ GTID. මෙයින් අදහස් කරන්නේ ගනුදෙනුවක් සාර්ථක යැයි සැලකීමට පෙර අවම වශයෙන් එක් අනුපිටපතක් ලොග් විය යුතු බවයි. ප්‍රධාන නෝඩය අසාර්ථක වූ විට කාර්ය සාධනය සහ දත්ත ආරක්ෂාව අතර ප්‍රශස්ත සමතුලිතතාවයක් මෙම අනුකරණ මාදිලිය සපයයි. මූලික වශයෙන් සියලුම වෙනස්කම් මාස්ටර් සිට අනුපිටපත් භාවිතා කරමින් මාරු කරනු ලැබේ Row Based Replication (RBR), නමුත් සමහර නෝඩ් තිබිය හැක mixed binlog format.

වාද්‍ය වෘන්දය වරින් වර පොකුරු ස්ථලකයේ තත්වය යාවත්කාලීන කරයි, ලැබුණු තොරතුරු විශ්ලේෂණය කරයි, ගැටළු ඇති වුවහොත් එය ස්වයංක්‍රීය ප්‍රතිසාධන ක්‍රියාවලියක් දියත් කළ හැකිය. එය විවිධ ආකාරවලින් ක්‍රියාත්මක කළ හැකි බැවින්, ක්‍රියා පටිපාටිය සඳහාම සංවර්ධකයා වගකිව යුතුය: VIP, DNS මත පදනම්ව, සේවා සොයාගැනීම් සේවා හෝ ස්වයං-ලිඛිත යාන්ත්‍රණ භාවිතා කිරීම.

මාස්ටර් අසමත් වුවහොත් එය ප්‍රතිස්ථාපනය කිරීමට එක් සරල ක්‍රමයක් නම් පාවෙන VIP ලිපින භාවිතා කිරීමයි.

ඉදිරියට යාමට පෙර මෙම විසඳුම ගැන ඔබ දැනගත යුතු දේ:

• VIP යනු නිශ්චිත භෞතික ජාල අතුරු මුහුණතක් සමඟ සම්බන්ධ නොවන IP ලිපිනයකි. නෝඩයක් අසමත් වුවහොත් හෝ නියමිත නඩත්තුව අතරතුර, අපට අවම අක්‍රීය කාලයකින් VIP වෙනත් සම්පතකට මාරු කළ හැකිය.
• අතථ්‍ය IP ලිපිනයක් නිදහස් කිරීම සහ නිකුත් කිරීම ලාභදායී සහ වේගවත් මෙහෙයුමකි.
• VIP සමඟ වැඩ කිරීමට, ඔබට SSH හරහා සේවාදායකයට ප්‍රවේශය අවශ්‍ය වේ, නැතහොත් විශේෂ උපයෝගිතා භාවිතා කිරීම, උදාහරණයක් ලෙස, keepalived.

අපගේ විශාරදයා සමඟ ඇති විය හැකි ගැටළු දෙස බලමු සහ ස්වයංක්‍රීය ප්‍රතිසාධන යාන්ත්‍රණය ක්‍රියා කළ යුතු ආකාරය සිතා බලමු.

මාස්ටර් වෙත ජාල සම්බන්ධතාව අතුරුදහන් වී ඇත, නැතහොත් දෘඪාංග මට්ටමින් ගැටලුවක් මතු වී ඇති අතර, සේවාදායකය නොමැත

1. වාද්‍ය වෘන්දය පොකුරු ස්ථාන විද්‍යාව යාවත්කාලීන කරයි, සෑම අනුරුවක්ම මාස්ටර් නොමැති බව වාර්තා කරයි. වාද්‍ය වෘන්දය නව ස්වාමියාගේ භූමිකාව සඳහා සුදුසු අනුරුවක් තෝරා ගැනීමේ ක්‍රියාවලිය ආරම්භ කර ප්‍රකෘතිමත් වීම ආරම්භ කරයි.
2. අපි උත්සාහ කරන්නේ VIP පැරණි මාස්ටර්ගෙන් ඉවත් කිරීමටයි - සාර්ථක නොවී.
3. අනුරුව මාස්ටර්ගේ භූමිකාවට මාරු වේ. ස්ථලකය නැවත ගොඩනඟමින් පවතී.
4. VIP සමඟ නව ජාල අතුරු මුහුණතක් එක් කිරීම. ප්‍රභූව ඉවත් කිරීමට නොහැකි වූ නිසා, අපි පසුබිමෙන් වරින් වර ඉල්ලීමක් යැවීමට පටන් ගනිමු නොමිලේ ARP. මෙම ආකාරයේ ඉල්ලීම්/ප්‍රතිචාර මඟින් සම්බන්ධිත ස්විචවල IP සහ MAC ලිපින සිතියම්ගත කිරීමේ වගුව යාවත්කාලීන කිරීමට ඔබට ඉඩ සලසයි, එමඟින් අපගේ VIP මාරු වී ඇති බව ඔබට දන්වයි. මෙය සම්භාවිතාව අවම කරයි split brain පැරණි ස්වාමියා ආපසු එන විට.
5. සියලුම නව සම්බන්ධතා වහාම නව මාස්ටර් වෙත හරවා යවනු ලැබේ. පැරණි සම්බන්ධතා අසාර්ථක වන අතර දත්ත සමුදායට නැවත නැවත ඇමතුම් යෙදුම් මට්ටමින් සිදු කෙරේ.

සේවාදායකය සාමාන්‍ය ආකාරයෙන් ක්‍රියාත්මක වේ, DBMS මට්ටමේදී අසාර්ථක වීමක් සිදු විය

ඇල්ගොරිතම පෙර නඩුවට සමාන වේ: ස්ථලකය යාවත්කාලීන කිරීම සහ ප්රතිසාධන ක්රියාවලිය ආරම්භ කිරීම. සේවාදායකය පවතින බැවින්, අපි පැරණි මාස්ටර් මත VIP සාර්ථකව මුදාහරිමු, එය නව එකක් වෙත මාරු කර ARP ඉල්ලීම් කිහිපයක් යවන්නෙමු. පැරණි ස්වාමියාගේ හැකි ප්‍රතිලාභය නැවත ගොඩනඟන ලද පොකුරට සහ යෙදුමේ ක්‍රියාකාරිත්වයට බලපාන්නේ නැත.

වෙනත් ගැටළු

අනුපිටපත් හෝ අතරමැදි මාස්ටර් අසමත් වීම මෙහෙයවන්නේ නැත ස්වයංක්‍රීය ක්‍රියාවන්ට සහ අතින් මැදිහත්වීමක් අවශ්‍ය වේ.

අතථ්‍ය ජාල අතුරුමුහුණතක් සෑම විටම තාවකාලිකව එකතු වේ, එනම්, සේවාදායකය නැවත ආරම්භ කිරීමෙන් පසුව, VIP ස්වයංක්‍රීයව පවරනු නොලැබේ. සෑම දත්ත සමුදා අවස්ථාවක්ම පෙරනිමියෙන් කියවීමට-පමණි ආකාරයෙන් ආරම්භ වේ, වාද්‍ය වෘන්දය ස්වයංක්‍රීයව නව මාස්ටර් ලිවීමට මාරු කර ස්ථාපනය කිරීමට උත්සාහ කරයි read only පැරණි ස්වාමියා මත. මෙම ක්රියාවන් සම්භාවිතාව අඩු කිරීම අරමුණු කර ගෙන ඇත split brain.

ප්‍රතිසාධන ක්‍රියාවලියේදී ගැටළු මතු විය හැකි අතර, සම්මත අධීක්ෂණ මෙවලම් වලට අමතරව වාද්‍ය වෘන්දය UI හරහාද දැනුම් දිය යුතුය. අපි මෙම විශේෂාංගය එක් කිරීමෙන් REST API පුළුල් කර ඇත (PR දැනට සමාලෝචනය කෙරේ).

HA විසඳුමේ සාමාන්ය රූප සටහන පහත දැක්වේ.

නව ස්වාමියා තෝරා ගැනීම

වාද්‍ය වෘන්දය ප්‍රමාණවත් තරම් බුද්ධිමත් වන අතර තෝරා ගැනීමට උත්සාහ කරයි වඩාත්ම සුදුසු අනුරුව පහත සඳහන් නිර්ණායක අනුව නව මාස්ටර් ලෙස:

• අනුරුව ස්වාමියාට වඩා පසුගාමී ය;
• මාස්ටර් සහ අනුරුවෙහි MySQL අනුවාදය;
• අනුකරණ වර්ගය (RBR, SBR හෝ මිශ්ර);
• එකම හෝ විවිධ දත්ත මධ්‍යස්ථානවල පිහිටීම;
• ලබා ගත හැකිය errant GTID - අනුරුව මත සිදු කරන ලද සහ මාස්ටර් මත නොමැති ගනුදෙනු;
• අභිරුචි තේරීමේ නීති ද සැලකිල්ලට ගනී.

සෑම ඉඟියක්ම මාස්ටර් සඳහා සුදුසු අපේක්ෂකයෙකු නොවේ. උදාහරණයක් ලෙස, දත්ත උපස්ථ කිරීමට අනුරුවක් භාවිතා කළ හැක, නැතහොත් සේවාදායකයට දුර්වල දෘඪාංග වින්‍යාසයක් ඇත. වාද්‍ය වෘන්දය සහයෝගය දක්වයි ඔබට ඔබගේ අපේක්ෂක තේරීම් මනාපයන් වඩාත් කැමති සිට නොසලකා හැර රිසිකරණය කළ හැකි අත්පොත රීති.

ප්‍රතිචාර සහ ප්‍රතිසාධන කාලය

සිදුවීමක් සිදු වූ විට, පද්ධතියේ අක්‍රිය කාලය අවම කිරීම වැදගත් වේ, එබැවින් වාද්‍ය වෘන්දය මගින් පොකුරු ස්ථලකය නිර්මාණය කිරීමට සහ යාවත්කාලීන කිරීමට බලපාන MySQL පරාමිතීන් සලකා බලමු:

• slave_net_timeout — සම්බන්ධතාවය නැති වී නැවත සම්බන්ධ වී ඇති බව හඳුනා ගැනීමට පෙර අනුරුව නව දත්ත හෝ හෘද ස්පන්දන සංඥාවක් ස්වාමියාගෙන් ලැබෙන තෙක් බලා සිටින තත්පර ගණන. අගය අඩු වන තරමට අනුරුවට ස්වාමියා සමඟ සන්නිවේදනය කැඩී ඇති බව තීරණය කළ හැකිය. අපි මෙම අගය තත්පර 5 දක්වා සකස් කරමු.
• MASTER_CONNECT_RETRY - නැවත සම්බන්ධ කිරීමේ උත්සාහයන් අතර තත්පර ගණන. ජාල ගැටළු වලදී, මෙම පරාමිතිය සඳහා අඩු අගයක් ඉක්මනින් නැවත සම්බන්ධ වීමට සහ පොකුරු ප්‍රතිසාධන ක්‍රියාවලිය ආරම්භ කිරීම වලක්වනු ඇත. නිර්දේශිත අගය තත්පර 1 කි.
• MASTER_RETRY_COUNT - උපරිම නැවත සම්බන්ධ කිරීමේ උත්සාහයන් ගණන.
• MASTER_HEARTBEAT_PERIOD - ස්වාමියා හෘද ස්පන්දන සංඥාවක් යවන තත්පර කිහිපයක පරතරය. අගයෙන් අඩකට පෙරනිමි slave_net_timeout.

වාදක පරාමිතීන්:

• DelayMasterPromotionIfSQLThreadNotUpToDate - සමාන නම් true, එවිට අනුරුවෙහි SQL ත්‍රෙඩ් එක Relay ලොගයෙන් අදාළ නොවන සියලුම ගනුදෙනු සම්පූර්ණ කරන තෙක් ප්‍රධාන භූමිකාව අපේක්ෂක අනුරුව මත යොදනු නොලැබේ. සියලුම අපේක්ෂක අනුරූ පසුපසට වැටෙන විට ගනුදෙනු අහිමි වීම වළක්වා ගැනීමට අපි මෙම විකල්පය භාවිතා කරමු.
• InstancePollSeconds - ස්ථලකය ගොඩනැගීමේ සහ යාවත්කාලීන කිරීමේ වාර ගණන.
• RecoveryPollSeconds - ස්ථලක විශ්ලේෂණයේ වාර ගණන. ගැටලුවක් අනාවරණය වුවහොත්, ස්ථලක ප්රතිසාධනය ආරම්භ වේ. මෙය නියත, තත්පර 1 ට සමාන වේ.

සෑම පොකුරු නෝඩයක්ම එක් වරක් වාද්‍ය වෘන්දය විසින් ඡන්ද විමසනු ලැබේ InstancePollSeconds තත්පර ගැටලුවක් අනාවරණය වූ විට, පොකුරු තත්ත්වය බල කෙරේ යාවත්කාලීන කරන ලදී, පසුව ප්රතිසාධනය සිදු කිරීමට අවසන් තීරණය ගනු ලැබේ. විවිධ දත්ත සමුදාය සහ වාදක පරාමිති සමඟ අත්හදා බැලීමෙන්, ප්‍රතිචාර සහ ප්‍රතිසාධන කාලය තත්පර 30 දක්වා අඩු කිරීමට අපට හැකි විය.

පරීක්ෂණ ස්ථාවරය

අපි දේශීය සංවර්ධනයත් සමඟ HA යෝජනා ක්‍රමය පරීක්ෂා කිරීමට පටන් ගත්තෙමු පරීක්ෂණ බංකුව සහ පරීක්ෂණ සහ නිෂ්පාදන පරිසරයන් තුළ තවදුරටත් ක්රියාත්මක කිරීම. දේශීය ස්ථාවරය ඩොකර් මත පදනම්ව සම්පුර්ණයෙන්ම ස්වයංක්‍රීය කර ඇති අතර ඔබට වාද්‍ය වෘන්දයේ සහ ජාලයේ වින්‍යාසය සමඟ අත්හදා බැලීමට, පොකුර 2-3 සේවාදායක සිට දුසිම් කිහිපයක් දක්වා පරිමාණය කිරීමට සහ ආරක්ෂිත පරිසරයක ව්‍යායාම කිරීමට ඉඩ සලසයි.

අභ්‍යාස අතරතුර, අපි ගැටළු අනුකරණ ක්‍රම වලින් එකක් තෝරා ගනිමු: භාවිතා කරමින් ස්වාමියාට ක්ෂණිකව වෙඩි තියන්න kill -9, ක්‍රියාවලිය මෘදු ලෙස අවසන් කර සේවාදායකය නවත්වන්න (docker-compose stop), භාවිතා කරන ජාල ගැටළු අනුකරණය කරන්න iptables -j REJECT හෝ iptables -j DROP. අපි පහත ප්‍රතිඵල බලාපොරොත්තු වෙමු:

• වාද්‍ය වෘන්දය ස්වාමියා සමඟ ඇති ගැටළු හඳුනාගෙන තත්පර 10 කට නොඅඩු කාලයකින් ස්ථලකය යාවත්කාලීන කරයි;
• ප්‍රතිසාධන ක්‍රියා පටිපාටිය ස්වයංක්‍රීයව ආරම්භ වනු ඇත: ජාල වින්‍යාසය වෙනස් වනු ඇත, ස්වාමියාගේ භූමිකාව අනුරුවට යයි, ස්ථලකය නැවත ගොඩනඟනු ලැබේ;
• නව ස්වාමියා ලිවිය හැකි වනු ඇත, නැවත ගොඩනැගීමේ ක්‍රියාවලියේදී සජීවී අනුරූ නැති නොවේ;
• දත්ත නව මාස්ටර් වෙත ලිවීමට සහ අනුකරණය කිරීමට පටන් ගනී;
• සම්පූර්ණ ප්‍රතිසාධන කාලය තත්පර 30 කට වඩා වැඩි නොවේ.

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

සොයා ගැනීම්

ප්‍රධාන ගබඩා පද්ධති නෝඩයේ සෞඛ්‍යය SRE සහ මෙහෙයුම් කණ්ඩායමේ ප්‍රධාන කාර්යයන්ගෙන් එකකි. VIP මත පදනම් වූ වාද්‍ය වෘන්දය සහ HA විසඳුම ක්‍රියාත්මක කිරීම අපට පහත ප්‍රතිඵල ලබා ගැනීමට ඉඩ සලසයි:

• දත්ත සමුදා පොකුරේ ස්ථලකය සමඟ ගැටළු විශ්වාසදායක ලෙස හඳුනා ගැනීම;
• ස්වාමියා සම්බන්ධ සිදුවීම් සඳහා ස්වයංක්‍රීය හා වේගවත් ප්‍රතිචාරය, පද්ධතියේ අක්‍රිය කාලය අඩු කිරීම.

කෙසේ වෙතත්, විසඳුමට එහි සීමාවන් සහ අවාසි ඇත:

• HA යෝජනා ක්‍රමය දත්ත මධ්‍යස්ථාන කිහිපයකට පරිමාණය කිරීම සඳහා ඒවා අතර තනි L2 ජාලයක් අවශ්‍ය වේ;
• නව මාස්ටර් මත VIP පැවරීමට පෙර, අපි එය පැරණි එක මත මුදා හැරිය යුතුය. ක්රියාවලිය අනුක්රමික වේ, එය ප්රකෘතිමත් වීමේ කාලය වැඩි කරයි;
• VIP මුදා හැරීමට SSH ප්‍රවේශය සේවාදායකයට හෝ දුරස්ථ ක්‍රියා පටිපාටි ඇමතීමේ වෙනත් ක්‍රමයක් අවශ්‍ය වේ. සේවාදායකය හෝ දත්ත සමුදාය ප්‍රතිසාධන ක්‍රියාවලියට හේතු වූ ගැටළු අත්විඳින බැවින්, VIP ඉවත් කිරීම සාර්ථකව අවසන් වනු ඇතැයි අපට සහතික විය නොහැක. තවද මෙය එකම අතථ්‍ය IP ලිපිනයක් සහිත සේවාදායකයන් දෙකක් සහ ගැටළුවක් ඇති කිරීමට හේතු විය හැක split brain.

වළක්වා ගැනීමට split brain, ඔබට ක්රමය භාවිතා කළ හැකිය ස්ටෝනිත් ("හිසෙහි අනෙක් නෝඩයට වෙඩි තියන්න"), එය ගැටළු නෝඩය සම්පූර්ණයෙන්ම හුදකලා කරයි හෝ අක්‍රීය කරයි. Cluster high availability ක්‍රියාත්මක කිරීමට වෙනත් ක්‍රම තිබේ: VIP සහ DNS, සේවා සොයාගැනීම් සහ ප්‍රොක්සි සේවා, සමමුහුර්ත අනුවර්තනය සහ ඒවායේ අවාසි සහ වාසි ඇති වෙනත් ක්‍රම වල එකතුවක්.

MySQL failover Cluster එකක් නිර්මාණය කිරීම සඳහා අපගේ ප්‍රවේශය ගැන මම කතා කළෙමි. එය ක්රියාත්මක කිරීමට පහසු වන අතර වර්තමාන තත්ත්වයන් යටතේ පිළිගත හැකි මට්ටමේ විශ්වසනීයත්වයක් ලබා දෙයි. පොදුවේ සමස්ත පද්ධතියම සහ විශේෂයෙන් යටිතල පහසුකම් සංවර්ධනය වන විට, මෙම ප්රවේශය නිසැකවම පරිණාමය වනු ඇත.

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