பட்ரோனி தோல்விக் கதைகள் அல்லது உங்கள் PostgreSQL கிளஸ்டரை எவ்வாறு சிதைப்பது. அலெக்ஸி லெசோவ்ஸ்கி

PostgreSQL க்கு அதிக கிடைக்கும் தன்மையை வழங்குவதே பட்ரோனியின் முக்கிய குறிக்கோள். ஆனால் பட்ரோனி ஒரு டெம்ப்ளேட் மட்டுமே, ஆயத்த கருவி அல்ல (பொதுவாக, ஆவணத்தில் கூறப்பட்டுள்ளது). முதல் பார்வையில், சோதனை ஆய்வகத்தில் பேட்ரோனியை அமைத்த பிறகு, இது என்ன ஒரு சிறந்த கருவி மற்றும் கிளஸ்டரை உடைப்பதற்கான எங்கள் முயற்சிகளை எவ்வளவு எளிதாகக் கையாளுகிறது என்பதை நீங்கள் பார்க்கலாம். இருப்பினும், நடைமுறையில், ஒரு உற்பத்தி சூழலில், எல்லாம் எப்போதும் ஒரு சோதனை ஆய்வகத்தில் போல் அழகாகவும் நேர்த்தியாகவும் நடக்காது.

என்னைப் பற்றி கொஞ்சம் சொல்கிறேன். நான் ஒரு கணினி நிர்வாகியாகத் தொடங்கினேன். இணைய வளர்ச்சியில் பணியாற்றினார். நான் 2014 முதல் Data Egret இல் பணிபுரிகிறேன். நிறுவனம் Postgres துறையில் ஆலோசனையில் ஈடுபட்டுள்ளது. நாங்கள் போஸ்ட்கிரெஸுக்குச் சரியாகச் சேவை செய்கிறோம், மேலும் ஒவ்வொரு நாளும் Postgres உடன் பணிபுரிகிறோம், எனவே செயல்பாடு தொடர்பான பல்வேறு நிபுணத்துவம் எங்களிடம் உள்ளது.

2018 ஆம் ஆண்டின் இறுதியில், நாங்கள் மெதுவாக பட்ரோனியைப் பயன்படுத்த ஆரம்பித்தோம். மற்றும் சில அனுபவங்கள் குவிந்துள்ளன. நாங்கள் எப்படியோ அதைக் கண்டறிந்து, டியூன் செய்து, எங்களின் சிறந்த நடைமுறைகளுக்கு வந்தோம். இந்த அறிக்கையில் நான் அவர்களைப் பற்றி பேசுவேன்.

Postgres தவிர, நான் Linux ஐ விரும்புகிறேன். நான் அதை சுற்றி குத்தி ஆராய விரும்புகிறேன், நான் கோர்களை சேகரிக்க விரும்புகிறேன். நான் மெய்நிகராக்கம், கொள்கலன்கள், டாக்கர், குபெர்னெட்ஸ் ஆகியவற்றை விரும்புகிறேன். பழைய நிர்வாக பழக்கவழக்கங்கள் பாதிக்கப்படுவதால் இவை அனைத்தும் எனக்கு ஆர்வமாக உள்ளன. நான் கண்காணிப்பை சமாளிக்க விரும்புகிறேன். மற்றும் நிர்வாகம் தொடர்பான postgres விஷயங்களை நான் விரும்புகிறேன், அதாவது பிரதி, காப்புப்பிரதி. எனது ஓய்வு நேரத்தில் நான் கோவில் எழுதுகிறேன். நான் சாப்ட்வேர் இன்ஜினியர் அல்ல, எனக்காகவே கோவில் எழுதுகிறேன். மேலும் அது எனக்கு மகிழ்ச்சியைத் தருகிறது.

• Postgres இல் HA (அதிக கிடைக்கும்) இல்லை என்பது உங்களில் பலருக்குத் தெரியும் என்று நினைக்கிறேன். HA ஐப் பெற, நீங்கள் எதையாவது நிறுவ வேண்டும், அதை உள்ளமைக்க வேண்டும், முயற்சி செய்து அதைப் பெற வேண்டும்.
• பல கருவிகள் உள்ளன, அவற்றில் பட்ரோனியும் ஒன்றாகும், இது HA ஐ அழகாகவும் நன்றாகவும் தீர்க்கிறது. ஆனால் எல்லாவற்றையும் ஒரு சோதனை ஆய்வகத்தில் வைத்து அதை இயக்குவதன் மூலம், இது அனைத்தும் செயல்படுவதை நாம் காணலாம், சில சிக்கல்களை மீண்டும் உருவாக்கலாம், பட்ரோனி அவற்றை எவ்வாறு வழங்குகிறது என்பதைப் பார்க்கலாம். மேலும் இவை அனைத்தும் சிறப்பாக செயல்படுவதை நாம் பார்ப்போம்.
• ஆனால் நடைமுறையில் பல்வேறு பிரச்சனைகளை எதிர்கொண்டோம். மேலும் இந்த பிரச்சனைகளை பற்றி பேசுவேன்.
• நாங்கள் அதை எவ்வாறு கண்டறிந்தோம், என்ன மாற்றியமைத்தோம் - அது எங்களுக்கு உதவுகிறதா இல்லையா என்பதை நான் உங்களுக்கு சொல்கிறேன்.

• பட்ரோனியை எவ்வாறு நிறுவுவது என்று நான் உங்களுக்குச் சொல்ல மாட்டேன், ஏனென்றால் நீங்கள் இணையத்தில் கூகிள் செய்யலாம், இது எவ்வாறு தொடங்குகிறது, அது எவ்வாறு கட்டமைக்கப்படுகிறது என்பதைப் புரிந்துகொள்ள உள்ளமைவு கோப்புகளைப் பார்க்கலாம். திட்டங்கள், கட்டமைப்புகள், இணையத்தில் அதைப் பற்றிய தகவல்களைக் கண்டறிதல் ஆகியவற்றை நீங்கள் புரிந்து கொள்ளலாம்.
• வேறொருவரின் அனுபவத்தைப் பற்றி நான் பேச மாட்டேன். நாங்கள் எதிர்கொண்ட பிரச்சனைகளை மட்டும் பேசுவேன்.
• நான் Patroni மற்றும் PostgreSQL க்கு வெளியே உள்ள பிரச்சனைகளைப் பற்றி பேசமாட்டேன். உதாரணமாக, சமநிலையுடன் தொடர்புடைய சிக்கல்கள் இருந்தால், எங்கள் கிளஸ்டர் சரிந்தால், நான் அதைப் பற்றி பேசமாட்டேன்.

எங்கள் அறிக்கையைத் தொடங்குவதற்கு முன் ஒரு சிறிய மறுப்பு.

நாங்கள் சந்தித்த இந்த சிக்கல்கள் அனைத்தும், செயல்பாட்டின் முதல் 6-7-8 மாதங்களில் அவற்றை நாங்கள் சந்தித்தோம். காலப்போக்கில், நாங்கள் எங்கள் உள் சிறந்த நடைமுறைகளுக்கு வந்தோம். மற்றும் எங்கள் பிரச்சினைகள் மறைந்துவிட்டன. எனவே, அறிக்கை ஆறு மாதங்களுக்கு முன்பு அறிவிக்கப்பட்டது, அது என் தலையில் புதியதாக இருந்தபோது, ​​​​அதை நான் சரியாக நினைவில் வைத்தேன்.

அறிக்கையைத் தயாரிக்கும் போது, ​​நான் ஏற்கனவே பழைய போஸ்ட்மார்ட்டம்களை எழுப்பி, பதிவுகளைப் பார்த்தேன். மேலும் சில விவரங்கள் மறக்கப்படலாம் அல்லது சில விவரங்களை முழுமையாக ஆய்வு செய்ய முடியாமல் போகலாம், எனவே சில புள்ளிகளில் சிக்கல்கள் முழுமையாகக் கருதப்படவில்லை அல்லது சில தகவல் பற்றாக்குறை இருப்பதாகத் தோன்றலாம். எனவே இந்த நேரத்தில் என்னை மன்னிக்குமாறு கேட்டுக்கொள்கிறேன்.

பட்ரோனி என்றால் என்ன?

• இது HA ஐ உருவாக்குவதற்கான டெம்ப்ளேட். என்று ஆவணத்தில் கூறப்பட்டுள்ளது. என் பார்வையில், இது மிகவும் சரியான தெளிவு. பட்ரோனி என்பது உங்கள் எல்லா பிரச்சனைகளையும் தீர்க்கும் ஒரு வெள்ளி புல்லட் அல்ல, அதாவது, அதைச் செயல்படுத்துவதற்கும் நன்மைகளைத் தருவதற்கும் நீங்கள் முயற்சி செய்ய வேண்டும்.
• இது ஒவ்வொரு தரவுத்தள சேவையிலும் நிறுவப்பட்ட ஒரு முகவர் சேவையாகும், மேலும் இது உங்கள் Postgres க்கான ஒரு வகையான init அமைப்பாகும். இது போஸ்ட்கிரெஸைத் தொடங்குகிறது, நிறுத்துகிறது, மறுதொடக்கம் செய்கிறது, மறுகட்டமைக்கிறது மற்றும் உங்கள் கிளஸ்டரின் இடவியலை மாற்றுகிறது.
• அதன்படி, கிளஸ்டரின் நிலையைச் சேமிக்க, அதன் தற்போதைய பிரதிநிதித்துவம், தோற்றமளிக்கும் வகையில், சில வகையான சேமிப்பு தேவைப்படுகிறது. இந்த கண்ணோட்டத்தில், பட்ரோனி ஒரு வெளிப்புற அமைப்பில் நிலையை சேமிக்கும் பாதையை எடுத்தார். இது ஒரு விநியோகிக்கப்பட்ட கட்டமைப்பு சேமிப்பு அமைப்பு. இது Etcd, Consul, ZooKeeper அல்லது kubernetes Etcd ஆக இருக்கலாம், அதாவது இந்த விருப்பங்களில் ஒன்று.
• மற்றும் Patroni இன் அம்சங்களில் ஒன்று, பெட்டியில் இருந்து ஆட்டோஃபைலரை அமைப்பதன் மூலம் மட்டுமே பெறுவீர்கள். ஒப்பிடுவதற்கு Repmgrஐ எடுத்துக் கொண்டால், அதில் ஃபைலர் சேர்க்கப்படும். Repmgr உடன், நாம் ஒரு மாறுதலைப் பெறுகிறோம், ஆனால் நமக்கு ஒரு ஆட்டோஃபைலர் தேவைப்பட்டால், அதை கூடுதலாக உள்ளமைக்க வேண்டும். Patroni ஏற்கனவே பெட்டிக்கு வெளியே ஒரு autofiler உள்ளது.
• மேலும் பல விஷயங்கள் உள்ளன. உதாரணமாக, கட்டமைப்புகளை பராமரித்தல், புதிய பிரதிகளை ஊற்றுதல், காப்புப்பிரதி போன்றவை. ஆனால் இது அறிக்கையின் எல்லைக்கு அப்பாற்பட்டது, நான் அதைப் பற்றி பேசமாட்டேன்.

மேலும் ஒரு சிறிய முடிவு என்னவென்றால், பட்ரோனியின் முக்கியப் பணியானது, ஒரு தன்னியக்க கோப்பை நன்றாகவும் நம்பகத்தன்மையுடனும் செய்வதே ஆகும், இதனால் எங்கள் கிளஸ்டர் தொடர்ந்து செயல்படும் மற்றும் பயன்பாடு கிளஸ்டர் டோபாலஜியில் மாற்றங்களைக் கவனிக்காது.

ஆனால் நாம் Patroni பயன்படுத்த தொடங்கும் போது, ​​எங்கள் அமைப்பு இன்னும் கொஞ்சம் சிக்கலாகிறது. முன்பு போஸ்ட்கிரெஸ் இருந்தால், பட்ரோனியைப் பயன்படுத்தும் போது, ​​​​பட்ரோனியைப் பெறுகிறோம், மாநிலம் சேமிக்கப்படும் இடத்தில் டிசிஎஸ் கிடைக்கும். மேலும் அது எப்படியாவது வேலை செய்ய வேண்டும். அதனால் என்ன தவறு நடக்கலாம்?

உடைந்து போகலாம்:

• போஸ்ட்கிரெஸ் உடைந்து போகலாம். இது ஒரு மாஸ்டர் அல்லது பிரதியாக இருக்கலாம், அவற்றில் ஒன்று தோல்வியடையலாம்.
• பட்ரோனியே உடைந்து போகலாம்.
• மாநிலம் சேமிக்கப்படும் DCS உடைந்து போகலாம்.
• மற்றும் நெட்வொர்க் உடைந்து போகலாம்.

இந்த புள்ளிகள் அனைத்தையும் நான் அறிக்கையில் பரிசீலிப்பேன்.

வழக்குகள் மிகவும் சிக்கலானதாக மாறும்போது நான் அவற்றைப் பரிசீலிப்பேன், வழக்கு பல கூறுகளை உள்ளடக்கியது என்ற கண்ணோட்டத்தில் அல்ல. அகநிலை உணர்வுகளின் பார்வையில், இந்த வழக்கு எனக்கு கடினமாக இருந்தது, அதை பிரிப்பது கடினம் ... மற்றும் நேர்மாறாக, சில வழக்குகள் இலகுவானவை மற்றும் அதை பிரிப்பது எளிது.

மற்றும் முதல் வழக்கு எளிதானது. நாங்கள் ஒரு தரவுத்தள கிளஸ்டரை எடுத்து அதே கிளஸ்டரில் எங்கள் DCS சேமிப்பகத்தை பயன்படுத்தும்போது இதுவே நடக்கும். இது மிகவும் பொதுவான தவறு. கட்டிடக்கலைகளை உருவாக்குவதில் இது ஒரு தவறு, அதாவது வெவ்வேறு கூறுகளை ஒரே இடத்தில் இணைப்பது.

அதனால, ஒரு ஃபைலர் இருந்தா, நடந்ததை சமாளிக்கப் போறோம்.

இங்கே நாம் தாக்கல் செய்தவர் எப்போது நடந்தது என்பதில் ஆர்வமாக உள்ளோம். அதாவது, கிளஸ்டர் நிலை மாறிய இந்த தருணத்தில் நாங்கள் ஆர்வமாக உள்ளோம்.

ஆனால் தாக்கல் செய்பவர் எப்பொழுதும் உடனடியாக இருப்பதில்லை, அதாவது எந்த யூனிட் நேரத்தையும் எடுக்காது, அது தாமதமாகலாம். இது நீண்ட காலம் நீடிக்கும்.

எனவே, இது ஒரு தொடக்க நேரம் மற்றும் ஒரு முடிவு நேரம், அதாவது இது ஒரு தொடர்ச்சியான நிகழ்வு. மேலும் அனைத்து நிகழ்வுகளையும் மூன்று இடைவெளிகளாகப் பிரிக்கிறோம்: தாக்கல் செய்பவருக்கு முன், தாக்கல் செய்யும் போது மற்றும் தாக்கல் செய்த பிறகு எங்களுக்கு நேரம் இருக்கிறது. அதாவது, இந்த காலவரிசையில் அனைத்து நிகழ்வுகளையும் நாங்கள் கருதுகிறோம்.

மற்றும் முதல் விஷயம், ஒரு தாக்கல் நடந்தது போது, ​​நாம் என்ன நடந்தது, என்ன காரணம் என்று தேடுகிறோம்.

பதிவுகளைப் பார்த்தால், அவை உன்னதமான பட்ரோனி பதிவுகளாக இருக்கும். சர்வர் மாஸ்டர் ஆகிவிட்டார், எஜமானரின் பங்கு இந்த முனைக்கு சென்றுவிட்டது என்று அவர் அவற்றில் கூறுகிறார். இங்கே அது முன்னிலைப்படுத்தப்படுகிறது.

அடுத்து, ஃபைலர் ஏன் நடந்தது என்பதை நாம் புரிந்து கொள்ள வேண்டும், அதாவது மாஸ்டர் பாத்திரத்தை ஒரு முனையிலிருந்து மற்றொரு முனைக்கு நகர்த்துவதற்கு என்ன நிகழ்வுகள் நிகழ்ந்தன. இந்த விஷயத்தில், எல்லாம் எளிது. சேமிப்பக அமைப்புடன் தொடர்புகொள்வதில் பிழை உள்ளது. டி.சி.எஸ் உடன் பணிபுரிய முடியாது என்பதை மாஸ்டர் உணர்ந்தார், அதாவது, தொடர்புகளில் ஒருவித சிக்கல் உள்ளது. மேலும் தன்னால் இனி மாஸ்டர் ஆக முடியாது என்று கூறிவிட்டு ராஜினாமா செய்கிறார். "தன்னைத் தாழ்த்தியது" என்ற இந்த வரி சரியாகச் சொல்கிறது.

ஃபைலருக்கு முந்திய நிகழ்வுகளைப் பார்த்தால், விஜார்ட் தொடர்வதற்குச் சிக்கலை ஏற்படுத்திய காரணங்களைத்தான் அங்கே பார்க்கலாம்.

Patroni பதிவுகளைப் பார்த்தால், நம்மிடம் நிறைய பிழைகள், காலக்கெடுக்கள் உள்ளன, அதாவது Patroni முகவர் DCS உடன் வேலை செய்ய முடியாது. இந்த வழக்கில், இது தூதரக முகவர், இது போர்ட் 8500 இல் தொடர்பு கொள்கிறது.

இங்குள்ள பிரச்சனை என்னவென்றால், Patroni மற்றும் தரவுத்தளமும் ஒரே ஹோஸ்டில் இயங்குகிறது. அதே முனையில் கான்சல் சர்வர்கள் தொடங்கப்பட்டன. சர்வரில் ஒரு சுமையை உருவாக்குவதன் மூலம், தூதரக சேவையகங்களுக்கும் சிக்கல்களை உருவாக்கினோம். அவர்களால் சரியாக தொடர்பு கொள்ள முடியவில்லை.

சிறிது நேரம் கழித்து, சுமை தணிந்ததும், எங்கள் பட்ரோனி மீண்டும் முகவர்களுடன் தொடர்பு கொள்ள முடிந்தது. வழக்கமான பணி மீண்டும் தொடங்கியது. அதே Pgdb-2 சேவையகம் மீண்டும் முதன்மையானது. அதாவது, ஒரு சிறிய திருப்பம் ஏற்பட்டது, இதன் காரணமாக முனை மாஸ்டரின் அதிகாரங்களை ராஜினாமா செய்தது, பின்னர் அவற்றை மீண்டும் எடுத்துக் கொண்டது, அதாவது, எல்லாம் அப்படியே திரும்பியது.

இது ஒரு தவறான அலாரமாகக் கருதப்படலாம் அல்லது பட்ரோனி எல்லாவற்றையும் சரியாகச் செய்தார் என்று கருதலாம். அதாவது, தன்னால் கொத்து நிலையைத் தக்கவைக்க முடியாது என்பதை உணர்ந்து தனது அதிகாரத்தை நீக்கினார்.

கான்சல் சேவையகங்கள் தளங்களின் அதே வன்பொருளில் இருப்பதால் இங்கே சிக்கல் எழுந்தது. அதன்படி, எந்த சுமையும்: அது வட்டுகள் அல்லது செயலிகளில் சுமையாக இருந்தாலும், அது கன்சல் கிளஸ்டருடனான தொடர்புகளையும் பாதிக்கிறது.

அது ஒன்றாக வாழக்கூடாது என்று நாங்கள் முடிவு செய்தோம், நாங்கள் தூதரகத்திற்கு ஒரு தனி கிளஸ்டரை ஒதுக்கினோம். பட்ரோனி ஏற்கனவே ஒரு தனி தூதருடன் பணிபுரிந்தார், அதாவது ஒரு தனி போஸ்ட்கிரெஸ் கிளஸ்டர், ஒரு தனி கான்சல் கிளஸ்டர் இருந்தது. இது ஒன்றாக வாழாமல் இருக்க, இவற்றையெல்லாம் எப்படி எடுத்துச் செல்வது மற்றும் வைத்திருப்பது என்பதற்கான அடிப்படை அறிவுறுத்தலாகும்.

ஒரு விருப்பமாக, நீங்கள் ttl, loop_wait, retry_timeout ஆகிய அளவுருக்களை திருப்பலாம், அதாவது இந்த அளவுருக்களை அதிகரிப்பதன் மூலம் இந்த குறுகிய கால சுமை உச்சங்களைத் தக்கவைக்க முயற்சிக்கவும். ஆனால் இது மிகவும் பொருத்தமான விருப்பம் அல்ல, ஏனென்றால் இந்த சுமை நீண்ட காலமாக இருக்கலாம். இந்த அளவுருக்களின் இந்த வரம்புகளுக்கு அப்பால் செல்வோம். அது உண்மையில் உதவாது.

முதல் பிரச்சனை, நீங்கள் புரிந்து கொண்டபடி, எளிமையானது. டி.சி.எஸ்-ஐ அடியோடு சேர்த்து எடுத்து வைத்தோம், எங்களுக்கு ஒரு சிக்கல் வந்தது.

இரண்டாவது பிரச்சனை முதல் பிரச்சனையைப் போன்றது. டிசிஎஸ் அமைப்பில் எங்களுக்கு மீண்டும் இயங்கக்கூடிய சிக்கல்கள் இருப்பதைப் போன்றது.

பதிவுகளைப் பார்த்தால், மீண்டும் ஒரு தகவல்தொடர்பு பிழை இருப்பதைக் காணலாம். நான் DCS உடன் தொடர்பு கொள்ள முடியாது, அதனால் தற்போதைய மாஸ்டர் பிரதி பயன்முறையில் செல்கிறார் என்று Patroni கூறுகிறார்.

பழைய மாஸ்டர் ஒரு பிரதியாக மாறுகிறார், இங்கே பட்ரோனி அது இருக்க வேண்டும். இது பரிவர்த்தனை பதிவை ரிவைண்ட் செய்ய pg_rewind ஐ இயக்குகிறது, பின்னர் புதிய மாஸ்டரைப் பிடிக்க புதிய மாஸ்டருடன் இணைக்கவும். இங்கே பட்ரோனி அவர் செய்ய வேண்டியதைப் போலவே செயல்படுகிறார்.

இங்கே நாம் ஃபைலருக்கு முந்தைய இடத்தைக் கண்டுபிடிக்க வேண்டும், அதாவது, நமக்கு ஒரு பைலரை ஏற்படுத்திய பிழைகள். இது சம்பந்தமாக, பேட்ரோனி பதிவுகள் வேலை செய்ய மிகவும் வசதியானவை. ஒரு குறிப்பிட்ட இடைவெளியில் அதே செய்திகளை எழுதுகிறார். இந்த பதிவுகளை விரைவாக ஸ்க்ரோலிங் செய்ய ஆரம்பித்தால், பதிவுகள் மாறிவிட்டன என்பதை நாம் பார்க்கலாம், அதாவது சில சிக்கல்கள் தொடங்கியுள்ளன. நாங்கள் விரைவாக இந்த இடத்திற்குத் திரும்புகிறோம், என்ன நடக்கிறது என்று பாருங்கள்.

ஒரு சாதாரண சூழ்நிலையில், பதிவுகள் இப்படி இருக்கும். பூட்டின் உரிமையாளர் சரிபார்க்கப்பட்டார். உதாரணமாக, உரிமையாளர் மாறியிருந்தால், பட்ரோனி பதிலளிக்க வேண்டிய சில நிகழ்வுகள் ஏற்படலாம். ஆனால் இந்த விஷயத்தில் நாங்கள் நன்றாக இருக்கிறோம். பிழைகள் தொடங்கிய இடத்தை நாங்கள் தேடுகிறோம்.

பிழைகள் தோன்றத் தொடங்கிய இடத்திற்கு ஸ்க்ரோல் செய்த பிறகு, எங்களிடம் ஆட்டோ-ஃபைல்ஓவர் இருப்பதைக் காண்கிறோம். எங்கள் பிழைகள் DCS உடனான தொடர்புடன் தொடர்புடையவை என்பதால், எங்கள் விஷயத்தில் நாங்கள் தூதரகத்தைப் பயன்படுத்தினோம், அங்கு என்ன நடந்தது என்பதை நாங்கள் தூதரக பதிவுகளையும் பார்க்கிறோம்.

தாக்கல் செய்பவரின் நேரத்தையும், தூதரகப் பதிவேடுகளில் உள்ள நேரத்தையும் தோராயமாக ஒப்பிட்டுப் பார்த்தால், தூதரகக் குழுவில் உள்ள நமது அண்டை வீட்டார், தூதரகக் குழுவின் மற்ற உறுப்பினர்களின் இருப்பை சந்தேகிக்கத் தொடங்கியதைக் காண்கிறோம்.

மற்ற கான்சல் ஏஜென்ட்களின் பதிவுகளையும் நீங்கள் பார்த்தால், அங்கு ஒருவித நெட்வொர்க் சரிவு நடைபெறுவதையும் காணலாம். தூதரகக் குழுவின் அனைத்து உறுப்பினர்களும் ஒருவருக்கொருவர் இருப்பதை சந்தேகிக்கிறார்கள். இது தாக்கல் செய்பவருக்கு உந்துதலாக இருந்தது.

இந்த பிழைகளுக்கு முன் என்ன நடந்தது என்பதை நீங்கள் பார்த்தால், எல்லா வகையான பிழைகளும் இருப்பதை நீங்கள் காணலாம், எடுத்துக்காட்டாக, காலக்கெடு, RPC வீழ்ச்சியடைந்தது, அதாவது, கன்சல் கிளஸ்டர் உறுப்பினர்கள் ஒருவருக்கொருவர் தொடர்புகொள்வதில் ஒருவித சிக்கல் தெளிவாக உள்ளது. .

நெட்வொர்க்கை சரிசெய்வதே எளிய பதில். ஆனால் மேடையில் நிற்கும் என்னைப் பொறுத்தவரை இதைச் சொல்வது எளிது. ஆனால் சூழ்நிலைகள் எப்போதும் வாடிக்கையாளர் நெட்வொர்க்கை சரிசெய்ய முடியாது. அவர் ஒரு DC இல் வசிக்கலாம் மற்றும் நெட்வொர்க்கை சரிசெய்ய முடியாமல் போகலாம், உபகரணங்கள் பாதிக்கலாம். எனவே வேறு சில விருப்பங்கள் தேவை.

விருப்பங்கள் உள்ளன:

• என் கருத்துப்படி, ஆவணத்தில் கூட எழுதப்பட்ட எளிய விருப்பம், தூதரக காசோலைகளை முடக்குவது, அதாவது வெற்று வரிசையை அனுப்புவது. எந்த காசோலைகளையும் பயன்படுத்த வேண்டாம் என்று தூதரக முகவருக்கு நாங்கள் கூறுகிறோம். இந்த சோதனைகள் மூலம், இந்த நெட்வொர்க் புயல்களை நாம் புறக்கணிக்கலாம் மற்றும் ஒரு ஃபைலரைத் தொடங்க முடியாது.
• மற்றொரு விருப்பம் raft_multiplier ஐ இருமுறை சரிபார்க்க வேண்டும். இது தூதரக சேவையகத்தின் அளவுருவாகும். முன்னிருப்பாக, இது 5 ஆக அமைக்கப்பட்டுள்ளது. இந்த மதிப்பு நிலை சூழல்களுக்கான ஆவணத்தால் பரிந்துரைக்கப்படுகிறது. உண்மையில், இது தூதரக நெட்வொர்க் உறுப்பினர்களிடையே செய்தி அனுப்பும் அதிர்வெண்ணை பாதிக்கிறது. உண்மையில், இந்த அளவுரு, கன்சல் கிளஸ்டரின் உறுப்பினர்களுக்கு இடையேயான சேவைத் தொடர்பு வேகத்தை பாதிக்கிறது. மேலும் உற்பத்திக்காக, கணுக்கள் அடிக்கடி செய்திகளை பரிமாறிக்கொள்ளும் வகையில் அதை குறைக்க ஏற்கனவே பரிந்துரைக்கப்பட்டுள்ளது.
• நாங்கள் கொண்டு வந்துள்ள மற்றொரு விருப்பம், ஆப்பரேட்டிங் சிஸ்டத்தின் செயல்முறை திட்டமிடலுக்கான பிற செயல்முறைகளில் கன்சல் செயல்முறைகளின் முன்னுரிமையை அதிகரிப்பதாகும். அத்தகைய "நல்ல" அளவுரு உள்ளது, இது திட்டமிடும் போது OS திட்டமிடுபவர் கணக்கில் எடுத்துக்கொள்ளும் செயல்முறைகளின் முன்னுரிமையை தீர்மானிக்கிறது. தூதரக முகவர்களுக்கான நல்ல மதிப்பையும் குறைத்துள்ளோம், அதாவது. முன்னுரிமையை அதிகரித்தது, இதனால் இயக்க முறைமை தூதரக செயல்முறைகளுக்கு வேலை செய்வதற்கும் அவற்றின் குறியீட்டை செயல்படுத்துவதற்கும் அதிக நேரத்தை வழங்குகிறது. எங்கள் விஷயத்தில், இது எங்கள் பிரச்சினையை தீர்த்தது.
• மற்றொரு விருப்பம் தூதரகத்தைப் பயன்படுத்தக்கூடாது. எனக்கு ஒரு நண்பர் இருக்கிறார், அவர் Etcd ஐ ஆதரிக்கிறார். மேலும் நாங்கள் அவருடன் தொடர்ந்து வாதிடுவது எது சிறந்தது Etcd அல்லது Consul. ஆனால் எது சிறந்தது என்பதன் அடிப்படையில், ஒவ்வொரு முனையிலும் ஒரு தரவுத்தளத்துடன் இயங்கும் ஒரு முகவர் தூதரிடம் இருக்கிறார் என்பதை நாங்கள் வழக்கமாக ஒப்புக்கொள்கிறோம். அதாவது, கன்சல் கிளஸ்டருடன் பட்ரோனியின் தொடர்பு இந்த ஏஜென்ட் மூலம் செல்கிறது. இந்த முகவர் ஒரு இடையூறாக மாறுகிறார். ஏஜெண்டுக்கு ஏதாவது நேர்ந்தால், பட்ரோனி இனி கன்சல் கிளஸ்டருடன் வேலை செய்ய முடியாது. மேலும் இதுதான் பிரச்சனை. Etcd திட்டத்தில் முகவர் இல்லை. Patroni Etcd சேவையகங்களின் பட்டியலுடன் நேரடியாக வேலை செய்யலாம் மற்றும் ஏற்கனவே அவர்களுடன் தொடர்பு கொள்ளலாம். இது சம்பந்தமாக, நீங்கள் உங்கள் நிறுவனத்தில் Etcd ஐப் பயன்படுத்தினால், தூதரகத்தை விட Etcd சிறந்த தேர்வாக இருக்கும். ஆனால் எங்கள் வாடிக்கையாளர்களில் நாங்கள் எப்போதும் வாடிக்கையாளர் தேர்ந்தெடுத்து பயன்படுத்துவதைக் கட்டுப்படுத்துகிறோம். மேலும் அனைத்து வாடிக்கையாளர்களுக்கும் எங்களிடம் தூதரகம் உள்ளது.
• மற்றும் கடைசி புள்ளி அளவுரு மதிப்புகளை திருத்த வேண்டும். நமது குறுகிய கால நெட்வொர்க் சிக்கல்கள் குறுகியதாக இருக்கும் மற்றும் இந்த அளவுருக்களின் வரம்பிற்கு வெளியே வராது என்ற நம்பிக்கையில் இந்த அளவுருக்களை உயர்த்தலாம். இந்த வழியில் சில நெட்வொர்க் சிக்கல்கள் ஏற்பட்டால், ஆட்டோஃபைல் செய்வதற்கான பட்ரோனியின் ஆக்கிரமிப்பைக் குறைக்கலாம்.

பட்ரோனியைப் பயன்படுத்தும் பலர் இந்த கட்டளையை நன்கு அறிந்திருக்கிறார்கள் என்று நினைக்கிறேன்.

இந்த கட்டளை கிளஸ்டரின் தற்போதைய நிலையை காட்டுகிறது. முதல் பார்வையில், இந்த படம் சாதாரணமாகத் தோன்றலாம். எங்களிடம் ஒரு மாஸ்டர் இருக்கிறார், எங்களிடம் ஒரு பிரதி உள்ளது, நகலெடுப்பதில் பின்னடைவு இல்லை. ஆனால் இந்த கிளஸ்டருக்கு இரண்டு முனைகள் அல்ல, மூன்று முனைகள் இருக்க வேண்டும் என்பதை நாம் அறியும் வரை இந்த படம் சாதாரணமானது.

அதன்படி, ஒரு ஆட்டோஃபைல் இருந்தது. இந்த ஆட்டோஃபைலுக்குப் பிறகு, எங்கள் பிரதி காணாமல் போனது. அவள் ஏன் காணாமல் போனாள் என்பதைக் கண்டுபிடித்து, அவளை மீட்டெடுக்க வேண்டும். நாங்கள் மீண்டும் பதிவுகளுக்குச் சென்று, எங்களிடம் ஆட்டோ-ஃபைல்ஓவர் ஏன் இருந்தது என்பதைப் பார்க்கிறோம்.

இந்த வழக்கில், இரண்டாவது பிரதி மாஸ்டர் ஆனது. இங்கே எல்லாம் சரிதான்.

மேலும் கீழே விழுந்த மற்றும் கொத்துக்குள் இல்லாத பிரதியை நாம் பார்க்க வேண்டும். நாங்கள் Patroni பதிவுகளைத் திறந்து, pg_rewind கட்டத்தில் க்ளஸ்டருடன் இணைக்கும் செயல்பாட்டின் போது சிக்கல் ஏற்பட்டதைக் காண்கிறோம். கிளஸ்டருடன் இணைக்க, நீங்கள் பரிவர்த்தனை பதிவை ரிவைண்ட் செய்ய வேண்டும், தேவையான பரிவர்த்தனை பதிவை மாஸ்டரிடம் இருந்து கோர வேண்டும், மேலும் மாஸ்டரைப் பிடிக்க அதைப் பயன்படுத்த வேண்டும்.

இந்த வழக்கில், எங்களிடம் பரிவர்த்தனை பதிவு இல்லை மற்றும் பிரதியை தொடங்க முடியாது. அதன்படி, பிழையுடன் Postgres ஐ நிறுத்துகிறோம். எனவே இது கிளஸ்டரில் இல்லை.

அது ஏன் கிளஸ்டரில் இல்லை, ஏன் பதிவுகள் இல்லை என்பதை நாம் புரிந்து கொள்ள வேண்டும். நாங்கள் புதிய மாஸ்டரிடம் சென்று அவர் பதிவுகளில் என்ன வைத்திருக்கிறார் என்பதைப் பார்க்கிறோம். pg_rewind செய்த போது, ​​ஒரு சோதனைச் சாவடி ஏற்பட்டது. மேலும் சில பழைய பரிவர்த்தனை பதிவுகள் வெறுமனே மறுபெயரிடப்பட்டன. பழைய மாஸ்டர் புதிய மாஸ்டருடன் இணைத்து இந்த பதிவுகளை வினவ முயன்றபோது, ​​அவை ஏற்கனவே மறுபெயரிடப்பட்டன, அவை இல்லை.

இந்த நிகழ்வுகள் நடந்த நேர முத்திரைகளை ஒப்பிட்டுப் பார்த்தேன். அங்கு வித்தியாசம் உண்மையில் 150 மில்லி விநாடிகள், அதாவது 369 மில்லி விநாடிகளில் முடிக்கப்பட்ட சோதனைச் சாவடி, WAL பிரிவுகள் மறுபெயரிடப்பட்டன. உண்மையில் 517 இல், 150 மில்லி விநாடிகளுக்குப் பிறகு, பழைய பிரதியில் ரிவைண்ட் தொடங்கியது. அதாவது, உண்மையில் 150 மில்லி விநாடிகள் எங்களுக்கு போதுமானதாக இருந்தது, இதனால் பிரதியை இணைத்து சம்பாதிக்க முடியவில்லை.

விருப்பங்கள் என்ன?

நாங்கள் ஆரம்பத்தில் பிரதி இடங்களைப் பயன்படுத்தினோம். நல்லது என்று நினைத்தோம். செயல்பாட்டின் முதல் கட்டத்தில் நாங்கள் ஸ்லாட்டுகளை அணைத்தோம். ஸ்லாட்டுகள் நிறைய WAL பிரிவுகளைக் குவித்தால், நாங்கள் மாஸ்டரை கைவிடலாம் என்று எங்களுக்குத் தோன்றியது. அவன் விழுவான். சில காலம் இடங்கள் இல்லாமல் தவித்தோம். எங்களுக்கு ஸ்லாட்டுகள் தேவை என்பதை நாங்கள் உணர்ந்தோம், நாங்கள் ஸ்லாட்டுகளை திருப்பி அனுப்பினோம்.

ஆனால் இங்கே ஒரு சிக்கல் உள்ளது, மாஸ்டர் பிரதிக்குச் செல்லும்போது, ​​​​அது ஸ்லாட்களை நீக்குகிறது மற்றும் ஸ்லாட்டுகளுடன் சேர்த்து WAL பிரிவுகளையும் நீக்குகிறது. இந்தச் சிக்கலை அகற்ற, wal_keep_segments அளவுருவை உயர்த்த முடிவு செய்தோம். இது 8 பிரிவுகளுக்கு இயல்புநிலையாக இருக்கும். நாங்கள் அதை 1 ஆக உயர்த்தி, எங்களிடம் எவ்வளவு இலவச இடம் உள்ளது என்பதைப் பார்த்தோம். மேலும் வால்_கீப்_பிரிவுகளுக்காக 000 ஜிகாபைட்களை நன்கொடையாக வழங்கினோம். அதாவது, மாறும்போது, ​​எல்லா முனைகளிலும் எப்போதும் 16 ஜிகாபைட் பரிவர்த்தனை பதிவுகள் இருப்பு வைத்திருக்கிறோம்.

மற்றும் பிளஸ் - இது நீண்ட கால பராமரிப்பு பணிகளுக்கு இன்னும் பொருத்தமானது. பிரதிகளில் ஒன்றைப் புதுப்பிக்க வேண்டும் என்று வைத்துக்கொள்வோம். நாங்கள் அதை அணைக்க விரும்புகிறோம். நாம் மென்பொருள் புதுப்பிக்க வேண்டும், ஒருவேளை இயக்க முறைமை, வேறு ஏதாவது. நாம் ஒரு பிரதியை அணைக்கும்போது, ​​அந்த பிரதிக்கான ஸ்லாட்டும் அகற்றப்படும். நாம் ஒரு சிறிய wal_keep_segments ஐப் பயன்படுத்தினால், ஒரு பிரதி நீண்ட காலமாக இல்லாததால், பரிவர்த்தனை பதிவுகள் இழக்கப்படும். நாங்கள் ஒரு பிரதியை எழுப்புவோம், அது நிறுத்தப்பட்ட இடத்தில் அந்த பரிவர்த்தனை பதிவுகளைக் கோரும், ஆனால் அவை முதன்மையில் இல்லாமல் இருக்கலாம். மேலும் பிரதியை இணைக்க முடியாது. எனவே, நாங்கள் பத்திரிகைகளின் பெரிய இருப்பு வைத்துள்ளோம்.

எங்களிடம் உற்பத்தித் தளம் உள்ளது. ஏற்கனவே திட்டங்கள் செயல்பாட்டில் உள்ளன.

ஒரு தாக்கல் செய்பவர் இருந்தார். நாங்கள் உள்ளே சென்று பார்த்தோம் - எல்லாம் ஒழுங்காக உள்ளது, பிரதிகள் இடத்தில் உள்ளன, பிரதி தாமதம் இல்லை. பதிவுகளில் பிழைகள் எதுவும் இல்லை, எல்லாம் ஒழுங்காக உள்ளது.

சில தரவு இருக்க வேண்டும் என்று தயாரிப்பு குழு கூறுகிறது, ஆனால் நாங்கள் அதை ஒரு மூலத்திலிருந்து பார்க்கிறோம், ஆனால் அதை தரவுத்தளத்தில் பார்க்கவில்லை. மேலும் அவர்களுக்கு என்ன நடந்தது என்பதை நாம் புரிந்து கொள்ள வேண்டும்.

pg_rewind அவற்றை தவறவிட்டது என்பது தெளிவாகிறது. நாங்கள் இதை உடனடியாக புரிந்து கொண்டோம், ஆனால் என்ன நடக்கிறது என்று பார்க்க சென்றோம்.

பதிவுகளில், தாக்கல் செய்தவர் எப்போது நடந்தது, யார் மாஸ்டர் ஆனார், யார் பழைய மாஸ்டர் மற்றும் அவர் எப்போது பிரதியாக மாற விரும்பினார் என்பதை நாம் எப்போதும் கண்டறியலாம், அதாவது பரிவர்த்தனை பதிவுகளின் அளவைக் கண்டறிய இந்த பதிவுகள் தேவை. தொலைந்து போயிற்று.

எங்கள் பழைய மாஸ்டர் மறுதொடக்கம் செய்துள்ளார். மற்றும் Patroni autorun பதிவு செய்யப்பட்டது. பட்ரோனியை துவக்கினார். பின்னர் அவர் போஸ்ட்கிரெஸைத் தொடங்கினார். இன்னும் துல்லியமாக, போஸ்ட்கிரெஸைத் தொடங்குவதற்கு முன்பும், அதை ஒரு பிரதியாக மாற்றுவதற்கு முன்பும், பேட்ரோனி pg_rewind செயல்முறையைத் தொடங்கினார். அதன்படி, பரிவர்த்தனை பதிவுகளில் ஒரு பகுதியை அழித்து, புதியவற்றை பதிவிறக்கம் செய்து இணைத்தார். இங்கே பட்ரோனி புத்திசாலித்தனமாக வேலை செய்தார், அதாவது எதிர்பார்த்தபடி. கிளஸ்டர் மீட்டெடுக்கப்பட்டது. எங்களிடம் 3 முனைகள் இருந்தன, ஃபைலர் 3 முனைகளுக்குப் பிறகு - எல்லாம் நன்றாக இருக்கிறது.

சில தரவுகளை இழந்துவிட்டோம். மேலும் நாம் எவ்வளவு இழந்துள்ளோம் என்பதை புரிந்து கொள்ள வேண்டும். நாங்கள் ஒரு முன்னாடி இருந்த தருணத்தை நாங்கள் தேடுகிறோம். போன்ற இதழ்களில் நாம் அதைக் காணலாம். ரீவைண்ட் ஆரம்பித்து அங்கேயே ஏதோ செய்து முடித்தார்.

பரிவர்த்தனை பதிவில் பழைய மாஸ்டர் விட்டுச் சென்ற இடத்தை நாம் கண்டுபிடிக்க வேண்டும். இந்த வழக்கில், இது குறி. நமக்கு இரண்டாவது குறி தேவை, அதாவது பழைய மாஸ்டர் புதியதிலிருந்து வேறுபடும் தூரம்.

நாங்கள் வழக்கமான pg_wal_lsn_diff ஐ எடுத்து இந்த இரண்டு மதிப்பெண்களையும் ஒப்பிடுகிறோம். இந்த வழக்கில், நாம் 17 மெகாபைட் கிடைக்கும். நிறைய அல்லது கொஞ்சம், எல்லோரும் தனக்குத்தானே தீர்மானிக்கிறார்கள். ஏனென்றால் ஒருவருக்கு 17 மெகாபைட் அதிகம் இல்லை, ஒருவருக்கு இது நிறைய மற்றும் ஏற்றுக்கொள்ள முடியாதது. இங்கே, ஒவ்வொரு நபரும் வணிகத்தின் தேவைகளுக்கு ஏற்ப தன்னைத் தீர்மானிக்கிறார்.

ஆனால் நமக்காக நாம் என்ன கண்டுபிடித்தோம்?

முதலில், நாமே முடிவு செய்ய வேண்டும் - கணினியை மறுதொடக்கம் செய்த பிறகு தானாக தொடங்குவதற்கு நமக்கு எப்போதும் Patroni தேவையா? நாம் பழைய மாஸ்டரிடம் செல்ல வேண்டும் என்று அடிக்கடி நடக்கும், அவர் எவ்வளவு தூரம் சென்றார் என்று பாருங்கள். பரிவர்த்தனை பதிவின் பிரிவுகளை ஆய்வு செய்து, அங்கு என்ன இருக்கிறது என்று பார்க்கவும். இந்தத் தரவை நாம் இழக்க முடியுமா அல்லது இந்தத் தரவை வெளியே எடுப்பதற்கு பழைய மாஸ்டரை தனித்தனி முறையில் இயக்க வேண்டுமா என்பதைப் புரிந்து கொள்ள.

அதன்பிறகுதான் இந்தத் தரவை நிராகரிக்கலாமா அல்லது அதை மீட்டெடுக்கலாமா என்பதை நாங்கள் தீர்மானிக்க வேண்டும், இந்த முனையை எங்கள் கிளஸ்டருடன் ஒரு பிரதியாக இணைக்கவும்.

கூடுதலாக, "maximum_lag_on_failover" அளவுரு உள்ளது. இயல்பாக, எனது நினைவகம் எனக்கு சேவை செய்தால், இந்த அளவுருவின் மதிப்பு 1 மெகாபைட் ஆகும்.

அவர் எப்படி வேலை செய்கிறார்? நகலெடுக்கும் பின்னடைவில் எங்கள் பிரதி 1 மெகாபைட் தரவு பின்தங்கியிருந்தால், இந்த பிரதி தேர்தலில் பங்கேற்காது. திடீரென்று ஒரு ஃபைல்ஓவர் இருந்தால், எந்தப் பிரதிகள் பின்தங்கியுள்ளன என்பதை பேட்ரோனி பார்க்கிறார். அதிக எண்ணிக்கையிலான பரிவர்த்தனை பதிவுகளால் அவர்கள் பின்தங்கியிருந்தால், அவர்களால் மாஸ்டர் ஆக முடியாது. இது ஒரு சிறந்த பாதுகாப்பு அம்சமாகும், இது நிறைய தரவை இழப்பதைத் தடுக்கிறது.

ஆனால் பேட்ரோனி கிளஸ்டர் மற்றும் டிசிஎஸ் ஆகியவற்றில் ரெப்ளிகேஷன் லேக் குறிப்பிட்ட இடைவெளியில் புதுப்பிக்கப்படுவதில் சிக்கல் உள்ளது. 30 வினாடிகள் இயல்புநிலை ttl மதிப்பு என்று நினைக்கிறேன்.

அதன்படி, DCS இல் பிரதிகளுக்கு ஒரு பிரதி பின்னடைவு இருக்கும் சூழ்நிலை இருக்கலாம், ஆனால் உண்மையில் முற்றிலும் மாறுபட்ட பின்னடைவு இருக்கலாம் அல்லது எந்த பின்னடைவும் இல்லாமல் இருக்கலாம், அதாவது இது நிகழ்நேரம் அல்ல. அது எப்போதும் உண்மையான படத்தை பிரதிபலிக்காது. மேலும் அதில் ஆடம்பரமான தர்க்கம் செய்வது மதிப்புக்குரியது அல்ல.

மற்றும் இழப்பு ஆபத்து எப்போதும் உள்ளது. மற்றும் மோசமான நிலையில், ஒரு சூத்திரம், மற்றும் சராசரி வழக்கில், மற்றொரு சூத்திரம். அதாவது, நாம் Patroni செயல்படுத்த திட்டமிடும் போது மற்றும் நாம் எவ்வளவு தரவு இழக்க முடியும் மதிப்பீடு போது, ​​நாம் இந்த சூத்திரங்கள் நம்பியிருக்க வேண்டும் மற்றும் தோராயமாக நாம் எவ்வளவு தரவு இழக்க முடியும் கற்பனை.

மற்றும் ஒரு நல்ல செய்தி உள்ளது. பழைய மாஸ்டர் முன்னோக்கிச் சென்றதும், சில பின்னணி செயல்முறைகள் காரணமாக அவர் முன்னேற முடியும். அதாவது, ஒருவித ஆட்டோவாக்யூம் இருந்தது, அவர் தரவை எழுதினார், அவற்றை பரிவர்த்தனை பதிவில் சேமித்தார். மேலும் இந்தத் தரவை நாம் எளிதாகப் புறக்கணித்து இழக்கலாம். இதில் எந்த பிரச்சனையும் இல்லை.

Maximum_lag_on_failover அமைக்கப்பட்டு, ஒரு ஃபைலர் ஏற்பட்டால், பதிவுகள் இப்படித்தான் இருக்கும், மேலும் நீங்கள் ஒரு புதிய மாஸ்டரைத் தேர்ந்தெடுக்க வேண்டும். தேர்தல்களில் பங்கேற்க இயலாது என்று பிரதி தன்னை மதிப்பிடுகிறது. மேலும் அவள் தலைவருக்கான போட்டியில் பங்கேற்க மறுக்கிறாள். ஒரு புதிய மாஸ்டர் தேர்ந்தெடுக்கப்படுவதற்கு அவள் காத்திருக்கிறாள், அதனால் அவள் அதனுடன் இணைக்க முடியும். இது தரவு இழப்பிற்கு எதிரான கூடுதல் நடவடிக்கையாகும்.

இங்கே எங்களிடம் ஒரு தயாரிப்புக் குழு உள்ளது, அவர்கள் தங்கள் தயாரிப்புக்கு Postgres இல் சிக்கல் இருப்பதாக எழுதியுள்ளனர். அதே நேரத்தில், மாஸ்டரை அணுக முடியாது, ஏனெனில் இது SSH வழியாக கிடைக்கவில்லை. மேலும் ஆட்டோஃபைலும் நடக்காது.

இந்த ஹோஸ்ட் மறுதொடக்கம் செய்ய வேண்டிய கட்டாயம் ஏற்பட்டது. மறுதொடக்கம் காரணமாக, ஒரு தானியங்கு கோப்பு ஏற்பட்டது, இருப்பினும் ஒரு கைமுறையாக தானியங்கு கோப்பு செய்ய முடியும், நான் இப்போது புரிந்து கொண்டேன். மறுதொடக்கம் செய்த பிறகு, தற்போதைய மாஸ்டரிடம் என்ன இருந்தது என்பதை நாங்கள் ஏற்கனவே பார்க்கப் போகிறோம்.

அதே நேரத்தில், வட்டுகளில் எங்களுக்கு சிக்கல்கள் இருப்பதை நாங்கள் முன்கூட்டியே அறிந்தோம், அதாவது, எங்கு தோண்டுவது மற்றும் எதைத் தேடுவது என்பதைக் கண்காணிப்பதில் இருந்து எங்களுக்கு முன்பே தெரியும்.

நாங்கள் போஸ்ட்கிரெஸ் பதிவில் நுழைந்து, அங்கு என்ன நடக்கிறது என்று பார்க்க ஆரம்பித்தோம். ஒன்று, இரண்டு, மூன்று வினாடிகள் அங்கு நீடித்திருக்கும் கமிட்களைப் பார்த்தோம், இது சாதாரணமாக இல்லை. எங்கள் ஆட்டோவாகும் மிகவும் மெதுவாகவும் விசித்திரமாகவும் தொடங்குவதைக் கண்டோம். வட்டில் தற்காலிக கோப்புகளைப் பார்த்தோம். அதாவது, இவை அனைத்தும் வட்டுகளில் உள்ள சிக்கல்களின் குறிகாட்டிகள்.

கணினி dmesg (கர்னல் பதிவு) ஐப் பார்த்தோம். வட்டுகளில் ஒன்றில் எங்களுக்கு சிக்கல் இருப்பதைக் கண்டோம். வட்டு துணை அமைப்பு மென்பொருள் ரெய்டு. நாங்கள் /proc/mdstat ஐப் பார்த்தோம், நாங்கள் ஒரு டிரைவைக் காணவில்லை என்பதைக் கண்டோம். அதாவது, 8 வட்டுகளின் ரெய்டு உள்ளது, நாங்கள் ஒன்றைக் காணவில்லை. நீங்கள் ஸ்லைடை கவனமாகப் பார்த்தால், வெளியீட்டில் எங்களிடம் sde இல்லை என்பதைக் காணலாம். எங்களிடம், நிபந்தனையுடன் பேசினால், வட்டு கைவிடப்பட்டது. இது வட்டு சிக்கல்களைத் தூண்டியது, மேலும் Postgres கிளஸ்டருடன் பணிபுரியும் போது பயன்பாடுகளும் சிக்கல்களை சந்தித்தன.

இந்த விஷயத்தில், பட்ரோனி எங்களுக்கு எந்த வகையிலும் உதவ மாட்டார், ஏனென்றால் சர்வரின் நிலை, வட்டின் நிலையை கண்காணிக்கும் பணி பட்ரோனிக்கு இல்லை. வெளிப்புற கண்காணிப்பு மூலம் இதுபோன்ற சூழ்நிலைகளை நாம் கண்காணிக்க வேண்டும். வெளிப்புற கண்காணிப்பில் வட்டு கண்காணிப்பை விரைவாகச் சேர்த்தோம்.

அத்தகைய எண்ணம் இருந்தது - ஃபென்சிங் அல்லது வாட்ச்டாக் மென்பொருள் நமக்கு உதவுமா? இந்த விஷயத்தில் அவர் எங்களுக்கு உதவி செய்திருக்க மாட்டார் என்று நாங்கள் நினைத்தோம், ஏனென்றால் பிரச்சனைகளின் போது பேட்ரோனி DCS கிளஸ்டருடன் தொடர்ந்து தொடர்பு கொண்டார் மற்றும் எந்த பிரச்சனையும் பார்க்கவில்லை. அதாவது, டிசிஎஸ் மற்றும் பேட்ரோனியின் பார்வையில், கிளஸ்டருடன் எல்லாம் நன்றாக இருந்தது, உண்மையில் வட்டில் சிக்கல்கள் இருந்தாலும், தரவுத்தளத்தின் கிடைக்கும் தன்மையில் சிக்கல்கள் இருந்தன.

என் கருத்துப்படி, நான் நீண்ட காலமாக ஆராய்ச்சி செய்த விசித்திரமான சிக்கல்களில் இதுவும் ஒன்றாகும், நான் நிறைய பதிவுகளைப் படித்தேன், அதை மீண்டும் தேர்ந்தெடுத்து கிளஸ்டர் சிமுலேட்டர் என்று அழைத்தேன்.

பிரச்சனை என்னவென்றால், பழைய மாஸ்டர் ஒரு சாதாரண பிரதியாக மாற முடியாது, அதாவது பட்ரோனி அதைத் தொடங்கினார், பட்ரோனி இந்த முனை ஒரு பிரதியாக இருப்பதைக் காட்டினார், ஆனால் அதே நேரத்தில் இது ஒரு சாதாரண பிரதி இல்லை. இப்போது நீங்கள் ஏன் பார்ப்பீர்கள். அந்தப் பிரச்சனையின் அலசலில் இருந்து நான் வைத்தது இதுதான்.

அது எப்படி தொடங்கியது? இது முந்தைய சிக்கலைப் போலவே, டிஸ்க் பிரேக்குகளுடன் தொடங்கியது. எங்களிடம் ஒரு வினாடி, இரண்டு கமிட்கள் இருந்தன.

இணைப்புகளில் முறிவுகள் இருந்தன, அதாவது, வாடிக்கையாளர்கள் கிழிந்தனர்.

பல்வேறு தீவிரத்தன்மையின் அடைப்புகள் இருந்தன.

மேலும், அதன்படி, வட்டு துணை அமைப்பு மிகவும் பதிலளிக்கவில்லை.

மேலும் எனக்கு மிகவும் மர்மமான விஷயம், வந்த உடனடி பணிநிறுத்தம் கோரிக்கை. Postgres மூன்று பணிநிறுத்தம் முறைகளைக் கொண்டுள்ளது:

• அனைத்து வாடிக்கையாளர்களும் தாங்களாகவே துண்டிக்கப்படும் வரை நாங்கள் காத்திருக்கும்போது இது மிகவும் அருமையாக இருக்கும்.
• நாங்கள் பணிநிறுத்தம் செய்யப் போகிறோம் என்பதால், வாடிக்கையாளர்களைத் துண்டிக்கும்படி வற்புறுத்தும்போது வேகமாக இருக்கும்.
• மற்றும் உடனடியாக. இந்த வழக்கில், உடனடியானது வாடிக்கையாளர்களை மூடச் சொல்லவில்லை, அது எச்சரிக்கையின்றி மூடப்படும். மேலும் அனைத்து வாடிக்கையாளர்களுக்கும், இயக்க முறைமை ஏற்கனவே ஒரு RST செய்தியை அனுப்புகிறது (இணைப்பு தடைபட்டுள்ளது மற்றும் கிளையன்ட் பிடிக்க எதுவும் இல்லை என்ற TCP செய்தி).

இந்த சமிக்ஞையை அனுப்பியது யார்? Postgres பின்னணி செயல்முறைகள் அத்தகைய சிக்னல்களை ஒன்றுக்கொன்று அனுப்பாது, அதாவது இது கில்-9. அவர்கள் ஒருவருக்கொருவர் இதுபோன்ற விஷயங்களை அனுப்புவதில்லை, அவர்கள் இதுபோன்ற விஷயங்களுக்கு மட்டுமே எதிர்வினையாற்றுகிறார்கள், அதாவது இது போஸ்ட்கிரெஸின் அவசர மறுதொடக்கம். அனுப்பியது யார், தெரியவில்லை.

நான் "கடைசி" கட்டளையைப் பார்த்தேன், எங்களுடன் இந்த சர்வரில் உள்நுழைந்த ஒரு நபரைப் பார்த்தேன், ஆனால் நான் ஒரு கேள்வி கேட்க வெட்கப்பட்டேன். ஒருவேளை அது கொலை -9. பதிவுகளில் கொலை -9 ஐ நான் பார்ப்பேன், ஏனென்றால் போஸ்ட்கிரெஸ் கூறுகையில், இது கொலை -9 எடுத்தது, ஆனால் நான் அதை பதிவுகளில் பார்க்கவில்லை.

மேலும் பார்க்கும்போது, ​​​​பட்ரோனி நீண்ட காலமாக பதிவில் எழுதவில்லை என்பதை நான் கண்டேன் - 54 வினாடிகள். இரண்டு நேர முத்திரைகளை ஒப்பிட்டுப் பார்த்தால், சுமார் 54 வினாடிகளுக்கு செய்திகள் எதுவும் இல்லை.

இந்த நேரத்தில் ஒரு ஆட்டோஃபைல் இருந்தது. பட்ரோனி மீண்டும் இங்கே ஒரு பெரிய வேலை செய்தார். எங்கள் பழைய மாஸ்டர் கிடைக்கவில்லை, அவருக்கு ஏதோ நடந்தது. மேலும் புதிய மாஸ்டர் தேர்வு தொடங்கியது. இங்கே எல்லாம் நன்றாக வேலை செய்தது. எங்கள் pgsql01 புதிய தலைவராக மாறியுள்ளது.

எங்களிடம் ஒரு மாஸ்டர் ஆன ஒரு பிரதி உள்ளது. மற்றும் இரண்டாவது பதில் உள்ளது. இரண்டாவது பிரதியில் சிக்கல்கள் இருந்தன. அவள் மீண்டும் கட்டமைக்க முயன்றாள். நான் புரிந்துகொண்டபடி, அவள் recovery.conf ஐ மாற்றவும், Postgres ஐ மறுதொடக்கம் செய்து புதிய மாஸ்டருடன் இணைக்கவும் முயன்றாள். அவள் முயற்சிக்கும் ஒவ்வொரு 10 வினாடிக்கும் செய்திகளை எழுதுகிறாள், ஆனால் அவள் வெற்றியடையவில்லை.

இந்த முயற்சிகளின் போது, ​​உடனடியாக பணிநிறுத்தம் சமிக்ஞை பழைய மாஸ்டருக்கு வந்து சேரும். மாஸ்டர் மீண்டும் தொடங்கப்பட்டது. பழைய மாஸ்டர் மறுதொடக்கம் செய்வதால் மீட்பு நிறுத்தப்படும். அதாவது, பிரதியை அதனுடன் இணைக்க முடியாது, ஏனெனில் அது பணிநிறுத்தம் முறையில் உள்ளது.

ஒரு கட்டத்தில், அது வேலை செய்தது, ஆனால் நகலெடுக்கத் தொடங்கவில்லை.

Recovery.conf இல் பழைய முதன்மை முகவரி இருந்தது என்பது எனது ஒரே யூகம். ஒரு புதிய மாஸ்டர் தோன்றியபோது, ​​​​இரண்டாவது பிரதி இன்னும் பழைய மாஸ்டருடன் இணைக்க முயன்றது.

இரண்டாவது பிரதியை பட்ரோனி தொடங்கும் போது, ​​கணு துவங்கியது ஆனால் நகலெடுக்க முடியவில்லை. மேலும் ஒரு பிரதி பின்னடைவு உருவாக்கப்பட்டது, இது போன்றது. அதாவது, மூன்று முனைகளும் இடத்தில் இருந்தன, ஆனால் இரண்டாவது முனை பின்தங்கியிருந்தது.

அதே நேரத்தில், நீங்கள் எழுதப்பட்ட பதிவுகளைப் பார்த்தால், பரிவர்த்தனை பதிவுகள் வித்தியாசமாக இருந்ததால், பிரதியை தொடங்க முடியவில்லை. மீட்பு.conf இல் குறிப்பிடப்பட்டுள்ள முதன்மை வழங்கும் பரிவர்த்தனை பதிவுகள், நமது தற்போதைய முனைக்கு பொருந்தாது.

இங்கே நான் ஒரு தவறு செய்தேன். நாங்கள் தவறான மாஸ்டருடன் இணைக்கிறோம் என்ற எனது கருதுகோளைச் சோதிக்க நான் வந்து, recovery.conf இல் என்ன இருக்கிறது என்பதைப் பார்க்க வேண்டியிருந்தது. ஆனால் பின்னர் நான் இதை கையாண்டேன், அது எனக்கு ஏற்படவில்லை, அல்லது பிரதி பின்தங்கியிருப்பதைக் கண்டேன், மீண்டும் நிரப்பப்பட வேண்டும், அதாவது, நான் எப்படியோ கவனக்குறைவாக வேலை செய்தேன். இது எனது கூட்டு.

30 நிமிடங்களுக்குப் பிறகு, நிர்வாகி ஏற்கனவே வந்தார், அதாவது நான் பிரதியில் பட்ரோனியை மறுதொடக்கம் செய்தேன். நான் ஏற்கனவே அதற்கு முற்றுப்புள்ளி வைத்தேன், அதை மீண்டும் நிரப்ப வேண்டும் என்று நினைத்தேன். நான் நினைத்தேன் - நான் பட்ரோனியை மறுதொடக்கம் செய்வேன், ஒருவேளை ஏதாவது நல்லது நடக்கும். மீட்பு தொடங்கியது. அடித்தளம் கூட திறக்கப்பட்டது, அது இணைப்புகளை ஏற்க தயாராக இருந்தது.

நகலெடுக்கத் தொடங்கியது. ஆனால் ஒரு நிமிடம் கழித்து, பரிவர்த்தனை பதிவுகள் தனக்குப் பொருந்தாது என்ற பிழையால் அவள் விழுந்தாள்.

நான் மீண்டும் தொடங்க நினைத்தேன். நான் மீண்டும் பட்ரோனியை மறுதொடக்கம் செய்தேன், நான் போஸ்ட்கிரெஸை மறுதொடக்கம் செய்யவில்லை, ஆனால் தரவுத்தளத்தை மாயமாகத் தொடங்கும் என்ற நம்பிக்கையில் பட்ரோனியை மறுதொடக்கம் செய்தேன்.

நகலெடுப்பு மீண்டும் தொடங்கியது, ஆனால் பரிவர்த்தனை பதிவில் உள்ள மதிப்பெண்கள் வேறுபட்டவை, அவை முந்தைய தொடக்க முயற்சியைப் போல இல்லை. நகலெடுப்பது மீண்டும் நிறுத்தப்பட்டது. மற்றும் செய்தி ஏற்கனவே சற்று வித்தியாசமாக இருந்தது. மேலும் இது எனக்கு மிகவும் தகவல் தரவில்லை.

பின்னர் அது எனக்கு நிகழ்கிறது - நான் போஸ்ட்கிரெஸை மறுதொடக்கம் செய்தால் என்ன செய்வது, இந்த நேரத்தில் பரிவர்த்தனை பதிவில் உள்ள புள்ளியை சிறிது முன்னோக்கி நகர்த்த தற்போதைய மாஸ்டரில் ஒரு சோதனைச் சாவடியை உருவாக்குகிறேன், இதனால் மீட்பு மற்றொரு தருணத்திலிருந்து தொடங்கும்? மேலும், எங்களிடம் இன்னும் WAL பங்குகள் இருந்தன.

நான் பட்ரோனியை மறுதொடக்கம் செய்தேன், மாஸ்டரில் இரண்டு சோதனைச் சாவடிகள் செய்தேன், அது திறக்கும் போது பிரதி மீது இரண்டு மறுதொடக்கம் புள்ளிகள். அது உதவியது. அது ஏன் உதவியது, எப்படி வேலை செய்தது என்று நீண்ட நேரம் யோசித்தேன். மற்றும் பிரதி தொடங்கியது. மேலும் பிரதி இனி கிழிக்கப்படவில்லை.

எனக்கு இதுபோன்ற ஒரு பிரச்சனை மிகவும் மர்மமான ஒன்றாகும், அதில் உண்மையில் என்ன நடந்தது என்பதில் நான் இன்னும் புதிராக இருக்கிறேன்.

இங்கே என்ன தாக்கங்கள் உள்ளன? Patroni நோக்கம் மற்றும் எந்த பிழைகள் இல்லாமல் வேலை செய்ய முடியும். ஆனால் அதே நேரத்தில், எல்லாம் எங்களுடன் நன்றாக இருக்கிறது என்பதற்கு இது 100% உத்தரவாதம் அல்ல. பிரதி தொடங்கலாம், ஆனால் அது அரை வேலை செய்யும் நிலையில் இருக்கலாம், மேலும் பழைய தரவு இருக்கும் என்பதால், அத்தகைய பிரதியுடன் பயன்பாடு வேலை செய்ய முடியாது.

ஃபைலருக்குப் பிறகு, கிளஸ்டருடன் எல்லாம் ஒழுங்காக இருக்கிறதா என்பதை நீங்கள் எப்போதும் சரிபார்க்க வேண்டும், அதாவது, தேவையான எண்ணிக்கையிலான பிரதிகள் உள்ளன, நகல் பின்னடைவு இல்லை.

இந்த சிக்கல்களை நாங்கள் கடந்து செல்லும்போது, ​​​​நான் பரிந்துரைகளை வழங்குவேன். நான் அவற்றை இரண்டு ஸ்லைடுகளாக இணைக்க முயற்சித்தேன். அநேகமாக, எல்லாக் கதைகளையும் இரண்டு ஸ்லைடுகளாக இணைத்து மட்டுமே சொல்ல முடியும்.

நீங்கள் Patroni பயன்படுத்தும் போது, ​​நீங்கள் கண்காணிப்பு வேண்டும். ஆட்டோஃபைல்ஓவர் எப்போது நிகழ்ந்தது என்பதை நீங்கள் எப்போதும் அறிந்திருக்க வேண்டும், ஏனென்றால் உங்களிடம் ஆட்டோஃபைல்ஓவர் இருப்பது உங்களுக்குத் தெரியாவிட்டால், கிளஸ்டரின் மீது உங்களுக்கு எந்தக் கட்டுப்பாடும் இல்லை. அதுவும் மோசமானது.

ஒவ்வொரு ஃபைலருக்கும் பிறகு, நாம் எப்போதும் கிளஸ்டரை கைமுறையாக சரிபார்க்க வேண்டும். நம்மிடம் எப்பொழுதும் புதுப்பித்த எண்ணிக்கையிலான பிரதிகள் இருப்பதை உறுதி செய்ய வேண்டும், எந்த நகலெடுப்பு தாமதமும் இல்லை, ஸ்ட்ரீமிங் ரெப்ளிகேஷன் தொடர்பான பதிவுகளில் பிழைகள் இல்லை, Patroni உடன், DCS அமைப்புடன்.

ஆட்டோமேஷன் வெற்றிகரமாக வேலை செய்ய முடியும், Patroni ஒரு நல்ல கருவி. இது வேலை செய்ய முடியும், ஆனால் இது கிளஸ்டரை விரும்பிய நிலைக்கு கொண்டு வராது. அதையும் கண்டு கொள்ளாவிட்டால் சிக்கலுக்கு ஆளாக நேரிடும்.

மற்றும் பட்ரோனி ஒரு வெள்ளி தோட்டா அல்ல. Postgres எவ்வாறு செயல்படுகிறது, எவ்வாறு பிரதியெடுப்பு வேலை செய்கிறது மற்றும் Patroni எவ்வாறு Postgres உடன் வேலை செய்கிறது மற்றும் கணுகளுக்கிடையிலான தொடர்பு எவ்வாறு வழங்கப்படுகிறது என்பதை நாம் இன்னும் புரிந்து கொள்ள வேண்டும். உங்கள் கைகளால் சிக்கல்களை சரிசெய்ய இது அவசியம்.

நோயறிதலின் சிக்கலை நான் எவ்வாறு அணுகுவது? நாங்கள் வெவ்வேறு வாடிக்கையாளர்களுடன் வேலை செய்கிறோம், யாரிடமும் ELK ஸ்டாக் இல்லை, மேலும் 6 கன்சோல்கள் மற்றும் 2 தாவல்களைத் திறப்பதன் மூலம் பதிவுகளை வரிசைப்படுத்த வேண்டும். ஒரு தாவலில், இவை ஒவ்வொரு முனைக்கான பேட்ரோனி பதிவுகள், மற்ற தாவலில், இவை கான்சல் பதிவுகள் அல்லது தேவைப்பட்டால் போஸ்ட்கிரெஸ். இதைக் கண்டறிவது மிகவும் கடினம்.

நான் என்ன அணுகுமுறைகளை எடுத்தேன்? முதலில், ஃபைலர் வரும்போது நான் எப்போதும் பார்ப்பேன். என்னைப் பொறுத்தவரை இது ஒரு நீர்நிலை. தாக்கல் செய்பவருக்கு முன்பும், தாக்கல் செய்யும் போதும், தாக்கல் செய்த பின்பும் என்ன நடந்தது என்று பார்க்கிறேன். கோப்புக்கு இரண்டு மதிப்பெண்கள் உள்ளன: இது தொடக்க மற்றும் முடிவு நேரம்.

அடுத்து, தாக்கல் செய்பவருக்கு முந்தைய நிகழ்வுகளுக்கான பதிவுகளை நான் பார்க்கிறேன், இது தாக்கல் செய்பவருக்கு முந்தையது, அதாவது தாக்கல் செய்ததற்கான காரணங்களை நான் தேடுகிறேன்.

இது என்ன நடந்தது மற்றும் எதிர்காலத்தில் என்ன செய்ய முடியும் என்பதைப் புரிந்துகொள்வதற்கான ஒரு படத்தை இது வழங்குகிறது, இதனால் இதுபோன்ற சூழ்நிலைகள் ஏற்படாது (இதன் விளைவாக, கோப்பு தாக்கல் செய்பவர் இல்லை).

நாம் பொதுவாக எங்கு பார்க்கிறோம்? நான் பார்க்கிறேன்:

• முதலில், பட்ரோனி பதிவுகளுக்கு.
• அடுத்து, நான் Postgres பதிவுகள் அல்லது DCS பதிவுகளைப் பார்க்கிறேன், இது Patroni பதிவுகளில் காணப்பட்டதைப் பொறுத்து.
• கணினி பதிவுகள் சில சமயங்களில் ஃபைலருக்கு என்ன காரணம் என்பதைப் பற்றிய புரிதலை அளிக்கிறது.

பட்ரோனியைப் பற்றி நான் எப்படி உணர்கிறேன்? பட்ரோனியுடன் எனக்கு நல்ல உறவு இருக்கிறது. என் கருத்துப்படி, இது இன்று சிறந்தது. எனக்கு பல தயாரிப்புகள் தெரியும். இவை ஸ்டோலோன், ரெப்எம்ஜிஆர், பிஜி_ஆட்டோ_ஃபெயில்ஓவர், பிஏஎஃப். 4 கருவிகள். நான் அவை அனைத்தையும் முயற்சித்தேன். பட்ரோனி எனக்கு மிகவும் பிடித்தது.

அவர்கள் என்னிடம் கேட்டால்: "நான் பட்ரோனியை பரிந்துரைக்கிறேனா?". நான் ஆம் என்று சொல்வேன், ஏனென்றால் எனக்கு பட்ரோனி பிடிக்கும். நான் அதை எப்படி சமைக்க வேண்டும் என்று கற்றுக்கொண்டேன் என்று நினைக்கிறேன்.

நான் குறிப்பிட்டுள்ள சிக்கல்களைத் தவிர பேட்ரோனியில் வேறு என்ன பிரச்சனைகள் உள்ளன என்பதைப் பார்க்க நீங்கள் ஆர்வமாக இருந்தால், நீங்கள் எப்போதும் பக்கத்தைப் பார்க்கலாம் பிரச்சினைகள் GitHub இல். பலவிதமான கதைகள் மற்றும் பல சுவாரஸ்யமான விஷயங்கள் அங்கு விவாதிக்கப்படுகின்றன. இதன் விளைவாக, சில பிழைகள் அறிமுகப்படுத்தப்பட்டு தீர்க்கப்பட்டன, அதாவது, இது ஒரு சுவாரஸ்யமான வாசிப்பு.

மக்கள் காலில் தங்களைத் தாங்களே சுட்டுக் கொள்வது பற்றி சில சுவாரஸ்யமான கதைகள் உள்ளன. மிகவும் தகவல். அப்படிச் செய்ய வேண்டிய அவசியமில்லை என்பதை நீங்கள் படித்துப் புரிந்து கொள்ளுங்கள். நானே டிக் செய்தேன்.

அலெக்சாண்டர் குகுஷ்கின் மற்றும் அலெக்ஸி க்லூகின் ஆகியோருக்கு இந்த திட்டத்தை உருவாக்கியதற்காக ஜலாண்டோவுக்கு நான் ஒரு பெரிய நன்றி சொல்ல விரும்புகிறேன். அலெக்ஸி க்லுகின் இணை ஆசிரியர்களில் ஒருவர், அவர் இனி ஜலாண்டோவில் வேலை செய்யவில்லை, ஆனால் இந்த தயாரிப்புடன் பணிபுரியத் தொடங்கிய இருவர் இவர்கள்.

பட்ரோனி மிகவும் அருமையான விஷயம் என்று நான் நினைக்கிறேன். அவள் இருப்பதில் நான் மகிழ்ச்சியடைகிறேன், அது அவளுடன் சுவாரஸ்யமானது. மற்றும் Patroni க்கு இணைப்புகளை எழுதும் அனைத்து பங்களிப்பாளர்களுக்கும் ஒரு பெரிய நன்றி. வயதுக்கு ஏற்ப பட்ரோனி மிகவும் முதிர்ச்சியடைந்தவராகவும், குளிர்ச்சியாகவும், திறமையாகவும் மாறுவார் என்று நம்புகிறேன். இது ஏற்கனவே செயல்பாட்டில் உள்ளது, ஆனால் அது இன்னும் சிறப்பாக இருக்கும் என்று நம்புகிறேன். எனவே, நீங்கள் பட்ரோனியைப் பயன்படுத்த திட்டமிட்டால், பயப்பட வேண்டாம். இது ஒரு நல்ல தீர்வு, அதை செயல்படுத்தி பயன்படுத்தலாம்.

அவ்வளவுதான். உங்களிடம் கேள்விகள் இருந்தால், கேளுங்கள்.

உங்கள் கேள்விகள்

அறிக்கைக்கு நன்றி! ஒரு ஃபைலருக்குப் பிறகும் நீங்கள் அங்கு மிகவும் கவனமாகப் பார்க்க வேண்டும் என்றால், எங்களுக்கு ஏன் ஒரு தானியங்கி கோப்பு தேவை?

ஏனென்றால் இது புதிய விஷயம். நாங்கள் அவளுடன் ஒரு வருடம் மட்டுமே இருந்தோம். பாதுகாப்பாக இருப்பது நல்லது. நாங்கள் உள்ளே வர விரும்புகிறோம், எல்லாம் உண்மையில் சரியாகச் செயல்படுவதைப் பார்க்க விரும்புகிறோம். இது வயது வந்தோருக்கான அவநம்பிக்கையின் நிலை - இருமுறை சரிபார்த்து பார்ப்பது நல்லது.

உதாரணமாக, காலையில் சென்று பார்த்தோம், இல்லையா?

காலையில் அல்ல, பொதுவாக ஆட்டோஃபைலைப் பற்றி உடனடியாக அறிந்து கொள்கிறோம். நாங்கள் அறிவிப்புகளைப் பெறுகிறோம், ஒரு தானியங்கு கோப்பு ஏற்பட்டதைக் காண்கிறோம். நாங்கள் உடனடியாக சென்று பார்க்கிறோம். ஆனால் இந்த சோதனைகள் அனைத்தும் கண்காணிப்பு நிலைக்கு கொண்டு வரப்பட வேண்டும். நீங்கள் REST API வழியாக Patroni ஐ அணுகினால், ஒரு வரலாறு உள்ளது. வரலாற்றின் மூலம், தாக்கல் செய்த நேர முத்திரைகளைக் காணலாம். அதன் அடிப்படையில், கண்காணிப்பு மேற்கொள்ள முடியும். நீங்கள் வரலாற்றைப் பார்க்கலாம், எத்தனை நிகழ்வுகள் இருந்தன. எங்களிடம் அதிக நிகழ்வுகள் இருந்தால், ஒரு தானியங்கு கோப்பு ஏற்பட்டது. நீங்கள் சென்று பார்க்கலாம். அல்லது எங்கள் கண்காணிப்பு ஆட்டோமேஷன் எங்களிடம் அனைத்து பிரதிகளும் உள்ளனவா என்பதைச் சரிபார்த்தது, எந்த பின்னடைவும் இல்லை மற்றும் எல்லாம் நன்றாக இருக்கிறது.

நன்றி!

அருமையான கதைக்கு மிக்க நன்றி! போஸ்ட்கிரெஸ் கிளஸ்டரிலிருந்து எங்காவது DCS கிளஸ்டரை நகர்த்தினால், இந்தக் கிளஸ்டரையும் அவ்வப்போது சர்வீஸ் செய்ய வேண்டுமா? DCS கிளஸ்டரின் சில துண்டுகளை அணைக்க வேண்டிய சிறந்த நடைமுறைகள் என்ன, அவற்றைக் கொண்டு ஏதாவது செய்ய வேண்டும், முதலியன? இந்த முழு அமைப்பும் எவ்வாறு உயிர்வாழ்கிறது? மற்றும் நீங்கள் இந்த விஷயங்களை எப்படி செய்கிறீர்கள்?

ஒரு நிறுவனத்திற்கு, சிக்கல்களின் மேட்ரிக்ஸை உருவாக்குவது அவசியம், கூறுகளில் ஒன்று அல்லது பல கூறுகள் தோல்வியுற்றால் என்ன ஆகும். இந்த மேட்ரிக்ஸின் படி, நாங்கள் அனைத்து கூறுகளையும் தொடர்ச்சியாகச் சென்று இந்த கூறுகள் தோல்வியுற்றால் காட்சிகளை உருவாக்குகிறோம். அதன்படி, ஒவ்வொரு தோல்வி சூழ்நிலையிலும், மீட்புக்கான செயல் திட்டத்தை நீங்கள் வைத்திருக்கலாம். மற்றும் DCS விஷயத்தில், இது நிலையான உள்கட்டமைப்பின் ஒரு பகுதியாக வருகிறது. நிர்வாகி அதை நிர்வகிக்கிறார், மேலும் அதை நிர்வகிக்கும் நிர்வாகிகள் மற்றும் விபத்துகளின் போது அதை சரிசெய்யும் திறனை நாங்கள் ஏற்கனவே நம்பியுள்ளோம். டிசிஎஸ் இல்லை என்றால், நாங்கள் அதை வரிசைப்படுத்துகிறோம், ஆனால் அதே நேரத்தில் நாங்கள் அதை குறிப்பாக கண்காணிக்க மாட்டோம், ஏனென்றால் உள்கட்டமைப்புக்கு நாங்கள் பொறுப்பல்ல, ஆனால் எப்படி, எதைக் கண்காணிக்க வேண்டும் என்பதற்கான பரிந்துரைகளை நாங்கள் வழங்குகிறோம்.

அதாவது, ஹோஸ்ட்களுடன் எதையும் செய்வதற்கு முன், பேட்ரோனியை முடக்க வேண்டும், ஃபைலரை முடக்க வேண்டும், எல்லாவற்றையும் முடக்க வேண்டும் என்பதை நான் சரியாகப் புரிந்துகொண்டேனா?

டிசிஎஸ் கிளஸ்டரில் எத்தனை முனைகள் உள்ளன என்பதைப் பொறுத்தது. பல முனைகள் இருந்தால் மற்றும் நாம் ஒரு முனையை மட்டும் (பிரதி) முடக்கினால், கிளஸ்டர் ஒரு கோரத்தை பராமரிக்கிறது. மற்றும் பட்ரோனி தொடர்ந்து செயல்பட்டு வருகிறது. மற்றும் எதுவும் தூண்டப்படவில்லை. அதிக முனைகளைப் பாதிக்கும் சில சிக்கலான செயல்பாடுகள் எங்களிடம் இருந்தால், அவை இல்லாதது கோரத்தை அழிக்கக்கூடும், பின்னர் - ஆம், பட்ரோனியை இடைநிறுத்துவது அர்த்தமுள்ளதாக இருக்கும். இது தொடர்புடைய கட்டளையைக் கொண்டுள்ளது - patronictl இடைநிறுத்தம், patronictl விண்ணப்பம். நாங்கள் இடைநிறுத்துகிறோம், அந்த நேரத்தில் ஆட்டோஃபைலர் வேலை செய்யாது. நாங்கள் DCS கிளஸ்டரில் பராமரிப்பு செய்கிறோம், பிறகு இடைநிறுத்தத்தை கழற்றிவிட்டு தொடர்ந்து வாழ்கிறோம்.

மிகவும் நன்றி!

உங்கள் அறிக்கைக்கு மிக்க நன்றி! தரவு இழக்கப்படுவதைப் பற்றி தயாரிப்புக் குழு எப்படி உணருகிறது?

தயாரிப்பு குழுக்கள் கவலைப்படுவதில்லை, மேலும் குழு தலைவர்கள் கவலைப்படுகிறார்கள்.

என்ன உத்தரவாதங்கள் உள்ளன?

உத்தரவாதங்கள் மிகவும் கடினமானவை. அலெக்சாண்டர் குகுஷ்கின் "ஆர்பிஓ மற்றும் ஆர்டிஓவை எவ்வாறு கணக்கிடுவது" என்ற அறிக்கை உள்ளது, அதாவது மீட்பு நேரம் மற்றும் எவ்வளவு தரவை நாம் இழக்கலாம். இந்த ஸ்லைடுகளைக் கண்டுபிடித்து படிக்க வேண்டும் என்று நினைக்கிறேன். எனக்கு நினைவிருக்கும் வரை, இந்த விஷயங்களை எவ்வாறு கணக்கிடுவது என்பதற்கான குறிப்பிட்ட படிகள் உள்ளன. எத்தனை பரிவர்த்தனைகளை நாம் இழக்கலாம், எவ்வளவு டேட்டாவை இழக்கலாம். ஒரு விருப்பமாக, நாம் பேட்ரோனி மட்டத்தில் ஒத்திசைவான நகலெடுப்பைப் பயன்படுத்தலாம், ஆனால் இது இரட்டை முனைகள் கொண்ட வாள்: எங்களிடம் தரவு நம்பகத்தன்மை உள்ளது அல்லது வேகத்தை இழக்கிறோம். ஒத்திசைவான பிரதியமைப்பு உள்ளது, ஆனால் இது தரவு இழப்பிற்கு எதிராக 100% பாதுகாப்பிற்கு உத்தரவாதம் அளிக்காது.

அலெக்ஸி, சிறந்த அறிக்கைக்கு நன்றி! பூஜ்ஜிய அளவிலான பாதுகாப்பிற்காக பேட்ரோனியைப் பயன்படுத்துவதில் ஏதேனும் அனுபவம் உள்ளதா? அதாவது, ஒத்திசைவான காத்திருப்புடன் இணைந்து? இதுதான் முதல் கேள்வி. மற்றும் இரண்டாவது கேள்வி. நீங்கள் வெவ்வேறு தீர்வுகளைப் பயன்படுத்தியுள்ளீர்கள். நாங்கள் Repmgr ஐப் பயன்படுத்தினோம், ஆனால் ஆட்டோஃபைலர் இல்லாமல், இப்போது ஆட்டோஃபைலரைச் சேர்க்க திட்டமிட்டுள்ளோம். மேலும் பட்ரோனியை மாற்று தீர்வாக நாங்கள் கருதுகிறோம். Repmgr உடன் ஒப்பிடும்போது நீங்கள் என்ன நன்மைகள் என்று சொல்லலாம்?

முதல் கேள்வி ஒத்திசைவான பிரதிகள் பற்றியது. இங்கே யாரும் ஒத்திசைவான நகலெடுப்பைப் பயன்படுத்துவதில்லை, ஏனென்றால் எல்லோரும் பயப்படுகிறார்கள் (பல வாடிக்கையாளர்கள் ஏற்கனவே இதைப் பயன்படுத்துகின்றனர், கொள்கையளவில், செயல்திறன் சிக்கல்களை அவர்கள் கவனிக்கவில்லை - சபாநாயகரின் குறிப்பு) ஆனால் சின்க்ரோனஸ் ரெப்ளிகேஷன் கிளஸ்டரில் குறைந்தது மூன்று முனைகளாவது இருக்க வேண்டும் என்று நாங்களே ஒரு விதியை உருவாக்கிக்கொண்டோம், ஏனென்றால் எங்களிடம் இரண்டு முனைகள் இருந்தால், மாஸ்டர் அல்லது பிரதி தோல்வியடைந்தால், பேட்ரோனி இந்த முனையை ஸ்டாண்டலோன் பயன்முறைக்கு மாற்றுகிறது, இதனால் பயன்பாடு தொடர்கிறது. வேலை. இந்த வழக்கில், தரவு இழப்பு ஆபத்து உள்ளது.

இரண்டாவது கேள்வியைப் பொறுத்தவரை, நாங்கள் Repmgr ஐப் பயன்படுத்தியுள்ளோம், இன்னும் சில வாடிக்கையாளர்களுடன் வரலாற்று காரணங்களுக்காக செய்கிறோம். என்ன சொல்ல முடியும்? Patroni பெட்டியின் வெளியே ஒரு ஆட்டோஃபைலருடன் வருகிறது, Repmgr ஒரு கூடுதல் அம்சமாக ஆட்டோஃபைலருடன் வருகிறது, அது இயக்கப்பட வேண்டும். நாம் ஒவ்வொரு முனையிலும் Repmgr டீமானை இயக்க வேண்டும், அதன் பிறகு நாம் ஆட்டோஃபைலரை உள்ளமைக்கலாம்.

Postgres முனைகள் உயிருடன் உள்ளதா என்பதை Repmgr சரிபார்க்கிறது. Repmgr செயல்முறைகள் ஒருவருக்கொருவர் இருப்பதை சரிபார்க்கின்றன, இது மிகவும் திறமையான அணுகுமுறை அல்ல. நெட்வொர்க் தனிமைப்படுத்துதலின் சிக்கலான நிகழ்வுகள் இருக்கலாம், இதில் ஒரு பெரிய Repmgr கிளஸ்டர் பல சிறியதாக பிரிந்து தொடர்ந்து வேலை செய்ய முடியும். நான் நீண்ட காலமாக Repmgr ஐப் பின்தொடரவில்லை, ஒருவேளை அது சரி செய்யப்பட்டிருக்கலாம் ... அல்லது இல்லை. ஆனால் ஸ்டோலோன், பட்ரோனி செய்வது போல, DCS இல் உள்ள கிளஸ்டரின் நிலை பற்றிய தகவலை அகற்றுவது மிகவும் சாத்தியமான விருப்பமாகும்.

அலெக்ஸி, எனக்கு ஒரு கேள்வி உள்ளது, ஒருவேளை ஒரு நொடியாக இருக்கலாம். முதல் உதாரணங்களில் ஒன்றில், நீங்கள் DCS ஐ லோக்கல் மெஷினிலிருந்து ரிமோட் ஹோஸ்டுக்கு நகர்த்தியுள்ளீர்கள். நெட்வொர்க் என்பது அதன் சொந்த குணாதிசயங்களைக் கொண்ட ஒரு விஷயம் என்பதை நாங்கள் புரிந்துகொள்கிறோம், அது சொந்தமாக வாழ்கிறது. சில காரணங்களால் DCS கிளஸ்டர் கிடைக்காமல் போனால் என்ன நடக்கும்? நான் காரணங்களைச் சொல்ல மாட்டேன், அவற்றில் நிறைய இருக்கலாம்: நெட்வொர்க்கர்களின் வளைந்த கைகளிலிருந்து உண்மையான பிரச்சினைகள் வரை.

நான் அதை சத்தமாக சொல்லவில்லை, ஆனால் DCS கிளஸ்டரும் தோல்வியுற்றதாக இருக்க வேண்டும், அதாவது ஒரு கோரம் சந்திக்க, அது ஒற்றைப்படை எண்ணிக்கையிலான முனைகளாக இருக்க வேண்டும். DCS க்ளஸ்டர் கிடைக்காமல் போனால், அல்லது கோரம் பூர்த்தி செய்யப்படாவிட்டால், அதாவது சில வகையான நெட்வொர்க் பிளவு அல்லது முனை தோல்வி ஏற்பட்டால் என்ன நடக்கும்? இந்த வழக்கில், Patroni கிளஸ்டர் படிக்க மட்டும் பயன்முறையில் செல்கிறது. பட்ரோனி கிளஸ்டரால் கிளஸ்டரின் நிலை மற்றும் என்ன செய்ய வேண்டும் என்பதை தீர்மானிக்க முடியாது. இது DCS ஐத் தொடர்புகொண்டு புதிய கிளஸ்டர் நிலையை அங்கே சேமிக்க முடியாது, எனவே முழு கிளஸ்டரும் படிக்க மட்டுமே செல்லும். ஆபரேட்டரிடமிருந்து கைமுறையான தலையீட்டிற்காக அல்லது DCS மீட்டெடுப்பதற்காக காத்திருக்கிறது.

தோராயமாகச் சொல்வதானால், DCS நமக்கு ஒரு சேவையாக மாறுவது எவ்வளவு முக்கியமோ அதே அளவு அடிப்படையும் அதுதானே?

ஆம் ஆம். பல நவீன நிறுவனங்களில், சர்வீஸ் டிஸ்கவரி என்பது உள்கட்டமைப்பின் ஒருங்கிணைந்த பகுதியாகும். உள்கட்டமைப்பில் ஒரு தரவுத்தளத்திற்கு முன்பே இது செயல்படுத்தப்படுகிறது. ஒப்பீட்டளவில் பேசுகையில், உள்கட்டமைப்பு தொடங்கப்பட்டது, DC இல் பயன்படுத்தப்பட்டது, எங்களிடம் உடனடியாக சர்வீஸ் டிஸ்கவரி உள்ளது. அது தூதரகமாக இருந்தால், DNS ஐ உருவாக்கலாம். இது Etcd எனில், குபெர்னெட்ஸ் கிளஸ்டரிலிருந்து ஒரு பகுதி இருக்கலாம், அதில் மற்ற அனைத்தும் பயன்படுத்தப்படும். சர்வீஸ் டிஸ்கவரி ஏற்கனவே நவீன உள்கட்டமைப்புகளின் ஒருங்கிணைந்த பகுதியாக இருப்பதாக எனக்குத் தோன்றுகிறது. தரவுத்தளங்களைப் பற்றி அவர்கள் மிகவும் முன்னதாகவே நினைக்கிறார்கள்.

நன்றி!

ஆதாரம்: www.habr.com