Кіріспе

Біраз уақыт бұрын маған істен шығу кластерін әзірлеу тапсырмасы берілді PostgreSQL, бір қала ішінде оптикалық талшықпен қосылған бірнеше деректер орталықтарында жұмыс істейді және бір деректер орталығының істен шығуына (мысалы, өшіру) төтеп бере алады. Ақауларға төзімділікке жауап беретін бағдарламалық құрал ретінде мен таңдадым Электрокардиостимуляторсебебі бұл RedHat компаниясының ауыспалы кластерлерді жасауға арналған ресми шешімі. Бұл жақсы, өйткені RedHat оған қолдау көрсетеді және бұл шешім әмбебап (модульдік) болып табылады. Оның көмегімен PostgreSQL ғана емес, сонымен қатар стандартты модульдерді пайдалана отырып немесе оларды белгілі бір қажеттіліктер үшін жасай отырып, басқа қызметтердің де ақауларға төзімділігін қамтамасыз етуге болады.

Бұл шешім ақылға қонымды сұрақ тудырды: істен шығу кластері ақауларға қаншалықты төзімді болады? Мұны зерттеу үшін мен кластер түйіндеріндегі әртүрлі сәтсіздіктерді имитациялайтын, қызметтің қалпына келуін күтетін, сәтсіз түйінді қалпына келтіретін және циклде тестілеуді жалғастыратын сынақ үстелін әзірледім. Бұл жоба бастапқыда hapgsql деп аталды, бірақ уақыт өте мен тек бір дауысты дыбыстан тұратын атаудан жалықтым. Сондықтан мен қателерге төзімді дерекқорларды шақыра бастадым (және оларға нұсқайтын қалқымалы IP) кроган (барлық маңызды мүшелер қайталанатын компьютерлік ойынның кейіпкері) және түйіндер, кластерлер және жобаның өзі тучанка (крогандар мекендейтін планета).

Қазір басшылық рұқсат берді жобаны MIT лицензиясы бойынша ашық бастапқы қауымдастыққа ашыңыз. Жақында README ағылшын тіліне аударылады (өйткені негізгі тұтынушылар кардиостимулятор және PostgreSQL әзірлеушілері болады деп күтілуде), мен README ескі орыс тіліндегі нұсқасын (жартылай) осы мақала түрінде ұсынуды жөн көрдім.

Кластерлер виртуалды машиналарда орналастырылған Virtualbox. Барлығы 12 виртуалды машина (барлығы 36ГиБ) орналастырылады, олар 4 ақауға төзімді кластерді (әр түрлі опциялар) құрайды. Алғашқы екі кластер әртүрлі деректер орталықтарында орналасқан екі PostgreSQL серверінен және ортақ серверден тұрады. куәгер c кворум құрылғысы (үшінші деректер орталығындағы арзан виртуалды машинада орналастырылған), ол белгісіздікті шешеді 50% / 50%, дауысыңызды партиялардың біріне беру. Үш деректер орталығындағы үшінші кластер: бір негізгі, екі бағынышты, жоқ кворум құрылғысы. Төртінші кластер төрт PostgreSQL серверінен тұрады, екі деректер орталығына: бір негізгі, қалған көшірмелері, сондай-ақ пайдаланады. куәгер c кворум құрылғысы. Төртінші екі сервердің немесе бір деректер орталығының істен шығуына төтеп бере алады. Қажет болса, бұл шешімді репликалардың көбірек санына дейін масштабтауға болады.

Дәл уақыт қызметі ntpd сонымен қатар ақауларға төзімділік үшін қайта конфигурацияланған, бірақ ол әдістің өзін пайдаланады ntpd (жетім режим). Ортақ сервер куәгер орталық NTP сервері ретінде әрекет етеді, өз уақытын барлық кластерлерге таратады, осылайша барлық серверлерді бір-бірімен синхрондайды. Егер куәгер сәтсіз аяқталса немесе оқшауланған болса, кластер серверлерінің бірі (кластер ішінде) өз уақытын тарата бастайды. Көмекші кэштеу HTTP прокси дейін көтерілді куәгер, оның көмегімен басқа виртуалды машиналар Yum репозиторийлеріне қол жеткізе алады. Шындығында, дәл уақыт пен прокси сияқты қызметтер арнайы серверлерде орналастырылады, бірақ олар стендте орналастырылады. куәгер виртуалды машиналар саны мен кеңістікті сақтау үшін ғана.

Нұсқалар

v0. VirtualBox 7 жүйесінде CentOS 11 және PostgreSQL 6.1-мен жұмыс істейді.

Кластер құрылымы

Барлық кластерлер бір тегіс желіге біріктірілген бірнеше деректер орталықтарында орналастыруға арналған және бір деректер орталығының істен шығуына немесе желілік оқшаулануға төтеп беруі керек. Сондықтан мүмкін емес қарсы қорғау үшін пайдаланыңыз бөлінген ми стандартты кардиостимулятор технологиясы деп аталады СТОНИТ (Бастағы басқа түйінді түсіріңіз) немесе қоршаулар. Оның мәні: егер кластердегі түйіндер қандай да бір түйінде бірдеңе дұрыс емес деп күдіктене бастаса, ол жауап бермейді немесе дұрыс әрекет етпейді, онда олар оны «сыртқы» құрылғылар арқылы, мысалы, IPMI немесе UPS басқару картасы арқылы мәжбүрлеп өшіреді. . Бірақ бұл бір рет ақау болған жағдайда IPMI немесе UPS сервері жұмысын жалғастыратын жағдайларда ғана жұмыс істейді. Мұнда біз бүкіл деректер орталығы істен шыққан кезде (мысалы, қуат жоғалған) әлдеқайда апатты істен шығудан қорғауды жоспарлап отырмыз. Және мұндай бас тартумен бәрі стонит-құрылғылар да (IPMI, UPS, т.б.) жұмыс істемейді.

Оның орнына жүйе кворум идеясына негізделген. Барлық түйіндердің дауысы бар және барлық түйіндердің жартысынан көбін көре алатындар ғана жұмыс істей алады. Бұл «жарты + 1» саны деп аталады кворум. Егер кворумға қол жеткізілмесе, онда түйін желі оқшаулануында екенін шешеді және өз ресурстарын өшіруі керек, яғни. бұл солай бөлінген миды қорғау. Егер бұл әрекетке жауапты бағдарламалық жасақтама жұмыс істемесе, онда бақылаушы, мысалы, IPMI негізінде жұмыс істеуге тура келеді.

Егер түйіндердің саны жұп болса (екі деректер орталығындағы кластер), онда белгісіздік деп аталатын жағдай туындауы мүмкін 50% / 50% (елу елу) желіні оқшаулау кластерді дәл екіге бөлгенде. Сондықтан, түйіндердің жұп саны үшін біз қосамыз кворум құрылғысы үшінші деректер орталығындағы ең арзан виртуалды машинада іске қосуға болатын қарапайым демон. Ол өз дауысын сегменттердің біріне береді (ол оны көреді) және осылайша 50%/50% белгісіздікті шешеді. Мен кворум құрылғысы іске қосылатын серверді атадым куәгер (repmgr терминологиясы, маған ұнады).

Ресурстарды бір жерден екінші жерге ауыстыруға болады, мысалы, ақаулы серверлерден сау серверлерге немесе жүйе әкімшілерінің бұйрығымен. Клиенттер өздеріне қажетті ресурстардың қайда орналасқанын білуі үшін (қайда қосылу керек?), өзгермелі IP (қалқымалы IP). Бұл кардиостимулятор түйіндердің айналасында қозғала алатын IP мекенжайлары (барлығы тегіс желіде). Олардың әрқайсысы ресурсты (қызметті) білдіреді және осы қызметке қол жеткізу үшін қосылу қажет жерде орналасады (біздің жағдайда деректер базасы).

Тучанка1 (нығыздалған схема)

құрылым

Идея бізде аз жүктемесі бар көптеген шағын дерекқорлар бар, олар үшін тек оқуға арналған транзакциялар үшін ыстық күту режимінде арнайы құл серверді ұстау тиімсіз (ресурстарды мұндай ысырап етудің қажеті жоқ) болды.

Әрбір деректер орталығында бір сервер бар. Әрбір серверде екі PostgreSQL данасы бар (PostgreSQL терминологиясында олар кластерлер деп аталады, бірақ шатастырмау үшін мен оларды даналар деп атаймын (басқа дерекқорларға ұқсастық бойынша), мен тек кардиостимулятор кластерлерін кластер деп атаймын). Бір данасы негізгі режимде жұмыс істейді және тек ол қызметтерді ұсынады (тек қалқымалы IP оған әкеледі). Екінші данасы екінші деректер орталығының құл ретінде жұмыс істейді және оның шебері сәтсіз болған жағдайда ғана қызметтерді көрсетеді. Көбінесе екі дананың бір данасы (басты) қызметтерді (сұрауларды орындау) қамтамасыз ететіндіктен, барлық сервер ресурстары негізгі үшін оңтайландырылған (жад ортақ_буферлер кэшіне бөлінген, т.б.), бірақ екінші данасы осылайша деректер орталықтарының бірі істен шыққан жағдайда жеткілікті ресурстарға ие (файлдық жүйе кэші арқылы оңтайлы емес жұмыс үшін болса да). Кластердің қалыпты жұмысы кезінде құл қызметтерді ұсынбайды (тек оқуға арналған сұрауларды орындамайды), осылайша бір машинада шебермен ресурстар үшін соғыс болмайды.

Екі түйін жағдайында ақауларға төзімділік тек асинхронды репликациямен мүмкін болады, өйткені синхронды репликация кезінде бағыныңқы жұмыс істемеуі шебердің тоқтауына әкеледі.

Куә болмау

Куә болмау (кворум құрылғысы) Мен тек Tuchanka1 кластерін қарастырамын, қалғандарымен бірдей оқиға болады. Егер куәгер сәтсіз болса, кластер құрылымында ештеңе өзгермейді, бәрі бұрынғыдай жұмысын жалғастырады. Бірақ кворум 2-тен 3 болады, сондықтан кез келген кейінгі сәтсіздік кластер үшін өлімге әкеледі. Оны әлі де шұғыл түрде жөндеу керек болады.

Тучанка1 бас тарту

Tuchanka1 үшін деректер орталықтарының бірінің істен шығуы. Бұл жағдайда куәгер дауысын екінші деректер орталығындағы екінші түйінге береді. Онда бұрынғы құл шеберге айналады, нәтижесінде екі шебер де бір серверде жұмыс істейді және олардың екі қалқымалы IP мекенжайлары оларға нұсқайды.

Тучанка2 (классикалық)

құрылым

Екі түйіннің классикалық схемасы. Қожайын біреуінде, құл екіншісінде жұмыс істейді. Екеуі де сұрауларды орындай алады (құл тек оқуға арналған), сондықтан екеуі де қалқымалы IP арқылы көрсетіледі: krogan2 - шебер, krogan2s1 - құл. Қожайынның да, құлдың да қателікке төзімділігі болады.

Екі түйін жағдайында ақауларға төзімділік асинхронды репликациямен ғана мүмкін болады, өйткені синхронды репликация кезінде бағыныңқы істен шығуы шебердің тоқтауына әкеледі.

Тучанка2 бас тарту

Деректер орталықтарының бірі істен шықса куәгер екіншісіне дауыс береді. Жалғыз жұмыс істейтін деректер орталығында мастер көтеріледі және екі қалқымалы IP оны көрсетеді: басты және бағынышты. Әрине, дананы бір уақытта негізгі және тәуелді қалқымалы IP-ден барлық қосылымдар мен сұрауларды қабылдау үшін жеткілікті ресурстары (қосылу шектеулері және т.б.) болатындай етіп конфигурациялау керек. Яғни, қалыпты жұмыс кезінде оның жеткілікті шектеулер қоры болуы керек.

Tuchanka4 (көп құлдар)

құрылым

Қазірдің өзінде басқа экстремалды. Көптеген тек оқуға арналған сұрауларды қабылдайтын дерекқорлар бар (жоғары жүктелетін сайттың әдеттегі жағдайы). Tuchanka4 - мұндай сұрауларды өңдеу үшін үш немесе одан да көп құл болуы мүмкін жағдай, бірақ әлі де көп емес. Құлдардың өте көп санымен иерархиялық репликация жүйесін ойлап табу қажет болады. Ең аз жағдайда (суретте) екі деректер орталығының әрқайсысында PostgreSQL данасы бар екі сервер бар.

Бұл схеманың тағы бір ерекшелігі - бір синхронды репликацияны ұйымдастыруға мүмкіндік бар. Ол, мүмкін болса, басты құрылғымен бір деректер орталығындағы көшірмеге емес, басқа деректер орталығына көшіру үшін конфигурацияланған. Мастер мен әрбір бағыныңқы қалқымалы IP арқылы көрсетіледі. Бақытымызға орай, құлдар арасында сұрауларды қандай да бір түрде теңестіру қажет болады sql прокси, мысалы, клиент жағында. Клиенттердің әртүрлі түрлері әртүрлі типтерді қажет етуі мүмкін sql прокси, және тек клиент әзірлеушілері кімге не қажет екенін біледі. Бұл функцияны сыртқы демон немесе клиент кітапханасы (байланыс пулы) және т.б. Бұның барлығы орындалмайтын дерекқор кластері тақырыбының шеңберінен шығады (failover SQL прокси клиенттің қателеріне төзімділікпен бірге дербес жүзеге асырылуы мүмкін).

Тучанка4 бас тарту

Бір деректер орталығы (яғни, екі сервер) сәтсіз болса, куәгер екіншісіне дауыс береді. Нәтижесінде, екінші деректер орталығында жұмыс істейтін екі сервер бар: біреуі шеберді іске қосады, ал негізгі қалқымалы IP оған нұсқайды (оқу-жазу сұрауларын қабылдау үшін); ал екінші серверде синхронды репликациямен жұмыс істейтін құл бар және бағынышты қалқымалы IP мекенжайларының бірі оны көрсетеді (тек оқуға арналған сұраулар үшін).

Бірінші ескеретін нәрсе, барлық құл флоат IP-тері жұмысшылар емес, тек біреуі ғана болады. Ал онымен дұрыс жұмыс істеу үшін бұл қажет болады sql прокси барлық сұрауларды қалған жалғыз қалқымалы IP-ге қайта бағыттады; ал егер sql прокси жоқ, онда қосылым URL мекенжайында үтірмен бөлінген барлық қалқымалы IP құлдарын тізімдей аласыз. Бұл жағдайда, бірге libpq қосылу бірінші жұмыс істейтін IP-ге болады, бұл автоматты тестілеу жүйесінде жасалады. Мүмкін, басқа кітапханаларда, мысалы, JDBC, бұл жұмыс істемейді және қажет sql прокси. Бұл құлдарға арналған қалқымалы IP мекенжайларының бір серверде бір уақытта көтерілуіне тыйым салынғандықтан жасалды, осылайша олар бірнеше жұмыс істеп тұрған болса, бағынышты серверлер арасында біркелкі бөлінеді.

Екіншіден: тіпті деректер орталығы істен шыққан жағдайда да синхронды репликация сақталады. Екінші реттік ақаулық орын алса да, яғни қалған деректер орталығындағы екі сервердің бірі істен шықса да, кластер қызметтерді көрсетуді тоқтатса да, ол міндеттемені растау берген барлық жасалған транзакциялар туралы ақпаратты сақтайды. (екінші рет бұзылған жағдайда жоғалту туралы ақпарат болмайды).

Tuchanka3 (3 деректер орталығы)

құрылым

Бұл үш толық жұмыс істейтін деректер орталығы бар жағдайға арналған кластер, олардың әрқайсысында толық жұмыс істейтін дерекқор сервері бар. Бұл жағдайда кворум құрылғысы керек емес. Бір деректер орталығында шебер, қалған екеуінде құлдар жұмыс істейді. Репликация синхронды болып табылады, КЕЗ КЕЛГЕН (құл1, құл2) түрі, яғни бағыныңқылардың кез келгені міндеттемені қабылдағаны туралы бірінші болып жауап бергенде, клиент міндеттеме растауын алады. Ресурстар басты үшін бір қалқымалы IP арқылы және бағыныштылар үшін екі арқылы көрсетіледі. Tuchanka4-тен айырмашылығы, барлық үш қалқымалы IP ақауларға төзімді. Тек оқуға арналған SQL сұрауларын теңестіру үшін пайдалануға болады sql прокси (бөлек ақауларға төзімділікпен) немесе бір бағынышты қалқымалы IP мекенжайын клиенттердің жартысына, ал қалған жартысын екіншісіне тағайындаңыз.

Тучанка3 бас тарту

Деректер орталықтарының бірі істен шықса, екеуі қалады. Бірінде шеберден негізгі және қалқымалы IP көтеріледі, екіншісінде - бағынышты және екі бағынышты қалқымалы IP мекенжайлары (дана екі бағынышты қалқымалы IP-ден барлық қосылымдарды қабылдау үшін ресурстардың қос резервіне ие болуы керек). Қожайындар мен құлдар арасындағы синхронды репликация. Сондай-ақ кластер жасалған және расталған транзакциялар туралы ақпаратты сақтайды (ақпарат жоғалмайды) екі деректер орталығы жойылған жағдайда (егер олар бір уақытта жойылмаса).

Мен файл құрылымы мен орналастырудың толық сипаттамасын қоспауды шештім. Ойнағысы келетін кез келген адам мұның бәрін README ішінен оқи алады. Мен тек автоматтандырылған тестілеудің сипаттамасын беремін.

Автоматты тестілеу жүйесі

Әртүрлі ақауларды имитациялау арқылы кластерлердің ақауларға төзімділігін тексеру үшін автоматты тестілеу жүйесі құрылды. Сценарий бойынша іске қосылды test/failure. Сценарий параметр ретінде тексергіңіз келетін кластерлердің санын қабылдай алады. Мысалы, бұл пәрмен:

test/failure 2 3

тек екінші және үшінші кластерді сынақтан өткізеді. Параметрлер көрсетілмесе, барлық кластерлер тексеріледі. Барлық кластерлер параллельді түрде тексеріліп, нәтиже tmux панелінде көрсетіледі. Tmux арнайы tmux серверін пайдаланады, сондықтан сценарийді әдепкі tmux астында іске қосуға болады, нәтижесінде кірістірілген tmux болады. Терминалды үлкен терезеде және шағын шрифтпен пайдалануды ұсынамын. Тестілеуді бастамас бұрын, сценарий аяқталған кезде барлық виртуалды машиналар суретке оралады. setup.

Терминал тексерілетін кластерлердің санына сәйкес бағандарға бөлінген; әдепкі бойынша (скриншотта) төртеуі бар. Мен бағандардың мазмұнын Тучанка2 мысалы арқылы сипаттаймын. Скриншоттағы панельдер нөмірленген:

1. Сынақ статистикасы осы жерде көрсетіледі. Бағандар:
   • сәтсіздік — қатені эмуляциялайтын сынақтың атауы (скрипттегі функция).
   • реакция — кластер өзінің функционалдығын қалпына келтірген секундтағы орташа арифметикалық уақыт. Ол қатені эмуляциялайтын сценарийдің басынан кластер өзінің функционалдығын қалпына келтіріп, қызметтерді көрсетуді жалғастыра алатын сәтке дейін өлшенеді. Егер уақыт өте қысқа болса, мысалы, алты секунд (бұл бірнеше құлдары бар кластерлерде болады (Тучанка3 және Тучанка4)), бұл ақау асинхронды құлда болды және өнімділікке ешқандай әсер етпеді; жоқ. кластер күйінің қосқыштары.
   • ауытқу — шаманың таралуын (дәлдігін) көрсетеді реакция стандартты ауытқу әдісін қолдану.
   • санау — бұл сынақ қанша рет жасалды.
2. Қысқа журнал кластердің қазіргі уақытта не істеп жатқанын бағалауға мүмкіндік береді. Итерация (сынақ) нөмірі, уақыт белгісі және операцияның аты көрсетіледі. Тым ұзақ жұмыс істеу (> 5 минут) ақаулықты көрсетеді.
3. жүрек (жүрек) - ағымдағы уақыт. Өнімділікті визуалды бағалау үшін шеберлер Ағымдағы уақыт өзгермелі IP шеберінің көмегімен оның кестесіне үнемі жазылады. Сәтті болса, нәтиже осы панельде көрсетіледі.
4. ұрыс (импульс) - бұрын сценариймен жазылған «ағымдағы уақыт». жүрек меңгеру, енді мына жерден оқы құл қалқымалы IP арқылы. Құлдың және репликацияның өнімділігін көрнекі түрде бағалауға мүмкіндік береді. Tuchanka1-де өзгермелі IP бар құлдар жоқ (қызмет көрсететін құлдар жоқ), бірақ екі данасы (ДҚ) бар, сондықтан ол мұнда көрсетілмейді. ұрысмен жүрек екінші инстанция.
5. Утилитаны пайдаланып кластер денсаулығын бақылау pcs mon. Түйіндер бойынша ресурстардың құрылымын, таралуын және басқа пайдалы ақпаратты көрсетеді.
6. Кластердегі әрбір виртуалды машинаның жүйелік мониторингі осы жерде көрсетіледі. Кластерде қанша виртуалды машина бар екеніне байланысты мұндай панельдер көбірек болуы мүмкін. Екі график CPU жүктемесі (виртуалды машиналарда екі процессор бар), виртуалды машина аты, Жүйелік жүктеме (орташа жүктеме 5, 10 және 15 минут ішінде орташаланғандықтан деп аталады), деректерді өңдеу және жадты бөлу.
7. Тестілеуді орындайтын сценарийдің ізі. Ақаулық жағдайында - жұмыстың кенеттен үзілуі немесе шексіз күту циклі - мұнда сіз бұл әрекеттің себебін көре аласыз.

Тестілеу екі кезеңде жүргізіледі. Біріншіден, сценарий осы сынақты қолдану үшін виртуалды машинаны кездейсоқ таңдай отырып, сынақтардың барлық түрлерінен өтеді. Содан кейін сынақтың шексіз циклі орындалады, виртуалды машиналар мен ақаулық әр жолы кездейсоқ таңдалады. Сынақ сценарийінің кенеттен тоқтатылуы (төменгі панель) немесе бірдеңені күтудің шексіз циклі (бір операция үшін > 5 минут орындау уақыты, мұны ізден көруге болады) осы кластердегі кейбір сынақтардың сәтсіз аяқталғанын көрсетеді.

Әрбір сынақ келесі операциялардан тұрады:

1. Қатені эмуляциялайтын функцияны іске қосыңыз.
2. Дайын? — кластердің қалпына келуін күту (барлық қызметтер көрсетілген кезде).
3. Кластерді қалпына келтіру күту уақытын көрсетеді (реакция).
4. Fix — кластер «жөнделуде». Осыдан кейін ол толық жұмыс күйіне оралып, келесі ақауларға дайын болуы керек.

Мұнда не істейтінін сипаттайтын сынақтар тізімі берілген:

• ForkBomb: Шанышқы бомбаны пайдаланып "Жад жоқ" жасайды.
• OutOfSpace: Қатты диск толы. Бірақ тест өте символдық болып табылады; тестілеу кезінде пайда болатын шамалы жүктемемен PostgreSQL әдетте қатты диск толған кезде сәтсіздікке ұшырамайды.
• Postgres-KILL: PostgreSQL пәрменімен жояды killall -KILL postgres.
• Postgres-STOP: PostgreSQL пәрменін іліп қояды killall -STOP postgres.
• Қуат көзін өшіру: пәрмен арқылы виртуалды машинаны «қуатсыздандырады». VBoxManage controlvm "виртуалка" poweroff.
• Ысыру: пәрменмен виртуалды машинаны шамадан тыс жүктейді VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: пәрменімен SBD жынын тоқтатады killall -STOP sbd.
• Жабу: SSH арқылы виртуалды машинаға пәрмен жібереді systemctl poweroff, жүйе әдемі түрде өшеді.
• Байланысты жою: желіні оқшаулау, команда VBoxManage controlvm "виртуалка" setlinkstate1 off.

Стандартты tmux "kill-window" пәрмені арқылы тестілеуді аяқтау Ctrl-b &, немесе «ажырату-клиент» пәрмені Ctrl-b d: осы кезде тестілеу аяқталады, tmux жабылады, виртуалды машиналар өшіріледі.

Тестілеу кезінде анықталған проблемалар

• Қазіргі уақытта күзетші жын sbd бақыланатын демондарды тоқтату бойынша жұмыс істейді, бірақ оларды қатыртпайды. Және, нәтижесінде, тек мұздатуға әкелетін ақаулар Коросинх и Электрокардиостимулятор, бірақ ілулі емес сбд. Тексеру үшін Коросинх енді бар PR №83 (GitHub сайтында сбд), жіпке қабылданды мастер. Олар (PR#83-те) кардиостимулятор үшін ұқсас нәрсе болады деп уәде берді, мен осылай деп үміттенемін Қызыл қалпақ 8 істеймін. Бірақ мұндай «ақаулар» алыпсатарлық болып табылады және оларды жасанды түрде оңай модельдеуге болады, мысалы, killall -STOP corosync, бірақ өмірде ешқашан кездеспеймін.

• У Электрокардиостимулятор арналған нұсқасында CentOS 7 қате орнатылған синхрондау_уақыты у кворум құрылғысы, нәтижесінде егер бір түйін сәтсіз болса, екінші түйін де қайта жүктеледі, оған шебер көшуі керек еді. Кеңейту арқылы емделеді синхрондау_уақыты у кворум құрылғысы орналастыру кезінде (скриптте setup/setup1). Бұл түзетуді әзірлеушілер қабылдамады Электрокардиостимулятор, оның орнына олар инфрақұрылымды бұл күту уақыты автоматты түрде есептелетіндей етіп (кейбір белгісіз болашақта) қайта құруға уәде берді.

• Егер дерекқор конфигурациясы мұны көрсетсе LC_MESSAGES (мәтіндік хабарлар) Юникодты пайдалануға болады, мысалы. ru_RU.UTF-8, содан кейін іске қосу кезінде postgres тіл UTF-8 емес ортада, айталық бос ортада (мұнда кардиостимулятор+pgsqlms(paf) жүгіреді postgres), содан кейін журналда UTF-8 әріптерінің орнына сұрақ белгілері болады. PostgreSQL әзірлеушілері бұл жағдайда не істеу керектігін келіскен жоқ. Бұл қымбат, орнату керек LC_MESSAGES=en_US.UTF-8 дерекқор данасын конфигурациялау (жасау) кезінде.

• Егер wal_receiver_timeout орнатылса (әдепкі бойынша ол 60с), онда tuchanka3 және tuchanka4 кластерлеріндегі мастерде PostgreSQL-STOP сынағы кезінде репликация жаңа шеберге қайта қосылмайды. Ол жерде репликация синхронды болады, сондықтан құл ғана емес, жаңа шебер де тоқтайды. PostgreSQL конфигурациялау кезінде wal_receiver_timeout=0 орнату арқылы жұмыс істейді.

• Кейде ForkBomb сынағында PostgreSQL-де репликацияның қатып қалғанын байқадым (жадтың толып кетуі). ForkBomb кейін кейде құлдар жаңа шеберге қайта қосылмауы мүмкін. Мен мұны тек tuchanka3 және tuchanka4 кластерлерінде кездестірдім, мұнда шебер синхронды репликацияға байланысты қатып қалды. Мәселе ұзақ уақыт өткеннен кейін (шамамен екі сағат) өздігінен жойылды. Мұны түзету үшін қосымша зерттеулер қажет. Симптомдар басқа себеппен туындаған алдыңғы қатеге ұқсас, бірақ бірдей салдары бар.

Кроганнан алынған сурет Девиантты өнер автордың рұқсатымен:

Ақпарат көзі: www.habr.com