இந்த கட்டுரையில் நான் PostgreSQL தவறு சகிப்புத்தன்மையின் சிக்கலை எவ்வாறு அணுகினோம், அது ஏன் எங்களுக்கு முக்கியமானது மற்றும் இறுதியில் என்ன நடந்தது என்பதை நான் உங்களுக்கு கூறுவேன்.
எங்களிடம் அதிக ஏற்றப்பட்ட சேவை உள்ளது: உலகளவில் 2,5 மில்லியன் பயனர்கள், ஒவ்வொரு நாளும் 50K+ செயலில் உள்ள பயனர்கள். அயர்லாந்தின் ஒரு பகுதியில் உள்ள அமேசானில் சேவையகங்கள் அமைந்துள்ளன: 100+ வெவ்வேறு சேவையகங்கள் தொடர்ந்து செயல்பாட்டில் உள்ளன, அவற்றில் கிட்டத்தட்ட 50 தரவுத்தளங்கள் உள்ளன.
முழு பின்தளமும் ஒரு பெரிய மோனோலிதிக் ஸ்டேட்ஃபுல் ஜாவா பயன்பாடாகும், இது கிளையண்டுடன் தொடர்ந்து வெப்சாக்கெட் இணைப்பைப் பராமரிக்கிறது. ஒரே பலகையில் பல பயனர்கள் ஒரே நேரத்தில் பணிபுரியும் போது, அவர்கள் அனைவரும் உண்மையான நேரத்தில் மாற்றங்களைக் காண்கிறார்கள், ஏனெனில் தரவுத்தளத்தில் ஒவ்வொரு மாற்றத்தையும் நாங்கள் பதிவு செய்கிறோம். எங்கள் தரவுத்தளங்களுக்கு வினாடிக்கு தோராயமாக 10K கோரிக்கைகள் உள்ளன. ரெடிஸில் உச்ச லோடில் வினாடிக்கு 80-100K கோரிக்கைகளை எழுதுகிறோம்.
நாம் ஏன் Redis இலிருந்து PostgreSQL க்கு மாறினோம்
ஆரம்பத்தில், எங்கள் சேவை ரெடிஸ் உடன் வேலை செய்தது, இது சர்வரின் ரேமில் எல்லா தரவையும் சேமிக்கும் முக்கிய மதிப்பு சேமிப்பகமாகும்.
ரெடிஸின் நன்மைகள்:
- அதிக பதில் வேகம், ஏனெனில் எல்லாம் நினைவகத்தில் சேமிக்கப்படுகிறது;
- வசதியான காப்பு மற்றும் பிரதி.
எங்களுக்கு ரெடிஸின் தீமைகள்:
- உண்மையான பரிவர்த்தனைகள் எதுவும் இல்லை. எங்கள் பயன்பாட்டு மட்டத்தில் அவற்றைப் பின்பற்ற முயற்சித்தோம். துரதிர்ஷ்டவசமாக, இது எப்போதும் நன்றாக வேலை செய்யவில்லை மற்றும் மிகவும் சிக்கலான குறியீட்டை எழுத வேண்டியிருந்தது.
- நினைவகத்தின் அளவினால் தரவுகளின் அளவு வரையறுக்கப்படுகிறது. தரவுகளின் அளவு அதிகரிக்கும் போது, நினைவகம் வளரும், இறுதியில், தேர்ந்தெடுக்கப்பட்ட நிகழ்வின் சிறப்பியல்புகளை நாங்கள் இயக்குவோம், இது AWS இல் நிகழ்வு வகையை மாற்ற எங்கள் சேவையை நிறுத்த வேண்டும்.
- குறைந்த தாமத நிலையை தொடர்ந்து பராமரிப்பது அவசியம், ஏனெனில் எங்களிடம் மிகப் பெரிய எண்ணிக்கையிலான கோரிக்கைகள் உள்ளன. எங்களுக்கான உகந்த தாமத நிலை 17-20 எம்.எஸ். 30-40 எம்எஸ் அளவில், எங்கள் விண்ணப்பக் கோரிக்கைகள் மற்றும் சேவைச் சீரழிவுக்கு நீண்ட பதில்களைப் பெறுகிறோம். துரதிர்ஷ்டவசமாக, இது செப்டம்பர் 2018 இல் எங்களுக்கு நடந்தது, சில காரணங்களால் ரெடிஸ் உடனான நிகழ்வுகளில் ஒன்று வழக்கத்தை விட 2 மடங்கு அதிகமாக தாமதத்தைப் பெற்றது. சிக்கலைத் தீர்க்க, திட்டமிடப்படாத பராமரிப்புக்காக வேலை நாளின் நடுவில் சேவையை நிறுத்திவிட்டு, பிரச்சனைக்குரிய ரெடிஸ் நிகழ்வை மாற்றியுள்ளோம்.
- குறியீட்டில் சிறிய பிழைகள் இருந்தாலும் சீரற்ற தரவைப் பெறுவது எளிது, பின்னர் அந்தத் தரவைச் சரிசெய்ய குறியீட்டை எழுதுவதற்கு அதிக நேரம் செலவிடலாம்.
குறைபாடுகளை நாங்கள் கணக்கில் எடுத்துக்கொண்டோம், மேலும் சாதாரண பரிவர்த்தனைகள் மற்றும் தாமதத்தை குறைவாக சார்ந்து, மிகவும் வசதியான ஏதாவது ஒன்றை நாங்கள் மாற்ற வேண்டும் என்பதை உணர்ந்தோம். நாங்கள் எங்கள் ஆராய்ச்சியை மேற்கொண்டோம், பல விருப்பங்களை பகுப்பாய்வு செய்து PostgreSQL ஐ தேர்வு செய்தோம்.
நாங்கள் இப்போது 1,5 ஆண்டுகளாக புதிய தரவுத்தளத்திற்கு நகர்ந்து வருகிறோம், மேலும் தரவின் ஒரு சிறிய பகுதியை மட்டுமே மாற்றியுள்ளோம், எனவே இப்போது நாங்கள் Redis மற்றும் PostgreSQL உடன் ஒரே நேரத்தில் வேலை செய்கிறோம். தரவுத்தளங்களுக்கு இடையில் தரவை நகர்த்துவது மற்றும் மாற்றுவது பற்றிய கூடுதல் தகவல்கள் எழுதப்பட்டுள்ளன .
நாங்கள் முதலில் நகரத் தொடங்கியபோது, எங்கள் பயன்பாடு நேரடியாக தரவுத்தளத்துடன் வேலை செய்தது மற்றும் Redis மற்றும் PostgreSQL மாஸ்டரை அணுகியது. PostgreSQL கிளஸ்டர் ஒரு மாஸ்டர் மற்றும் ஒத்திசைவற்ற பிரதியுடனான பிரதி ஆகியவற்றைக் கொண்டிருந்தது. தரவுத்தள பணிப்பாய்வு இப்படி இருந்தது:
PgBouncer ஐ செயல்படுத்துதல்
நாங்கள் நகரும் போது, தயாரிப்பும் வளர்ச்சியடைந்தது: PostgreSQL உடன் பணிபுரியும் பயனர்களின் எண்ணிக்கை மற்றும் சேவையகங்களின் எண்ணிக்கை அதிகரித்தது, மேலும் எங்களிடம் இணைப்புகள் இல்லாமல் போக ஆரம்பித்தது. PostgreSQL ஒவ்வொரு இணைப்பிற்கும் ஒரு தனி செயல்முறையை உருவாக்கி வளங்களை பயன்படுத்துகிறது. நீங்கள் ஒரு குறிப்பிட்ட புள்ளி வரை இணைப்புகளின் எண்ணிக்கையை அதிகரிக்கலாம், இல்லையெனில் தரவுத்தளம் உகந்ததாக வேலை செய்யாத வாய்ப்பு உள்ளது. அத்தகைய சூழ்நிலையில் சிறந்த விருப்பம் தரவுத்தளத்தின் முன் நிற்கும் இணைப்பு மேலாளரைத் தேர்ந்தெடுப்பதாகும்.
இணைப்பு மேலாளருக்கான இரண்டு விருப்பங்கள் எங்களிடம் இருந்தன: Pgpool மற்றும் PgBouncer. ஆனால் முதலாவது தரவுத்தளத்துடன் பணிபுரியும் பரிவர்த்தனை முறையை ஆதரிக்காது, எனவே நாங்கள் PgBouncer ஐத் தேர்ந்தெடுத்தோம்.
பின்வரும் வேலைத் திட்டத்தை நாங்கள் உள்ளமைத்துள்ளோம்: எங்கள் பயன்பாடு ஒரு PgBouncer ஐ அணுகுகிறது, அதன் பின்னால் PostgreSQL மாஸ்டர்கள் உள்ளனர், மேலும் ஒவ்வொரு மாஸ்டருக்குப் பின்னும் ஒத்திசைவற்ற நகலெடுப்புடன் ஒரு பிரதி உள்ளது.
அதே நேரத்தில், PostgreSQL இல் முழுத் தரவையும் எங்களால் சேமிக்க முடியவில்லை மற்றும் தரவுத்தளத்துடன் பணிபுரியும் வேகம் எங்களுக்கு முக்கியமானது, எனவே பயன்பாட்டு மட்டத்தில் PostgreSQL ஐப் பிரிக்கத் தொடங்கினோம். மேலே விவரிக்கப்பட்ட திட்டம் இதற்கு ஒப்பீட்டளவில் வசதியானது: புதிய PostgreSQL ஷார்டைச் சேர்க்கும்போது, PgBouncer உள்ளமைவைப் புதுப்பித்தால் போதுமானது மற்றும் பயன்பாடு உடனடியாக புதிய ஷார்டுடன் வேலை செய்ய முடியும்.
PgBouncer தவறு சகிப்புத்தன்மை
ஒரே PgBouncer நிகழ்வு இறக்கும் வரை இந்தத் திட்டம் செயல்பட்டது. நாங்கள் AWS இல் இருக்கிறோம், அங்கு எல்லா நிகழ்வுகளும் அவ்வப்போது இறக்கும் வன்பொருளில் தொடங்கப்படுகின்றன. இதுபோன்ற சந்தர்ப்பங்களில், நிகழ்வு வெறுமனே புதிய வன்பொருளுக்கு நகர்ந்து மீண்டும் வேலை செய்கிறது. இது PgBouncer உடன் நடந்தது, ஆனால் அது கிடைக்கவில்லை. இந்த விபத்தின் விளைவாக எங்கள் சேவை 25 நிமிடங்களுக்கு கிடைக்கவில்லை. இதுபோன்ற சூழ்நிலைகளுக்கு, பயனர் பக்கத்தில் பணிநீக்கத்தைப் பயன்படுத்த AWS பரிந்துரைக்கிறது, அதை நாங்கள் அந்த நேரத்தில் செயல்படுத்தவில்லை.
அதன் பிறகு, PgBouncer மற்றும் PostgreSQL க்ளஸ்டர்களின் தவறு சகிப்புத்தன்மை பற்றி நாங்கள் தீவிரமாக யோசித்தோம், ஏனெனில் எங்கள் AWS கணக்கில் எந்த நிகழ்விலும் இதே போன்ற நிலை மீண்டும் நிகழலாம்.
நாங்கள் PgBouncer தவறு சகிப்புத்தன்மை திட்டத்தை பின்வருமாறு உருவாக்கினோம்: அனைத்து பயன்பாட்டு சேவையகங்களும் நெட்வொர்க் லோட் பேலன்சரை அணுகுகின்றன, அதன் பின்னால் இரண்டு PgBouncers உள்ளன. PgBouncers ஒவ்வொன்றும் ஒவ்வொரு துண்டின் அதே முதன்மை PostgreSQL ஐப் பார்க்கிறது. AWS நிகழ்வின் நிலை மீண்டும் மீண்டும் ஏற்பட்டால், அனைத்து போக்குவரத்தும் மற்றொரு PgBouncer மூலம் திருப்பி விடப்படும். நெட்வொர்க் லோட் பேலன்சர் தவறு சகிப்புத்தன்மை AWS ஆல் வழங்கப்படுகிறது.
புதிய PgBouncer சேவையகங்களை எளிதாகச் சேர்க்க இந்தத் திட்டம் உங்களை அனுமதிக்கிறது.
PostgreSQL ஃபெயில்ஓவர் கிளஸ்டரை உருவாக்குதல்
இந்த சிக்கலை தீர்க்கும் போது, நாங்கள் வெவ்வேறு விருப்பங்களைக் கருத்தில் கொண்டோம்: சுயமாக எழுதப்பட்ட தோல்வி, repmgr, AWS RDS, Patroni.
சுயமாக எழுதப்பட்ட ஸ்கிரிப்டுகள்
அவர்கள் மாஸ்டரின் வேலையைக் கண்காணிக்கலாம், அது தோல்வியுற்றால், மாஸ்டருக்குப் பிரதியை விளம்பரப்படுத்தலாம் மற்றும் PgBouncer உள்ளமைவைப் புதுப்பிக்கலாம்.
இந்த அணுகுமுறையின் நன்மைகள் அதிகபட்ச எளிமையாகும், ஏனென்றால் ஸ்கிரிப்ட்களை நீங்களே எழுதி, அவை எவ்வாறு செயல்படுகின்றன என்பதைப் புரிந்துகொள்வீர்கள்.
தீமைகள்:
- மாஸ்டர் இறந்திருக்க வாய்ப்பில்லை; அதற்கு பதிலாக, நெட்வொர்க் தோல்வி ஏற்பட்டிருக்கலாம். ஃபெயில்ஓவர், இதை அறியாமல், மாஸ்டருக்கு நகலெடுப்பதை ஊக்குவிக்கும், மேலும் பழைய மாஸ்டர் தொடர்ந்து வேலை செய்வார். இதன் விளைவாக, முதன்மைப் பாத்திரத்தில் இரண்டு சேவையகங்களைப் பெறுவோம், அவற்றில் சமீபத்திய தற்போதைய தரவு எது என்பதை அறிய முடியாது. இந்த நிலைமை பிளவு-மூளை என்றும் அழைக்கப்படுகிறது;
- பதில் சொல்லாமல் தவித்தோம். எங்கள் உள்ளமைவில் ஒரு மாஸ்டர் மற்றும் ஒரு பிரதி உள்ளது, பிரதியை மாற்றிய பின் மாஸ்டருக்கு பதவி உயர்வு அளிக்கப்படுகிறது, மேலும் எங்களிடம் இனி பிரதிகள் இல்லை, எனவே புதிய பிரதியை கைமுறையாக சேர்க்க வேண்டும்;
- தோல்விச் செயல்பாட்டின் கூடுதல் கண்காணிப்பு எங்களுக்குத் தேவை, மேலும் எங்களிடம் 12 PostgreSQL துண்டுகள் உள்ளன, அதாவது 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 ஐ நல்ல ஆவணங்கள், தானியங்கி தோல்வி மற்றும் கிதுப்பில் மூலக் குறியீட்டுடன் நிர்வகிப்பதற்கான ஒரு பைதான் டெம்ப்ளேட் ஆகும்.
பட்ரோனியின் நன்மைகள்:
- ஒவ்வொரு உள்ளமைவு அளவுருவும் விவரிக்கப்பட்டுள்ளது, அது எவ்வாறு செயல்படுகிறது என்பது தெளிவாகிறது;
- தானியங்கி தோல்வி பெட்டிக்கு வெளியே வேலை செய்கிறது;
- பைத்தானில் எழுதப்பட்டது, மேலும் நாமே பைத்தானில் நிறைய எழுதுவதால், சிக்கல்களைச் சமாளிப்பது எங்களுக்கு எளிதாக இருக்கும், ஒருவேளை, திட்டத்தின் வளர்ச்சிக்கு கூட உதவும்;
- PostgreSQL ஐ முழுமையாகக் கட்டுப்படுத்துகிறது, கிளஸ்டரின் அனைத்து முனைகளிலும் உள்ளமைவை ஒரே நேரத்தில் மாற்ற உங்களை அனுமதிக்கிறது, மேலும் புதிய உள்ளமைவைப் பயன்படுத்துவதற்கு கிளஸ்டரின் மறுதொடக்கம் தேவைப்பட்டால், இதை மீண்டும் Patroni ஐப் பயன்படுத்தி செய்யலாம்.
தீமைகள்:
- PgBouncer உடன் எவ்வாறு சரியாக வேலை செய்வது என்பது ஆவணங்களில் இருந்து தெளிவாக இல்லை. இதை மைனஸ் என்று அழைப்பது கடினம் என்றாலும், PostgreSQL ஐ நிர்வகிப்பது Patroni இன் பணியாகும், மேலும் Patroni உடனான இணைப்புகள் எவ்வாறு செயல்படும் என்பது ஏற்கனவே எங்கள் பிரச்சனையாக உள்ளது;
- பாட்ரோனியை பெரிய அளவில் செயல்படுத்துவதற்கு சில எடுத்துக்காட்டுகள் உள்ளன, அதே சமயம் புதிதாக செயல்படுத்தப்பட்டதற்கு பல எடுத்துக்காட்டுகள் உள்ளன.
இதன் விளைவாக, ஃபெயில்ஓவர் கிளஸ்டரை உருவாக்க பட்ரோனியைத் தேர்ந்தெடுத்தோம்.
பட்ரோனி செயல்படுத்தல் செயல்முறை
Patroniக்கு முன், ஒரு மாஸ்டரில் 12 PostgreSQL துகள்கள் மற்றும் ஒத்திசைவற்ற பிரதியமைப்புடன் ஒரு பிரதி உள்ளமைவு எங்களிடம் இருந்தது. பயன்பாட்டு சேவையகங்கள் நெட்வொர்க் லோட் பேலன்சர் மூலம் தரவுத்தளங்களை அணுகின, அதன் பின்னால் PgBouncer உடன் இரண்டு நிகழ்வுகள் இருந்தன, அவற்றின் பின்னால் அனைத்து PostgreSQL சேவையகங்களும் இருந்தன.
Patroni ஐ செயல்படுத்த, விநியோகிக்கப்பட்ட கிளஸ்டர் உள்ளமைவு சேமிப்பிடத்தைத் தேர்ந்தெடுக்க வேண்டும். Patroni விநியோகிக்கப்பட்ட கட்டமைப்பு சேமிப்பு அமைப்புகளான etcd, Zookeeper, Consul போன்றவற்றுடன் செயல்படுகிறது. எங்களிடம் முழு அளவிலான கன்சல் கிளஸ்டர் உற்பத்தியில் உள்ளது, இது வால்ட் உடன் இணைந்து செயல்படுகிறது மேலும் நாங்கள் அதை இனி பயன்படுத்த மாட்டோம். தூதரகத்தை அதன் நோக்கத்திற்காகப் பயன்படுத்தத் தொடங்குவதற்கு ஒரு சிறந்த காரணம்.
தூதரகத்துடன் பட்ரோனி எவ்வாறு பணியாற்றுகிறார்
எங்களிடம் மூன்று முனைகளைக் கொண்ட ஒரு கன்சல் கிளஸ்டர் மற்றும் ஒரு தலைவர் மற்றும் ஒரு பிரதியைக் கொண்ட ஒரு பேட்ரோனி கிளஸ்டர் உள்ளது (பட்ரோனியில், மாஸ்டர் கிளஸ்டர் லீடர் என்றும், அடிமைகள் பிரதிகள் என்றும் அழைக்கப்படுகிறார்கள்). ஒவ்வொரு பேட்ரோனி கிளஸ்டர் நிகழ்வும் கொத்துவின் நிலையைப் பற்றிய தகவல்களைத் தூதரகத்திற்குத் தொடர்ந்து அனுப்புகிறது. எனவே, தூதரகத்திலிருந்து நீங்கள் எப்போதும் பேட்ரோனி கிளஸ்டரின் தற்போதைய உள்ளமைவைக் கண்டறியலாம் மற்றும் இந்த நேரத்தில் யார் தலைவர்.
பட்ரோனியை தூதரகத்துடன் இணைக்க, நாங்கள் தூதரகத்துடன் எவ்வாறு வேலை செய்கிறோம் என்பதைப் பொறுத்து 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 }}ஆனால் அது அப்படிச் செயல்படாது. தொடக்கத்தில், பட்ரோனி தூதரகத்துடன் இணைக்க முடியாது, ஏனெனில் அது இன்னும் http வழியாக செல்ல முயற்சிக்கிறது.
Patroni மூலக் குறியீடு சிக்கலைத் தீர்க்க உதவியது. பைத்தானில் எழுதப்பட்டிருப்பது நல்லது. ஹோஸ்ட் அளவுரு எந்த வகையிலும் பாகுபடுத்தப்படவில்லை என்று மாறிவிடும், மேலும் திட்டத்தில் நெறிமுறை குறிப்பிடப்பட வேண்டும். தூதரகத்துடன் பணிபுரிவதற்கான ஒரு வேலை உள்ளமைவுத் தொகுதி எங்களுக்கு இது போல் தெரிகிறது:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}கன்சல்-வார்ப்புரு
எனவே, உள்ளமைவு சேமிப்பகத்தைத் தேர்ந்தெடுத்துள்ளோம். பட்ரோனி கிளஸ்டரில் தலைவர் மாறும்போது PgBouncer அதன் உள்ளமைவை எவ்வாறு மாற்றும் என்பதை இப்போது நாம் புரிந்து கொள்ள வேண்டும். ஆவணத்தில் இந்த கேள்விக்கு பதில் இல்லை, ஏனென்றால்... கொள்கையளவில், PgBouncer உடன் பணிபுரிவது அங்கு விவரிக்கப்படவில்லை.
ஒரு தீர்வைத் தேடி, நாங்கள் ஒரு கட்டுரையைக் கண்டோம் (துரதிர்ஷ்டவசமாக, பெயர் எனக்கு நினைவில் இல்லை), அங்கு PgBouncer மற்றும் Patroni ஆகியவற்றை இணைப்பதில் கன்சல்-வார்ப்புரு மிகவும் உதவியாக இருந்தது என்று எழுதப்பட்டது. இது கன்சல்-டெம்ப்ளேட்டின் வேலையைப் படிக்கத் தூண்டியது.
தூதரகத்தில் உள்ள PostgreSQL கிளஸ்டரின் உள்ளமைவை கன்சல் டெம்ப்ளேட் தொடர்ந்து கண்காணிக்கிறது. தலைவர் மாறும்போது, அது PgBouncer உள்ளமைவைப் புதுப்பித்து அதை மீண்டும் ஏற்ற ஒரு கட்டளையை அனுப்புகிறது.
டெம்ப்ளேட்டின் பெரிய நன்மை என்னவென்றால், அது குறியீடாக சேமிக்கப்படுகிறது, எனவே ஒரு புதிய துண்டைச் சேர்க்கும்போது, புதிய உறுதியை உருவாக்கி, வார்ப்புருவை தானாகவே புதுப்பித்து, உள்கட்டமைப்பை குறியீட்டு கொள்கையாக ஆதரிக்கிறது.
பட்ரோனியுடன் புதிய கட்டிடக்கலை
இதன் விளைவாக, பின்வரும் வேலைத் திட்டத்தைப் பெற்றோம்:
அனைத்து பயன்பாட்டு சேவையகங்களும் பேலன்சரை அணுகுகின்றன → அதன் பின்னால் PgBouncer இன் இரண்டு நிகழ்வுகள் உள்ளன → ஒவ்வொரு நிகழ்விலும் ஒரு தூதரக-வார்ப்புரு இயங்குகிறது, இது ஒவ்வொரு Patroni கிளஸ்டரின் நிலையை கண்காணிக்கிறது மற்றும் PgBouncer கட்டமைப்பின் பொருத்தத்தை கண்காணிக்கிறது, இது தற்போதைய தலைவருக்கு கோரிக்கைகளை அனுப்புகிறது. ஒவ்வொரு கிளஸ்டரின்.
கைமுறை சோதனை
இதைத் தயாரிப்பில் தொடங்குவதற்கு முன், சிறிய சோதனைச் சூழலில் இந்தத் திட்டத்தைத் தொடங்கினோம் மற்றும் தானியங்கி மாறுதலின் செயல்பாட்டைச் சரிபார்த்தோம். அவர்கள் பலகையைத் திறந்து, ஸ்டிக்கரை நகர்த்தினர், அந்த நேரத்தில் கிளஸ்டரின் தலைவரை "கொன்றனர்". AWS இல், நீங்கள் செய்ய வேண்டியது கன்சோல் வழியாக நிகழ்வை அணைக்க வேண்டும்.
ஸ்டிக்கர் 10-20 வினாடிகளுக்குள் திரும்பியது, பின்னர் மீண்டும் சாதாரணமாக நகரத் தொடங்கியது. இதன் பொருள் Patroni கிளஸ்டர் சரியாக வேலை செய்தது: அது தலைவரை மாற்றியது, தூதரகத்திற்கு தகவலை அனுப்பியது, மேலும் தூதரக-வார்ப்புரு உடனடியாக இந்தத் தகவலை எடுத்து, PgBouncer உள்ளமைவை மாற்றி, மீண்டும் ஏற்றுவதற்கான கட்டளையை அனுப்பியது.
அதிக சுமைகளின் கீழ் உயிர்வாழ்வது மற்றும் குறைந்த வேலையில்லா நேரத்தை எவ்வாறு பராமரிப்பது?
எல்லாம் சரியாக வேலை செய்கிறது! ஆனால் புதிய கேள்விகள் எழுகின்றன: அதிக சுமையின் கீழ் இது எவ்வாறு வேலை செய்யும்? உற்பத்தியில் உள்ள அனைத்தையும் விரைவாகவும் பாதுகாப்பாகவும் உருட்டுவது எப்படி?
சுமை சோதனையை நாங்கள் நடத்தும் சோதனை சூழல் முதல் கேள்விக்கு பதிலளிக்க உதவுகிறது. இது கட்டிடக்கலையில் உற்பத்திக்கு முற்றிலும் ஒத்ததாக உள்ளது மற்றும் சோதனைத் தரவை உருவாக்கியுள்ளது, இது உற்பத்திக்கு சமமாக இருக்கும். சோதனையின் போது PostgreSQL மாஸ்டர்களில் ஒருவரை "கொல்ல" முடிவு செய்து என்ன நடக்கிறது என்று பார்க்கிறோம். ஆனால் அதற்கு முன், தானியங்கி வெளியீட்டை சரிபார்க்க வேண்டியது அவசியம், ஏனெனில் இந்த சூழலில் பல PostgreSQL துண்டுகள் உள்ளன, எனவே உற்பத்திக்கு முன் உள்ளமைவு ஸ்கிரிப்ட்களின் சிறந்த சோதனையைப் பெறுவோம்.
இரண்டு பணிகளும் லட்சியமாகத் தெரிகிறது, ஆனால் எங்களிடம் PostgreSQL 9.6 உள்ளது. ஒருவேளை நாம் இப்போதே 11.2 க்கு புதுப்பிக்க முடியுமா?
இதை 2 நிலைகளில் செய்ய நாங்கள் முடிவு செய்கிறோம்: முதலில் பதிப்பை 11.2 க்கு புதுப்பித்து, பின்னர் Patroni ஐத் தொடங்கவும்.
PostgreSQL புதுப்பிப்பு
PostgreSQL பதிப்பை விரைவாகப் புதுப்பிக்க, நீங்கள் விருப்பத்தைப் பயன்படுத்த வேண்டும் -k, இதில் ஒரு கடினமான இணைப்பு வட்டில் உருவாக்கப்பட்டது மற்றும் உங்கள் தரவை நகலெடுக்க வேண்டிய அவசியமில்லை. 300-400 ஜிபி தரவுத்தளங்களில், புதுப்பிப்பு 1 வினாடி ஆகும்.
எங்களிடம் நிறைய துண்டுகள் உள்ளன, எனவே புதுப்பிப்பு தானாகவே செய்யப்பட வேண்டும். இதைச் செய்ய, எங்களுக்காக முழு புதுப்பிப்பு செயல்முறையையும் செய்யும் அன்சிபிள் பிளேபுக்கை நாங்கள் எழுதினோம்:
/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 உள்ளமைவைப் பாருங்கள். அதிகாரப்பூர்வ களஞ்சியமானது initdb உடன் ஒரு எடுத்துக்காட்டு உள்ளமைவைக் கொண்டுள்ளது, இது Patroni முதன்முதலில் தொடங்கப்படும் போது ஒரு புதிய தரவுத்தளத்தை துவக்குவதற்கு பொறுப்பாகும். ஆனால் எங்களிடம் ஏற்கனவே ஆயத்த தரவுத்தளம் இருப்பதால், இந்த பகுதியை உள்ளமைவிலிருந்து அகற்றினோம்.
நாங்கள் ஆயத்த PostgreSQL கிளஸ்டரில் Patroni ஐ நிறுவத் தொடங்கியபோது, அதைத் தொடங்கும்போது, நாங்கள் ஒரு புதிய சிக்கலை எதிர்கொண்டோம்: இரண்டு சேவையகங்களும் முன்னணியில் தொடங்கப்பட்டன. பட்ரோனிக்கு கிளஸ்டரின் ஆரம்ப நிலை பற்றி எதுவும் தெரியாது மற்றும் இரண்டு சேவையகங்களையும் ஒரே பெயரில் இரண்டு தனித்தனி கிளஸ்டர்களாக இயக்க முயற்சிக்கிறார். இந்தச் சிக்கலைத் தீர்க்க, அடிமையில் உள்ள தரவுக் கோப்பகத்தை நீக்க வேண்டும்:
rm -rf /var/lib/postgresql/இது அடிமை மீது மட்டுமே செய்யப்பட வேண்டும்!
ஒரு சுத்தமான பிரதியை இணைக்கும் போது, Patroni ஒரு பேஸ்பேக்அப் லீடரை உருவாக்கி அதை பிரதிக்கு மீட்டெடுக்கிறார், பின்னர் வால் பதிவுகளைப் பயன்படுத்தி தற்போதைய நிலையைப் பிடிக்கிறார்.
நாங்கள் சந்தித்த மற்றொரு சிரமம் என்னவென்றால், எல்லா PostgreSQL கிளஸ்டர்களும் இயல்பாகவே பிரதானமாக அழைக்கப்படுகின்றன. ஒவ்வொரு கிளஸ்டருக்கும் மற்றொன்றைப் பற்றி எதுவும் தெரியாதபோது, இது சாதாரணமானது. ஆனால் நீங்கள் Patroni ஐப் பயன்படுத்த விரும்பினால், அனைத்து கிளஸ்டர்களுக்கும் ஒரு தனிப்பட்ட பெயர் இருக்க வேண்டும். PostgreSQL உள்ளமைவில் கிளஸ்டர் பெயரை மாற்றுவதே தீர்வு.
சுமை சோதனை
பலகைகளில் பயனர்கள் எவ்வாறு செயல்படுகிறார்கள் என்பதை உருவகப்படுத்தும் சோதனையை நாங்கள் தொடங்கினோம். சுமை எங்கள் தினசரி சராசரியை அடைந்ததும், அதே சோதனையை மீண்டும் செய்தோம், தலைவர் PostgreSQL உடன் ஒரு நிகழ்வை முடக்கினோம். தானியங்கி தோல்வி நாங்கள் எதிர்பார்த்தது போல் வேலை செய்தது: பட்ரோனி தலைவரை மாற்றினார், கன்சல்-டெம்ப்ளேட் PgBouncer உள்ளமைவை புதுப்பித்து மீண்டும் ஏற்றுவதற்கான கட்டளையை அனுப்பியது. கிராஃபனாவில் உள்ள எங்கள் வரைபடங்களின்படி, 20-30 வினாடிகள் தாமதம் மற்றும் தரவுத்தளத்திற்கான இணைப்பு தொடர்பான சேவையகங்களிலிருந்து ஒரு சிறிய அளவு பிழைகள் இருப்பது தெளிவாகத் தெரிந்தது. இது ஒரு சாதாரண சூழ்நிலை, இதுபோன்ற மதிப்புகள் எங்கள் தோல்விக்கு ஏற்றுக்கொள்ளத்தக்கவை மற்றும் சேவை வேலையில்லா நேரத்தை விட நிச்சயமாக சிறந்தவை.
தயாரிப்பில் பட்ரோனி தொடங்கப்பட்டது
இதன் விளைவாக, பின்வரும் திட்டத்தை நாங்கள் கொண்டு வந்தோம்:
- தூதரக-வார்ப்புருவை PgBouncer சர்வரில் வரிசைப்படுத்தி துவக்கவும்;
- PostgreSQL பதிப்பு 11.2க்கு புதுப்பிக்கப்பட்டது;
- கிளஸ்டர் பெயரை மாற்றுதல்;
- பேட்ரோனி கிளஸ்டரின் துவக்கம்.
அதே நேரத்தில், எங்கள் திட்டம் எந்த நேரத்திலும் முதல் புள்ளியைச் செய்ய அனுமதிக்கிறது; ஒவ்வொரு பிஜிபவுன்சரையும் வேலையிலிருந்து ஒவ்வொன்றாக அகற்றி, அதன் மீது தூதரக-வார்ப்புருவை வரிசைப்படுத்தவும் தொடங்கவும் முடியும். அதைத்தான் நாங்கள் செய்தோம்.
விரைவான சோதனைக்கு, நாங்கள் Ansible ஐப் பயன்படுத்தினோம், ஏனெனில் நாங்கள் முழு பிளேபுக்கையும் ஒரு சோதனை சூழலில் ஏற்கனவே சோதித்துள்ளோம், மேலும் முழு ஸ்கிரிப்டிற்கான செயலாக்க நேரம் ஒவ்வொரு ஷார்டிற்கும் 1,5 முதல் 2 நிமிடங்கள் வரை. எங்கள் சேவையை நிறுத்தாமல் எல்லாவற்றையும் ஒவ்வொன்றாக ஒவ்வொரு ஷார்டுக்கும் அனுப்பலாம், ஆனால் ஒவ்வொரு PostgreSQL ஐயும் பல நிமிடங்களுக்கு அணைக்க வேண்டும். இந்த நிலையில், இந்தத் துண்டில் உள்ள தரவு உள்ள பயனர்கள் இந்த நேரத்தில் முழுமையாக வேலை செய்ய முடியாது, மேலும் இது எங்களுக்கு ஏற்றுக்கொள்ள முடியாதது.
இந்த சூழ்நிலையிலிருந்து வெளியேறும் வழி திட்டமிடப்பட்ட பராமரிப்பு ஆகும், இது ஒவ்வொரு 3 மாதங்களுக்கும் நாங்கள் செய்கிறோம். எங்கள் சேவையை முழுவதுமாக முடக்கி, தரவுத்தள நிகழ்வுகளைப் புதுப்பிக்கும்போது, திட்டமிடப்பட்ட வேலைக்கான சாளரம் இது. அடுத்த சாளரத்திற்கு இன்னும் ஒரு வாரம் உள்ளது, நாங்கள் காத்திருந்து மேலும் தயார் செய்ய முடிவு செய்தோம். காத்திருப்பின் போது, நாங்கள் எங்கள் சவால்களை கூடுதலாகக் கட்டுப்படுத்தினோம்: சமீபத்திய தரவைச் சேமிப்பதற்காக, ஒவ்வொரு PostgreSQL ஷார்டுக்கும் தோல்வியுற்றால் ஒரு உதிரி பிரதியை உருவாக்கினோம், மேலும் ஒவ்வொரு துண்டிற்கும் ஒரு புதிய நிகழ்வைச் சேர்த்துள்ளோம், இது 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 கிளஸ்டர் அதன் கிளஸ்டர் பற்றிய தகவலைப் பெற முடியாமல் மீண்டும் தொடங்கப்பட்டது.
ஒரு தீர்வைக் காண, கிதுப்பில் ஒரு சிக்கல் மூலம் பேட்ரோனியின் ஆசிரியர்களைத் தொடர்புகொண்டோம். அவர்கள் எங்கள் உள்ளமைவு கோப்புகளை மேம்படுத்த பரிந்துரைத்தனர்:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8சோதனைச் சூழலில் சிக்கலைப் பிரதிபலிக்க முடிந்தது மற்றும் இந்த அமைப்புகளை அங்கு சோதனை செய்தோம், ஆனால் துரதிர்ஷ்டவசமாக அவை வேலை செய்யவில்லை.
பிரச்சனை இன்னும் தீர்க்கப்படாமல் உள்ளது. பின்வரும் தீர்வுகளை முயற்சிக்க நாங்கள் திட்டமிட்டுள்ளோம்:
- பேட்ரோனி கிளஸ்டரின் ஒவ்வொரு நிகழ்விலும் கன்சல்-ஏஜெண்டைப் பயன்படுத்தவும்;
- குறியீட்டில் உள்ள சிக்கலை சரிசெய்யவும்.
பிழை எங்கு ஏற்பட்டது என்பதை நாங்கள் புரிந்துகொள்கிறோம்: இயல்புநிலை காலக்கெடுவைப் பயன்படுத்துவதில் சிக்கல் இருக்கலாம், இது உள்ளமைவு கோப்பு மூலம் மேலெழுதப்படவில்லை. கடைசி தூதரக சேவையகம் கிளஸ்டரிலிருந்து அகற்றப்பட்டால், முழு கான்சல் கிளஸ்டரும் உறைகிறது, இது ஒரு நொடிக்கு மேல் நீடிக்கும்; இதன் காரணமாக, பட்ரோனி கிளஸ்டரின் நிலையைப் பெற முடியாது மற்றும் முழு கிளஸ்டரையும் முழுமையாக மறுதொடக்கம் செய்கிறது.
அதிர்ஷ்டவசமாக, நாங்கள் எந்த பிழைகளையும் சந்திக்கவில்லை.
பட்ரோனியைப் பயன்படுத்துவதன் முடிவுகள்
Patroni வெற்றிகரமாக அறிமுகப்படுத்தப்பட்ட பிறகு, ஒவ்வொரு கிளஸ்டரிலும் ஒரு கூடுதல் பிரதியைச் சேர்த்துள்ளோம். இப்போது ஒவ்வொரு கிளஸ்டருக்கும் ஒரு கோரத்தின் சாயல் உள்ளது: ஒரு தலைவர் மற்றும் இரண்டு பிரதிகள், மாறும்போது மூளை பிளவுபடாமல் பாதுகாக்க.
பட்ரோனி மூன்று மாதங்களுக்கும் மேலாக தயாரிப்பில் பணியாற்றி வருகிறார். இந்த நேரத்தில், அவர் ஏற்கனவே எங்களுக்கு உதவ முடிந்தது. சமீபத்தில், கிளஸ்டர்களில் ஒன்றின் தலைவர் AWS இல் இறந்தார், தானியங்கி தோல்வி வேலை செய்தது மற்றும் பயனர்கள் தொடர்ந்து வேலை செய்தனர். பட்ரோனி அதன் முக்கிய பணியை நிறைவேற்றியுள்ளது.
Patroni ஐப் பயன்படுத்துவதற்கான சுருக்கமான சுருக்கம்:
- உள்ளமைவு மாற்றங்களின் எளிமை. ஒரு நிகழ்வில் உள்ளமைவை மாற்றினால் போதும், அது முழு கிளஸ்டருக்கும் பொருந்தும். புதிய உள்ளமைவைப் பயன்படுத்த மறுதொடக்கம் தேவைப்பட்டால், பேட்ரோனி இதை உங்களுக்குத் தெரிவிக்கும். பட்ரோனி ஒரு கட்டளை மூலம் முழு கிளஸ்டரையும் மறுதொடக்கம் செய்யலாம், இது மிகவும் வசதியானது.
- தானியங்கி தோல்வி வேலை செய்கிறது மற்றும் ஏற்கனவே எங்களுக்கு உதவியது.
- பயன்பாடு செயலிழக்காமல் PostgreSQL ஐப் புதுப்பிக்கிறது. நீங்கள் முதலில் பிரதிகளை புதிய பதிப்பிற்கு புதுப்பிக்க வேண்டும், பின்னர் Patroni கிளஸ்டரில் உள்ள தலைவரை மாற்றி பழைய தலைவரை புதுப்பிக்க வேண்டும். இந்த வழக்கில், தானியங்கி தோல்வியின் தேவையான சோதனை ஏற்படுகிறது.
ஆதாரம்: www.habr.com