PostgreSQL වැරදි ඉවසීමේ ගැටලුවට අප ප්‍රවේශ වූයේ කෙසේද, එය අපට වැදගත් වූයේ ඇයි සහ අවසානයේ සිදුවූයේ කුමක්ද යන්න ලිපියෙන් මම ඔබට කියමි.
අපට අධික ලෙස පටවන ලද සේවාවක් ඇත: ලොව පුරා මිලියන 2,5 පරිශීලකයින්, සෑම දිනකම 50K+ ක්‍රියාකාරී පරිශීලකයින්. සේවාදායකයන් අයර්ලන්තයේ එක් කලාපයක ඇමසෝන් හි පිහිටා ඇත: විවිධ සේවාදායකයන් 100+ ක් නිරන්තරයෙන් ක්රියා කරයි, එයින් 50 කට ආසන්න සංඛ්‍යාවක් දත්ත සමුදායන් සමඟ ඇත.
සම්පූර්ණ පසුපෙළ යනු සේවාලාභියා සමඟ නිරන්තර වෙබ් සොකට් සම්බන්ධතාවක් තබා ගන්නා විශාල ඒකලිතික ප්‍රකාශිත ජාවා යෙදුමකි. පරිශීලකයන් කිහිප දෙනෙකු එකම පුවරුවක එකවර වැඩ කරන විට, ඔවුන් සියලු දෙනාම තත්‍ය කාලීන වෙනස්කම් දකිමු, මන්ද අපි එක් එක් වෙනස්කම දත්ත ගබඩාවට ලියන බැවිනි. අපගේ දත්ත සමුදායන් වෙත තත්පරයකට 10K පමණ ඉල්ලීම් ඇත. Redis හි උපරිම පැටවීමේදී, අපි තත්පරයකට 80-100K ඉල්ලීම් ලියන්නෙමු.
අපි Redis සිට PostgreSQL වෙත මාරු වූයේ ඇයි?
මුලදී, අපගේ සේවාව සේවාදායක RAM හි සියලුම දත්ත ගබඩා කරන ප්රධාන අගය ගබඩාවක් වන Redis සමඟ ක්රියා කළේය.
රෙඩිස්ගේ වාසි:
- ඉහළ ප්රතිචාර වේගය, නිසා සෑම දෙයක්ම මතකයේ ගබඩා කර ඇත;
- උපස්ථ සහ අනුකරණයේ පහසුව.
අපට Redis හි අවාසි:
- සැබෑ ගනුදෙනු නැත. අපි ඒවා අපගේ යෙදුමේ මට්ටමින් අනුකරණය කිරීමට උත්සාහ කළෙමු. අවාසනාවකට, මෙය සැමවිටම හොඳින් ක්රියා නොකළ අතර ඉතා සංකීර්ණ කේතයක් ලිවීමට අවශ්ය විය.
- මතක ප්‍රමාණය අනුව දත්ත ප්‍රමාණය සීමා වේ. දත්ත ප්‍රමාණය වැඩි වන විට, මතකය වර්ධනය වන අතර, අවසානයේදී, අපි තෝරාගත් අවස්ථාවෙහි ලක්ෂණ වෙත දිව යන්නෙමු, AWS හි උදාහරණ වර්ගය වෙනස් කිරීම සඳහා අපගේ සේවාව නැවැත්වීමට අවශ්ය වේ.
- අඩු ප්‍රමාද මට්ටමක් නිරන්තරයෙන් පවත්වා ගැනීම අවශ්ය වේ, මන්ද. අපට ඉතා විශාල ඉල්ලීම් ප්‍රමාණයක් ඇත. අපට ප්‍රශස්ත ප්‍රමාද මට්ටම 17-20 ms වේ. 30-40 ms මට්ටමකදී, අපගේ අයදුම්පත්‍රයේ ඉල්ලීම් සහ සේවාව පිරිහීම සඳහා අපට දිගු ප්රතිචාර ලැබේ. අවාසනාවකට මෙන්, මෙය අපට සිදු වූයේ 2018 සැප්තැම්බර් මාසයේදී, කිසියම් හේතුවක් නිසා රෙඩිස් සමඟ එක් අවස්ථාවකට වෙනදාට වඩා 2 ගුණයකින් ප්‍රමාදයක් ලැබුණු විටය. ගැටළුව විසඳීම සඳහා, අපි සැලසුම් නොකළ නඩත්තුව සඳහා මධ්‍යම රාත්‍රියේ සේවාව නවතා ගැටලුකාරී රෙඩිස් අවස්ථාව ප්‍රතිස්ථාපනය කළෙමු.
- කේතයේ සුළු දෝෂ සහිතව පවා දත්ත නොගැලපීම ලබා ගැනීම පහසු වන අතර පසුව මෙම දත්ත නිවැරදි කිරීම සඳහා කේතය ලිවීමට බොහෝ කාලයක් ගත වේ.
අපි අවාසි සැලකිල්ලට ගත් අතර සාමාන්ය ගනුදෙනු සහ ප්‍රමාදය මත අඩු යැපීම සමඟ වඩාත් පහසු දෙයකට යාමට අවශ්ය බව අපි තේරුම් ගත්තෙමු. පර්යේෂණ සිදු කර, බොහෝ විකල්ප විශ්ලේෂණය කර PostgreSQL තෝරා ගත්තේය.
අපි දැනටමත් වසර 1,5 ක් තිස්සේ නව දත්ත ගබඩාවකට මාරු වී ඇති අතර දත්ත වලින් කුඩා කොටසක් පමණක් ගෙන ගොස් ඇත, එබැවින් දැන් අපි Redis සහ PostgreSQL සමඟ එකවර වැඩ කරන්නෙමු. දත්ත සමුදායන් අතර දත්ත චලනය කිරීමේ සහ මාරු කිරීමේ අදියර පිළිබඳ වැඩි විස්තර ලියා ඇත .
අපි මුලින්ම ගමන් ආරම්භ කළ විට, අපගේ යෙදුම දත්ත සමුදාය සමඟ කෙලින්ම ක්රියා කළ අතර ප්රධාන Redis සහ PostgreSQL වෙත ප්‍රවේශ විය. PostgreSQL පොකුර ප්රධාන සහ අසමමුහුර්ත ප්‍රතිනිර්මාණයක් සහිත අනුරුවකින් සමන්විත විය. දත්ත සමුදා යෝජනා ක්රමය දිස් වූ ආකාරය මෙයයි:
PgBouncer ක්රියාත්මක කිරීම
අප ගමන් කරන අතරතුර, නිෂ්පාදිතය ද වර්ධනය වෙමින් පැවතුනි: PostgreSQL සමඟ වැඩ කරන පරිශීලකයින් සංඛ්යාව සහ සේවාදායක සංඛ්යාව වැඩි වූ අතර, අපට සම්බන්ධතා නොමැතිකම ආරම්භ විය. PostgreSQL එක් එක් සම්බන්ධතාවය සඳහා වෙනම ක්‍රියාවලියක් නිර්මාණය කර සම්පත් පරිභෝජනය කරයි. ඔබට නිශ්චිත ලක්ෂ්‍යයක් දක්වා සම්බන්ධතා ගණන වැඩි කළ හැකිය, එසේ නොමැතිනම් උප ප්‍රශස්ත දත්ත සමුදා ක්‍රියාකාරිත්වය ලබා ගැනීමට අවස්ථාවක් තිබේ. එවැනි තත්වයක් තුළ කදිම විකල්පය වනුයේ පදනම ඉදිරිපිට සිටින සම්බන්ධතා කළමනාකරුවෙකු තෝරා ගැනීමයි.
සම්බන්ධතා කළමනාකරු සඳහා අපට විකල්ප දෙකක් තිබුණි: Pgpool සහ PgBouncer. නමුත් පළමු එක දත්ත සමුදාය සමඟ වැඩ කිරීමේ ගනුදෙනු මාදිලියට සහය නොදක්වයි, එබැවින් අපි PgBouncer තෝරා ගත්තෙමු.
අපි පහත වැඩ යෝජනා ක්රමය සකසා ඇත: අපගේ යෙදුම එක් PgBouncer වෙත ප්‍රවේශ වන අතර, පිටුපස PostgreSQL මාස්ටර් සිටින අතර, එක් එක් ප්‍රධානියා පිටුපස අසමමුහුර්ත අනුකරණයක් සහිත එක් අනුරුවකි.
ඒ අතරම, අපට PostgreSQL හි සම්පූර්ණ දත්ත ප්‍රමාණය ගබඩා කළ නොහැකි වූ අතර දත්ත සමුදාය සමඟ වැඩ කිරීමේ වේගය අපට වැදගත් වූ බැවින් අපි යෙදුම් මට්ටමින් PostgreSQL බෙදා හැරීම ආරම්භ කළෙමු. ඉහත විස්තර කර ඇති යෝජනා ක්රමය මේ සඳහා සාපේක්ෂ වශයෙන් පහසු වේ: නව PostgreSQL shard එකක් එකතු කරන විට, PgBouncer වින්යාසය යාවත්කාලීන කිරීම ප්‍රමාණවත් වන අතර යෙදුමට වහාම නව කැබැල්ල සමඟ ක්රියා කළ හැකිය.
PgBouncer අසාර්ථක වීම
මෙම යෝජනා ක්රමය එකම PgBouncer අවස්ථාව මිය යන මොහොත දක්වා ක්රියාත්මක විය. අපි AWS හි සිටිමු, සියලු අවස්ථා කාලානුරූපව මිය යන දෘඪාංග මත ධාවනය වේ. එවැනි අවස්ථාවන්හිදී, නිදසුන සරලව නව දෘඪාංග වෙත ගොස් නැවත ක්රියා කරයි. මෙය PgBouncer සමඟ සිදු වූ නමුත් එය ලබා ගත නොහැකි විය. මෙම වැටීමේ ප්‍රතිඵලය වූයේ විනාඩි 25ක් අපගේ සේවාව ලබා ගැනීමට නොහැකි වීමයි. එකල අපේ රටේ ක්රියාත්මක නොවූ එවැනි තත්වයන් සඳහා පරිශීලක-පාර්ශවීය අතිරික්තය භාවිතා කිරීම AWS නිර්දේශ කරයි.
ඊට පසු, අපි PgBouncer සහ PostgreSQL පොකුරු වල වැරදි ඉවසීම ගැන බැරෑරුම් ලෙස සිතුවෙමු, මන්ද අපගේ AWS ගිණුමේ ඕනෑම අවස්ථාවක් සමඟ සමාන තත්වයක් සිදුවිය හැකි බැවිනි.
අපි PgBouncer දෝෂ ඉවසීමේ යෝජනා ක්රමය පහත පරිදි ගොඩනඟා ඇත්තෙමු: සියලුම යෙදුම් සේවාදායකයන් PgBouncers දෙකක් ඇති Network Load Balancer වෙත ප්‍රවේශ වේ. සෑම PgBouncer එකකම එකම PostgreSQL මාස්ටර් දෙස බලයි. AWS අවස්ථාවක් බිඳ වැටීමක් නැවත සිදුවුවහොත්, සියලුම ගමනාගමනය වෙනත් PgBouncer හරහා හරවා යවනු ලැබේ. Network Load Balancer අසාර්ථකත්වය සපයනු ලබන්නේ AWS විසිනි.
මෙම යෝජනා ක්රමය නව PgBouncer සේවාදායකයන් එකතු කිරීම පහසු කරයි.
PostgreSQL Failover Cluster එකක් සාදන්න
මෙම ගැටළුව විසඳන විට, අපි විවිධ විකල්ප සලකා බැලුවෙමු: ස්වයං-ලිඛිත අසාර්ථකත්වය, repmgr, AWS RDS, Patroni.
ස්වයං-ලිඛිත පිටපත්
ඔවුන්ට ප්‍රධානියාගේ කාර්යය නිරීක්ෂණය කළ හැකි අතර, එය අසාර්ථක වුවහොත්, අනුරුව ප්‍රධානියා වෙත ප්‍රවර්ධනය කර PgBouncer වින්යාසය යාවත්කාලීන කරන්න.
මෙම ප්‍රවේශයේ ඇති වාසි උපරිම සරලත්වයයි, මන්ද ඔබ විසින්ම ස්ක්‍රිප්ට් ලියන අතර ඒවා ක්රියා කරන ආකාරය හරියටම තේරුම් ගනී.
එය:
- ස්වාමියා මිය නොයන්නට ඇත, ඒ වෙනුවට ජාල අසාර්ථක වීමක් සිදු විය හැකිය. අසමත් වීම, මෙය නොදැන, අනුරුව ස්වාමියාට ප්‍රවර්ධනය කරනු ඇත, පැරණි මාස්ටර් දිගටම වැඩ කරනු ඇත. එහි ප්රතිඵලයක් වශයෙන්, අපට ප්‍රධානියාගේ භූමිකාව තුළ සේවාදායකයන් දෙකක් ලැබෙනු ඇති අතර ඒවායින් නවතම යාවත්කාලීන දත්ත ඇත්තේ කුමන ඒවාදැයි අපි නොදනිමු. මෙම තත්වය බෙදීම්-මොළය ලෙසද හැඳින්වේ;
- ප්‍රතිචාරයක් නැතිව අපි ගියා. අපගේ වින්යාසය තුළ, මාස්ටර් සහ එක් අනුරුව, මාරු වූ පසු, අනුරුව ප්‍රධානය වෙතට ගමන් කරන අතර අපට තවදුරටත් අනුරූ නොමැත, එබැවින් අපට නව අනුරුවක් අතින් එකතු කළ යුතුය;
- අපට PostgreSQL කැබලි 12 ක් ඇති අතර, අපට අසාර්ථක ක්‍රියාකාරිත්වය පිළිබඳ අමතර අධීක්ෂණයක් අවශ්ය වේ, එයින් අදහස් කරන්නේ අපට පොකුරු 12 ක් නිරීක්ෂණය කළ යුතු බවයි. කැබලි ගණන වැඩිවීමත් සමඟ, අසාර්ථකත්වය යාවත්කාලීන කිරීමටද ඔබ මතක තබා ගත යුතුය.
ස්වයං-ලිඛිත අසාර්ථකත්වය ඉතා සංකීර්ණ ලෙස පෙනෙන අතර සුළු නොවන සහාය අවශ්ය වේ. තනි PostgreSQL පොකුරක් සමඟ, මෙය පහසුම විකල්පය වනු ඇත, නමුත් එය පරිමාණය නොවේ, එබැවින් එය අපට සුදුසු නොවේ.
Repmgr
PostgreSQL පොකුරු ක්‍රියාකාරිත්වය කළමනාකරණය කළ හැකි PostgreSQL පොකුරු සඳහා අනුකරණ කළමනාකරු. ඒ අතරම, එය පෙට්ටියෙන් පිටත ස්වයංක්‍රීයව අසමත් වීමක් නොමැත, එබැවින් වැඩ සඳහා ඔබට නිමි විසඳුමට ඉහළින් ඔබේම “එතුම” ලිවිය යුතුය. එබැවින් සෑම දෙයක්ම ස්වයං-ලිඛිත ස්ක්‍රිප්ට් වලට වඩා සංකීර්ණ විය හැකිය, එබැවින් අපි Repmgr උත්සාහ කළේ නැත.
AWS RDS
අපට අවශ්ය සියල්ලට සහය දක්වයි, උපස්ථ කරන්නේ කෙසේදැයි දනී සහ සම්බන්ධතා සංචිතයක් පවත්වාගෙන යයි. එහි ස්වයංක්රීය මාරුවීමක් ඇත: ප්‍රධානියා මිය ගිය විට, අනුරුව නව මාස්ටර් බවට පත් වන අතර, AWS විසින් dns වාර්තාව නව මාස්ටර් වෙත වෙනස් කරන අතර, අනුරූ විවිධ AZ වල ස්ථානගත කළ හැක.
අවාසි අතර සියුම් ගැලපීම් නොමැතිකම ඇතුළත් වේ. සියුම් සුසර කිරීමේ උදාහරණයක් ලෙස: අපගේ නිදසුන් tcp සම්බන්ධතා සඳහා සීමාවන් ඇත, අවාසනාවකට මෙන්, RDS හි කළ නොහැක:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
මීට අමතරව, AWS RDS සාමාන්ය නිදර්ශන මිල මෙන් දෙගුණයක් පමණ මිල අධික වන අතර එය මෙම විසඳුම අත්හැරීමට ප්රධාන හේතුව විය.
පැට්රෝනි
මෙය හොඳ ලියකියවිලි, ස්වයංක්රීය අසාර්ථකත්වය සහ ගිතුබ් හි ප්‍රභව කේතය සමඟ PostgreSQL කළමනාකරණය කිරීම සඳහා වන පයිතන් අච්චුවකි.
Patroni හි වාසි:
- එක් එක් වින්යාස පරාමිතිය විස්තර කර ඇත, එය ක්රියා කරන ආකාරය පැහැදිලිය;
- ස්වයංක්රීය අසාර්ථකත්වය කොටුවෙන් පිටත ක්රියා කරයි;
- පයිතන් වලින් ලියා ඇති අතර, අප විසින්ම පයිතන් වලින් බොහෝ දේ ලියන බැවින්, ගැටළු සමඟ කටයුතු කිරීම අපට පහසු වනු ඇති අතර, සමහර විට, ව්‍යාපෘතියේ සංවර්ධනයට පවා උපකාර වනු ඇත;
- PostgreSQL සම්පූර්ණයෙන්ම කළමනාකරණය කරයි, ඔබට පොකුරේ සියලුම නෝඩ් වල වින්යාසය එකවර වෙනස් කිරීමට ඉඩ සලසයි, සහ නව වින්යාසය යෙදීම සඳහා පොකුර නැවත ආරම්භ කිරීමට අවශ්ය නම්, මෙය නැවත Patroni භාවිතයෙන් කළ හැකිය.
එය:
- PgBouncer සමඟ නිවැරදිව වැඩ කරන්නේ කෙසේද යන්න ලේඛනයෙන් පැහැදිලි නැත. එය අවාසියක් ලෙස හැඳින්වීමට අපහසු වුවද, Patroni හි කාර්යය වන්නේ PostgreSQL කළමනාකරණය කිරීම සහ Patroni වෙත සම්බන්ධතා යන්නේ කෙසේද යන්න දැනටමත් අපගේ ගැටලුවයි;
- විශාල වෙළුම් මත Patroni ක්රියාත්මක කිරීම සඳහා උදාහරණ කිහිපයක් ඇත, මුල සිට ක්රියාත්මක කිරීම සඳහා බොහෝ උදාහරණ ඇත.
එහි ප්රතිඵලයක් වශයෙන්, අසාර්ථක පොකුරක් නිර්මාණය කිරීමට අපි Patroni තෝරා ගත්තෙමු.
Patroni ක්රියාත්මක කිරීමේ ක්රියාවලිය
Patroni ට පෙර, අපි එක් master එකක වින්‍යාසයක PostgreSQL කැබලි 12 ක් සහ අසමමුහුර්ත ප්‍රතිනිර්මාණය සහිත එක් අනුරුවක සිටිමු. යෙදුම් සේවාදායකයන් Network Load Balancer හරහා දත්ත සමුදායන් වෙත ප්‍රවේශ විය, එහි පිටුපස PgBouncer සමඟ අවස්ථා දෙකක් තිබූ අතර ඒවා පිටුපස සියලුම PostgreSQL සේවාදායකයන් විය.
Patroni ක්රියාත්මක කිරීමට, අපට බෙදා හරින ලද ගබඩා පොකුරු වින්‍යාසයක් තෝරා ගැනීමට අවශ්ය විය. Patroni වැනි etcd, Zookeeper, Consul වැනි බෙදා හරින ලද වින්යාස ගබඩා පද්ධති සමඟ ක්රියා කරයි. අපට වෙළඳපොලේ සම්පූර්ණ කොන්සල් පොකුරක් ඇත, එය වෝල්ට් සමඟ එක්ව ක්රියා කරන අතර අපි එය තවදුරටත් භාවිතා නොකරමු. එහි අපේක්ෂිත අරමුණ සඳහා කොන්සල් භාවිතා කිරීම ආරම්භ කිරීමට හොඳ හේතුවක්.
Patroni කොන්සල් සමඟ වැඩ කරන ආකාරය
අප සතුව නෝඩ් තුනකින් සමන්විත කොන්සල් පොකුරක් සහ නායකයෙකු සහ අනුරුවකින් සමන්විත පැට්රෝනි පොකුරක් ඇත (පැට්රෝනි හි ස්වාමියා පොකුරු නායකයා ලෙසද වහලුන් අනුරූ ලෙසද හැඳින්වේ). Patroni පොකුරේ සෑම අවස්ථාවක්ම පොකුරේ තත්ත්වය පිළිබඳ තොරතුරු කොන්සල් වෙත නිරන්තරයෙන් යවයි. එබැවින්, කොන්සල් වෙතින් ඔබට සැමවිටම Patroni පොකුරේ වත්මන් වින්යාසය සහ මේ මොහොතේ නායකයා කවුදැයි සොයා ගත හැකිය.
Patroni කොන්සල් වෙත සම්බන්ධ කිරීම සඳහා, අපි කොන්සල් සමඟ වැඩ කරන ආකාරය සහ සම්බන්ධතා යෝජනා ක්රමය මත පදනම්ව, ඔබට http හෝ https ආකෘතියෙන් ධාරකයක් නියම කිරීමට අවශ්ය බව පවසන නිල ලේඛන අධ්‍යයනය කිරීම ප්‍රමාණවත් වේ:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpඑය සරල බව පෙනේ, නමුත් මෙහි අන්තරායන් ආරම්භ වේ. කොන්සල් සමඟ, අපි https හරහා ආරක්ෂිත සම්බන්ධතාවයක් හරහා වැඩ කරන අතර අපගේ සම්බන්ධතා වින්යාසය මේ ආකාරයෙන් පෙනෙනු ඇත:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}ඒත් ඒක හරියන්නෙ නෑ. ආරම්භයේදී, Patroni හට කොන්සල් වෙත සම්බන්ධ විය නොහැක, මන්ද එය කෙසේ හෝ http හරහා යාමට උත්සාහ කරයි.
Patroni හි මූල කේතය ගැටලුව සමඟ කටයුතු කිරීමට උපකාරී විය. ඒක python වලින් ලියලා තියෙන එක හොඳයි. ධාරක පරාමිතිය කිසිඳු ආකාරයකින් විග්‍රහ කර නොමැති අතර ප්‍රොටෝකෝලය යෝජනා ක්‍රමයේ සඳහන් කළ යුතු බව පෙනේ. කොන්සල් සමඟ වැඩ කිරීම සඳහා වැඩ කරන වින්යාස කොටස අපට පෙනෙන්නේ එලෙස ය:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}කොන්සල්-සැකිල්ල
එබැවින්, අපි වින්යාසය සඳහා ගබඩාව තෝරාගෙන ඇත. Patroni පොකුරේ නායකයා වෙනස් කිරීමේදී PgBouncer එහි වින්යාසය මාරු කරන්නේ කෙසේදැයි දැන් අප තේරුම් ගත යුතුය. ලේඛනයේ මෙම ප්රශ්නයට පිළිතුරක් නොමැත, මන්ද. එහිදී, ප්‍රතිපත්තිමය වශයෙන්, PgBouncer සමඟ වැඩ කිරීම විස්තර කර නොමැත.
විසඳුමක් සෙවීමේදී, අපට ලිපියක් හමු විය (අවාසනාවකට මට මාතෘකාව මතක නැත) එහි ලියා ඇත්තේ Сonsul-template PgBouncer සහ Patroni යුගල කිරීම සඳහා බොහෝ උපකාර කළ බවයි. මෙය Consul-template ක්රියා කරන ආකාරය විමර්ශනය කිරීමට අපව පොළඹවන ලදී.
කොන්සල්-සැකිල්ල කොන්සල් හි PostgreSQL පොකුරේ වින්යාසය නිරන්තරයෙන් අධීක්ෂණය කරන බව පෙනී ගියේය. නායකයා වෙනස් වූ විට, එය PgBouncer වින්යාසය යාවත්කාලීන කර එය නැවත පූරණය කිරීමට විධානයක් යවයි.
අච්චුවේ විශාල ප්ලස් එකක් නම් එය කේතයක් ලෙස ගබඩා කර තිබීමයි, එබැවින් නව කැබැල්ලක් එක් කරන විට, නව කැපවීමක් කර අච්චුව ස්වයංක්‍රීයව යාවත්කාලීන කිරීම ප්‍රමාණවත් වේ, කේත මූලධර්මය ලෙස යටිතල පහසුකම් සඳහා සහය දක්වයි.
Patroni සමඟ නව ගෘහ නිර්මාණ ශිල්පය
එහි ප්රතිඵලයක් වශයෙන්, අපට පහත සඳහන් වැඩ යෝජනා ක්රමය ලැබුණි:
සියලුම යෙදුම් සේවාදායකයන් balancer වෙත ප්‍රවේශ වේ → එය පිටුපස PgBouncer අවස්ථා දෙකක් ඇත → සෑම අවස්ථාවකදීම, කොන්සල්-සැකිල්ල දියත් කරනු ලැබේ, එය එක් එක් Patroni පොකුරේ තත්ත්වය නිරීක්ෂණය කරන අතර PgBouncer වින්‍යාසයේ අදාළත්වය නිරීක්ෂණය කරයි, එය වත්මන් නායකයාට ඉල්ලීම් යවයි. එක් එක් පොකුරේ.
අතින් පරීක්ෂා කිරීම
අපි මෙම යෝජනා ක්රමය කුඩා පරීක්ෂණ පරිසරයක් මත දියත් කිරීමට පෙර ක්රියාත්මක කර ස්වයංක්රීය මාරු කිරීමේ ක්‍රියාකාරිත්වය පරීක්ෂා කළෙමු. ඔවුන් පුවරුව විවෘත කර, ස්ටිකරය ගෙන ගිය අතර, ඒ මොහොතේ ඔවුන් පොකුරේ නායකයා "මරා" ඇත. AWS හි, මෙය කොන්සෝලය හරහා නිදසුන වසා දැමීම තරම් සරල ය.
ස්ටිකරය තත්පර 10-20 කින් ආපසු හැරී, පසුව නැවතත් සාමාන්යයෙන් චලනය වීමට පටන් ගත්තේය. මෙයින් අදහස් කරන්නේ Patroni පොකුර නිවැරදිව ක්රියා කළ බවයි: එය නායකයා වෙනස් කර, තොරතුරු Сonsul වෙත යවා, සහ Сonsul-template වහාම මෙම තොරතුරු ලබාගෙන, PgBouncer වින්යාසය ප්‍රතිස්ථාපනය කර නැවත පූරණය කිරීමට විධානය යවා ඇත.
අධික බරක් යටතේ දිවි ගලවා ගන්නේ කෙසේද සහ අක්‍රීය කාලය අවම කර ගන්නේ කෙසේද?
සෑම දෙයක්ම පරිපූර්ණව ක්රියා කරයි! නමුත් නව ප්රශ්න තිබේ: එය අධික බරක් යටතේ ක්රියා කරන්නේ කෙසේද? නිෂ්පාදනයේ සෑම දෙයක්ම ඉක්මනින් හා ආරක්ෂිතව පෙරළන්නේ කෙසේද?
අප බර පරීක්ෂාව සිදු කරන පරීක්ෂණ පරිසරය අපට පළමු ප්රශ්නයට පිළිතුරු දීමට උපකාරී වේ. එය ගෘහ නිර්මාණ ශිල්පය අනුව නිෂ්පාදනයට සම්පූර්ණයෙන්ම සමාන වන අතර නිෂ්පාදනයට පරිමාව ආසන්න වශයෙන් සමාන වන පරීක්ෂණ දත්ත ජනනය කර ඇත. පරීක්ෂණය අතරතුර PostgreSQL මාස්ටර්ගෙන් එක් අයෙකු "මරා දැමීමට" අපි තීරණය කර සිදුවන්නේ කුමක්දැයි බලන්න. නමුත් ඊට පෙර, ස්වයංක්රීය පෙරළීම පරීක්ෂා කිරීම වැදගත් වේ, මන්ද මෙම පරිසරයේ අපට PostgreSQL කැබලි කිහිපයක් ඇති බැවින් නිෂ්පාදනයට පෙර වින්යාස ස්ක්‍රිප්ට් පිළිබඳ විශිෂ්ට පරීක්ෂණයක් අපට ලැබෙනු ඇත.
කාර්යයන් දෙකම අභිලාෂකාමී ලෙස පෙනේ, නමුත් අපට PostgreSQL 9.6 ඇත. අපට වහාම 11.2 වෙත යාවත්කාලීන කළ හැකිද?
අපි එය පියවර 2 කින් කිරීමට තීරණය කරමු: පළමුව 11.2 වෙත උත්ශ්රේණි කරන්න, පසුව Patroni දියත් කරන්න.
PostgreSQL යාවත්කාලීන කිරීම
PostgreSQL අනුවාදය ඉක්මනින් යාවත්කාලීන කිරීමට, විකල්පය භාවිතා කරන්න -k, තැටියේ දෘඪ සබැඳි නිර්මාණය කර ඇති අතර ඔබේ දත්ත පිටපත් කිරීමට අවශ්ය නොවේ. 300-400 GB පදනම මත, යාවත්කාලීන කිරීම තත්පර 1 ක් ගතවේ.
අපිට ගොඩක් කෑලි තියෙනවා, ඒ නිසා යාවත්කාලීන කිරීම ස්වයංක්‍රීයව කළ යුතුයි. මෙය සිදු කිරීම සඳහා, අපි අප වෙනුවෙන් සම්පූර්ණ යාවත්කාලීන ක්රියාවලිය හසුරුවන Ansible playbook එකක් ලිව්වෙමු:
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='උත්ශ්රේණි කිරීම ආරම්භ කිරීමට පෙර, ඔබ පරාමිතිය සමඟ එය ඉටු කළ යුතු බව මෙහිදී සැලකිල්ලට ගැනීම වැදගත්ය --චෙක් පතඔබට උත්ශ්රේණි කළ හැකි බව තහවුරු කර ගැනීමට. උත්ශ්‍රේණිගත කිරීමේ කාලසීමාව සඳහා අපගේ ස්ක්‍රිප්ට් මඟින් වින්යාස ආදේශ කිරීම ද සිදු කරයි. අපගේ ස්ක්‍රිප්ට් තත්පර 30කින් අවසන් වූ අතර එය විශිෂ්ට ප්‍රතිඵලයකි.
Patroni දියත් කරන්න
දෙවන ගැටළුව විසඳීම සඳහා, Patroni වින්යාසය දෙස බලන්න. නිල ගබඩාවේ initdb සමඟ උදාහරණ වින්‍යාසයක් ඇත, එය ඔබ මුලින්ම Patroni ආරම්භ කරන විට නව දත්ත සමුදායක් ආරම්භ කිරීම සඳහා වගකිව යුතුය. නමුත් අපට දැනටමත් සූදානම් කළ දත්ත සමුදායක් ඇති බැවින්, අපි මෙම කොටස වින්‍යාසයෙන් ඉවත් කළෙමු.
අපි දැනටමත් පවතින PostgreSQL පොකුරක් මත Patroni ස්ථාපනය කර එය ක්රියාත්මක කිරීම ආරම්භ කළ විට, අපි නව ගැටලුවකට මුහුණ දුන්නෙමු: සේවාදායකයන් දෙකම නායකයෙකු ලෙස ආරම්භ විය. පැට්රෝනි පොකුරේ මුල් තත්ත්වය ගැන කිසිවක් නොදන්නා අතර සර්වර් දෙකම එකම නමින් වෙනම පොකුරු දෙකක් ලෙස ආරම්භ කිරීමට උත්සාහ කරයි. මෙම ගැටළුව විසඳීම සඳහා, ඔබ දාසයේ දත්ත සහිත නාමාවලිය මකා දැමිය යුතුය:
rm -rf /var/lib/postgresql/මෙය කළ යුත්තේ වහලා මත පමණි!
පිරිසිදු අනුරුවක් සම්බන්ධ කළ විට, පැට්රෝනි බේස්බැක්අප් නායකයෙකු සාදා එය අනුරුවට ප්‍රතිසාධනය කරයි, පසුව වල් ලොග් වලට අනුව වත්මන් තත්වය අල්ලා ගනී.
අප මුහුණ දුන් තවත් දුෂ්කරතාවයක් නම් සියලුම PostgreSQL පොකුරු පෙරනිමියෙන් ප්රධාන ලෙස නම් කර තිබීමයි. සෑම පොකුරක්ම අනෙකා ගැන කිසිවක් නොදන්නා විට, මෙය සාමාන්ය වේ. නමුත් ඔබට Patroni භාවිතා කිරීමට අවශ්ය වූ විට, සියලුම පොකුරු වලට අනන්‍ය නමක් තිබිය යුතුය. විසඳුම වන්නේ PostgreSQL වින්යාසය තුළ පොකුරු නම වෙනස් කිරීමයි.
පැටවීමේ පරීක්ෂණය
අපි පුවරු මත පරිශීලක අත්දැකීම් අනුකරණය කරන පරීක්ෂණයක් දියත් කර ඇත. භාරය අපගේ සාමාන්ය දෛනික අගයට ළඟා වූ විට, අපි එම පරීක්ෂණයම නැවත නැවතත් කළෙමු, අපි PostgreSQL නායකයා සමඟ එක් අවස්ථාවක් අක්‍රිය කළෙමු. ස්වයංක්රීය අසාර්ථකත්වය අප බලාපොරොත්තු වූ පරිදි ක්රියාත්මක විය: Patroni නායකයා වෙනස් කළේය, කොන්සල්-සැකිල්ල PgBouncer වින්යාසය යාවත්කාලීන කර නැවත පූරණය කිරීමට විධානයක් යවන ලදී. Grafana හි අපගේ ප්‍රස්ථාරවලට අනුව, දත්ත සමුදායට සම්බන්ධ කිරීම හා සම්බන්ධ සේවාදායකයන්ගෙන් තත්පර 20-30 අතර ප්‍රමාදයන් සහ කුඩා දෝෂ ප්‍රමාණයක් ඇති බව පැහැදිලි විය. මෙය සාමාන්ය තත්වයකි, එවැනි අගයන් අපගේ අසාර්ථකත්වය සඳහා පිළිගත හැකි අතර සේවා අක්‍රිය කාලයට වඩා නියත වශයෙන්ම හොඳය.
Patroni නිෂ්පාදනයට ගෙන ඒම
එහි ප්රතිඵලයක් වශයෙන්, අපි පහත සැලැස්ම ඉදිරිපත් කළෙමු:
- PgBouncer සේවාදායකයන් වෙත කොන්සල්-සැකිල්ල යොදවා දියත් කරන්න;
- PostgreSQL 11.2 අනුවාදයට යාවත්කාලීන;
- පොකුරේ නම වෙනස් කරන්න;
- Patroni Cluster ආරම්භ කිරීම.
ඒ අතරම, අපගේ යෝජනා ක්රමය අපට ඕනෑම වේලාවක පාහේ පළමු කරුණ ඉදිරිපත් කිරීමට ඉඩ සලසයි, අපට එක් එක් PgBouncer එක එක වැඩවලින් ඉවත් කර ඒ මත කොන්සල් සැකිල්ල යෙදවීමට සහ ක්රියාත්මක කිරීමට හැකිය. ඉතින් අපි කළා.
ඉක්මන් යෙදවීම සඳහා, අපි Ansible භාවිතා කළෙමු, මන්ද අපි දැනටමත් සියලුම ක්‍රීඩා පොත් පරීක්ෂණ පරිසරයක් මත පරීක්ෂා කර ඇති අතර, සම්පූර්ණ ස්ක්‍රිප්ට් ක්රියාත්මක කිරීමේ කාලය එක් එක් කැබැල්ලක් සඳහා මිනිත්තු 1,5 සිට 2 දක්වා විය. අපගේ සේවාව නතර නොකර අපට සෑම දෙයක්ම එක් එක් කැබලිවලට මාරු කළ හැකිය, නමුත් අපට සෑම PostgreSQL මිනිත්තු කිහිපයක්ම ක්රියා විරහිත කිරීමට සිදුවේ. මෙම අවස්ථාවේදී, මෙම කොටසෙහි දත්ත ඇති පරිශීලකයින්ට මෙම අවස්ථාවේදී සම්පුර්ණයෙන්ම ක්රියා කළ නොහැකි අතර මෙය අපට පිළිගත නොහැකිය.
මෙම තත්වයෙන් මිදීමට මාර්ගය වූයේ සෑම මාස 3 කට වරක් සිදු වන සැලසුම්ගත නඩත්තුවයි. අපි අපගේ සේවාව සම්පූර්ණයෙන්ම වසා දමා අපගේ දත්ත සමුදා අවස්ථා උත්ශ්රේණි කරන විට, මෙය නියමිත වැඩ සඳහා කවුළුවකි. ඊළඟ කවුළුව තෙක් සතියක් ඉතිරිව ඇති අතර, අපි බලා සිට තවදුරටත් සූදානම් වීමට තීරණය කළෙමු. පොරොත්තු කාලය තුළ, අපි අමතර වශයෙන් අපව ආරක්‍ෂා කර ගත්තෙමු: එක් එක් PostgreSQL shard සඳහා, නවතම දත්ත තබා ගැනීමට අපොහොසත් වුවහොත් අපි අමතර අනුරුවක් මතු කළ අතර, එක් එක් කොටස සඳහා නව අවස්ථාවක් එකතු කළෙමු, එය Patroni පොකුරේ නව අනුරුවක් බවට පත් විය යුතුය. දත්ත මකා දැමීම සඳහා විධානයක් ක්රියාත්මක නොකිරීමට . මේ සියල්ල දෝෂ අවදානම අවම කිරීමට උපකාරී විය.
අපි අපගේ සේවාව නැවත ආරම්භ කළෙමු, සෑම දෙයක්ම කළ යුතු පරිදි ක්රියාත්මක විය, පරිශීලකයින් දිගටම වැඩ කරමින් සිටියෙමු, නමුත් ප්‍රස්ථාරවල කොන්සල් සේවාදායකයන් මත අසාමාන්‍ය ලෙස ඉහළ බරක් ඇති බව අපි දුටුවෙමු.
ඇයි අපි මේක පරීක්ෂණ පරිසරයේ දැක්කේ නැත්තේ? යටිතල ව්‍යුහය කේත මූලධර්මය ලෙස අනුගමනය කිරීම සහ පරීක්ෂණ පරිසරයේ සිට නිෂ්පාදනය දක්වා සමස්ත යටිතල ව්‍යුහයම පිරිපහදු කිරීම අවශ්ය බව මෙම ගැටලුව මනාව විදහා දක්වයි. එසේ නොමැති නම්, අපට ඇති වූ ගැටලුව ලබා ගැනීම ඉතා පහසු ය. සිදුවුයේ කුමක් ද? කොන්සල් මුලින්ම නිෂ්පාදනය මත පෙනී සිටි අතර, පසුව පරීක්ෂණ පරිසරයන් මත, ප්රතිඵලයක් වශයෙන්, පරීක්ෂණ පරිසරයන් මත, කොන්සල් අනුවාදය නිෂ්පාදනයට වඩා ඉහළ විය. එක් නිකුතුවක දී, කොන්සල්-සැකිල්ල සමඟ වැඩ කිරීමේදී CPU කාන්දුවක් විසඳා ඇත. එබැවින්, අපි හුදෙක් කොන්සල් යාවත්කාලීන කර, ගැටළුව විසඳා ගත්තෙමු.
Patroni පොකුර නැවත ආරම්භ කරන්න
කෙසේ වෙතත්, අපට නව ගැටළුවක් ඇති විය, එය අප සැක නොකළෙමු. කොන්සල් යාවත්කාලීන කිරීමේදී, අපි කොන්සල් නිවාඩු විධානය භාවිතා කර පොකුරෙන් කොන්සල් නෝඩය ඉවත් කරමු → පැට්රෝනි වෙනත් කොන්සල් සේවාදායකයකට සම්බන්ධ කරයි → සියල්ල ක්රියාත්මක වේ. නමුත් අපි කොන්සල් පොකුරේ අවසාන අවස්ථාවට පැමිණ කොන්සල් නිවාඩු විධානය එවූ විට, සියලුම පැට්රෝනි පොකුරු සරලව නැවත ආරම්භ වූ අතර, ලොග් වල අපට පහත දෝෂය දක්නට ලැබුණි:
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>Patroni පොකුරට එහි පොකුර පිළිබඳ තොරතුරු ලබා ගැනීමට නොහැකි වූ අතර නැවත ආරම්භ විය.
විසඳුමක් සෙවීම සඳහා, අපි github හි ගැටලුවක් හරහා Patroni කතුවරුන් සම්බන්ධ කර ගත්තෙමු. ඔවුන් අපගේ වින්යාස ගොනු සඳහා වැඩිදියුණු කිරීම් යෝජනා කරන ලදී:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8අපට පරීක්ෂණ පරිසරයක් මත ගැටලුව ප්‍රතිනිර්මාණය කිරීමට හැකි වූ අතර එහිදී මෙම විකල්පයන් පරීක්ෂා කළ නමුත්, අවාසනාවන්ත ලෙස ඒවා ක්රියා කළේ නැත.
ගැටලුව තවමත් නොවිසඳී පවතී. අපි පහත විසඳුම් උත්සාහ කිරීමට සැලසුම් කරමු:
- එක් එක් Patroni පොකුරු අවස්ථාවන්හිදී කොන්සල් නියෝජිතයා භාවිතා කරන්න;
- කේතයේ ඇති ගැටළුව විසඳන්න.
දෝෂය සිදුවූයේ කොතැනද යන්න අපට වැටහෙනවා: ගැටළුව බොහෝ විට පෙරනිමි කල් ඉකුත්වීම භාවිතා කිරීම විය හැකිය, එය වින්යාස ගොනුව හරහා ප්‍රතිස්ථාපනය නොවේ. අන්තිම කොන්සල් සර්වර් එක පොකුරෙන් අයින් කළාම මුළු කොන්සල් පොකුරම තත්පරයකට වඩා එල්ලෙනවා, මේ නිසා පැට්‍රෝනිට පොකුරේ තත්ත්වය ලබාගන්න බැරිවෙලා සම්පූර්ණ පොකුර සම්පූර්ණයෙන්ම නැවත පණ ගන්වනවා.
වාසනාවකට මෙන්, අපට තවත් දෝෂ හමු නොවීය.
Patroni භාවිතා කිරීමේ ප්රතිඵල
Patroni සාර්ථකව දියත් කිරීමෙන් පසුව, අපි සෑම පොකුරකම අතිරේක අනුරුවක් එකතු කළා. දැන් සෑම පොකුරකම ගණපූරණයක සමානකමක් ඇත: එක් නායකයෙක් සහ අනුරූ දෙකක්, මාරු කිරීමේදී මොළය බෙදීමකදී ආරක්ෂිත දැලක් සඳහා.
Patroni මාස තුනකට වැඩි කාලයක් නිෂ්පාදනය මත වැඩ කර ඇත. මෙම කාලය තුළ, ඔහු දැනටමත් අපට උදව් කිරීමට සමත් වී ඇත. මෑතකදී, එක් පොකුරු නායකයා AWS හි මිය ගියේය, ස්වයංක්රීය අසමත් වීම ක්රියාත්මක වූ අතර පරිශීලකයින් දිගටම වැඩ කළහ. Patroni එහි ප්රධාන කාර්යය ඉටු කළේය.
Patroni භාවිතය පිළිබඳ කුඩා සාරාංශයක්:
- වින්යාස වෙනස් කිරීමේ පහසුව. එක් අවස්ථාවකදී වින්යාසය වෙනස් කිරීම ප්‍රමාණවත් වන අතර එය සම්පූර්ණ පොකුරටම ඇදී යනු ඇත. නව වින්යාසය යෙදීමට නැවත පණගැන්වීමක් අවශ්ය නම්, එවිට Patroni ඔබට දන්වනු ඇත. Patroni හට තනි විධානයකින් සම්පූර්ණ පොකුර නැවත ආරම්භ කළ හැකි අතර එයද ඉතා පහසු වේ.
- ස්වයංක්රීය අසාර්ථකත්වය ක්රියා කරන අතර දැනටමත් අපට උදව් කිරීමට සමත් වී ඇත.
- යෙදුම් අක්‍රිය කාලයකින් තොරව PostgreSQL යාවත්කාලීන කිරීම. ඔබ මුලින්ම අනුරූ නව අනුවාදයට යාවත්කාලීන කළ යුතුය, පසුව Patroni පොකුරේ නායකයා වෙනස් කර පැරණි නායකයා යාවත්කාලීන කළ යුතුය. මෙම අවස්ථාවෙහිදී, ස්වයංක්රීය අසමත් වීම පිළිබඳ අවශ්ය පරීක්ෂණය සිදු වේ.
මූලාශ්රය: www.habr.com