සම්බන්ධතා සංචිතය සැලසුම් කිරීමේදී PgBouncer පරිමාණය කිරීමේ අත්දැකීම ඔවුන් සැලකිල්ලට ගත් ආකාරය ඔහුගේ වාර්තාවේ Andrey Borodin ඔබට කියනු ඇත. , ඔවුන් එය නිෂ්පාදනයේදී එළිදැක්වූ ආකාරය. ඊට අමතරව, අපි නව අනුවාදවල දැකීමට කැමති සංචිතයේ කාර්යයන් මොනවාදැයි අපි සාකච්ඡා කරමු: අපගේ අවශ්යතා ආවරණය කිරීම පමණක් නොව, පරිශීලක ප්‍රජාව සංවර්ධනය කිරීම අපට වැදගත් වේ. .
වීඩියෝ:
ආයුබෝවන් සියල්ලටම! මගේ නම ඇන්ඩෘ.
Yandex හි, මම විවෘත මූලාශ්‍ර දත්ත සමුදායන් සංවර්ධනය කරමි. අද අපට සම්බන්ධතා සංචිත සම්බන්ධතා පිළිබඳ මාතෘකාවක් තිබේ.
රුසියානු භාෂාවෙන් සම්බන්ධතා සංචිතය අමතන්නේ කෙසේදැයි ඔබ දන්නේ නම්, මට කියන්න. මම ඇත්තටම තාක්ෂණික සාහිත්යය තුළ ස්ථාපිත කළ යුතු හොඳ තාක්ෂණික යෙදුමක් සොයා ගැනීමට අවශ්යයි.
මාතෘකාව බෙහෙවින් සංකීර්ණ ය, මන්ද බොහෝ දත්ත සමුදායන් තුළ සම්බන්ධතා සංචිතය ගොඩනඟා ඇති අතර ඔබ ඒ ගැන දැන ගැනීමට පවා අවශ්ය නොවේ. සමහර සැකසුම්, ඇත්ත වශයෙන්ම, සෑම තැනකම ඇත, නමුත් Postgres හි මෙය ක්රියා නොකරයි. සහ සමාන්තරව (HyLoad++ 2019 හි) Postgres හි විමසුම් පිහිටුවීම පිළිබඳ Nikolai Samokhvalov විසින් වාර්තාවක් ඇත. දැනටමත් ඉල්ලීම් පරිපූර්ණ ලෙස වින්‍යාස කර ඇති පුද්ගලයින් මෙහි පැමිණ ඇති බවත්, මොවුන් ජාලය, සම්පත් භාවිතය සම්බන්ධ දුර්ලභ පද්ධති ගැටළු වලට මුහුණ දෙන පුද්ගලයින් බවත් මට වැටහේ. සහ සමහර තැන්වලදී ගැටලු පැහැදිලිව පෙනෙන්නේ නැති නිසා එය තරමක් අපහසු විය හැකිය.
Yandex සතුව Postgres ඇත. බොහෝ Yandex සේවාවන් Yandex.Cloud හි ජීවත් වේ. තවද Postgres හි තත්පරයකට අවම වශයෙන් මිලියනයක් ඉල්ලීම් ජනනය කරන දත්ත පෙටාබයිට් කිහිපයක් අප සතුව ඇත.
තවද අපි සියලුම සේවාවන් සඳහා තරමක් සාමාන්ය පොකුරක් සපයන්නෙමු - මෙය නෝඩයේ ප්රධාන ප්‍රාථමික නෝඩය, සාමාන්ය අනුරූ දෙක (සමමුහුර්ත සහ අසමමුහුර්ත), උපස්ථ, අනුරුවෙහි කියවීමේ ඉල්ලීම් පරිමාණය කිරීම.
සෑම පොකුරු නෝඩයක්ම Postgres වන අතර, Postgres සහ අධීක්ෂණ පද්ධති වලට අමතරව, සම්බන්ධතා සංචිතයක් ද ස්ථාපනය කර ඇත. සම්බන්ධක තටාකය වැටවල් සඳහා සහ එහි ප්රධාන අරමුණ සඳහා භාවිතා වේ.
සම්බන්ධතා සංචිතයක ප්රධාන අරමුණ කුමක්ද?
Postgres දත්ත සමුදායක් සමඟ වැඩ කිරීම සඳහා ක්‍රියාවලි ආකෘතියක් අනුගමනය කරයි. මෙයින් අදහස් කරන්නේ එක් සම්බන්ධතාවයක් එක් ක්‍රියාවලියක්, එක් Postgres පසුබිමක් බවයි. තවද මෙම පසුබිමෙහි විවිධ හැඹිලි රාශියක් ඇත, ඒවා විවිධ සම්බන්ධතා සඳහා වෙනස් කිරීමට බෙහෙවින් මිල අධික වේ.
ඒ වගේම Postgres code එකේ procArray කියලා array එකක් තියෙනවා. ජාල සම්බන්ධතා පිළිබඳ මූලික දත්ත එහි අඩංගු වේ. සියලුම procArray සැකසුම් ඇල්ගොරිතම පාහේ රේඛීය සංකීර්ණතාවයක් ඇත, ඒවා සමස්ත ජාල සම්බන්ධතා මාලාව හරහා දිව යයි. එය ඉතා වේගවත් චක්‍රයක්, නමුත් වැඩි ලැබෙන ජාල සම්බන්ධතා සමඟ, දේවල් ටිකක් මිල අධික වේ. තවද දේවල් ටිකක් මිල අධික වන විට, ඔබ ජාල සම්බන්ධතා විශාල සංඛ්යාවක් සඳහා ඉතා ඉහළ මිලක් ගෙවනු ඇත.
හැකි ප්රවේශයන් 3 ක් ඇත:
- යෙදුම පැත්තෙන්.
- දත්ත සමුදාය පැත්තෙන්.
- සහ අතර, එනම්, හැකි සියලු සංයෝජන.
අවාසනාවකට, ගොඩනඟන ලද තටාකය දැනට සංවර්ධනය වෙමින් පවතී. PostgreSQL Professional හි මිතුරන් මෙය බොහෝ දුරට කරයි. එය දිස්වන්නේ කවදාදැයි අනාවැකි කීම දුෂ්කර ය. ඇත්ත වශයෙන්ම, ගෘහ නිර්මාණ ශිල්පියෙකු තෝරා ගැනීම සඳහා අපට විසඳුම් දෙකක් තිබේ. මේවා යෙදුම් පැත්තේ සංචිතය සහ ප්‍රොක්සි තටාකයයි.
යෙදුම් පැති සංචිතය පහසුම ක්‍රමයයි. තවද සියලුම සේවාදායක රියදුරන් පාහේ ඔබට මාර්ගයක් සපයයි: දත්ත සමුදායට සම්බන්ධතා දුසිම් ගණනක් ලෙස කේතයේ ඔබගේ සම්බන්ධතා මිලියන ගණනක් නියෝජනය කිරීමට.
යම් අවස්ථාවක ඔබට පසුපෙළ පරිමාණය කිරීමට අවශ්ය වන අතර, ඔබට එය බොහෝ අතථ්‍ය යන්ත්‍ර වෙත යෙදවීමට අවශ්ය වීම පිළිබඳ ගැටලුවක් තිබේ.
එවිට ඔබට තවත් ලබා ගත හැකි කලාප කිහිපයක්, දත්ත මධ්‍යස්ථාන කිහිපයක් ඇති බව ඔබට තවමත් වැටහේ. තවද සේවාලාභී පාර්ශ්ව එකතු කිරීමේ ප්‍රවේශය විශාල සංඛ්‍යා වෙත යොමු කරයි. විශාල ඒවා සම්බන්ධතා 10 ක් පමණ වේ. මෙය හොඳින් වැඩ කළ හැකි කෙළවරකි.
අපි proxy poolers ගැන කතා කළොත්, ගොඩක් දේවල් කරන්න පුළුවන් poolers දෙන්නෙක් ඉන්නවා. ඔවුන් සංචිත කරන්නන් පමණක් නොවේ. ඒවා තටාක + වඩාත් සිසිල් ක්‍රියාකාරීත්වය. මෙය и .
එහෙත්, අවාසනාවකට මෙන්, සෑම කෙනෙකුටම මෙම අතිරේක ක්රියාකාරිත්වය අවශ්ය නොවේ. එය සංචිතයන් සැසි සංචිතයට පමණක් සහය දක්වයි, එනම් එක් පැමිණෙන සේවාදායකයා, එක් පිටතට යන සේවාදායකයා දත්ත සමුදායට සහාය දක්වයි.
මෙය අපගේ අරමුණු සඳහා එතරම් සුදුසු නොවේ, එබැවින් අපි ගනුදෙනු එකතු කිරීම ක්රියාත්මක කරන PgBouncer භාවිතා කරමු, එනම් සේවාදායක සම්බන්ධතා ගණුදෙණුවේ කාලසීමාව සඳහා පමණක් සේවාදායක සම්බන්ධතා වලට ගැලපේ.
සහ අපගේ බර මත - එය සත්යයකි. නමුත් ගැටළු කිහිපයක් තිබේ.
ඔබට සැසියක් හඳුනා ගැනීමට අවශ්ය වූ විට ගැටළු ආරම්භ වේ, මන්ද එන සියලුම සම්බන්ධතා දේශීය ඒවා වේ. හැමෝම ලූප්බැක් එක්ක ඇවිත් කොහොම හරි සැසිය ට්‍රේස් කරන්න අමාරු වෙනවා.
ඇත්ත වශයෙන්ම ඔබට application_name_add_host භාවිතා කළ හැක. application_name වෙත IP ලිපිනයක් එක් කිරීමට Bouncer පැත්තේ මාර්ගය මෙයයි. නමුත් application_name සකසනු ලබන්නේ අමතර සම්බන්ධතාවයක් මගිනි.
මෙම ප්‍රස්ථාරයේ, කහ ඉර සැබෑ ඉල්ලීම් වන අතර, නිල් රේඛාව දත්ත ගබඩාවට පියාසර කරන ඉල්ලීම් වේ. තවද මෙම වෙනස හරියටම application_name හි සැකසීමයි, එය ලුහුබැඳීම සඳහා පමණක් අවශ්ය වේ, නමුත් එය කිසිසේත්ම නොමිලේ නොවේ.
මීට අමතරව, Bouncer හට එක් සංචිතයක් සීමා කළ නොහැක, එනම් එක් පරිශීලකයෙකුට දත්ත සමුදා සම්බන්ධතා ගණන, දත්ත ගබඩාවකට.
මෙය හේතු වන්නේ කුමක් ද? ඔබට C ++ වලින් ලියා ඇති පටවන ලද සේවාවක් ඇති අතර පාදයේ කිසිදු වරදක් නොකරන නෝඩයක කොහේ හරි කුඩා සේවාවක් ඇත, නමුත් එහි රියදුරු පිස්සු වැටේ. එය සම්බන්ධතා 20 ක් විවෘත කරන අතර අනෙක් සියල්ල බලා සිටිනු ඇත. ඔබේ කේතය පවා නිවැරදියි.
ඇත්ත වශයෙන්ම, අපි මෙම සැකසුම එකතු කරන ලද බවුන්සර් සඳහා කුඩා පැච් එකක් ලිවීය, එනම් සංචිතයට ගනුදෙනුකරුවන් සීමා කිරීම.
Postgres පැත්තෙන් මෙය කිරීමට හැකි වනු ඇත, එනම්, සම්බන්ධතා ගණන අනුව දත්ත සමුදායේ භූමිකාවන් සීමා කරන්න.
නමුත් එවිට ඔබට සේවාදායකයට සම්බන්ධතා නොමැති ඇයි දැයි තේරුම් ගැනීමේ හැකියාව ඔබට අහිමි වේ. PgBouncer සම්බන්ධතා දෝෂයක් විසි නොකරයි, එය සෑම විටම එකම තොරතුරු ලබා දෙයි. ඔබට තේරුම් ගත නොහැක: සමහර විට ඔබගේ මුරපදය වෙනස් වී ඇත, සමහර විට දත්ත සමුදාය පහත වැටී ඇත, සමහර විට යමක් වැරදියි. නමුත් රෝග විනිශ්චය නොමැත. සැසිය ස්ථාපිත කළ නොහැකි නම්, එය කළ නොහැක්කේ මන්දැයි ඔබ නොදනී.
යම් අවස්ථාවක, ඔබ යෙදුමේ ප්‍රස්ථාර දෙස බලා යෙදුම ක්රියා නොකරන බව දකියි.
උඩ බලපන් Bouncer එක තනි ත්‍රෙඩ් එකක් කියල. මෙය සේවයේ ජීවිතයේ සන්ධිස්ථානයකි. ඔබ වසර එකහමාරකින් දත්ත සමුදාය පරිමාණය කිරීමට සූදානම් වන බව ඔබට වැටහෙන අතර, ඔබ සංචිතය පරිමාණය කළ යුතුය.
අපිට තව PgBouncers අවශ්ය බව අපි නිගමනය කරා.
බවුන්සර් ටිකක් පැච් කරලා.
TCP පෝට් එක නැවත භාවිතා කිරීමෙන් බවුන්සර් කීප දෙනෙකුට ඉහල නැංවිය හැකි පරිදි ඔවුන් එය සාදන ලදී. තවද මෙහෙයුම් පද්ධතිය රවුන්ඩ් රොබින් භාවිතයෙන් ඒවා අතරට එන TCP සම්බන්ධතා ස්වයංක්‍රීයව මාරු කරයි.
මෙය සේවාලාභීන්ට විනිවිද පෙනෙන, එනම් ඔබට එක් බවුන්සර් එකක් ඇති බව පෙනේ, නමුත් ඔබට ධාවනය වන බවුන්සර් අතර අක්රිය සම්බන්ධතා ඛණ්ඩනය වී ඇත.
තවද යම් අවස්ථාවක දී, මෙම බවුන්සර් 3 දෙනාම ඔවුන්ගේ හරය 100% කින් අනුභව කරන බව ඔබට පෙනෙනු ඇත. ඔබට බවුන්සර් කිහිප දෙනෙකු අවශ්ය වේ. ඇයි?
මොකද ඔයාට TLS තියෙනවා. ඔබට සංකේතාත්මක සම්බන්ධතාවයක් ඇත. ඔබ TLS සමඟ සහ රහිතව Postgres මිණුම් සලකුණු කරන්නේ නම්, TLS හෑන්ඩ්ෂේක් CPU සම්පත් පරිභෝජනය කරන බැවින්, සංකේතනය සක්‍රීය කර ඇති ස්ථාපිත සම්බන්ධතා සංඛ්‍යාව විශාලත්වයේ ඇණවුම් දෙකකින් පමණ පහත වැටෙන බව ඔබට පෙනී යනු ඇත.
සහ ඉහළින් ඔබට ලැබෙන සම්බන්ධතා රැල්ලක් ඇති විට ක්රියාත්මක වන ගුප්ත ලේඛන කාර්යයන් කිහිපයක් දැකිය හැකිය. අපගේ ප්‍රාථමිකයට ලද හැකි කලාප අතර මාරු විය හැකි බැවින්, පැමිණෙන සම්බන්ධතා රැල්ලක් සාමාන්ය තත්වයකි. එනම්, කිසියම් හේතුවක් නිසා පැරණි ප්‍රාථමිකය නොතිබීම, සම්පූර්ණ භාරය වෙනත් දත්ත මධ්‍යස්ථානයකට යවන ලදි. ඔවුන් සියලු දෙනාම එකවර TLS වෙත ආයුබෝවන් කියන්නට පැමිණෙනු ඇත.
TLS අතට අත දීම විශාල සංඛ්යාවක් දැනටමත් බවුන්සර්ට ආචාර නොකර ඔහුගේ උගුර මිරිකා ගත හැක. කල් ඉකුත්වීම හේතුවෙන් පැමිණෙන සම්බන්ධතා රැල්ලක් නොනැසී පැවතිය හැක. ඔබට ඝාතීය පසුබෑමක් නොමැතිව පදනම වෙත නැවත උත්සාහයක් ඇත්නම්, ඒවා සුසංයෝගී තරංගයකින් නැවත නැවතත් නොපැමිණේ.
මෙන්න cores 16ක් 16% ලෝඩ් කරන PgBouncers 100කට උදාහරණයක්.
අපි cascading PgBouncer වෙත පැමිණ ඇත. අපගේ බවුන්සර් බර මත අපට ලබා ගත හැකි හොඳම වින්යාසය මෙයයි. අපගේ බාහිර බවුන්සර් TCP අතට අත දීම සඳහා සේවය කරන අතර අභ්‍යන්තර බවුන්සර් බාහිර සම්බන්ධතා විශාල වශයෙන් ඛණ්ඩනය නොකිරීමට සැබෑ සංචිතය සඳහා සේවය කරයි.
මෙම වින්යාසය තුළ, මෘදු නැවත ආරම්භ කළ හැකිය. ඔබට මෙම බවුන්සර් 18ම එකින් එක නැවත ආරම්භ කළ හැක. නමුත් එවැනි වින්‍යාසයක් පවත්වා ගැනීම තරමක් අපහසුය. Sysadmins, DevOps, සහ මෙම සේවාදායකය සඳහා සැබවින්ම වගකිව යුතු පුද්ගලයින් මෙම විධිවිධානය ගැන එතරම් සතුටු නොවනු ඇත.
අපගේ සියලු වැඩිදියුණු කිරීම් විවෘත මූලාශ්‍ර වෙත ප්‍රවර්ධනය කළ හැකි බව පෙනේ, නමුත් Bouncer සඳහා එතරම් හොඳ සහයක් නොමැත. උදාහරණයක් ලෙස, එක් වරායක් මත PgBouncers කිහිපයක් ධාවනය කිරීමේ හැකියාව මාසයකට පෙර කැප කරන ලදී. වසර කිහිපයකට පෙර මෙම විශේෂාංගය සමඟ ඇදීමේ ඉල්ලීමක් තිබුණි.
නැතහොත් තවත් එක් උදාහරණයක්. Postgres හි, අමතර සත්‍යාපනයකින් තොරව රහස වෙනත් සම්බන්ධතාවයකට යැවීමෙන් ඔබට ධාවන ඉල්ලීමක් අවලංගු කළ හැක. නමුත් සමහර සේවාලාභීන් සරලව TCP-reset යවයි, එනම් ඔවුන් ජාල සම්බන්ධතාවය බිඳ දමයි. Bouncer මේකට මොනවා කරයිද? ඔහු කිසිවක් නොකරනු ඇත. එය ඉල්ලීම දිගටම ක්රියාත්මක කරනු ඇත. ඔබට කුඩා ඉල්ලීම් සමඟ පදනම සකස් කර ඇති සම්බන්ධතා විශාල සංඛ්යාවක් ලැබී ඇත්නම්, බවුන්සර් වෙතින් සම්බන්ධතාවය විසන්ධි කිරීම ප්රමාණවත් නොවනු ඇත, ඔබ තවමත් දත්ත ගබඩාවේ ක්රියාත්මක වන එම ඉල්ලීම් සම්පූර්ණ කළ යුතුය.
මෙය පැච් කර ඇති අතර ගැටලුව තවමත් Bouncer's upstream වෙත ඒකාබද්ධ කර නොමැත.
එබැවින් අපි අපගේම සම්බන්ධතා සංචිතයක් අවශ්ය බව නිගමනය කළෙමු, එය සංවර්ධනය කර, පැච් කරන ලද, එමඟින් ගැටළු ඉක්මනින් විසඳීමට හැකි වන අතර, ඇත්ත වශයෙන්ම, බහු-නූල් විය යුතුය.
අපි ප්රධාන කාර්යය ලෙස multithreading සකස් කරමු. එන TLS සම්බන්ධතා රැල්ල හොඳින් හසුරුවා ගැනීමට අපට හැකි විය යුතුය.
මෙය සිදු කිරීම සඳහා, අපට Machinarium නමින් වෙනම පුස්තකාලයක් සංවර්ධනය කිරීමට සිදු විය, එය ජාල සම්බන්ධතාවයක යන්ත්‍ර තත්ත්වයන් අනුක්‍රමික කේතයක් ලෙස විස්තර කිරීමට නිර්මාණය කර ඇත. ඔබ libpq මූලාශ්‍ර කේතය දෙස බැලුවහොත්, ඔබට ප්‍රතිඵලයක් ලබා දිය හැකි ඉතා සංකීර්ණ ඇමතුම් කිහිපයක් ඔබට පෙනෙනු ඇති අතර, “මට පසුව අමතන්න. දැනට මට IO ඇත, නමුත් IO නැති වූ විට මට ප්‍රොසෙසරයේ බරක් ඇත. ” තවද මෙය බහු මට්ටමේ යෝජනා ක්රමයකි. ජාල සන්නිවේදනය සාමාන්යයෙන් රාජ්ය යන්ත්රයක් මගින් විස්තර කෙරේ. “මට කලින් N ප්‍රමාණයේ පැකට් ශීර්ෂයක් ලැබුණේ නම්, දැන් මම N බයිට් සඳහා බලා සිටිමි,” “මම SYNC පැකට්ටුවක් යැව්වා නම්, දැන් මම ප්‍රතිඵල පාරදත්ත සහිත පැකට්ටුවක් එනතුරු බලා සිටිමි” වැනි නීති ගොඩක්. එහි ප්‍රතිඵලය වන්නේ, වංකගිරිය රේඛා පරිලෝකනයට පරිවර්තනය කළාක් මෙන් තරමක් දුෂ්කර, ප්‍රතිවිරෝධී කේතයකි. අපි එය සෑදුවේ රාජ්ය යන්ත්රයක් වෙනුවට ක්‍රමලේඛකයා සාමාන්ය අත්‍යවශ්‍ය කේතයක් ආකාරයෙන් අන්තර්ක්‍රියා කිරීමේ ප්රධාන මාර්ගය විස්තර කරන පරිදි ය. මෙම අත්‍යවශ්‍ය කේතය තුළ ඔබට ජාලයෙන් දත්ත එනතෙක් බලා සිටීමෙන්, ක්රියාත්මක කිරීමේ සන්දර්භය වෙනත් coroutine (හරිත නූල්) වෙත යැවීමෙන් ක්රියාත්මක කිරීමේ අනුපිළිවෙලට බාධා කළ යුතු ස්ථාන ඇතුළත් කිරීමට අවශ්ය වේ. මෙම ප්‍රවේශය අපි වංකගිරියේ වඩාත්ම අපේක්ෂිත මාර්ගය පේළියකට ලියා එයට අතු එකතු කිරීමට සමාන වේ.
එහි ප්‍රතිඵලයක් වශයෙන්, TCP පිළිගැනීමට සහ රවුන්ඩ් රොබින් බොහෝ කම්කරුවන්ට TPC සම්බන්ධතාවක් ලබා දෙන එක් නූලක් අප සතුව ඇත.
මෙම අවස්ථාවේදී, සෑම සේවාදායක සම්බන්ධතාවයක්ම සෑම විටම එක් ප්රොසෙසරයක් මත ක්රියාත්මක වේ. තවද මෙය හැඹිලි-හිතකාමී බවට පත් කිරීමට ඔබට ඉඩ සලසයි.
තවද, පද්ධති TCP තොගය ඉවත් කිරීම සඳහා අපි කුඩා පැකට් එකතු කිරීම එක් විශාල පැකට්ටුවකට තරමක් වැඩි දියුණු කර ඇත.
මීට අමතරව, අපි Odyssey, වින්‍යාස කර ඇති විට, ජාල සම්බන්ධතා අසමත් වීමකදී අවලංගු කිරීම සහ ROLLBACK යැවිය හැකිය යන අර්ථයෙන් ගනුදෙනු එකතු කිරීම වැඩිදියුණු කර ඇත, එනම් ඉල්ලීම සඳහා කිසිවෙකු බලා නොසිටින්නේ නම්, Odyssey දත්ත ගබඩාවට පවසනු ඇත. වටිනා සම්පත් නාස්ති කළ හැකි ඉල්ලීම.
හැකි සෑම විටම, අපි එකම සේවාදායකයා සමඟ සම්බන්ධතා පවත්වන්නෙමු. මෙය application_name_add_host නැවත ස්ථාපනය කිරීම වළක්වයි. හැකි නම්, රෝග විනිශ්චය සඳහා අවශ්ය පරාමිතිවල අතිරේක යළි පිහිටුවීමක් අප සතුව නොමැත.
අපි Yandex.Cloud හි අවශ්යතා සඳහා වැඩ කරන්නෙමු. තවද ඔබ කළමනාකරණය කළ PostgreSQL භාවිතා කරන්නේ නම් සහ ඔබට සම්බන්ධතා සංචිතයක් ස්ථාපනය කර ඇත්නම්, ඔබට තාර්කික අනුකරණයක් පිටතින් නිර්මාණය කළ හැකිය, එනම් ඔබට අවශ්ය නම්, තාර්කික අනුකරණය භාවිතයෙන් අපෙන් ඉවත් වන්න. තාර්කික අනුකරණයේ ප්‍රවාහයෙන් පිටත බවුන්සර් ලබා නොදේ.
මෙය තාර්කික අනුකරණයක් සැකසීමේ උදාහරණයකි.
ඊට අමතරව, භෞතික අනුකරණය සඳහා අපට සහාය ඇත. වලාකුළෙහි, ඇත්ත වශයෙන්ම, එය කළ නොහැකි ය, මන්ද එවිට පොකුර ඔබට තමන් ගැන ඕනෑවට වඩා තොරතුරු ලබා දෙනු ඇත. නමුත් ඔබේ ස්ථාපනයන්හිදී, ඔබට Odyssey හි සම්බන්ධතා සංචිතය හරහා භෞතික අනුකරණයක් අවශ්ය නම්, එය කළ හැකිය.
Odyssey PgBouncer සමඟ සම්පුර්ණයෙන්ම අනුකූල අධීක්ෂණයක් ඇත. එකම විධාන සියල්ලම පාහේ ක්රියාත්මක කරන එකම කොන්සෝලය අප සතුව ඇත. යමක් අස්ථානගත වී ඇත්නම්, අදින්න ඉල්ලීමක් යවන්න, හෝ අවම වශයෙන් GitHub හි ගැටලුවක් තිබේ නම්, අපි අවශ්ය විධාන සම්පූර්ණ කරන්නෙමු. නමුත් අපි දැනටමත් PgBouncer කොන්සෝලයේ ප්රධාන ක්රියාකාරිත්වය ඇත.
ඇත්ත වශයෙන්ම අපට යොමු කිරීමේ දෝෂයක් ඇත. අපි පදනම විසින් වාර්තා කරන ලද දෝෂය නැවත ලබා දෙන්නෙමු. ඔබ පදනමේ නොසිටින්නේ මන්දැයි ඔබට තොරතුරු ලැබෙනු ඇත, ඔබ එහි නොමැති බව පමණක් නොවේ.
ඔබට PgBouncer සමඟ 100% ගැළපීමක් අවශ්ය නම් මෙම විශේෂාංගය අක්රිය කර ඇත. අපිට Bouncer කෙනෙක් වගේ හැසිරෙන්න පුළුවන්.
සංවර්ධනය
Odyssey මූල කේතය ගැන වචන කිහිපයක්.
උදාහරණයක් ලෙස, "Pause / Resume" විධාන ඇත. ඒවා සාමාන්යයෙන් දත්ත සමුදාය යාවත්කාලීන කිරීමට භාවිතා කරයි. ඔබට Postgres උත්ශ්‍රේණි කිරීමට අවශ්ය නම්, ඔබට එය සම්බන්ධතා සංචිතය තුළ විරාමයක් තබා, pg_upgrade එකක් කර, පසුව නැවත ආරම්භ කළ හැක. සේවාදායකයා පැත්තෙන්, දත්ත සමුදාය මන්දගාමී වන බවක් පෙනෙනු ඇත. මෙම ක්රියාකාරිත්වය අප වෙත ගෙන ආවේ ප්‍රජාවේ පුද්ගලයින් විසිනි. ඇය තවමත් මිය ගොස් නැත, නමුත් ඉක්මනින් සියල්ල සිදුවනු ඇත. (දැනටමත් මිය ගොස් ඇත)
- දැනටමත් මිය ගොස් ඇත
මීට අමතරව, PgBouncer හි ඇති එක් නව අංගයක් වන්නේ SCRAM සත්‍යාපන සහාය වන අතර එය Yandex.Cloud හි වැඩ නොකරන පුද්ගලයෙකු විසින් අප වෙත ගෙන එන ලදී. දෙකම සංකීර්ණ ක්රියාකාරිත්වය සහ වැදගත් වේ.
ඒ නිසා ඔයාලටත් දැන් code ටිකක් ලියන්න ඕන නම් Odyssey හදල තියෙන්නේ මොකක්ද කියල මම කියන්න කැමතියි.
ප්රධාන පුස්තකාල දෙකක් මත රඳා පවතින Odyssey මූලාශ්‍ර පදනම ඔබ සතුව ඇත. කිවි පුස්තකාලය යනු Postgres පණිවිඩ ප්රොටෝකෝලය ක්රියාත්මක කිරීමකි. එනම්, Postgres හි ස්වදේශික ප්‍රෝටෝ 3 යනු ඉදිරිපස සහ පසුපස අන්තයන්ට හුවමාරු කළ හැකි සම්මත පණිවිඩ වේ. ඒවා කිවි පුස්තකාලයේ ක්රියාත්මක වේ.
Machinarium පුස්තකාලය යනු නූල් ක්රියාත්මක කිරීමේ පුස්තකාලයකි. මෙම යන්ත්‍රාගාරයේ කුඩා කොටසක් එකලස් කිරීමේ යන්ත්‍රයෙන් ලියා ඇත. හැබැයි බය වෙන්න එපා පේලි 15යි තියෙන්නේ.
ඔඩිසි ගෘහ නිර්මාණ ශිල්පය. කෝරූටින් ක්රියාත්මක වන ප්රධාන යන්ත්රයක් තිබේ. මෙම යන්ත්‍රය මඟින් පැමිණෙන TCP සම්බන්ධතා පිළිගැනීම සහ ඒවා කම්කරුවන් අතර බෙදා හැරීම ක්රියාත්මක කරයි.
එක් සේවකයෙකු තුළ, ගනුදෙනුකරුවන් කිහිප දෙනෙකු සඳහා හසුරුවන්නෙකුට වැඩ කළ හැකිය. තවද ප්රධාන නූලෙහි, සංචිතයේ තවදුරටත් අවශ්ය නොවන සම්බන්ධතා ඉවත් කිරීම සඳහා කොන්සෝලය සහ ක්‍රෝන් කාර්යයන් සැකසීම කැරකෙමින් පවතී.
Odyssey සම්මත Postgres පරීක්ෂණ කට්ටලය භාවිතයෙන් පරීක්ෂා කරනු ලැබේ. අපි Bouncer හරහා ස්ථාපනය-පරීක්ෂා කිරීම ධාවනය කර Odyssey හරහා, අපට null div එකක් ලැබේ. Bouncer සහ Odyssey වලදී හරියටම සමත් නොවන දින හැඩතල ගැන්වීම සම්බන්ධ පරීක්ෂණ කිහිපයක් තිබේ.
මීට අමතරව, තමන්ගේම පරීක්ෂණ ඇති බොහෝ රියදුරන් ඇත. ඔඩිසි පරීක්ෂා කිරීමට අපි ඔවුන්ගේ පරීක්ෂණ භාවිතා කරමු.
එසේම, අපගේ කැස්කැඩින් වින්යාසය හේතුවෙන්, අපට විවිධ මිටි පරීක්ෂා කිරීමට සිදුවේ: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey කඳුරැල්ලේ ඕනෑම කොටසක Odyssey තිබේ නම්, එය තවමත් අපේක්ෂිත පරිදි ක්රියා කරයි. .
රාක්
අපි නිෂ්පාදනයේදී Odyssey භාවිතා කරනවා. අනික හැමදෙයක්ම හරියට වැඩ කරනවා කිව්වොත් සාධාරණ නැහැ. නැත, එනම්, ඔව්, නමුත් සෑම විටම නොවේ. උදාහරණයක් ලෙස, නිෂ්පාදනයේදී සෑම දෙයක්ම ක්රියාත්මක විය, පසුව PostgreSQL Professional හි අපගේ මිතුරන් පැමිණ අපට මතක කාන්දුවක් ඇති බව පැවසීය. ඒවා ඇත්තටම තිබුණා, අපි ඒවා නිවැරදි කළා. නමුත් එය සරල විය.
එවිට සම්බන්ධක සංචිතයේ එන TLS සම්බන්ධතා සහ පිටතට යන TLS සම්බන්ධතා ඇති බව අපට පෙනී ගියේය. සහ සම්බන්ධතා සඳහා සේවාදායක සහතික සහ සේවාදායක සහතික අවශ්ය වේ.
Bouncer සහ Odyssey සේවාදායක සහතික pcache මගින් නැවත කියවනු ලැබේ, නමුත් සේවාදායක සහතික pcache වෙතින් නැවත කියවීමට අවශ්ය නොවේ, මන්ද අපගේ පරිමාණය කළ හැකි Odyssey අවසානයේ මෙම සහතිකය කියවීමේ පද්ධති ක්රියාකාරිත්වය මත රඳා පවතී. ඔහු වහාම විවේක නොගත් නිසා මෙය අපට පුදුමයක් විය. මුලදී එය රේඛීයව පරිමාණය කරන ලද අතර, පැමිණෙන සමගාමී සම්බන්ධතා 20 කට පසුව, මෙම ගැටළුව ප්රකාශයට පත් විය.
Pluggable Authentication Method යනු බිල්ට්-ඉන් lunux මෙවලම් සමඟින් සත්‍යාපනය කිරීමේ හැකියාවයි. PgBouncer හි එය ක්රියාත්මක වන්නේ PAM වෙතින් ප්‍රතිචාරයක් බලාපොරොත්තුවෙන් සිටින වෙනම ත්‍රෙඩ් එකක් වන අතර වත්මන් සම්බන්ධතාවයට සේවය කරන ප්රධාන PgBouncer ත්‍රෙඩ් එකක් ඇති අතර ඔවුන්ට PAM ත්‍රෙඩ් එකේ ජීවත් වීමට ඉල්ලා සිටිය හැකිය.
අපි මෙය ක්රියාත්මක කළේ එක් සරල හේතුවක් නිසා නොවේ. අපට බොහෝ ධාරාවන් ඇත. අපට එය අවශ්ය වන්නේ ඇයි?
මෙහි ප්‍රතිඵලයක් වශයෙන්, ඔබට PAM සත්‍යාපනය සහ PAM නොවන සත්‍යාපනය තිබේ නම්, PAM සත්‍යාපනයේ විශාල රැල්ලක් PAM නොවන සත්‍යාපනය සැලකිය යුතු ලෙස ප්‍රමාද කළ හැකි බව මෙය ගැටළු ඇති කළ හැක. ඒක අපි හදල නැති දේවල් වලින් එකක්. නමුත් ඔබට එය නිවැරදි කිරීමට අවශ්ය නම්, ඔබට මෙය කළ හැකිය.
එන කනෙක්ෂන් සේරම පිලිගන්න එක ත්‍රෙඩ් එකක් අපිට තියන එකත් එක්ක තව පොරක් උනා. ඉන්පසු ඔවුන් කම්කරු සංචිතයට මාරු කරනු ලැබේ, එහිදී TLS අතට අත දීම සිදු වේ.
පහළම රේඛාව, ඔබට ජාල සම්බන්ධතා 20 ක සමෝධානික තරංගයක් තිබේ නම්, ඒවා සියල්ල පිළිගනු ලැබේ. සහ සේවාදායක පැත්තෙන්, libpq කල් ඉකුත්වීම් වාර්තා කිරීම ආරම්භ කරනු ඇත. පෙරනිමියෙන්, එය එහි තත්පර 000ක් වැනිය.
ඔවුන් සියල්ලන්ටම එකවර පාදයට ඇතුළු වීමට නොහැකි නම්, ඔවුන්ට පාදයට ඇතුළු විය නොහැක, මන්ද මේ සියල්ල ඝාතීය නොවන නැවත උත්සාහයකින් ආවරණය කළ හැකිය.
අපි මෙහි PgBouncer වෙතින් යෝජනා ක්‍රමය පිටපත් කළ බව අපි නිගමනය කළේ අප පිළිගන්නා TCP සම්බන්ධතා සංඛ්‍යාව ත්‍රොට්ල් කර ඇති බැවිනි.
අපි සම්බන්ධතා පිළිගන්නවා, නමුත් අවසානයේ ඔවුන්ට අතට අත දීමට වෙලාවක් නොමැති බව අපට පෙනේ නම්, අපි ඒවා CPU සම්පත් පරිභෝජනය නොකරන ලෙස පෝලිමේ තබමු. මෙය පැමිණ ඇති සියලුම සම්බන්ධතා සඳහා එකවර අතට අත දීමක් සිදු නොකළ හැකිය. නමුත් අඩුම තරමින් කවුරුන් හෝ දත්ත ගබඩාවට ඇතුළු වනු ඇත, බර ප්රමාණවත් තරම් ශක්තිමත් වුවද.
මාර්ග සිතියමක්
ඔබ අනාගතයේදී Odyssey හි දැකීමට කැමති කුමක්ද? අපව දියුණු කර ගැනීමට අප සූදානම් වන්නේ කුමක්ද සහ ප්‍රජාවෙන් අප අපේක්ෂා කරන්නේ කුමක්ද?
2019 අගෝස්තු සඳහා.
ඔඩිසි මාර්ග සිතියම අගෝස්තු මාසයේදී දිස් වූයේ මෙයයි:
- අපට SCRAM සහ PAM සත්‍යාපනය අවශ්ය විය.
- අපට කියවීමේ ඉල්ලීම් පොරොත්තුවෙන් ඉදිරිපත් කිරීමට අවශ්ය විය.
- මම සබැඳි-නැවත ආරම්භ කිරීමට කැමතියි.
- සහ සේවාදායකයේ විරාමයක් තැබීමේ හැකියාව.
මෙම මාර්ග සිතියමෙන් අඩක් කරන්නේ අප විසින් නොවේ. ඒ වගේම මේක හොඳයි. ඉතින් අපි ඉතිරිව ඇති දේ සාකච්ඡා කර තවත් එකතු කරමු.
? ඉල්ලීම් ඉටු නොකර සරලව වාතය රත් කරන අනුරූ අප සතුව ඇත. අපට ඔවුන් අසමත් වීම සහ මාරුවීම ලබා දීමට අවශ්යයි. එක් දත්ත මධ්‍යස්ථානයක ගැටළු ඇති වුවහොත්, මම ඒවා යම් ප්‍රයෝජනවත් වැඩකටයුතු කිරීමට කැමතියි. මක්නිසාද යත් අපට එකම මධ්‍යම ප්‍රොසෙසරය, එකම මතකය වෙනත් ආකාරයකින් වින්‍යාසගත කළ නොහැකි බැවිනි, මන්ද අනුකරණය වෙනත් ආකාරයකින් ක්රියා නොකරනු ඇත.
ප්‍රතිපත්තිමය වශයෙන්, Postgres හි, 10 සිට ආරම්භ වන විට, එය සම්බන්ධ කිරීමේදී session_attrs සඳහන් කළ හැකිය. ඔබට සම්බන්ධතාවයේ ඇති සියලුම දත්ත සමුදා ධාරක ලැයිස්තුගත කර ඔබ දත්ත සමුදායට යන්නේ මන්දැයි පැවසිය හැකිය: ලිවීමට හෝ කියවීමට පමණි. තවද, රියදුරු විසින්ම තමන් කැමති ලැයිස්තුවේ පළමු ධාරකය තෝරා ගනු ඇත, එය session_attrs හි අවශ්යතා සපුරාලයි.
නමුත් මෙම ප්‍රවේශයේ ඇති ගැටලුව වන්නේ එය ප්‍රතිනිර්මාණ ප්‍රමාදය පාලනය නොකිරීමයි. ඔබගේ සේවය සඳහා පිළිගත නොහැකි කාලයක් පිටුපසින් ඇති යම් ආකාරයක අනුරුවක් ඔබට තිබිය හැක. අනුරුවක කියවීමේ ඉල්ලීම් සම්පූර්ණ විශේෂාංග සහිතව ක්රියාත්මක කිරීම සඳහා, ඇත්ත වශයෙන්ම, කියවීමට නොහැකි වූ විට ක්රියා නොකිරීමේ හැකියාවට අපි Odyssey හි සහාය දැක්විය යුතුය.
Odyssey දත්ත ගබඩාවට විටින් විට ගොස් ප්‍රාථමිකයේ සිට ප්‍රතිනිර්මාණ දුර ප්‍රමාණය ඉල්ලා සිටිය යුතුය. එය සීමාවට ළඟා වී ඇත්නම්, දත්ත සමුදාය තුළට නව ඉල්ලීම් වලට ඉඩ නොදෙන්න, ඔබට සම්බන්ධතා නැවත ආරම්භ කිරීමට අවශ්ය බව සේවාදායකයාට පවසන්න සහ, සමහර විට, ඉල්ලීම් ක්රියාත්මක කිරීමට වෙනත් සත්කාරකයක් තෝරන්න. මෙමගින් දත්ත සමුදායට ප්‍රතිනිර්මාණ ප්‍රමාදය ඉක්මනින් ප්‍රතිසාධනය කිරීමට සහ විමසුමකින් ප්‍රතිචාර දැක්වීමට නැවත පැමිණීමට ඉඩ සලසයි.
එය විවෘත මූලාශ්‍රයක් බැවින් ක්රියාත්මක කිරීමේ දිනයන් නම් කිරීමට අපහසුය. නමුත්, මම බලාපොරොත්තු වෙනවා, PgBouncer හි සගයන් මෙන් වසර 2,5 ක් නොවේ. Odyssey හි මා දැකීමට කැමති විශේෂාංගය මෙයයි.
. දැන් ඔබට ආකාර දෙකකින් සකස් කළ ප්‍රකාශයක් සෑදිය හැකිය. පළමුව, ඔබට SQL විධානයක් ක්රියාත්මක කළ හැකිය, එනම් "සූදානම්". මෙම SQL විධානය තේරුම් ගැනීමට නම්, අපි Bouncer පැත්තෙන් SQL තේරුම් ගන්නේ කෙසේදැයි ඉගෙන ගත යුතුය. අපට සම්පූර්ණ විග්‍රහකයම අවශ්ය බැවින් මෙය අධික ලෙස කිල්මක් වනු ඇත. අපට සෑම SQL විධානයක්ම විග්‍රහ කළ නොහැක.
නමුත් proto3 හි පණිවිඩ ප්‍රොටෝකෝල මට්ටමින් සකස් කළ ප්‍රකාශයක් ඇත. තවද සකස් කරන ලද ප්‍රකාශයක් සාදනු ලබන බවට තොරතුරු ව්‍යුහගත ආකාරයෙන් පැමිණෙන ස්ථානය මෙයයි. සමහර සේවාදායක සම්බන්ධතාවයකදී සේවාදායකයා විසින් සකස් කරන ලද ප්‍රකාශයන් සෑදීමට ඉල්ලා සිටින බව තේරුම් ගැනීමට අපට සහාය විය හැකිය. ගනුදෙනුව වසා ඇතත්, සේවාදායකය සහ සේවාලාභියා අතර සම්බන්ධතාවය පවත්වා ගැනීමට අපට තවමත් අවශ්ය වේ.
නමුත් මෙහිදී සංවාදයේ විෂමතාවයක් පැන නගින්නේ, සේවාදායකයා විසින් නිර්මාණය කරන ලද ප්‍රකාශයන් මොනවාද යන්න ඔබ තේරුම් ගත යුතු බවත්, මෙම සේවාදායක සම්බන්ධතාවය නිර්මාණය කළ සියලුම සේවාදායකයින් අතර, එනම් එවැනි සකස් කළ ප්‍රකාශයක් නිර්මාණය කළේ කවුරුන්ද යන්නත් ඔබ තේරුම් ගත යුතු බව යමෙකු පවසන බැවිනි.
Andres Freund පැවසුවේ වෙනත් සේවාදායක සම්බන්ධතාවයක දැනටමත් එවැනි සූදානම් කළ ප්‍රකාශයක් නිර්මාණය කර ඇති සේවාදායකයෙකු ඔබ වෙත පැමිණියේ නම්, ඔහු වෙනුවෙන් එය නිර්මාණය කරන බවයි. නමුත් සේවාදායකයා වෙනුවට දත්ත ගබඩාවේ විමසුම් ක්රියාත්මක කිරීම තරමක් වැරදි බව පෙනේ, නමුත් දත්ත සමුදාය සමඟ අන්තර් ක්රියා කිරීම සඳහා ප්‍රොටෝකෝලයක් ලියන සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන්, ඔහුට සරලවම ජාල සම්බන්ධතාවයක් ලබා දුන්නේ නම් එය පහසු වනු ඇත. එහෙම සූදානම් කළ ඉල්ලීමක් තියෙනවා කියලා.
අපි ක්රියාත්මක කළ යුතු තවත් එක් අංගයක්. අපට දැන් PgBouncer සමඟ අනුකූල අධීක්ෂණයක් ඇත. අපට සාමාන්ය විමසුම් ක්රියාත්මක කිරීමේ කාලය ආපසු ලබා දිය හැක. නමුත් සාමාන්ය කාලය යනු රෝහලේ සාමාන්ය උෂ්ණත්වයයි: කවුරුහරි සීතලයි, කවුරුහරි උණුසුම්යි - සාමාන්යයෙන් හැමෝම සෞඛ්ය සම්පන්නයි. එය සත්‍යයක් නොවේ.
අපට ප්‍රතිශත සඳහා සහය ක්රියාත්මක කිරීමට අවශ්ය වන අතර, එමඟින් සම්පත් පරිභෝජනය කරන මන්දගාමී ඉල්ලීම් පවතින බවත්, අධීක්ෂණය වඩාත් පිළිගත හැකි බවත් පෙන්නුම් කරයි.
වැදගත්ම දෙය නම් මට 1.0 අනුවාදය අවශ්යයි (1.1 අනුවාදය දැනටමත් නිකුත් කර ඇත). කාරණය නම් Odyssey දැන් 1.0rc අනුවාදයේ ඇත, එනම් නිදහස් අපේක්ෂකයා. මතක කාන්දුව හැර මා ලැයිස්තුගත කර ඇති සියලුම ගැටළු හරියටම එකම අනුවාදයකින් විසඳා ඇත.
1.0 අනුවාදය අපට අදහස් කරන්නේ කුමක්ද? අපි ඔඩිසි අපේ කඳවුරුවලට ගෙන යනවා. එය දැනටමත් අපගේ දත්ත සමුදායන් මත ක්රියාත්මක වේ, නමුත් එය තත්පරයකට ඉල්ලීම් 1 දක්වා ළඟා වූ විට, අපට මෙය මුදා හැරීමේ අනුවාදයක් බවත් මෙය 000 ලෙස හැඳින්විය හැකි අනුවාදයක් බවත් පැවසිය හැකිය.
ප්‍රජාවේ කිහිප දෙනෙක් 1.0 අනුවාදයේ තවත් විරාමයක් සහ SCRAM ඉල්ලා ඇත. නමුත් මින් අදහස් වනුයේ SCRAM හෝ විරාමය තවම ඒකාබද්ධ කර නොමැති නිසා අපට ඊළඟ අනුවාදය නිෂ්පාදනය කිරීමට අවශ්ය වනු ඇති බවයි. එහෙත්, බොහෝ දුරට, මෙම ගැටළුව තරමක් ඉක්මනින් විසඳනු ඇත.
මම ඔබේ ඇදීමේ ඉල්ලීම බලා සිටිමි. Bouncer සමඟ ඔබට ඇති ගැටළු මොනවාදැයි ඇසීමටද මම කැමතියි. අපි ඒවා සාකච්ඡා කරමු. සමහර විට අපට ඔබට අවශ්ය කාර්යයන් කිහිපයක් ක්රියාත්මක කළ හැක.
මෙය මගේ කොටස අවසන් කරයි, මම ඔබෙන් ඇසීමට කැමතියි. ඔයාට ස්තූතියි!
ඔබගේ ප්රශ්න
මම මගේම application_name දැම්මොත්, Odyssey හි ගණුදෙණු එකතු කිරීමේදී එය නිවැරදිව විසි කරයිද?
ඔඩිසි හෝ බවුන්සර්?
ඔඩිසි හි. බවුන්සර් එක විසි වෙනවා.
අපි සෙට් එකක් හදමු.
තවද මගේ සැබෑ සම්බන්ධතාවය වෙනත් සම්බන්ධතා මත පැන්නේ නම්, එය සම්ප්‍රේෂණය වේවිද?
අපි ලැයිස්තුගත කර ඇති සියලුම පරාමිති කට්ටලයක් සාදන්නෙමු. Application_name මෙම ලැයිස්තුවේ තිබේදැයි මට කිව නොහැක. ඔහු එහිදී ඔහුව දුටු බව පෙනේ. අපි එකම පරාමිතීන් සකස් කරමු. එක් ඉල්ලීමක් සමඟ, කට්ටලය ආරම්භයේදී සේවාදායකයා විසින් ස්ථාපනය කරන ලද සියල්ල සිදු කරනු ඇත.
වාර්තාවට ස්තූතියි Andrey! හොඳ වාර්තාවක්! Odyssey සෑම මිනිත්තුවකම වේගයෙන් හා වේගයෙන් වර්ධනය වීම ගැන මම සතුටු වෙමි. මම එයම දිගටම කරගෙන යාමට කැමතියි. Odyssey හට එකවර විවිධ දත්ත සමුදායන් වෙත, එනම් slave master වෙත සම්බන්ධ වීමට හැකි වන පරිදි බහු දත්ත මූලාශ්‍ර සම්බන්ධතාවයක් ඇති කර ගැනීමට අපි දැනටමත් ඔබෙන් ඉල්ලා ඇත, පසුව අසාර්ථක වීමෙන් පසු ස්වයංක්‍රීයව නව මාස්ටර් වෙත සම්බන්ධ වන්න.
ඔව්, මට ඒ සාකච්ඡාව මතකයි වගේ. දැන් ගබඩා කිහිපයක් තිබේ. නමුත් ඔවුන් අතර මාරුවීමක් නොමැත. අපගේ පැත්තෙන්, අපි සේවාදායකය තවමත් ජීවමාන බව විමසිය යුතු අතර අසාර්ථක වීමක් සිදුවී ඇති බව තේරුම් ගත යුතුය, ඔවුන් pg_recovery අමතන්න. අපි ස්වාමියා වෙත නොපැමිණි බව තේරුම් ගැනීමට මට සම්මත ක්රමයක් තිබේ. අපි වැරදි වලින් කෙසේ හෝ තේරුම් ගත යුතුයි හෝ කෙසේද? එනම්, අදහස සිත්ගන්නා සුළුය, එය සාකච්ඡා වෙමින් පවතී. තවත් අදහස් ලියන්න. ඔබට C දන්නා වැඩ කරන අත් තිබේ නම්, මෙය සාමාන්යයෙන් අපූරු ය.
යෙදුම් සංවර්ධකයින් සඳහා අනුරූ පොකුරු සම්මත කිරීම හැකි තරම් සරල කිරීමට අපට අවශ්ය නිසා අනුරූ හරහා පරිමාණය කිරීමේ ප්‍රශ්නය ද අපට උනන්දුවක් දක්වයි. නමුත් මෙහිදී මම තවත් අදහස් දැක්වීමට කැමතියි, එනම් එය කරන්නේ කෙසේද, එය හොඳින් කරන්නේ කෙසේද.
ප්‍රශ්නය ද අනුපිටපත් ගැන ය. ඔබට ස්වාමියෙකු සහ අනුරූ කිහිපයක් ඇති බව පෙනේ. ඔවුන් සම්බන්ධතා සඳහා ස්වාමියාට වඩා අඩු වාර ගණනක් අනුරුව වෙත යන බව පැහැදිලිය, මන්ද ඔවුන්ට වෙනස්කම් තිබිය හැකි බැවිනි. දත්තවල වෙනස එය ඔබේ ව්‍යාපාරය තෘප්තිමත් නොවන පරිදි විය හැකි බවත්, එය ප්‍රතිනිර්මාණය වන තුරු ඔබ එහි නොයන බවත් ඔබ පැවසුවා. ඒ අතරම, ඔබ දිගු වේලාවක් එහි නොගොස්, පසුව යාමට පටන් ගත්තේ නම්, අවශ්ය දත්ත ක්ෂණිකව ලබා ගත නොහැක. එනම්, අපි නිරන්තරයෙන් මාස්ටර් වෙත ගියහොත්, එහි ඇති හැඹිලිය උණුසුම් වේ, නමුත් අනුරුවේ හැඹිලිය ටිකක් පසුගාමී වේ.
ඔව් ඒක ඇත්ත. ඔබට අවශ්ය pcache හි දත්ත අවහිර කිරීම් නොමැත, සැබෑ හැඹිලියේ ඔබට අවශ්ය වගු පිළිබඳ තොරතුරු නොමැත, සැලසුම්වල විග්‍රහ කළ විමසුම් නොමැත, කිසිවක් නැත.
ඔබට යම් ආකාරයක පොකුරක් ඇති විට, ඔබ එහි නව අනුරුවක් එකතු කරන විට, එය ආරම්භ වන විට, එහි ඇති සියල්ල නරක ය, එනම් එය එහි හැඹිලිය වැඩි කරයි.
මට අදහසක් ආවා. නිවැරදි ප්‍රවේශය වනුයේ ප්‍රථමයෙන් අනුරුව මත විමසුම් කුඩා ප්‍රතිශතයක් ධාවනය කිරීමයි, එය හැඹිලිය උණුසුම් කරයි. දළ වශයෙන් කිවහොත්, අපි ස්වාමියාට වඩා තත්පර 10 කට වඩා පිටුපසින් සිටිය යුතු කොන්දේසියක් ඇත. මෙම කොන්දේසිය එක් රැල්ලකට ඇතුළත් නොකළ යුතුය, නමුත් සමහර ගනුදෙනුකරුවන් සඳහා සුමටව.
ඔව්, බර වැඩි කරන්න.
මේක හොඳ අදහසක්. නමුත් පළමුව ඔබ මෙම වසා දැමීම ක්රියාත්මක කළ යුතුය. මුලින්ම අපි අක්රිය කළ යුතුයි, පසුව අපි සක්රිය කරන්නේ කෙසේද යන්න ගැන සිතා බලමු. මෙය සුමටව ක්රියාත්මක වීමට විශිෂ්ට අංගයකි.
nginx ට මෙම විකල්පය ඇත slowly start සේවාදායකය සඳහා පොකුරේ. තවද ඔහු ක්‍රමයෙන් බර ගොඩනඟයි.
ඔව්, නියම අදහසක්, අපි එය ලබා ගත් විට එය උත්සාහ කරමු.
මූලාශ්රය: www.habr.com