இணைப்பு பூலரை வடிவமைக்கும் போது PgBouncer அளவிடுதலின் அனுபவத்தை எவ்வாறு கணக்கில் எடுத்துக் கொண்டார்கள் என்பதை ஆண்ட்ரே போரோடின் தனது உரையில் கூறுவார். , அவர்கள் அதை எவ்வாறு தயாரிப்பில் வெளியிட்டார்கள். கூடுதலாக, புதிய பதிப்புகளில் பூலரின் என்ன செயல்பாடுகளை நாங்கள் பார்க்க விரும்புகிறோம் என்பதை நாங்கள் விவாதிப்போம்: எங்கள் தேவைகளை பூர்த்தி செய்வது மட்டுமல்லாமல், பயனர் சமூகத்தை மேம்படுத்துவதும் எங்களுக்கு முக்கியம். .
வீடியோக்கள்:
அனைவருக்கும் வணக்கம்! என் பெயர் ஆண்ட்ரூ.
Yandex இல், நான் திறந்த மூல தரவுத்தளங்களை உருவாக்குகிறேன். இன்று எங்களிடம் இணைப்பு பூலர் இணைப்புகள் பற்றிய தலைப்பு உள்ளது.
ரஷ்ய மொழியில் இணைப்பு பூலரை எவ்வாறு அழைப்பது என்று உங்களுக்குத் தெரிந்தால், சொல்லுங்கள். தொழில்நுட்ப இலக்கியத்தில் நிறுவப்பட வேண்டிய ஒரு நல்ல தொழில்நுட்ப வார்த்தையை நான் கண்டுபிடிக்க விரும்புகிறேன்.
தலைப்பு மிகவும் சிக்கலானது, ஏனென்றால் பல தரவுத்தளங்களில் இணைப்பு பூலர் உள்ளமைக்கப்பட்டுள்ளது மற்றும் அதைப் பற்றி நீங்கள் தெரிந்து கொள்ள வேண்டிய அவசியமில்லை. சில அமைப்புகள், நிச்சயமாக, எல்லா இடங்களிலும் உள்ளன, ஆனால் Postgres இல் இது வேலை செய்யாது. மற்றும் இணையாக (HighLoad++ 2019 இல்) Postgres இல் வினவல்களை அமைப்பது குறித்து Nikolai Samokhvalov அறிக்கை உள்ளது. ஏற்கனவே கோரிக்கைகளை சரியாக உள்ளமைத்த நபர்கள் இங்கு வந்துள்ளனர் என்பதை நான் புரிந்துகொள்கிறேன், மேலும் இவர்கள் நெட்வொர்க், வள பயன்பாடு தொடர்பான அரிதான கணினி சிக்கல்களை எதிர்கொள்பவர்கள். மேலும் சில இடங்களில் பிரச்சனைகள் வெளிப்படையாக இல்லை என்ற பொருளில் மிகவும் கடினமாக இருக்கலாம்.
யாண்டெக்ஸில் Postgres உள்ளது. பல Yandex சேவைகள் Yandex.Cloud இல் வாழ்கின்றன. போஸ்ட்கிரெஸில் வினாடிக்கு குறைந்தது ஒரு மில்லியன் கோரிக்கைகளை உருவாக்கும் பல பெட்டாபைட் தரவு எங்களிடம் உள்ளது.
அனைத்து சேவைகளுக்கும் மிகவும் பொதுவான கிளஸ்டரை நாங்கள் வழங்குகிறோம் - இது முனையின் முக்கிய முதன்மை முனை, வழக்கமான இரண்டு பிரதிகள் (ஒத்திசைவு மற்றும் ஒத்திசைவற்ற), காப்புப்பிரதி, பிரதி மீதான வாசிப்பு கோரிக்கைகளை அளவிடுதல்.
ஒவ்வொரு கிளஸ்டர் முனையும் Postgres ஆகும், இதில் Postgres மற்றும் கண்காணிப்பு அமைப்புகளுக்கு கூடுதலாக ஒரு இணைப்பு பூலர் நிறுவப்பட்டுள்ளது. இணைப்பு பூலர் ஃபென்சிங் மற்றும் அதன் முக்கிய நோக்கத்திற்காக பயன்படுத்தப்படுகிறது.
இணைப்பு பூலரின் முக்கிய நோக்கம் என்ன?
Postgres ஒரு தரவுத்தளத்துடன் வேலை செய்வதற்கான செயல்முறை மாதிரியை ஏற்றுக்கொள்கிறது. இதன் பொருள் ஒரு இணைப்பு ஒரு செயல்முறை, ஒரு Postgres பின்தளம். இந்த பின்தளத்தில் பல்வேறு கேச்கள் உள்ளன, அவை வெவ்வேறு இணைப்புகளுக்கு வித்தியாசமாக உருவாக்க மிகவும் விலை உயர்ந்தவை.
மேலும், போஸ்ட்கிரெஸ் குறியீட்டில் procArray எனப்படும் வரிசை உள்ளது. பிணைய இணைப்புகள் பற்றிய அடிப்படை தரவு இதில் உள்ளது. மற்றும் கிட்டத்தட்ட அனைத்து procArray செயலாக்க வழிமுறைகளும் நேரியல் சிக்கலானது, அவை நெட்வொர்க் இணைப்புகளின் முழு வரிசையிலும் இயங்குகின்றன. இது ஒரு அழகான வேகமான சுழற்சி, ஆனால் அதிக உள்வரும் நெட்வொர்க் இணைப்புகளுடன், விஷயங்கள் சற்று விலை அதிகம். மேலும் விஷயங்கள் கொஞ்சம் விலை உயர்ந்தால், அதிக எண்ணிக்கையிலான நெட்வொர்க் இணைப்புகளுக்கு நீங்கள் அதிக விலையை செலுத்துவீர்கள்.
3 சாத்தியமான அணுகுமுறைகள் உள்ளன:
- விண்ணப்பத்தின் பக்கத்தில்.
- தரவுத்தள பக்கத்தில்.
- மற்றும் இடையில், அதாவது, சாத்தியமான அனைத்து சேர்க்கைகள்.
துரதிர்ஷ்டவசமாக, உள்ளமைக்கப்பட்ட பூலர் தற்போது வளர்ச்சியில் உள்ளது. PostgreSQL Professional இல் உள்ள நண்பர்கள் இதை பெரும்பாலும் செய்கிறார்கள். அது எப்போது தோன்றும் என்று கணிப்பது கடினம். உண்மையில், ஒரு கட்டிடக் கலைஞரைத் தேர்ந்தெடுப்பதற்கு எங்களிடம் இரண்டு தீர்வுகள் உள்ளன. இவை பயன்பாட்டு பக்க குளம் மற்றும் ப்ராக்ஸி குளம்.
பயன்பாட்டு பக்க குளம் எளிதான வழி. மற்றும் கிட்டத்தட்ட அனைத்து கிளையன்ட் டிரைவர்களும் உங்களுக்கு ஒரு வழியை வழங்குகிறார்கள்: உங்கள் மில்லியன் கணக்கான இணைப்புகளை குறியீட்டில் சில டஜன் இணைப்புகளாக தரவுத்தளத்தில் குறிப்பிடுவதற்கு.
ஒரு குறிப்பிட்ட கட்டத்தில் நீங்கள் பின்தளத்தை அளவிட வேண்டும் என்பதில் சிக்கல் உள்ளது, அதை பல மெய்நிகர் இயந்திரங்களுக்கு பயன்படுத்த விரும்புகிறீர்கள்.
உங்களிடம் இன்னும் பல கிடைக்கும் மண்டலங்கள், பல தரவு மையங்கள் உள்ளன என்பதை நீங்கள் இன்னும் உணருகிறீர்கள். கிளையன்ட் பக்க பூலிங் அணுகுமுறை பெரிய எண்களுக்கு வழிவகுக்கிறது. பெரியவை சுமார் 10 இணைப்புகள். இது நன்றாக வேலை செய்யக்கூடிய விளிம்பு.
நாம் ப்ராக்ஸி பூலர்களைப் பற்றி பேசினால், நிறைய விஷயங்களைச் செய்யக்கூடிய இரண்டு பூலர்கள் உள்ளனர். அவர்கள் குளம் பிடிப்பவர்கள் மட்டுமல்ல. அவை பூலர்கள் + அதிக கூல் செயல்பாடு. இது и .
ஆனால், துரதிர்ஷ்டவசமாக, அனைவருக்கும் இந்த கூடுதல் செயல்பாடு தேவையில்லை. பூலர்கள் செஷன் பூலிங்கை மட்டுமே ஆதரிக்கிறார்கள், அதாவது ஒரு உள்வரும் கிளையன்ட், ஒரு வெளிச்செல்லும் கிளையன்ட் தரவுத்தளத்திற்கு இது வழிவகுக்கிறது.
இது எங்கள் பணிகளுக்கு மிகவும் பொருத்தமானது அல்ல, எனவே நாங்கள் PgBouncer ஐப் பயன்படுத்துகிறோம், இது பரிவர்த்தனை தொகுப்பை செயல்படுத்துகிறது, அதாவது சேவையக இணைப்புகள் பரிவர்த்தனையின் காலத்திற்கு மட்டுமே கிளையன்ட் இணைப்புகளுக்கு மேப் செய்யப்படுகின்றன.
மற்றும் எங்கள் சுமை - அது உண்மை. ஆனால் பல சிக்கல்கள் உள்ளன.
நீங்கள் ஒரு அமர்வைக் கண்டறிய விரும்பும் போது சிக்கல்கள் தொடங்குகின்றன, ஏனெனில் உள்வரும் அனைத்து இணைப்புகளும் உள்ளூர் ஆகும். எல்லோரும் லூப்பேக்குடன் வந்தார்கள், எப்படியாவது அமர்வைக் கண்டுபிடிப்பது கடினம்.
நிச்சயமாக நீங்கள் application_name_add_host ஐப் பயன்படுத்தலாம். இது அப்ளிகேஷன்_பெயரில் ஐபி முகவரியைச் சேர்ப்பதற்கான பவுன்சர் பக்க வழி. ஆனால் application_name என்பது கூடுதல் இணைப்பு மூலம் அமைக்கப்பட்டுள்ளது.
இந்த விளக்கப்படத்தில், மஞ்சள் கோடு உண்மையான கோரிக்கைகளாகவும், நீலக் கோடு தரவுத்தளத்தில் பறக்கும் கோரிக்கைகளாகவும் இருக்கும். இந்த வேறுபாடு துல்லியமாக அப்ளிகேஷன்_பெயரின் அமைப்பாகும், இது தடமறிவதற்கு மட்டுமே தேவைப்படுகிறது, ஆனால் இது இலவசம் அல்ல.
கூடுதலாக, பவுன்சர் ஒரு குளத்தை கட்டுப்படுத்த முடியாது, அதாவது ஒரு பயனருக்கு ஒரு தரவுத்தள இணைப்புகளின் எண்ணிக்கை.
இது எதற்கு வழிவகுக்கிறது? உங்களிடம் C ++ இல் எழுதப்பட்ட ஒரு ஏற்றப்பட்ட சேவை உள்ளது மற்றும் எங்காவது ஒரு முனையில் ஒரு சிறிய சேவை உள்ளது, அது அடித்தளத்தில் எந்தத் தவறும் செய்யாது, ஆனால் அதன் இயக்கி பைத்தியமாகிறது. இது 20 இணைப்புகளைத் திறக்கிறது, மற்ற அனைத்தும் காத்திருக்கும். உங்கள் குறியீடு கூட சரியாக உள்ளது.
நிச்சயமாக, இந்த அமைப்பைச் சேர்த்த பவுன்சருக்கு ஒரு சிறிய பேட்ச் எழுதினோம், அதாவது க்ளையன்ட்களை குளத்தில் வரம்பிடுகிறோம்.
போஸ்ட்கிரெஸ் பக்கத்தில் இதைச் செய்ய முடியும், அதாவது தரவுத்தளத்தில் உள்ள பாத்திரங்களை இணைப்புகளின் எண்ணிக்கைக்கு வரம்பிடலாம்.
ஆனால் சேவையகத்துடன் உங்களுக்கு ஏன் இணைப்புகள் இல்லை என்பதைப் புரிந்துகொள்ளும் திறனை நீங்கள் இழக்கிறீர்கள். PgBouncer இணைப்புப் பிழையை ஏற்படுத்தாது, அது எப்போதும் அதே தகவலை வழங்கும். உங்களால் புரிந்து கொள்ள முடியவில்லை: ஒருவேளை உங்கள் கடவுச்சொல் மாறியிருக்கலாம், ஒருவேளை தரவுத்தளம் கீழே சென்றிருக்கலாம், ஒருவேளை ஏதோ தவறாக இருக்கலாம். ஆனால் நோயறிதல் இல்லை. அமர்வை நிறுவ முடியாவிட்டால், அதை ஏன் செய்ய முடியாது என்று உங்களுக்குத் தெரியாது.
ஒரு குறிப்பிட்ட கட்டத்தில், நீங்கள் பயன்பாட்டின் வரைபடங்களைப் பார்த்து, பயன்பாடு வேலை செய்யவில்லை என்பதைப் பார்க்கவும்.
மேலே பார்க்கவும், பவுன்சர் ஒற்றை-திரிப்பாக இருப்பதைப் பாருங்கள். இது சேவையின் வாழ்க்கையில் ஒரு திருப்புமுனையாகும். ஒன்றரை ஆண்டுகளில் தரவுத்தளத்தை அளவிடத் தயாராகி வருகிறீர்கள் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள், மேலும் நீங்கள் பூலரை அளவிட வேண்டும்.
மேலும் PgBouncers தேவை என்ற முடிவுக்கு வந்துள்ளோம்.
பவுன்சர் சற்று ஒட்டப்பட்டுள்ளது.
டிசிபி போர்ட்டின் மறுபயன்பாட்டின் மூலம் பல பவுன்சர்களை உருவாக்க முடியும் என்று அவர்கள் அதை உருவாக்கினர். ஏற்கனவே இயங்குதளமானது உள்வரும் TCP இணைப்புகளை அவற்றுக்கிடையே round-robin'om மூலம் தானாக மாற்றுகிறது.
இது வாடிக்கையாளர்களுக்கு வெளிப்படையானது, அதாவது உங்களிடம் ஒரு பவுன்சர் இருப்பது போல் தெரிகிறது, ஆனால் நீங்கள் இயங்கும் பவுன்சர்களுக்கு இடையே செயலற்ற இணைப்புகளின் துண்டு துண்டாக உள்ளது.
ஒரு கட்டத்தில், இந்த 3 பவுன்சர்கள் ஒவ்வொருவரும் 100% தங்கள் மையத்தை சாப்பிடுவதை நீங்கள் கவனிக்கலாம். உங்களுக்கு சில பவுன்சர்கள் தேவை. ஏன்?
ஏனென்றால் உங்களிடம் TLS உள்ளது. உங்களிடம் மறைகுறியாக்கப்பட்ட இணைப்பு உள்ளது. TLS உடன் மற்றும் இல்லாமல் போஸ்ட்கிரெஸை நீங்கள் பெஞ்ச்மார்க் செய்தால், TLS ஹேண்ட்ஷேக் CPU ஆதாரங்களைப் பயன்படுத்துவதால், நிறுவப்பட்ட இணைப்புகளின் எண்ணிக்கை கிட்டத்தட்ட இரண்டு அளவுகளில் என்க்ரிப்ஷன் மூலம் குறைவதை நீங்கள் காண்பீர்கள்.
மேலே, உள்வரும் இணைப்புகளின் அலையின் போது செயல்படுத்தப்படும் சில கிரிப்டோகிராஃபிக் செயல்பாடுகளை நீங்கள் காணலாம். எங்கள் முதன்மையானது கிடைக்கும் மண்டலங்களுக்கு இடையில் மாற முடியும் என்பதால், உள்வரும் இணைப்புகளின் அலை மிகவும் பொதுவான சூழ்நிலையாகும். அதாவது, சில காரணங்களால், பழைய முதன்மை கிடைக்கவில்லை, முழு சுமை மற்றொரு தரவு மையத்திற்கு அனுப்பப்பட்டது. அவர்கள் அனைவரும் ஒரே நேரத்தில் TLS க்கு வணக்கம் சொல்ல வருவார்கள்.
அதிக எண்ணிக்கையிலான TLS கைகுலுக்கல் ஏற்கனவே பவுன்சரை வாழ்த்தாமல் இருக்கலாம், ஆனால் அவரது தொண்டையை அழுத்துகிறது. நேரம் முடிவதால் உள்வரும் இணைப்புகளின் அலை குறையலாம். அதிவேக பின்னடைவு இல்லாமல் தளத்திற்கு நீங்கள் மீண்டும் முயற்சி செய்தால், அவை ஒத்திசைவான அலையில் மீண்டும் மீண்டும் வராது.
16 கோர்களை 16% இல் ஏற்றும் 100 PgBouncers இன் உதாரணம் இங்கே.
நாங்கள் கேஸ்கேடிங் PgBouncerக்கு வந்துவிட்டோம். இது எங்கள் பவுன்சர் சுமையில் நாம் அடையக்கூடிய சிறந்த உள்ளமைவாகும். எங்கள் வெளிப்புற பவுன்சர்கள் TCP ஹேண்ட்ஷேக்கிற்காக சேவை செய்கின்றன, மேலும் உள் பவுன்சர்கள் வெளிப்புற இணைப்புகளை பெரிதும் துண்டாடாமல் இருப்பதற்காக உண்மையான பூலிங்கிற்காக சேவை செய்கின்றன.
இந்த கட்டமைப்பில், ஒரு மென்மையான மறுதொடக்கம் சாத்தியமாகும். இந்த 18 பவுன்சர்களையும் ஒவ்வொன்றாக மறுதொடக்கம் செய்யலாம். ஆனால் அத்தகைய கட்டமைப்பை பராமரிப்பது மிகவும் கடினம். சிஸ்டம் நிர்வாகிகள், டெவொப்ஸ் மற்றும் இந்த சர்வருக்கு உண்மையிலேயே பொறுப்பான நபர்கள் இந்த திட்டத்தில் மிகவும் மகிழ்ச்சியாக இருக்க மாட்டார்கள்.
எங்களின் அனைத்து மேம்பாடுகளும் ஓப்பன் சோர்ஸில் விளம்பரப்படுத்தப்படலாம் என்று தோன்றுகிறது, ஆனால் பவுன்சர் சரியாக ஆதரிக்கவில்லை. எடுத்துக்காட்டாக, ஒரே போர்ட்டில் பல பிஜிபவுன்சர்களை இயக்கும் திறன் ஒரு மாதத்திற்கு முன்பு செய்யப்பட்டது. இந்த அம்சத்துடன் ஒரு இழுவை கோரிக்கை சில ஆண்டுகளுக்கு முன்பு இருந்தது.
அல்லது இன்னும் ஒரு உதாரணம். Postgres இல், கூடுதல் அங்கீகாரம் இல்லாமல் மற்றொரு இணைப்பிற்கு ரகசியத்தை அனுப்புவதன் மூலம் இயங்கும் கோரிக்கையை ரத்து செய்யலாம். ஆனால் சில கிளையண்டுகள் ஒரு TCP-மீட்டமைப்பை அனுப்புகின்றன, அதாவது அவர்கள் பிணைய இணைப்பை உடைக்கிறார்கள். பவுன்சர் இதை என்ன செய்வார்? அவன் ஒன்றும் செய்ய மாட்டான். கோரிக்கையை அது தொடர்ந்து செயல்படுத்தும். சிறிய கோரிக்கைகளுடன் அடித்தளத்தை அமைத்த ஏராளமான இணைப்புகளை நீங்கள் பெற்றிருந்தால், பவுன்சரிலிருந்து இணைப்பைத் துண்டிப்பது போதுமானதாக இருக்காது, தரவுத்தளத்தில் இயங்கும் கோரிக்கைகளையும் நீங்கள் பூர்த்தி செய்ய வேண்டும்.
இது இணைக்கப்பட்டுள்ளது, மேலும் சிக்கல் இன்னும் பவுன்சரின் அப்ஸ்ட்ரீமில் இணைக்கப்படவில்லை.
எனவே, எங்களுக்கு எங்கள் சொந்த இணைப்பு பூலர் தேவை என்ற முடிவுக்கு வந்தோம், இது உருவாக்கப்படும், இணைக்கப்படும், அதில் சிக்கல்களை விரைவாக சரிசெய்ய முடியும், மேலும் இது பல திரிக்கப்பட்டதாக இருக்க வேண்டும்.
மல்டித்ரெடிங்கை முக்கிய பணியாக அமைத்துள்ளோம். உள்வரும் TLS இணைப்புகளின் அலைகளை நாம் நன்றாகக் கையாள வேண்டும்.
இதைச் செய்ய, மெஷினாரியம் என்ற தனி நூலகத்தை உருவாக்க வேண்டியிருந்தது, இது நெட்வொர்க் இணைப்பின் இயந்திர நிலைகளை வரிசைக் குறியீடாக விவரிக்க வடிவமைக்கப்பட்டுள்ளது. நீங்கள் libpq மூலக் குறியீட்டைப் பார்த்தால், உங்களுக்கு ஒரு முடிவைத் தரக்கூடிய சிக்கலான அழைப்புகளைக் காண்பீர்கள், மேலும், "சிறிது நேரம் கழித்து என்னை அழைக்கவும். இப்போது என்னிடம் IO உள்ளது, ஆனால் IO கடந்து செல்லும் போது, செயலியில் சுமை உள்ளது. மேலும் இது பல நிலை திட்டமாகும். நெட்வொர்க் தொடர்பு பொதுவாக மாநில இயந்திரத்தால் விவரிக்கப்படுகிறது. "நான் இதற்கு முன்பு N அளவுள்ள பாக்கெட் தலைப்பைப் பெற்றிருந்தால், இப்போது நான் N பைட்டுகளுக்காகக் காத்திருக்கிறேன்", "நான் ஒரு SYNC பாக்கெட்டை அனுப்பியிருந்தால், இப்போது நான் ரிசல்ட் மெட்டாடேட்டாவுடன் ஒரு பாக்கெட்டுக்காகக் காத்திருக்கிறேன்" போன்ற நிறைய விதிகள் உள்ளன. பிரமை ஒரு வரி ஸ்கேனாக மாற்றப்பட்டது போல் இது கடினமான எதிர்-உள்ளுணர்வு குறியீட்டை மாற்றுகிறது. மாநில இயந்திரத்திற்குப் பதிலாக, புரோகிராமர் முக்கிய தொடர்புப் பாதையை சாதாரண கட்டாயக் குறியீட்டின் வடிவத்தில் விவரிக்கும் வகையில் நாங்கள் அதை உருவாக்கினோம். இந்த கட்டாயக் குறியீட்டில், நெட்வொர்க்கில் இருந்து தரவைக் காத்து, செயல்படுத்தும் சூழலை மற்றொரு கரோட்டினுக்கு (கிரீன் த்ரெட்) அனுப்புவதன் மூலம் செயல்படுத்தல் வரிசை குறுக்கிடப்பட வேண்டிய இடங்களை நீங்கள் செருக வேண்டும். இந்த அணுகுமுறை பிரமையில் மிகவும் எதிர்பார்க்கப்படும் பாதையை வரிசையாக எழுதி, பின்னர் அதில் கிளைகளைச் சேர்ப்பதைப் போன்றது.
இதன் விளைவாக, TCP ஏற்றுக்கொள்ளும் மற்றும் ரவுண்ட்-ராபின் பல தொழிலாளர்களுக்கு TPC இணைப்பை அனுப்பும் ஒரு நூல் எங்களிடம் உள்ளது.
இந்த வழக்கில், ஒவ்வொரு கிளையன்ட் இணைப்பும் எப்போதும் ஒரு செயலியில் இயங்கும். மேலும் இது தற்காலிக சேமிப்பிற்கு ஏற்றதாக மாற்ற உங்களை அனுமதிக்கிறது.
தவிர, சிஸ்டம் TCP ஸ்டேக்கை ஆஃப்லோட் செய்வதற்காக சிறிய பாக்கெட்டுகளின் சேகரிப்பை ஒரு பெரிய பாக்கெட்டாக சிறிது மேம்படுத்தியுள்ளோம்.
கூடுதலாக, ஒடிஸி, கட்டமைக்கப்படும் போது, நெட்வொர்க் இணைப்பு செயலிழந்தால் ரத்துசெய்து திரும்ப திரும்ப அனுப்ப முடியும், அதாவது கோரிக்கைக்காக யாரும் காத்திருக்கவில்லை எனில், ஒடிஸி தரவுத்தளத்தை நிறைவேற்ற முயற்சிக்க வேண்டாம் என்று கூறுகிறது. விலைமதிப்பற்ற வளங்களை வீணாக்கக்கூடிய கோரிக்கை.
முடிந்த போதெல்லாம், நாங்கள் ஒரே கிளையண்டுடன் இணைப்புகளை வைத்திருக்கிறோம். இது application_name_add_host ஐ மீண்டும் நிறுவுவதைத் தவிர்க்கிறது. முடிந்தால், கண்டறிதலுக்குத் தேவையான அளவுருக்களின் கூடுதல் மீட்டமைப்பு எங்களிடம் இல்லை.
நாங்கள் Yandex.Cloud இன் நலன்களுக்காக வேலை செய்கிறோம். நீங்கள் நிர்வகிக்கப்பட்ட PostgreSQL ஐப் பயன்படுத்துகிறீர்கள் மற்றும் உங்களிடம் இணைப்பு பூலர் நிறுவப்பட்டிருந்தால், நீங்கள் தர்க்கரீதியான பிரதிகளை வெளிப்புறமாக உருவாக்கலாம், அதாவது நீங்கள் விரும்பினால், தருக்க நகலெடுப்பைப் பயன்படுத்தி எங்களை விட்டுவிடுங்கள். தர்க்கரீதியான நகலெடுப்பின் ஓட்டத்திற்கு வெளியே பவுன்சர் கொடுக்காது.
இது தர்க்கரீதியான பிரதிகளை அமைப்பதற்கான ஒரு எடுத்துக்காட்டு.
கூடுதலாக, எங்களிடம் உடல் பிரதிபலிப்பு வெளிப்புறமாக உள்ளது. கிளவுட்டில், நிச்சயமாக, இது சாத்தியமற்றது, ஏனென்றால் கிளஸ்டர் தன்னைப் பற்றிய அதிக தகவல்களைத் தரும். ஆனால் உங்கள் நிறுவல்களில், ஒடிஸியில் இணைப்பு பூலர் மூலம் உங்களுக்கு உடல் பிரதிபலிப்பு தேவைப்பட்டால், அது சாத்தியமாகும்.
ஒடிஸி PgBouncer உடன் முழுமையாக இணக்கமான கண்காணிப்பைக் கொண்டுள்ளது. ஏறக்குறைய ஒரே கட்டளைகளை இயக்கும் அதே கன்சோல் எங்களிடம் உள்ளது. ஏதேனும் விடுபட்டிருந்தால், இழுக்கும் கோரிக்கையை அனுப்பவும் அல்லது குறைந்தபட்சம் GitHub இல் ஏதேனும் சிக்கலை அனுப்பினால், தேவையான கட்டளைகளை நிறைவு செய்வோம். ஆனால் எங்களிடம் ஏற்கனவே PgBouncer கன்சோலின் முக்கிய செயல்பாடு உள்ளது.
நிச்சயமாக எங்களிடம் பகிர்தலில் பிழை உள்ளது. தளத்தால் புகாரளிக்கப்பட்ட பிழையை நாங்கள் திருப்பித் தருவோம். நீங்கள் ஏன் அடிவாரத்தில் இல்லை என்ற தகவலைப் பெறுவீர்கள், நீங்கள் அதில் இல்லை என்பது மட்டுமல்ல.
PgBouncer உடன் உங்களுக்கு 100% இணக்கத்தன்மை தேவைப்பட்டால் இந்த அம்சம் முடக்கப்படும். நாம் ஒரு பவுன்சரைப் போல் நடந்து கொள்ளலாம்.
வடிவமைப்பு
ஒடிஸி மூலக் குறியீடு பற்றி சில வார்த்தைகள்.
எடுத்துக்காட்டாக, "Pause / Resume" கட்டளைகள் உள்ளன. அவை பொதுவாக தரவுத்தளத்தைப் புதுப்பிக்கப் பயன்படுகின்றன. நீங்கள் Postgres ஐ மேம்படுத்த வேண்டும் என்றால், நீங்கள் அதை இணைப்பு பூலரில் இடைநிறுத்தி, pg_upgrade செய்து, பின்னர் மீண்டும் தொடரலாம். கிளையன்ட் தரப்பிலிருந்து, தரவுத்தளத்தின் வேகம் குறைவது போல் இருக்கும். இந்த செயல்பாடு சமூகத்தைச் சேர்ந்தவர்களால் எங்களிடம் கொண்டு வரப்பட்டது. அவள் இன்னும் இறக்கவில்லை, ஆனால் விரைவில் எல்லாம் நடக்கும். (ஏற்கனவே இறந்துவிட்டார்)
- ஏற்கனவே இறந்துவிட்டார்
கூடுதலாக, PgBouncer இல் உள்ள புதிய அம்சங்களில் ஒன்று SCRAM அங்கீகார ஆதரவு ஆகும், இது Yandex.Cloud இல் வேலை செய்யாத ஒருவரால் எங்களிடம் கொண்டு வரப்பட்டது. இரண்டும் சிக்கலான செயல்பாடு மற்றும் முக்கியமானவை.
எனவே, ஒடிஸி எதனால் ஆனது என்பதை நான் உங்களுக்குச் சொல்ல விரும்புகிறேன், நீங்கள் இப்போது சில குறியீட்டை எழுத விரும்பினால்.
உங்களிடம் அசல் ஒடிஸி தளம் உள்ளது, இது இரண்டு முக்கிய நூலகங்களை நம்பியுள்ளது. கிவி நூலகம் என்பது போஸ்ட்கிரெஸ் செய்தி நெறிமுறையின் செயலாக்கமாகும். அதாவது, போஸ்ட்கிரெஸின் நேட்டிவ் ப்ரோட்டோ 3 என்பது ஸ்டாண்டர்ட் மெசேஜ் ஆகும், அவை முன்பக்கமும் பின்தளங்களும் பரிமாறிக்கொள்ளலாம். அவை கிவி நூலகத்தில் செயல்படுத்தப்படுகின்றன.
மெஷினேரியம் நூலகம் ஒரு நூல் செயலாக்க நூலகம் ஆகும். இந்த மெஷினேரியத்தின் ஒரு சிறிய பகுதி அசெம்பிளரில் எழுதப்பட்டுள்ளது. ஆனால் கவலைப்பட வேண்டாம், 15 வரிகள் மட்டுமே உள்ளன.
ஒடிஸி கட்டிடக்கலை. கரோட்டின்களை இயக்கும் ஒரு முக்கிய இயந்திரம் உள்ளது. இந்த இயந்திரம் உள்வரும் TCP இணைப்புகளை ஏற்றுக்கொண்டு தொழிலாளர்களிடையே விநியோகம் செய்கிறது.
ஒரு தொழிலாளிக்குள், பல வாடிக்கையாளர்களுக்கான கையாளுபவர் வேலை செய்ய முடியும். மேலும் பிரதான நூலில், குளத்தில் இனி தேவைப்படாத இணைப்புகளை அகற்றுவதற்கான கன்சோல் மற்றும் க்ரோன் பணிகளின் செயலாக்கம் சுழல்கிறது.
ஒடிஸி நிலையான போஸ்ட்கிரெஸ் சோதனைத் தொகுப்பைப் பயன்படுத்தி சோதிக்கப்படுகிறது. நாங்கள் பவுன்சர் மூலமாகவும், ஒடிஸி மூலமாகவும் நிறுவல் சரிபார்ப்பை இயக்குகிறோம், நாங்கள் ஒரு பூஜ்ய டிவியைப் பெறுகிறோம். பௌன்சர் மற்றும் ஒடிஸியில் ஒரே மாதிரியாக தோல்வியடைந்த தேதி வடிவமைப்பு தொடர்பான பல சோதனைகள் உள்ளன.
கூடுதலாக, பல ஓட்டுநர்கள் தங்கள் சொந்த சோதனைகளைக் கொண்டுள்ளனர். ஒடிஸியை சோதிக்க அவர்களின் சோதனைகளைப் பயன்படுத்துகிறோம்.
மேலும், எங்களின் அடுக்கடுக்கான உள்ளமைவின் காரணமாக, நாம் பல்வேறு மூட்டைகளை சோதிக்க வேண்டும்: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, அடுக்கில் உள்ள ஏதேனும் ஒரு பாகத்தில் ஒடிஸி இருந்தால், அது எதிர்பார்த்தபடியே செயல்படும். .
ரேக்
உற்பத்தியில் ஒடிஸியைப் பயன்படுத்துகிறோம். மேலும், எல்லாம் வேலை செய்யும் என்று நான் சொன்னால் அது நியாயமாக இருக்காது. இல்லை, அதாவது ஆம், ஆனால் எப்போதும் இல்லை. எடுத்துக்காட்டாக, தயாரிப்பில் அனைத்தும் வேலை செய்தன, பின்னர் PostgreSQL புரொபஷனலில் இருந்து எங்கள் நண்பர்கள் வந்து எங்களுக்கு நினைவக கசிவு இருப்பதாகக் கூறினார்கள். அவை உண்மையில் இருந்தன, நாங்கள் அவற்றை சரிசெய்தோம். ஆனால் அது எளிமையாக இருந்தது.
இணைப்பு பூலரில் உள்வரும் TLS இணைப்புகள் மற்றும் வெளிச்செல்லும் TLS இணைப்புகள் இருப்பதைக் கண்டறிந்தோம். இணைப்புகளுக்கு கிளையன்ட் சான்றிதழ்கள் மற்றும் சர்வர் சான்றிதழ்கள் தேவை.
பவுன்சர் மற்றும் ஒடிஸி சர்வர் சான்றிதழ்கள் pcache மூலம் மீண்டும் படிக்கப்படுகின்றன, ஆனால் கிளையன்ட் சான்றிதழ்கள் pcache இலிருந்து மீண்டும் படிக்க வேண்டிய அவசியமில்லை, ஏனெனில் எங்கள் அளவிடக்கூடிய Odyssey இறுதியில் இந்த சான்றிதழைப் படிக்கும் கணினி செயல்திறனைப் பொறுத்தது. அவர் உடனடியாக ஓய்வெடுக்காததால் இது எங்களுக்கு ஆச்சரியமாக இருந்தது. முதலில், இது நேர்கோட்டில் அளவிடப்பட்டது, மேலும் 20 உள்வரும் ஒரே நேரத்தில் இணைப்புகளுக்குப் பிறகு, இந்த சிக்கல் தன்னை வெளிப்படுத்தியது.
செருகக்கூடிய அங்கீகார முறை என்பது உள்ளமைக்கப்பட்ட lunux கருவிகள் மூலம் அங்கீகரிக்கும் திறன் ஆகும். PgBouncer இல், PAM இலிருந்து ஒரு பதிலுக்காகக் காத்திருக்கும் ஒரு தனி இழை உள்ளது மற்றும் தற்போதைய இணைப்பிற்கு சேவை செய்யும் ஒரு முக்கிய PgBouncer நூல் உள்ளது மற்றும் PAM இழையில் வாழ அவர்களைக் கேட்கும் வகையில் இது செயல்படுத்தப்படுகிறது.
ஒரு எளிய காரணத்திற்காக இதை நாங்கள் செயல்படுத்தவில்லை. எங்களிடம் பல நீரோடைகள் உள்ளன. நமக்கு அது ஏன் தேவை?
இதன் விளைவாக, உங்களிடம் PAM அங்கீகாரம் மற்றும் PAM அல்லாத அங்கீகாரம் இருந்தால் இது சிக்கல்களை உருவாக்கலாம், பின்னர் PAM அங்கீகாரத்தின் பெரிய அலையானது PAM அல்லாத அங்கீகாரத்தை கணிசமாக தாமதப்படுத்தும். நாம் சரி செய்யாத விஷயங்களில் இதுவும் ஒன்று. ஆனால் நீங்கள் அதை சரிசெய்ய விரும்பினால், இதைச் செய்யலாம்.
உள்வரும் அனைத்து இணைப்புகளையும் ஏற்கும் ஒரு நூல் எங்களிடம் உள்ளது என்பது மற்றொரு ரேக். பின்னர் அவர்கள் தொழிலாளர் குளத்திற்கு மாற்றப்படுகிறார்கள், அங்கு TLS கைகுலுக்கல் நடைபெறும்.
இதன் விளைவாக, உங்களிடம் 20 நெட்வொர்க் இணைப்புகளின் ஒத்திசைவான அலை இருந்தால், அவை அனைத்தும் ஏற்றுக்கொள்ளப்படும். கிளையன்ட் பக்கத்தில், libpq காலாவதியைப் புகாரளிக்கத் தொடங்கும். இயல்பாக, அங்கு 000 வினாடிகள் ஆகும்.
அவர்கள் அனைவரும் ஒரே நேரத்தில் அடித்தளத்திற்குள் நுழைய முடியாவிட்டால், அவர்களால் அடித்தளத்திற்குள் நுழைய முடியாது, ஏனென்றால் இவை அனைத்தும் ஒரு அதிவேகமற்ற மறு முயற்சியால் மறைக்கப்படலாம்.
PgBouncer திட்டத்தை இங்கே நகலெடுத்து முடித்தோம், இதனால் நாங்கள் ஏற்கும் TCP இணைப்புகளின் எண்ணிக்கையைத் தடுக்கலாம்.
நாங்கள் இணைப்புகளை ஏற்றுக்கொள்கிறோம், ஆனால் இறுதியில் அவர்களுக்கு கைகுலுக்க நேரம் இல்லை என்று பார்த்தால், CPU ஆதாரங்களை அவர்கள் பயன்படுத்தாதபடி வரிசையில் வைக்கிறோம். வந்துள்ள அனைத்து இணைப்புகளுக்கும் ஒரே நேரத்தில் கைகுலுக்கல் செய்யப்படாமல் போகலாம் என்பதற்கு இது வழிவகுக்கிறது. சுமை போதுமானதாக இருந்தாலும், குறைந்தபட்சம் யாராவது தரவுத்தளத்தில் நுழைவார்கள்.
ரோடுமேப்
ஒடிஸியில் நீங்கள் எதிர்காலத்தில் என்ன பார்க்க விரும்புகிறீர்கள்? நம்மை வளர்த்துக் கொள்ள நாம் என்ன தயாராக இருக்கிறோம், சமூகத்திடம் இருந்து நாம் என்ன எதிர்பார்க்கிறோம்?
ஆகஸ்ட் 2019 க்கு.
ஆகஸ்ட் மாதத்தில் ஒடிஸி சாலை வரைபடம் இப்படி இருந்தது:
- SCRAM மற்றும் PAM அங்கீகாரம் தேவை.
- காத்திருப்புக்கு படிக்கக் கோரிக்கைகளை அனுப்ப விரும்புகிறோம்.
- நான் ஆன்லைனில் மறுதொடக்கம் செய்ய விரும்புகிறேன்.
- மற்றும் சர்வரில் இடைநிறுத்தும் திறன்.
இந்த வரைபடத்தில் பாதி முடிந்தது, எங்களால் அல்ல. மேலும் இது நல்லது. எனவே மீதமுள்ளவற்றை விவாதித்து மேலும் சேர்ப்போம்.
? கோரிக்கைகளை நிறைவேற்றாமல், காற்றை வெறுமனே சூடாக்கும் பிரதிகள் எங்களிடம் உள்ளன. அவர்கள் தோல்வி மற்றும் மாறுதல் வழங்க வேண்டும். தரவு மையங்களில் ஏதேனும் சிக்கல்கள் ஏற்பட்டால், சில பயனுள்ள வேலைகளில் அவற்றை ஆக்கிரமிக்க விரும்புகிறேன். ஏனெனில் அதே மைய செயலிகளை, அதே நினைவகத்தை வேறுவிதமாக நாம் கட்டமைக்க முடியாது, ஏனெனில் பிரதியெடுப்பு இல்லையெனில் வேலை செய்யாது.
கொள்கையளவில், Postgres இல், 10 இல் தொடங்கி, இணைக்கும் போது session_attrs ஐக் குறிப்பிட முடியும். இணைப்பில் உள்ள அனைத்து தரவுத்தள ஹோஸ்ட்களையும் நீங்கள் பட்டியலிடலாம் மற்றும் நீங்கள் ஏன் தரவுத்தளத்திற்கு செல்கிறீர்கள் என்று கூறலாம்: எழுத அல்லது படிக்க மட்டும். மேலும், ட்ரைவரே தனக்கு மிகவும் பிடித்தமான பட்டியலில் முதல் ஹோஸ்டைத் தேர்ந்தெடுப்பார், இது session_attrs இன் தேவைகளைப் பூர்த்தி செய்கிறது.
ஆனால் இந்த அணுகுமுறையின் சிக்கல் என்னவென்றால், அது பிரதிபலிப்பு தாமதத்தை கட்டுப்படுத்தாது. உங்கள் சேவைக்கு ஏற்றுக்கொள்ள முடியாத நேரத்தில் பின்னால் இருக்கும் சில வகையான பிரதிகள் உங்களிடம் இருக்கலாம். ஒரு பிரதியில் வாசிப்பு கோரிக்கைகளை முழு அம்சத்துடன் செயல்படுத்த, உண்மையில், ஒடிஸியில் படிக்க முடியாதபோது வேலை செய்யாத திறனை நாம் ஆதரிக்க வேண்டும்.
ஒடிஸி அவ்வப்போது தரவுத்தளத்திற்குச் சென்று முதன்மையிலிருந்து பிரதி தூரத்தைக் கேட்க வேண்டும். அது வரம்பை அடைந்துவிட்டால், தரவுத்தளத்தில் புதிய கோரிக்கைகளை அனுமதிக்காதீர்கள், நீங்கள் இணைப்புகளை மீண்டும் தொடங்க வேண்டும் என்று கிளையண்டிடம் சொல்லுங்கள், மேலும் கோரிக்கைகளை செயல்படுத்த மற்றொரு ஹோஸ்டைத் தேர்ந்தெடுக்கவும். இது தரவுத்தளத்தை விரைவாக பிரதியெடுப்பு பின்னடைவை மீட்டெடுக்கவும், வினவலுக்கு பதிலளிக்க மீண்டும் திரும்பவும் அனுமதிக்கும்.
செயல்படுத்தும் தேதிகளை பெயரிடுவது கடினம், ஏனெனில் இது திறந்த மூலமாகும். ஆனால், நான் நம்புகிறேன், PgBouncer இன் சக ஊழியர்களைப் போல 2,5 ஆண்டுகள் அல்ல. ஒடிஸியில் நான் பார்க்க விரும்பும் அம்சம் இதுதான்.
. இப்போது நீங்கள் ஒரு தயாரிக்கப்பட்ட அறிக்கையை இரண்டு வழிகளில் உருவாக்கலாம். முதலில், நீங்கள் ஒரு SQL கட்டளையை இயக்கலாம், அதாவது "தயாரித்தது". இந்த SQL கட்டளையைப் புரிந்து கொள்ள, பவுன்சர் பக்கத்தில் SQL ஐ எவ்வாறு புரிந்துகொள்வது என்பதை நாம் கற்றுக் கொள்ள வேண்டும். முழுப் பாகுபடுத்தியும் தேவைப்படுவதால், இது ஓவர்கில் ஆகும். ஒவ்வொரு SQL கட்டளையையும் நாம் அலச முடியாது.
ஆனால் proto3 இல் செய்தி நெறிமுறை மட்டத்தில் ஒரு தயாரிக்கப்பட்ட அறிக்கை உள்ளது. தயாரிக்கப்பட்ட அறிக்கை உருவாக்கப்படுகிறது என்ற தகவல் கட்டமைக்கப்பட்ட வடிவத்தில் வரும் இடம் இது. சில சர்வர் இணைப்பில் கிளையன்ட் தயார் செய்யப்பட்ட அறிக்கைகளை உருவாக்குமாறு கேட்டுக்கொண்டார் என்ற புரிதலை நாங்கள் ஆதரிக்கலாம். பரிவர்த்தனை மூடப்பட்டிருந்தாலும், சேவையகத்தையும் கிளையண்டையும் இணைக்க வேண்டும்.
ஆனால் இங்கே உரையாடலில் ஒரு முரண்பாடு எழுகிறது, ஏனெனில் கிளையன்ட் எந்த தயாரிக்கப்பட்ட அறிக்கைகளை உருவாக்கினார் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும் மற்றும் இந்த சேவையக இணைப்பை உருவாக்கிய அனைத்து கிளையண்டுகளுக்கும் இடையில் சேவையக இணைப்பைப் பகிர்ந்து கொள்ள வேண்டும் என்று ஒருவர் கூறுகிறார்.
ஆண்ட்ரெஸ் ஃப்ராய்ண்ட், வேறொரு சர்வர் இணைப்பில் ஏற்கனவே இதுபோன்ற தயாரிக்கப்பட்ட அறிக்கையை உருவாக்கிய வாடிக்கையாளர் உங்களிடம் வந்தால், அவருக்காக அதை உருவாக்கவும். ஆனால் கிளையண்டிற்குப் பதிலாக தரவுத்தளத்தில் வினவல்களை இயக்குவது கொஞ்சம் தவறாகத் தெரிகிறது, ஆனால் தரவுத்தளத்துடன் தொடர்புகொள்வதற்கான நெறிமுறையை எழுதும் டெவலப்பரின் பார்வையில், அவருக்கு வெறுமனே பிணைய இணைப்பு வழங்கப்பட்டால் வசதியாக இருக்கும். என்று ஒரு தயார் கோரிக்கை உள்ளது.
மேலும் ஒரு அம்சத்தை நாம் செயல்படுத்த வேண்டும். இப்போது PgBouncer உடன் இணக்கமான கண்காணிப்பு உள்ளது. சராசரி வினவல் செயல்படுத்தும் நேரத்தை நாம் திரும்பப் பெறலாம். ஆனால் சராசரி நேரம் மருத்துவமனையில் சராசரி வெப்பநிலை: யாரோ குளிர், யாரோ சூடாக - சராசரியாக எல்லோரும் ஆரோக்கியமாக இருக்கிறார்கள். அது உண்மையல்ல.
சதவீதங்களுக்கான ஆதரவை நாங்கள் செயல்படுத்த வேண்டும், இது வளங்களை உட்கொள்ளும் மெதுவான கோரிக்கைகள் இருப்பதைக் குறிக்கும் மற்றும் கண்காணிப்பை மிகவும் ஏற்றுக்கொள்ளும்.
மிக முக்கியமான விஷயம் என்னவென்றால், எனக்கு பதிப்பு 1.0 வேண்டும் (பதிப்பு 1.1 ஏற்கனவே வெளியிடப்பட்டது). உண்மை என்னவென்றால், இப்போது ஒடிஸி பதிப்பு 1.0rc இல் உள்ளது, அதாவது வெளியீட்டு வேட்பாளர். நினைவக கசிவைத் தவிர, நான் பட்டியலிட்ட அனைத்து ரேக்கும் அதே பதிப்பில் சரியாக சரி செய்யப்பட்டது.
பதிப்பு 1.0 நமக்கு என்ன அர்த்தம்? நாங்கள் ஒடிஸியை எங்கள் தளங்களுக்கு அனுப்புகிறோம். இது ஏற்கனவே எங்கள் தரவுத்தளங்களில் இயங்குகிறது, ஆனால் அது ஒரு வினாடிக்கு 1 கோரிக்கைகளை அடையும் போது, இது ஒரு வெளியீட்டு பதிப்பு என்றும் இது 000 என்று அழைக்கப்படும் பதிப்பு என்றும் கூறலாம்.
சமூகத்தில் உள்ள பலர் பதிப்பு 1.0 இல் அதிக இடைநிறுத்தம் மற்றும் SCRAM ஆகியவற்றைக் கேட்டுள்ளனர். ஆனால் SCRAM அல்லது இடைநிறுத்தம் இன்னும் ஒன்றிணைக்கப்படவில்லை என்பதால், அடுத்த பதிப்பை உற்பத்திக்கு வெளியிட வேண்டும் என்பதை இது குறிக்கும். ஆனால், பெரும்பாலும், இந்த பிரச்சினை மிகவும் விரைவாக தீர்க்கப்படும்.
உங்கள் கோரிக்கைக்காக காத்திருக்கிறேன். மேலும் பவுன்சரில் உங்களுக்கு என்ன பிரச்சனைகள் உள்ளன என்பதையும் கேட்க விரும்புகிறேன். அவற்றை விவாதிப்போம். உங்களுக்குத் தேவையான சில செயல்பாடுகளை நாங்கள் செயல்படுத்தலாம்.
இது எனது பகுதியை முடிக்கிறது, உங்களிடமிருந்து நான் கேட்க விரும்புகிறேன். நன்றி!
உங்கள் கேள்விகள்
எனது சொந்த application_பெயரை நான் வைத்தால், ஒடிஸியில் பரிவர்த்தனை பூலிங் உட்பட, அது சரியாக வீசப்படுமா?
ஒடிஸி அல்லது பவுன்சர்?
ஒடிஸியில். பவுன்சர் வீசப்பட்டது.
நாங்கள் ஒரு தொகுப்பை உருவாக்குவோம்.
எனது உண்மையான இணைப்பு மற்ற இணைப்புகளை விட அதிகமாக இருந்தால், அது அனுப்பப்படுமா?
பட்டியலிடப்பட்டுள்ள அனைத்து அளவுருக்களின் தொகுப்பை உருவாக்குவோம். இந்தப் பட்டியலில் application_name உள்ளதா என்று என்னால் சொல்ல முடியாது. அங்கு அவரைப் பார்த்ததாகத் தெரிகிறது. ஒரே அளவுருக்கள் அனைத்தையும் அமைப்போம். ஒரு கோரிக்கையுடன், தொடக்கத்தின் போது கிளையன்ட் நிறுவிய அனைத்தையும் செட் செய்யும்.
அறிக்கைக்கு நன்றி ஆண்ட்ரே! நல்ல அறிக்கை! ஒடிஸி ஒவ்வொரு நிமிடமும் வேகமாகவும் வேகமாகவும் உருவாகி வருவதில் நான் மகிழ்ச்சியடைகிறேன். அதையே தொடர விரும்புகிறேன். நாங்கள் ஏற்கனவே உங்களிடம் பல தரவு மூல இணைப்பைக் கேட்டுள்ளோம், இதனால் ஒடிஸி ஒரே நேரத்தில் வெவ்வேறு தரவுத்தளங்களுடன், அதாவது ஸ்லேவ் மாஸ்டருடன் இணைக்க முடியும், பின்னர் தோல்விக்குப் பிறகு தானாகவே புதிய மாஸ்டருடன் இணைக்க முடியும்.
ஆம், அந்த விவாதம் எனக்கு நினைவுக்கு வருகிறது. இப்போது பல சேமிப்பகங்கள் உள்ளன. ஆனால் அவர்களுக்கு இடையே மாறுதல் இல்லை. எங்கள் பக்கத்தில், சேவையகம் இன்னும் உயிருடன் இருக்கிறதா என்று வினவ வேண்டும் மற்றும் ஒரு தோல்வி ஏற்பட்டுள்ளதை புரிந்து கொள்ள வேண்டும், யார் pg_recovery ஐ அழைப்பார்கள். நாங்கள் மாஸ்டரிடம் வரவில்லை என்பதை புரிந்து கொள்ள எனக்கு ஒரு நிலையான வழி உள்ளது. தவறுகளிலிருந்து எப்படியாவது புரிந்து கொள்ள வேண்டும் அல்லது எப்படி? அதாவது, யோசனை சுவாரஸ்யமானது, அது விவாதிக்கப்படுகிறது. மேலும் கருத்துகளை எழுதுங்கள். சி தெரிந்த உழைக்கும் கைகள் உங்களிடம் இருந்தால், இது பொதுவாக அற்புதம்.
பிரதிகள் முழுவதும் அளவிடுதல் பற்றிய பிரச்சினையும் எங்களுக்கு ஆர்வமாக உள்ளது, ஏனென்றால், அப்ளிகேஷன் டெவலப்பர்களுக்கு, பிரதியூட்டப்பட்ட கிளஸ்டர்களை ஏற்றுக்கொள்வதை முடிந்தவரை எளிமையாக்க விரும்புகிறோம். ஆனால் இங்கே நான் அதிக கருத்துகளை விரும்புகிறேன், அதாவது, அதை எப்படி செய்வது, எப்படி நன்றாக செய்வது.
கேள்வி பிரதிகள் பற்றியது. உங்களிடம் ஒரு மாஸ்டர் மற்றும் பல பிரதிகள் இருப்பதாக மாறிவிடும். இணைப்புகளுக்காக மாஸ்டரை விட அவர்கள் நகலெடுப்பதற்கு குறைவாகவே செல்கிறார்கள் என்பது தெளிவாகிறது, ஏனெனில் அவர்களுக்கு வேறுபாடு இருக்கலாம். தரவுகளில் உள்ள வேறுபாடு உங்கள் வணிகம் திருப்தியடையாத வகையில் இருக்கலாம் என்றும், அது நகலெடுக்கப்படும் வரை நீங்கள் அங்கு செல்ல மாட்டீர்கள் என்றும் கூறியுள்ளீர்கள். அதே நேரத்தில், நீங்கள் நீண்ட நேரம் அங்கு செல்லாமல், பின்னர் செல்லத் தொடங்கினால், உங்களுக்குத் தேவையான தரவு உடனடியாக கிடைக்காது. அதாவது, நாம் தொடர்ந்து மாஸ்டரிடம் சென்றால், கேச் அங்கு வெப்பமடைகிறது, மேலும் கேச் பிரதியில் சற்று பின்தங்கியிருக்கும்.
ஆமாம், அது உண்மை தான். நீங்கள் விரும்பும் pcache இல் தரவுத் தொகுதிகள் இருக்காது, உண்மையான தற்காலிக சேமிப்பில் நீங்கள் விரும்பும் அட்டவணைகள் பற்றிய எந்த தகவலும் இருக்காது, திட்டங்களில் பாகுபடுத்தப்பட்ட வினவல்கள் இருக்காது, எதுவும் இல்லை.
உங்களிடம் சில வகையான கிளஸ்டர் இருக்கும்போது, அங்கு ஒரு புதிய பிரதியைச் சேர்க்கும்போது, அது தொடங்கும் போது, அதில் எல்லாம் மோசமாக உள்ளது, அதாவது அது அதன் தற்காலிக சேமிப்பை வளர்க்கிறது.
எனக்கு யோசனை வந்தது. ஒரு சிறிய சதவீத வினவல்களை முதலில் பிரதியில் இயக்குவதே சரியான அணுகுமுறையாக இருக்கும், இது தற்காலிக சேமிப்பை வெப்பமாக்கும். தோராயமாகச் சொன்னால், நாம் மாஸ்டரை விட 10 வினாடிகளுக்கு மேல் இருக்கக்கூடாது என்ற நிபந்தனை உள்ளது. இந்த நிலை ஒரு அலையில் சேர்க்கப்படக்கூடாது, ஆனால் சில வாடிக்கையாளர்களுக்கு சுமூகமாக.
ஆம், எடையை அதிகரிக்கவும்.
இது ஒரு நல்ல யோசனை. ஆனால் முதலில் நீங்கள் இந்த பணிநிறுத்தத்தை செயல்படுத்த வேண்டும். முதலில் நாம் அணைக்க வேண்டும், பின்னர் எப்படி இயக்குவது என்று யோசிப்போம். சீராக இயக்க இது ஒரு சிறந்த அம்சமாகும்.
nginx க்கு இந்த விருப்பம் உள்ளது slowly start சேவையகத்திற்கான கிளஸ்டரில். மேலும் அவர் படிப்படியாக சுமைகளை உருவாக்குகிறார்.
ஆம், அருமையான யோசனை, நாங்கள் அதை அடையும்போது முயற்சிப்போம்.
ஆதாரம்: www.habr.com