тааныштыруу

Бир нече убакыт мурун мага өчүрүү кластерин иштеп чыгуу тапшырмасы берилген PostgreSQL, бир шаардын ичинде оптикалык була менен туташтырылган бир нече маалымат борборлорунда иштейт жана бир маалымат борборунун иштен чыгышына (мисалы, өчүрүү) туруштук бере алат. Мүчүлүштүккө чыдамдуулук үчүн жооптуу программа катары мен тандадым электрокардиостимуляторгоанткени бул иштебей калган кластерлерди түзүү үчүн RedHatтын расмий чечими. Бул жакшы, анткени RedHat ага колдоо көрсөтөт жана бул чечим универсалдуу (модулдук). Анын жардамы менен бир гана PostgreSQL эмес, башка кызматтардын да каталарга чыдамдуулугун камсыз кылууга болот, же стандарттык модулдарды колдонуу же аларды белгилүү бир муктаждыктар үчүн түзүү.

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

Азыр жетекчилик уруксат берди MIT лицензиясы боюнча ачык булак коомчулугуна долбоорду ачуу. README жакында англис тилине которулат (анткени негизги керектөөчүлөр Pacemaker жана PostgreSQL иштеп чыгуучулары болот деп күтүлүүдө) жана мен READMEнин эски орус версиясын (жарым-жартылай) ушул макаланын түрүндө берүүнү чечтим.

Кластерлер виртуалдык машиналарда жайгаштырылат VirtualBox. Бардыгы болуп 12 виртуалдык машина (жалпысынан 36GiB) жайгаштырылат, алар каталарга чыдамдуу 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 (float IP). Бул кардиостимулятор түйүндөрдүн айланасында кыймылдай турган IP'лер (баары жалпак тармакта). Алардын ар бири ресурсту (кызматты) символдоштурат жана бул кызматка (биздин учурда маалымат базасы) жетүү үчүн туташуу керек жерде жайгашат.

Tuchanka1 (жыйноо менен схема)

түзүлүш

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

Ар бир маалымат борборунда бирден сервер бар. Ар бир серверде эки PostgreSQL инстанциясы бар (PostgreSQL терминологиясында алар кластерлер деп аталат, бирок башаламандыкка жол бербөө үчүн мен аларды инстанциялар деп атайм (башка маалымат базаларына окшоштук боюнча) жана мен бир гана Pacemaker кластерлерин кластер деп атайм). Бир инстанция мастер режиминде иштейт жана ал гана кызматтарды көрсөтөт (ага калкып чыгуучу IP гана алып келет). Экинчи инстанция экинчи маалымат борборунун кулу катары иштейт жана анын кожоюну иштебей калса гана кызматтарды көрсөтөт. Көбүнчө эки инстанциянын бир гана инстанциясы (мастер) кызматтарды көрсөтө тургандыктан (суроолорду аткарат), бардык сервер ресурстары мастер үчүн оптималдаштырылган (эс тутум shared_buffers кэшине бөлүнгөн, ж.б.), бирок экинчи инстанция маалымат борборлорунун бири иштен чыккан учурда жетиштүү ресурстарга ээ (файл тутумунун кэши аркылуу оптималдуу эмес иштеши үчүн). Кул бир эле машинада кожоюн менен ресурстар үчүн согуш болбошу үчүн кластердин нормалдуу иштеши учурунда кызматтарды көрсөтпөйт (окуу үчүн гана суроо-талаптарды аткарбайт).

Эки түйүндөрдө катага толеранттуулук асинхрондуу репликацияда гана мүмкүн, анткени синхрондуу репликацияда кулдун иштебей калышы кожоюндун токтошуна алып келет.

Күбө болбоо

күбө болбоо (кворум түзмөк) Мен Tuchanka1 кластери үчүн гана карап чыгам, калгандары менен ал бир эле окуя болот. Күбө болбой калса, кластердик структурада эч нерсе өзгөрбөйт, баары мурдагыдай иштей берет. Бирок кворум 2төн 3 болуп калат, демек, кийинки ийгиликсиздик кластер үчүн өлүмгө алып келет. Аны дагы тез арада оңдоо керек болот.

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

Tuchanka1 үчүн маалымат борборлорунун биринин иштен чыгышы. Бул учурда күбө добушун экинчи маалымат борборундагы экинчи түйүнгө берет. Ал жерде мурунку кул кожоюнга айланат, натыйжада эки кожоюн тең бир серверде иштешет жана алардын эки калкып турган IP даректери аларды көрсөтөт.

Tuchanka2 (классикалык)

түзүлүш

Эки түйүндөрдүн классикалык схемасы. Биринде кожоюн, экинчисинде кул иштейт. Экөө тең сурамдарды аткара алат (кул окуу үчүн гана), андыктан экөө тең калкыма 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 маалымат борбору)

түзүлүш

Бул үч толук иштеген маалымат борбору бар кырдаал үчүн кластер, алардын ар биринде толук иштеген маалымат базасы сервери бар. Бул учурда кворум түзмөк кереги жок. Бир маалымат борборунда мастер, калган экөө кулдар менен иштейт. Репликация синхрондуу, ANY түрү (кул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.

Терминал текшерилип жаткан кластерлердин санына жараша тилкелерге бөлүнгөн; демейки боюнча (скриншотто) төртөө бар. Мен мамычалардын мазмунун Tuchanka2 мисалында сүрөттөп берем. Скриншоттогу панелдер номерленген:

1. Сынактын статистикасы бул жерде көрсөтүлөт. Мамычалар:
   • ката — катаны эмуляциялаган тесттин аталышы (скрипттеги функция).
   • жооп — кластер өз функцияларын калыбына келтирген секунддардагы орточо арифметикалык убакыт. Ал катаны эмуляциялоочу скрипт башталгандан баштап кластер өзүнүн функционалдуулугун калыбына келтирип, кызматтарды көрсөтүүнү уланта алган учурга чейин өлчөнөт. Убакыт өтө кыска болсо, мисалы, алты секунд (бул бир нече кулдары бар кластерлерде болот (Tuchanka3 жана Tuchanka4)), бул ката асинхрондук кулда болгон жана эч кандай түрдө аткарууга таасир эткен эмес дегенди билдирет; кластердик абалды өчүргүчтөр.
   • бир жакка жантаюу — нарктын таралышын (тактыгын) көрсөтөт жооп стандарттык четтөө ыкмасын колдонуу.
   • эсептөө — бул сыноо канча жолу жасалган.
2. Кыска журнал кластер учурда эмне кылып жатканын баалоого мүмкүндүк берет. Итерация (сыноо) номери, убакыт белгиси жана операциянын аталышы көрсөтүлөт. Өтө узакка чуркоо (> 5 мүнөт) көйгөйдү көрсөтүп турат.
3. жүрөк (жүрөк) - учурдагы убакыт. Ишти визуалдык баалоо үчүн мастерлер Учурдагы убакыт калкып чыгуучу IP мастерди колдонуп, анын таблицасына дайыма жазылып турат. Эгер ийгиликтүү болсо, натыйжа бул панелде көрсөтүлөт.
4. сабап, (импульс) - мурда сценарий менен жазылган "учурдагы убакыт" жүрөк өздөштүрүү, азыр андан оку кул анын калкыма IP аркылуу. Кулдун жана репликациянын иштешин визуалдык баалоого мүмкүндүк берет. Tuchanka1де калкып чыкма IP бар кулдар жок (кызмат көрсөтүүчү кулдар жок), бирок эки инстанция (МБ) бар, андыктан ал бул жерде көрсөтүлбөйт сабап,жана жүрөк экинчи инстанция.
5. Утилитаны колдонуу менен кластердин ден соолугуна мониторинг жүргүзүү pcs mon. Түзүмүн, ресурстардын түйүндөр боюнча бөлүштүрүлүшүн жана башка пайдалуу маалыматтарды көрсөтөт.
6. Бул жерде кластердеги ар бир виртуалдык машинадан системанын мониторинги көрсөтүлөт. Кластерде канча виртуалдык машина бар экенине жараша мындай панелдер көбүрөөк болушу мүмкүн. Эки график CPU жүктөө (виртуалдык машиналарда эки процессор бар), виртуалдык машинанын аталышы, Системаны жүктөө (5, 10 жана 15 мүнөттүн ичинде орточо болуп эсептелгендиктен Load Average деп аталат), маалыматтарды жана эстутумду бөлүштүрүү.
7. Сценарийдин изи. Мүчүлүштүк болгондо - күтүлбөгөн жерден иштөө же чексиз күтүү цикли - бул жерде сиз бул жүрүм-турумдун себебин көрө аласыз.

Сыноо эки этапта жүргүзүлөт. Биринчиден, скрипт тесттердин бардык түрлөрүнөн өтүп, бул тестти колдонуу үчүн виртуалдык машинаны туш келди тандап алат. Андан кийин чексиз тестирлөө цикли аткарылып, виртуалдык машиналар жана ката ар бир жолу туш келди тандалып алынат. Сыноо скриптинин капысынан токтотулушу (төмөнкү панель) же бир нерсени күтүүнүн чексиз цикли (бир операция үчүн > 5 мүнөт аткаруу убактысы, муну изден көрүүгө болот) бул кластердеги кээ бир сыноолор ишке ашпай калганын көрсөтүп турат.

Ар бир тест төмөнкү операциялардан турат:

1. Мүчүлүштүктөрдү эмуляциялоочу функцияны ишке киргизиңиз.
2. Даярсызбы? — кластердин калыбына келишин күтүү (бардык кызматтар көрсөтүлгөндө).
3. Кластерди калыбына келтирүү таймаутун көрсөтөт (жооп).
4. бекитүү — кластер «ремонттолуп жатат». Андан кийин ал толугу менен иштөө абалына кайтып, кийинки бузулууга даяр болушу керек.

Бул жерде тесттердин тизмеси, алар эмне кылышы керек:

• 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, система акырындык менен жабылат.
• Unlink: тармактык изоляция, буйрук VBoxManage controlvm "виртуалка" setlinkstate1 off.

Стандарттык tmux буйругу "kill-window" аркылуу тестирлөө бүтүрүү Ctrl-b &, же "ажыратуу-кардар" буйругу Ctrl-b d: бул учурда тестирлөө аяктайт, tmux жабылат, виртуалдык машиналар өчүрүлөт.

Сыноо учурунда аныкталган көйгөйлөр

• Азыркы учурда күзөтчү жин сбд байкалган демондорду токтотуунун үстүндө иштейт, бирок аларды тоңдурбайт. Жана, натыйжада, үшүккө гана алып келген каталар Corosync и электрокардиостимуляторго, бирок илинбейт сбд. Текшерүү үчүн Corosync бар PR#83 (GitHub боюнча сбд), жипке кабыл алынды кожоюн. Алар (PR#83-те) Кардиостимулятордо ушундай нерсе болот деп убада беришти, мен ишенем Кызыл калпак 8 кылат. Бирок мындай "бузуулар" спекуляция болуп саналат жана аларды оңой эле жасалма жол менен окшоштурса болот, мисалы, killall -STOP corosync, бирок чыныгы жашоодо жолукпайм.

• У электрокардиостимуляторго үчүн версиясында CentOS 7 туура эмес коюлган sync_timeout у кворум түзмөк, Натыйжада бир түйүн иштебей калса, экинчи түйүн дагы кайра жүктөлөт, ага кожоюн көчүшү керек болчу. Чоңойтуу жолу менен айыгат sync_timeout у кворум түзмөк жайылтуу учурунда (скрипт боюнча setup/setup1). Бул түзөтүү иштеп чыгуучулар тарабынан кабыл алынган эмес электрокардиостимуляторго, анын ордуна алар инфраструктураны (кээ бир такталбаган келечекте) бул күтүү убакыты автоматтык түрдө эсептеле тургандай кылып кайра конструкциялоого убада беришти.

• Эгерде маалымат базасынын конфигурациясы муну аныктаса LC_MESSAGES (тексттик билдирүүлөр) Юникод колдонсо болот, мис. ru_RU.UTF-8, андан кийин ишке киргизүүдө postgres жергиликтүү тил UTF-8 эмес чөйрөдө, айталы, бош чөйрөдө (бул жерде электрокардиостимуляторго+pgsqlms(паф) чуркайт 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 кластерлеринде гана жолуктурдум, анда мастер синхрондук репликациядан улам катып калган. Көйгөй бир топ убакыттан кийин (эки саатка жакын) өзүнөн өзү кетти. Муну оңдоо үчүн дагы изилдөө керек. Симптомдору мурунку катага окшош, ал башка себеп менен пайда болот, бирок ошол эле кесепеттерге алып келет.

Крогандан алынган сүрөт адашкан Art автордун уруксаты менен:

Source: www.habr.com