ඕනෑම විශාල ව්‍යාපෘතියක් සර්වර් කිහිපයකින් ආරම්භ විය. මුලදී එක් DB සේවාදායකයක් විය, පසුව කියවීම පරිමාණය කිරීම සඳහා වහලුන් එයට එකතු කරන ලදී. ඉන්පසු - නවත්වන්න! එක් ස්වාමියෙක් ඇත, නමුත් බොහෝ වහලුන් ඇත; එක් වහලෙකු පිටව ගියහොත් සියල්ල හොඳින් සිදුවනු ඇත, නමුත් ස්වාමියා පිටව ගියහොත් එය නරක වනු ඇත: අක්‍රීය කාලය, පරිපාලකයින් සේවාදායකයා ඉහළ නැංවීමට උත්සාහ කරයි. කුමක් කරන්න ද? ස්වාමියා වෙන්කරවා ගන්න. මගේ සගයා වන පාවෙල් දැනටමත් මේ ගැන ලියා ඇත , මම එය නැවත නොකියමි. ඒ වෙනුවට, MySQL සඳහා ඔබට අනිවාර්යයෙන්ම Orchestrator අවශ්ය වන්නේ මන්දැයි මම ඔබට කියමි!
අපි ප්‍රධාන ප්‍රශ්නයෙන් පටන් ගනිමු: “මාස්ටර් පිටත් වූ විට අපි කේතය නව යන්ත්‍රයකට මාරු කරන්නේ කෙසේද?”
- මම VIP (Virtual IP) සමඟ යෝජනා ක්රමයට වඩාත්ම කැමතියි, අපි එය පහතින් කතා කරමු. පැහැදිලි සීමාවක් තිබුණද එය සරලම හා වඩාත්ම පැහැදිලිය: අප විසින් වෙන් කරන ලද මාස්ටර් නව යන්ත්‍රය සමඟ L2 කොටසේ සිටිය යුතුය, එනම් අපට දෙවන DC ගැන අමතක කළ හැකිය. තවද, සාමකාමී ආකාරයකින්, ඔබ විශාල L2 නරක යැයි රීතිය අනුගමනය කරන්නේ නම්, L2 යනු රාක්කයකට පමණක් වන අතර L3 රාක්ක අතර වන අතර එවැනි යෝජනා ක්‍රමයකට ඊටත් වඩා සීමාවන් ඇත.
- ඔබට කේතයේ DNS නමක් ලිවිය හැකි අතර එය /etc/hosts හරහා විසඳා ගත හැක. ඇත්ත වශයෙන්ම, විසඳුමක් නොලැබෙනු ඇත. යෝජනා ක්රමයේ වාසිය: පළමු ක්රමයේ සීමාවන් ලක්ෂණයක් නොමැත, එනම්, එය හරස් DC සංවිධානය කිරීමට හැකි වේ. නමුත් එවිට පැහැදිලි ප්‍රශ්නය පැන නගී: රූකඩ-ඇන්සිබල් හරහා අපට වෙනස් කිරීම /etc/hosts වෙත කෙතරම් ඉක්මනින් ලබා දිය හැකිද?
- ඔබට දෙවන ක්‍රමය ටිකක් වෙනස් කළ හැකිය: සියලුම වෙබ් සේවාදායකයන් මත හැඹිලි DNS ස්ථාපනය කරන්න, එමඟින් කේතය ප්‍රධාන දත්ත ගබඩාවට යයි. DNS හි මෙම ප්‍රවේශය සඳහා ඔබට TTL 60 සැකසිය හැක. හරියට ක්‍රියාත්මක කළොත් ක්‍රමය හොඳයි වගේ.
- සේවා සොයාගැනීම් සහිත යෝජනා ක්‍රමයක්, කොන්සල් සහ යනාදිය භාවිතා කිරීම ඇඟවුම් කරයි.
- සමඟ සිත්ගන්නා විකල්පයක් . ඔබට ProxySQL හරහා MySQL වෙත සියලුම ගමනාගමනය යොමු කිරීමට අවශ්ය වේ; ප්‍රොක්සිSQL විසින් ප්‍රධානියා කවුරුන්ද යන්න තීරණය කළ හැක. මාර්ගය වන විට, මෙම නිෂ්පාදනය භාවිතා කිරීම සඳහා වූ එක් විකල්පයක් ගැන ඔබට කියවිය හැකිය .
Github හි සේවය කරන Orchestrator හි කතුවරයා පළමුව VIP සමඟ පළමු යෝජනා ක්‍රමය ක්‍රියාත්මක කළ අතර පසුව එය කොන්සල් සමඟ යෝජනා ක්‍රමයක් බවට පරිවර්තනය කළේය.
සාමාන්‍ය යටිතල පහසුකම් පිරිසැලසුම:
සැලකිල්ලට ගත යුතු පැහැදිලි තත්වයන් මම වහාම විස්තර කරමි:
- VIP ලිපිනය කිසිදු සේවාදායකයක වින්‍යාසය තුළ ලියාපදිංචි නොකළ යුතුය. අපි යම් තත්වයක් සිතමු: ස්වාමියා නැවත පණ ගැන්වූ අතර, එය පූරණය වන අතරතුර, වාදකයා අසාර්ථක මාදිලියට ගොස් එක් වහලෙකු ස්වාමියා බවට පත් කළේය; එවිට පැරණි මාස්ටර් නැඟිට, දැන් VIP මෝටර් රථ දෙකක. මේක නරකයි.
- වාද්‍ය වෘන්දය සඳහා, ඔබ පැරණි ස්වාමියා සහ නව ස්වාමියා ඇමතීම සඳහා පිටපතක් ලිවීමට අවශ්ය වනු ඇත. පැරණි මාස්ටර් මත ඔබ ifdown ධාවනය කළ යුතු අතර, නව මාස්ටර් මත - ifup vip. අසමත් වීමකදී, පැරණි මාස්ටර් ස්විචයේ ඇති තොට කිසිදු බෙදීමක් වළක්වා ගැනීම සඳහා සරලව ක්‍රියා විරහිත කර ඇති බව මෙම පිටපතට ඇතුළත් කිරීම සතුටක්.
- මුලින්ම VIP ඉවත් කිරීමට සහ/හෝ ස්විචයේ ඇති පෝට් එක නිවා දැමීමට Orchestrator ඔබගේ ස්ක්‍රිප්ට් අමතා, පසුව නව මාස්ටර් මත VIP raising script ලෙස හැඳින්වූ පසු, නව VIP දැන් බව සැමට පැවසීමට arping විධානය භාවිතා කිරීමට අමතක නොකරන්න. මෙතන.
- සියලුම වහලුන්ට read_only=1 තිබිය යුතු අතර, ඔබ දාසයාව ස්වාමියා වෙත උසස් කළ වහාම එහි read_only=0 තිබිය යුතුය.
- මේ සඳහා අප තෝරාගෙන ඇති ඕනෑම වහලෙකු ස්වාමියෙකු විය හැකි බව අමතක නොකරන්න (Orchestrator සතුව සම්පූර්ණ මනාප යාන්ත්‍රණයක් ඇත, ඒ සඳහා වහලෙකු පළමු ස්ථානයේ නව ස්වාමියෙකු සඳහා අපේක්ෂකයෙකු ලෙස සලකා බැලිය යුතු අතර, දෙවන ස්ථානයට සහ කුමන දාසය කළ යුතුද? කිසිම තත්වයක් යටතේ කිසිසේත් තෝරා නොගත යුතුය ස්වාමියා). දාසයා ස්වාමියා බවට පත් වුවහොත්, වහලාගේ බර එය මත පවතිනු ඇති අතර ස්වාමියාගේ බර එකතු වනු ඇත, මෙය සැලකිල්ලට ගත යුතුය.
ඔබට වාද්‍ය වෘන්දයක් නොමැති නම් ඔබට එය අවශ්ය වන්නේ ඇයි?
- Orchestrator සතුව ඉතා පරිශීලක-හිතකාමී චිත්‍රක අතුරු මුහුණතක් ඇති අතර එය සම්පූර්ණ ස්ථලකයම පෙන්වයි (පහත තිර රුව බලන්න).
- වාද්‍ය වෘන්දයට පසුගාමී වන්නේ කුමන වහලුන්ද, සහ සාමාන්‍යයෙන් අනුකරණය බිඳ වැටී ඇති ස්ථාන නිරීක්ෂණය කළ හැක (අපි SMS යැවීම සඳහා Orchestrator වෙත ස්ක්‍රිප්ට් අමුණා ඇත).
- GTID දෝෂයක් ඇත්තේ කුමන වහලුන්ටදැයි වාද්‍ය වෘන්දය ඔබට කියයි.
වාදක අතුරුමුහුණත:
GTID දෝෂය යනු කුමක්ද?
Orchestrator වැඩ කිරීමට ප්‍රධාන අවශ්‍යතා දෙකක් තිබේ:
- MySQL පොකුරේ සියලුම යන්ත්‍රවල ව්‍යාජ GTID සක්‍රීය කර තිබීම අවශ්ය වේ; අපි GTID සක්‍රීය කර ඇත.
- සෑම තැනකම එක් වර්ගයක බින්ලොග් තිබීම අවශ්ය වේ, ඔබට ප්‍රකාශය භාවිතා කළ හැකිය. අපට ස්වාමියා සහ බොහෝ වහලුන්ට පේළිය ඇති වින්‍යාසයක් තිබූ අතර, දෙදෙනෙක් ඓතිහාසිකව මිශ්‍ර මාදිලියේ රැඳී සිටියහ. එහි ප්රතිඵලයක් වශයෙන්, මෙම වහලුන් නව ස්වාමියා වෙත සම්බන්ධ කිරීමට Orchestrator හට අවශ්ය වූයේ නැත.
නිෂ්පාදන වහලෙකුගේ වැදගත්ම දෙය ස්වාමියා සමඟ එහි අනුකූලතාවය බව මතක තබා ගන්න! ඔබට ඔබගේ ස්වාමියා සහ වහල් යන දෙඅංශයෙන්ම ගෝලීය ගනුදෙනු හැඳුනුම්පත (GTID) සක්‍රීය කර තිබේ නම්, එවිට ඔබට gtid_subset ශ්‍රිතය භාවිතා කර දත්ත වෙනස් කිරීම් සඳහා වන ඉල්ලීම් මෙම යන්ත්‍රවල සත්‍ය වශයෙන්ම ක්‍රියාත්මක කර තිබේද යන්න සොයා බැලිය හැක. ඔබට මේ ගැන වැඩිදුර කියවිය හැකිය .
මේ අනුව, වාද්‍ය වෘන්දය GTID දෝෂය හරහා ඔබට පෙන්වන්නේ ස්වාමියා මත නොමැති ගණුදෙණු දාසයා මත පවතින බවයි. ඇයි මෙහෙම වෙන්නේ?
- Read_only=1 ස්ලේව් මත සක්‍රීය කර නැත, යමෙකු සම්බන්ධ වී දත්ත වෙනස් කිරීමට ඉල්ලීමක් සම්පූර්ණ කළේය.
- Super_read_only=1 ස්ලේව් මත සක්‍රීය කර නැත, එවිට පරිපාලක, සේවාදායකය ව්‍යාකූල කර, ඇතුලට ගොස් එහි ඉල්ලීම ක්‍රියාත්මක කළේය.
- ඔබ පෙර කරුණු දෙකම සැලකිල්ලට ගත්තේ නම්, තවත් එක් උපක්‍රමයක් තිබේ: MySQL හි, බින්ලොග් ෆ්ලෂ් කිරීමට ඉල්ලීමක් ද බින්ලොග් වෙත යයි, එබැවින් පළමු ෆ්ලෂ් කිරීමේදී, ස්වාමියා සහ සියලුම වහලුන් මත GTID දෝෂයක් දිස්වනු ඇත. මෙය වළක්වා ගන්නේ කෙසේද? Perona-5.7.25-28 විසින් binlog_skip_flush_commands=1 සැකසුම හඳුන්වා දෙන ලදී, එය බින්ලොග් වලට ෆ්ලෂ් ලිවීම තහනම් කරයි. mysql.com වෙබ් අඩවියේ ස්ථාපිත එකක් ඇත .
ඉහත සියල්ල සාරාංශ කිරීමට මට ඉඩ දෙන්න. ඔබට තවමත් Orchestrator අසාර්ථක මාදිලියේ භාවිතා කිරීමට අවශ්ය නැතිනම්, එය නිරීක්ෂණ මාදිලියේ තබන්න. එවිට ඔබ සැම විටම MySQL යන්ත්‍රවල අන්තර් ක්‍රියාකාරිත්වයේ සිතියමක් සහ එක් එක් යන්ත්‍රයක කුමන ආකාරයේ අනුකරණයක් තිබේද, වහලුන් පසුගාමීද යන්න සහ වඩාත්ම වැදගත් දෙය නම්, ඔවුන් ස්වාමියා සමඟ කෙතරම් අනුකූලද යන්න පිළිබඳ දෘශ්‍ය තොරතුරු ඔබේ ඇස් ඉදිරිපිට ඇති වනු ඇත!
පැහැදිලි ප්‍රශ්නය නම්: "Ochestrator වැඩ කළ යුත්තේ කෙසේද?" ඔහු වත්මන් වහලුන්ගෙන් නව ස්වාමියෙකු තෝරා ගත යුතු අතර, පසුව සියලුම වහලුන් එයට නැවත සම්බන්ධ කළ යුතුය (GTID අවශ්ය වන්නේ මෙයයි; ඔබ binlog_name සහ binlog_pos සමඟ පැරණි යාන්ත්‍රණය භාවිතා කරන්නේ නම්, වත්මන් ස්වාමියාගෙන් වහලෙකු නව එකකට මාරු කිරීම සරලවම කළ නොහැක්කකි!). අපිට Orchestrator වෙන්න කලින් මට මේ හැම දෙයක්ම අතින් කරන්න සිද්ධ වුණා. දෝෂ සහිත ඇඩප්ටෙක් පාලකයක් හේතුවෙන් පැරණි ස්වාමියා එල්ලී සිටියේය; එහි වහලුන් 10 ක් පමණ සිටියහ. මට ප්‍රභූවරයා ස්වාමියාගෙන් එක් වහලෙකුට මාරු කිරීමටත් අනෙක් සියලුම වහලුන්ව එයට නැවත සම්බන්ධ කිරීමටත් අවශ්ය විය. මට කොන්සෝල් කීයක් විවෘත කිරීමට සිදු වූවාද, මම එකවර විධාන කීයක් ඇතුළු කළාද ... මට පාන්දර 3 වන තෙක් බලා සිටීමට සිදු විය, දෙදෙනෙකු හැර අනෙක් සියලුම වහලුන්ගෙන් බර ඉවත් කර, පළමු යන්ත්‍රය මාස්ටර් දෙදෙනෙකුගෙන් සාදා, වහාම දෙවන යන්ත්‍රය අමුණන්න එයට, එබැවින් අනෙක් සියලුම වහලුන් නව ස්වාමියාට අනුයුක්ත කර බර ආපසු දෙන්න. සමස්තයක් වශයෙන්, භයානක ...
එය අසාර්ථක මාදිලියට ගිය විට Orchestrator ක්‍රියා කරන්නේ කෙසේද? ස්වාමියා දැන් ඇති යන්ත්‍රයකට වඩා බලවත්, නවීන යන්ත්‍රයක් බවට පත් කිරීමට අපට අවශ්ය වන අවස්ථාවක උදාහරණයකින් මෙය වඩාත් පහසුවෙන් පැහැදිලි වේ.
රූපයේ දැක්වෙන්නේ ක්රියාවලියේ මැද කොටසයි. මේ දක්වා දැනටමත් කර ඇත්තේ කුමක්ද? අපට වහලෙකු නව ස්වාමියා කිරීමට අවශ්ය බව අපි කීවෙමු, වාද්‍ය වෘන්දය අනෙක් සියලුම වහලුන් එයට නැවත සම්බන්ධ කිරීමට පටන් ගත්තේය, නව ස්වාමියා සංක්‍රමණ යන්ත්‍රයක් ලෙස ක්‍රියා කරයි. මෙම යෝජනා ක්‍රමය සමඟ, කිසිදු දෝෂයක් සිදු නොවේ, සියලුම වහලුන් ක්‍රියා කරයි, වාදකයා පැරණි මාස්ටර්ගෙන් VIP ඉවත් කරයි, එය අලුත් එකට මාරු කරයි, read_only=0 බවට පත් කර පැරණි ස්වාමියා අමතක කරයි. සෑම! අපගේ සේවාවේ අක්‍රීය කාලය ප්‍රභූ මාරු කිරීමේ කාලය වන අතර එය තත්පර 2-3 කි.
අදට එච්චරයි, ස්තූතියි හැමෝටම. Orchestrator ගැන දෙවෙනි ලිපියක් ළඟදීම එනවා. සුප්‍රසිද්ධ සෝවියට් චිත්‍රපටයක් වන "ගරාජ්" හි එක් චරිතයක් පැවසුවේ, "මම ඔහු සමඟ ඔත්තු බැලීමේ නොයමි!" ඉතින්, වාදක, මම ඔත්තු බැලීම සඳහා ඔබ සමඟ යන්නම්!
මූලාශ්රය: www.habr.com