Patroni негізгі мақсаты - PostgreSQL үшін жоғары қолжетімділікті қамтамасыз ету. Бірақ Патрони - бұл дайын құрал емес, жай шаблон (ол, жалпы алғанда, құжаттамада айтылған). Бір қарағанда, Patroni-ны сынақ зертханасында орнатқаннан кейін сіз оның қандай тамаша құрал екенін және оның кластерді бұзу әрекеттерін қаншалықты оңай басқаратынын көре аласыз. Дегенмен, іс жүзінде, өндірістік ортада бәрі сынақ зертханасындағыдай әдемі және талғампаз бола бермейді.
Мен өзім туралы аздап айтып беремін. Мен жүйелік әкімші болып бастадым. Веб әзірлеуде жұмыс істеді. Мен Data Egret компаниясында 2014 жылдан бері жұмыс істеймін. Компания Postgres саласында кеңес берумен айналысады. Біз дәл Postgres-ке қызмет етеміз және біз Postgres-пен күн сайын жұмыс істейміз, сондықтан операцияға қатысты әртүрлі тәжірибеміз бар.
Ал 2018 жылдың соңында біз Patroni-ді баяу пайдалана бастадық. Және біраз тәжірибе жинақталды. Біз әйтеуір диагноз қойдық, баптадық, озық тәжірибемізге келдік. Және бұл баяндамада мен олар туралы айтатын боламын.
Postgres-тен басқа мен Linux-ті жақсы көремін. Мен оны сүзіп, зерттегенді ұнатамын, мен өзектерді жинағанды ұнатамын. Маған виртуализация, контейнерлер, докер, Кубернетес ұнайды. Мұның бәрі мені қызықтырады, өйткені ескі әкімші әдеттер әсер етеді. Мен мониторингпен айналысқанды ұнатамын. Мен әкімшілікке қатысты постгресті жақсы көремін, яғни репликация, сақтық көшірме. Ал бос уақытымда Go-да жазамын. Мен бағдарламалық жасақтама инженері емеспін, мен Go бағдарламасында өзім үшін жазамын. Және бұл маған рахат сыйлайды.
- Менің ойымша, сіздердің көпшілігіңіз Postgres-те HA (жоғары қолжетімділік) жоқ екенін білесіздер. HA алу үшін бірдеңені орнату, конфигурациялау, күш салу және оны алу керек.
- Бірнеше құралдар бар және Patroni олардың бірі HA-ны өте керемет және өте жақсы шешеді. Бірақ мұның бәрін сынақ зертханасына қою және оны іске қосу арқылы біз мұның бәрі жұмыс істейтінін көреміз, кейбір мәселелерді қайта шығара аламыз, Patroni оларға қалай қызмет көрсететінін көре аламыз. Және біз бәрі тамаша жұмыс істейтінін көреміз.
- Бірақ іс жүзінде біз әртүрлі мәселелерге тап болдық. Және мен бұл мәселелер туралы айтатын боламын.
- Мен сізге қалай диагноз қойғанымызды, нені өзгерткенімізді айтып беремін - бұл бізге көмектесті ме, жоқ па.
- Мен сізге Patroni қалай орнату керектігін айтпаймын, өйткені сіз Интернетте google-ді таба аласыз, бәрі қалай басталатынын, қалай конфигурацияланғанын түсіну үшін конфигурация файлдарын қарауға болады. Интернеттен ол туралы ақпаратты таба отырып, схемаларды, архитектураларды түсінуге болады.
- Мен басқа біреудің тәжірибесі туралы айтпаймын. Мен тек бастан кешкен мәселелер туралы айтамын.
- Мен Patroni және PostgreSQL-тен тыс мәселелер туралы айтпаймын. Егер, мысалы, баланстауға байланысты проблемалар туындаса, біздің кластеріміз құлдыраған кезде, мен бұл туралы айтпаймын.
Есепті бастамас бұрын шағын ескерту.
Біз кездестірген осы мәселелердің барлығы бізде жұмыстың алғашқы 6-7-8 айында болды. Уақыт өте келе біз ішкі озық тәжірибемізге жеттік. Ал біздің проблемаларымыз жойылды. Сондықтан, есеп жарты жыл бұрын жарияланған болатын, ол менің ойымда жаңа болды және мен оның барлығын жақсы есте сақтадым.
Баяндаманы дайындау барысында мен ескі өлгеннен кейінгілерді көтердім, журналдарды қарадым. Ал кейбір детальдар ұмытылып қалуы мүмкін, немесе проблемаларды талдау барысында кейбір мәліметтер толық зерттелмей қалуы мүмкін, сондықтан кей тұстарда мәселелер толық қарастырылмаған немесе ақпараттың аздығы сияқты көрінуі мүмкін. Сондықтан осы сәт үшін кешірім сұраймын.
Патрони дегеніміз не?
- Бұл HA құруға арналған үлгі. Бұл құжаттамада айтылған. Ал менің көзқарасым бойынша, бұл өте дұрыс түсініктеме. Патрони сіздің барлық мәселелеріңізді шешетін күміс оқ емес, яғни оның жұмыс істеп, пайда әкелуіне күш салу керек.
- Бұл әрбір дерекқор қызметіне орнатылған агент қызметі және Postgres үшін бастапқы жүйенің бір түрі болып табылады. Ол Postgres бағдарламасын іске қосады, тоқтатады, қайта іске қосады, қайта конфигурациялайды және кластердің топологиясын өзгертеді.
- Сәйкесінше, кластердің күйін, оның ағымдағы көрінісін сақтау үшін, қандай да бір сақтау түрі қажет. Және осы тұрғыдан алғанда Патрони сыртқы жүйеде күйді сақтау жолын ұстанды. Бұл таратылған конфигурацияны сақтау жүйесі. Бұл Etcd, Consul, ZooKeeper немесе kubernetes Etcd болуы мүмкін, яғни осы опциялардың бірі.
- Patroni мүмкіндіктерінің бірі - сіз автофиляторды қораптан тек оны орнату арқылы аласыз. Салыстыру үшін Repmgr-ді алсақ, онда филер сонда қосылады. Repmgr көмегімен біз ауысуды аламыз, бірақ біз автофилер қажет болса, оны қосымша конфигурациялауымыз керек. Patroni-де автоматты толтырғыш бар.
- Және басқа да көптеген нәрселер бар. Мысалы, конфигурацияларға қызмет көрсету, жаңа көшірмелерді құю, сақтық көшірме жасау, т.б.. Бірақ бұл есептің ауқымынан тыс, мен бұл туралы айтпаймын.
Кішкентай нәтиже - бұл біздің кластер жұмыс істеп тұруы үшін және қолданба кластер топологиясындағы өзгерістерді байқамауы үшін Patroni-нің негізгі міндеті - автофайлды жақсы және сенімді орындау.
Бірақ біз Patroni пайдалануды бастағанда, біздің жүйе біршама күрделене түседі. Егер бұрын бізде Postgres болса, Patroni-ны пайдаланған кезде біз Patroni-нің өзін аламыз, күй сақталған жерде DCS аламыз. Және бәрі қандай да бір жолмен жұмыс істеуі керек. Сонымен не дұрыс емес болуы мүмкін?
Бұзылуы мүмкін:
- Postgres бұзылуы мүмкін. Бұл шебер немесе көшірме болуы мүмкін, олардың біреуі сәтсіздікке ұшырауы мүмкін.
- Патронидің өзі сынуы мүмкін.
- Күй сақталатын DCS үзілуі мүмкін.
- Ал желі үзілуі мүмкін.
Осы тармақтардың барлығын мен есепте қарастырамын.
Мен істерді істің көптеген құрамдас бөліктерін қамтитыны тұрғысынан емес, олар күрделене түскен сайын қарастырамын. Ал субъективті сезім тұрғысынан алғанда, бұл іс маған қиын болды, оны бөлшектеу қиын болды ... және керісінше, кейбір іс жеңіл болды және оны бөлшектеу оңай болды.
Ал бірінші жағдай ең оңай. Бұл дерекқор кластерін алып, DCS қоймасын сол кластерде орналастырған кездегі жағдай. Бұл ең көп тараған қате. Бұл архитектураны құрудағы қате, яғни әртүрлі компоненттерді бір жерде біріктіру.
Сонымен, филер болды, не болғанын шешуге барайық.
Бұл жерде бізді файлдың қашан болғаны қызықтырады. Яғни, бізді кластер күйінің өзгерген осы сәті қызықтырады.
Бірақ толтырғыш әрқашан лезде болмайды, яғни уақыт бірлігін қажет етпейді, оны кейінге қалдыруға болады. Ол ұзақ уақытқа созылуы мүмкін.
Сондықтан оның басталу уақыты мен аяқталу уақыты бар, яғни бұл үздіксіз оқиға. Және біз барлық оқиғаларды үш интервалға бөлеміз: толтырғышқа дейін, толтырғыш кезінде және файлдан кейін уақыт бар. Яғни, біз осы уақыт шкаласында барлық оқиғаларды қарастырамыз.
Біріншіден, филер болған кезде, біз не болғанын іздейміз, файлға не себеп болды.
Бөренелерге қарасақ, олар классикалық Patroni журналдары болады. Ол бізге сервердің шеберге айналғанын, ал шебердің рөлі осы түйінге өткенін айтады. Мұнда ол ерекшеленген.
Әрі қарай, файлдың неліктен орын алғанын, яғни басты рөлдің бір түйіннен екіншісіне ауысуына себеп болған қандай оқиғалар болғанын түсінуіміз керек. Және бұл жағдайда бәрі қарапайым. Сақтау жүйесімен әрекеттесуде қате бар. Шебер DCS-пен жұмыс істей алмайтынын түсінді, яғни өзара әрекеттесу кезінде қандай да бір мәселе бар. Ал енді шебер бола алмайтынын айтып, жұмыстан кетеді. Бұл «төмендетілген өзін-өзі» сызығы дәл осылай айтады.
Егер біз файлдың алдындағы оқиғаларды қарастырсақ, онда шеберді жалғастыру үшін ақаулық тудырған себептерді көре аламыз.
Егер біз Patroni журналдарына қарасақ, бізде көптеген қателер, күту уақыттары бар екенін көреміз, яғни Patroni агенті DCS-пен жұмыс істей алмайды. Бұл жағдайда бұл 8500 портында байланысатын консул агенті.
Бұл жерде мәселе Patroni мен дерекқордың бір хостта жұмыс істеуінде. Ал Консул серверлері сол түйінде іске қосылды. Серверге жүктеме жасау арқылы біз консулдық серверлер үшін де проблемалар тудырдық. Олар дұрыс сөйлесе алмады.
Біраз уақыттан кейін, жүктеме басылғанда, біздің Патрони агенттермен қайтадан байланыса алды. Қалыпты жұмыс қайта жалғасты. Және сол Pgdb-2 сервері қайтадан шебер болды. Яғни, кішігірім флип болды, соның салдарынан түйін шебердің өкілеттіктерінен бас тартты, содан кейін оларды қайтадан қабылдады, яғни бәрі бұрынғыдай болды.
Мұны жалған дабыл деп санауға болады немесе Патрони бәрін дұрыс жасады деп санауға болады. Яғни, кластердің жағдайын сақтай алмайтынын түсініп, билігін алып тастады.
Бұл жерде мәселе консулдық серверлердің базалармен бірдей аппараттық құралда болуына байланысты туындады. Тиісінше, кез келген жүктеме: дискілердегі немесе процессорлардағы жүктеме болсын, ол Консул кластерімен өзара әрекеттесуге де әсер етеді.
Ал біз бірге тұруға болмайды деп шештік, Консулға бөлек кластер бөлдік. Ал Патрони бөлек Консулмен жұмыс істеп жүрді, яғни бөлек Postgres кластері, бөлек Консул кластері болды. Бұл бірге өмір сүрмеу үшін осы заттардың барлығын қалай алып жүру және сақтау туралы негізгі нұсқаулық.
Опция ретінде сіз ttl, loop_wait, retry_timeout параметрлерін бұра аласыз, яғни осы параметрлерді арттыру арқылы осы қысқа мерзімді жүктеме шыңдарынан аман қалуға тырысыңыз. Бірақ бұл ең қолайлы нұсқа емес, өйткені бұл жүктеме уақыт өте ұзақ болуы мүмкін. Және біз жай ғана осы параметрлердің осы шегінен шығамыз. Және бұл шынымен көмектеспеуі мүмкін.
Бірінші мәселе, сіз түсінгендей, қарапайым. Біз DCS алып, базамен бірге қойдық, мәселе туындады.
Екінші мәселе біріншіге ұқсас. Осыған ұқсас, бізде DCS жүйесімен өзара әрекеттесу проблемалары тағы бар.
Егер журналдарға қарасақ, бізде тағы да байланыс қатесі бар екенін көреміз. Ал Патрони менің DCS-пен әрекеттесе алмайтынымды айтады, сондықтан ағымдағы шебер реплика режиміне өтеді.
Ескі шебер репликаға айналады, мұнда Патрони жұмыс істейді, солай болуы керек. Ол транзакциялар журналын кері айналдыру үшін pg_rewind іске қосады, содан кейін жаңа шеберді қуып жету үшін жаңа шеберге қосылады. Мұнда Патрони жұмыс істейді.
Мұнда біз файлдан бұрын болған орынды табуымыз керек, яғни файлдың болуын тудырған қателер. Осыған байланысты Patroni журналдарымен жұмыс істеу өте ыңғайлы. Ол белгілі бір аралықта бірдей хабарламаларды жазады. Ал егер біз бұл журналдарды жылдам айналдыра бастасақ, онда журналдардан журналдардың өзгергенін көреміз, бұл кейбір мәселелердің басталғанын білдіреді. Біз бұл жерге тез ораламыз, не болғанын көреміз.
Ал қалыпты жағдайда бөренелер осындай көрінеді. Құлыптың иесі тексеріледі. Ал егер иесі, мысалы, өзгерген болса, онда Патрони жауап беруі керек кейбір оқиғалар орын алуы мүмкін. Бірақ бұл жағдайда біз жақсымыз. Біз қателер басталған жерді іздейміз.
Қателер пайда бола бастаған нүктеге жылжып, бізде автоматты файлды ауыстыру болғанын көреміз. Біздің қателіктеріміз DCS-пен өзара әрекеттесумен байланысты болғандықтан және біздің жағдайда біз Консулды пайдаландық, біз консулдық журналдарды да қараймыз, онда не болды.
Құжаттар мен консулдық журналдардағы уақытты шамамен салыстыра отырып, біз консулдық кластердегі көршілеріміз консулдық кластердің басқа мүшелерінің бар екеніне күмән келтіре бастағанын көреміз.
Егер сіз басқа консулдық агенттердің журналдарына қарасаңыз, онда желілік құлдыраудың қандай да бір түрі орын алып жатқанын көруге болады. Ал консулдық кластердің барлық мүшелері бір-бірінің бар екеніне күмәнданады. Бұл филер үшін серпін болды.
Егер сіз осы қателіктерге дейін болған жағдайды қарасаңыз, қателердің барлық түрлері бар екенін көруге болады, мысалы, мерзімі, RPC төмендеді, яғни консулдық кластер мүшелерінің бір-бірімен өзара әрекеттесуінде қандай да бір мәселе бар екені анық. .
Ең қарапайым жауап - желіні жөндеу. Бірақ жеңіс тұғырында тұрған мен үшін мұны айту оңай. Бірақ жағдай тұтынушылардың желіні жөндеуге әрқашан мүмкіндігі бола бермейді. Ол тұрақты токта тұруы мүмкін және желіні жөндей алмауы, жабдыққа әсер етуі мүмкін. Сондықтан басқа опциялар қажет.
Опциялар бар:
- Менің ойымша, құжаттамада жазылған ең қарапайым нұсқа - бұл консулдық тексерулерді өшіру, яғни бос массивтен өту. Біз консул агентіне ешқандай чек қолданбауын айтамыз. Осы тексерулер арқылы біз бұл желілік дауылдарды елемей, файлды іске қоспай аламыз.
- Тағы бір нұсқа - raft_multiplier параметрін екі рет тексеру. Бұл Консул серверінің өзінің параметрі. Әдепкі бойынша, ол 5 мәніне орнатылады. Бұл мән кезеңдік орталарға арналған құжаттамада ұсынылады. Шын мәнінде, бұл Консул желісінің мүшелері арасындағы хабар алмасу жиілігіне әсер етеді. Іс жүзінде бұл параметр консулдық кластер мүшелерінің арасындағы қызметтік байланыстың жылдамдығына әсер етеді. Ал өндіріс үшін түйіндер хабарламаларды жиі алмасуы үшін оны азайту ұсынылады.
- Біз ойлап тапқан тағы бір нұсқа операциялық жүйенің процесс жоспарлаушысы үшін басқа процестер арасында Консул процестерінің басымдылығын арттыру болып табылады. Мұндай «жақсы» параметр бар, ол жоспарлау кезінде ОЖ жоспарлаушысы ескеретін процестердің басымдығын анықтайды. Біз сондай-ақ консул агенттері үшін жақсы құндылықты төмендеттік, яғни. операциялық жүйе Консул процестеріне жұмыс істеуге және олардың кодын орындауға көбірек уақыт беруі үшін басымдылықты арттырды. Біздің жағдайда бұл біздің мәселемізді шешті.
- Басқа нұсқа - консулды пайдаланбау. Менің досым бар, ол Etcd-тің үлкен қолдаушысы. Біз онымен үнемі айтысамыз, қайсысы жақсы Etcd немесе Консул. Бірақ қайсысы жақсы деген сұраққа біз әдетте консулдың дерекқоры бар әрбір түйінде жұмыс істейтін агенті бар екендігімен келісеміз. Яғни, Патронидің Консул кластерімен әрекеттесуі осы агент арқылы өтеді. Және бұл агент тығырыққа айналады. Егер агентпен бірдеңе болса, Патрони бұдан былай Консул кластерімен жұмыс істей алмайды. Ал бұл мәселе. Etcd жоспарында агент жоқ. Patroni Etcd серверлерінің тізімімен тікелей жұмыс істей алады және олармен байланыса алады. Осыған байланысты, егер сіз өзіңіздің компанияңызда Etcd қолдансаңыз, онда Etcd Консулға қарағанда жақсы таңдау болуы мүмкін. Бірақ біз өз клиенттерімізде әрқашан клиент таңдаған және пайдаланатын нәрселермен шектелеміз. Бізде барлық клиенттер үшін консул бар.
- Және соңғы нүкте - параметр мәндерін қайта қарау. Біздің қысқа мерзімді желілік проблемаларымыз қысқа болады және осы параметрлер ауқымынан тыс қалмайды деген үмітпен бұл параметрлерді көтере аламыз. Осылайша, кейбір желі ақаулары орын алса, біз Patroni қолданбасының автофайлға агрессивтілігін азайта аламыз.
Менің ойымша, Patroni пайдаланатындардың көпшілігі бұл командамен таныс.
Бұл пәрмен кластердің ағымдағы күйін көрсетеді. Ал бір қарағанда бұл сурет қалыпты болып көрінуі мүмкін. Бізде шебер бар, бізде реплика бар, репликацияның артта қалуы жоқ. Бірақ бұл кластерде екі емес, үш түйін болуы керек екенін білмейінше, бұл сурет қалыпты.
Сәйкесінше, автофайл болды. Осы автофайлдан кейін біздің көшірме жоғалып кетті. Неліктен жоғалып кеткенін анықтап, оны қайтару, қалпына келтіру керек. Біз тағы да журналдарға барып, неліктен бізде автоматты файлды ауыстыру болғанын көреміз.
Бұл жағдайда екінші көшірме шебер болды. Мұнда бәрі жақсы.
Ал біз кластерде жоқ және құлаған көшірмені қарауымыз керек. Біз Patroni журналдарын ашамыз және pg_rewind сатысында кластерге қосылу процесінде мәселе туындағанын көреміз. Кластерге қосылу үшін транзакциялар журналын кері айналдыру, шеберден қажетті транзакция журналын сұрау және оны шеберді қуып жету үшін пайдалану қажет.
Бұл жағдайда бізде транзакция журналы жоқ және реплика басталмайды. Тиісінше, біз Postgres-ті қатемен тоқтатамыз. Сондықтан ол кластерде жоқ.
Неліктен оның кластерде жоқ екенін және неге журналдар болмағанын түсінуіміз керек. Біз жаңа шеберге барып, оның бөренелерде не бар екенін көреміз. pg_rewind орындалған кезде бақылау нүктесі пайда болды. Ал кейбір ескі транзакция журналдары жай ғана атауын өзгертті. Ескі шебер жаңа шеберге қосылуға және осы журналдарды сұрауға тырысқанда, олар әлдеқашан аталды, олар жай ғана жоқ болды.
Мен бұл оқиғалар болған кезде уақыт белгілерін салыстырдым. Мұнда айырмашылық 150 миллисекундты құрайды, яғни бақылау нүктесі 369 миллисекундта аяқталды, WAL сегменттері қайта аталды. 517-де, 150 миллисекундтан кейін, ескі көшірмеде кері айналдыру басталды. Яғни, реплика қосылып, табыс таба алмау үшін бізге 150 миллисекунд жеткілікті болды.
Опциялар қандай?
Біз бастапқыда репликация слоттарын қолдандық. Жақсы деп ойладық. Жұмыстың бірінші кезеңінде біз слоттарды өшірдік. Бізге, егер ұяшықтар WAL сегменттерін көп жинақтаса, біз шеберді тастай аламыз. Ол құлап қалады. Біраз уақыт слотсыз қиналдық. Біз слоттар қажет екенін түсіндік, біз слоттарды қайтардық.
Бірақ мұнда мәселе бар, ол репликаға өткенде, ол слоттарды жояды және ұялармен бірге WAL сегменттерін жояды. Және бұл мәселені жою үшін біз wal_keep_segments параметрін көтеруді шештік. Ол әдепкі бойынша 8 сегментке арналған. Біз оны 1-ға дейін көтеріп, қанша бос орын бар екенін қарадық. Біз wal_keep_segments үшін 000 гигабайт бердік. Яғни, ауысу кезінде бізде әрқашан барлық түйіндерде транзакция журналдарының 16 гигабайт резерві болады.
Және плюс - бұл ұзақ мерзімді техникалық қызмет көрсету тапсырмалары үшін әлі де өзекті. Көшірмелердің бірін жаңарту керек делік. Ал біз оны өшіргіміз келеді. Біз бағдарламалық жасақтаманы жаңартуымыз керек, мүмкін операциялық жүйе, басқа нәрсе. Ал репликаны өшірген кезде, сол көшірмеге арналған слот та жойылады. Егер біз кішкентай wal_keep_segments қолданатын болсақ, онда реплика ұзақ уақыт болмаған кезде транзакция журналдары жоғалады. Біз көшірме жасаймыз, ол тоқтаған транзакция журналдарын сұрайды, бірақ олар шеберде болмауы мүмкін. Ал реплика да қосыла алмайды. Сондықтан біз журналдардың үлкен қорын сақтаймыз.
Бізде өндірістік база бар. Қазірдің өзінде жүзеге асырылып жатқан жобалар бар.
Файлшы болды. Біз кіріп, қарадық - бәрі тәртіппен, репликалар орнында, репликацияда лаг жоқ. Журналдарда да қателер жоқ, бәрі тәртіппен.
Өнім тобы кейбір деректер болуы керек дейді, бірақ біз оны бір көзден көреміз, бірақ дерекқорда көрмейміз. Ал біз оларға не болғанын түсінуіміз керек.
pg_rewind оларды жіберіп алғаны анық. Біз мұны бірден түсіндік, бірақ не болып жатқанын көруге бардық.
Журналдарда біз әрқашан файл жасаушының қашан болғанын, кім шебер болғанын таба аламыз және кім ескі шебер болғанын және оның қашан көшірме болғысы келетінін анықтай аламыз, яғни бізге транзакция журналдарының санын білу үшін бұл журналдар қажет. жоғалып кетті.
Біздің ескі шеберіміз қайта іске қосылды. Ал Патрони авторанға тіркелді. Patroni іске қосылды. Содан кейін ол Postgres компаниясын бастады. Дәлірек айтқанда, Postgres қолданбас бұрын және оны көшірме жасамас бұрын, Патрони pg_rewind процесін іске қосты. Тиісінше, ол транзакция журналдарының бір бөлігін өшіріп, жаңаларын жүктеп алып, қосылды. Мұнда Патрони ақылмен жұмыс істеді, яғни күткендей. Кластер қалпына келтірілді. Бізде 3 түйін болды, филерден кейін 3 түйін болды - бәрі керемет.
Біз кейбір деректерді жоғалттық. Ал біз қанша жоғалтқанымызды түсінуіміз керек. Біз кері айналдырған сәтті іздейміз. Біз оны осындай журнал жазбаларынан таба аламыз. Артқа айналдыру басталды, сол жерде бірдеңе жасады және аяқталды.
Біз транзакциялар журналында ескі шебер тоқтаған орынды табуымыз керек. Бұл жағдайда бұл белгі. Ал бізге екінші белгі керек, яғни ескі шебердің жаңадан ерекшеленетін қашықтығы.
Біз әдеттегі pg_wal_lsn_diff аламыз және осы екі белгіні салыстырамыз. Және бұл жағдайда біз 17 мегабайт аламыз. Аз немесе көп, әркім өзі шешеді. Өйткені біреу үшін 17 мегабайт көп емес, біреу үшін бұл көп және қолайсыз. Мұнда әрбір жеке тұлға бизнестің қажеттіліктеріне сәйкес өзі анықтайды.
Бірақ біз өзіміз үшін не білдік?
Біріншіден, біз өзіміз шешуіміз керек - жүйені қайта жүктегеннен кейін автоматты іске қосу үшін Patroni әрқашан қажет пе? Көбінесе ескі қожайынға бару керек, оның қаншалықты алыс кеткенін көру керек. Мүмкін транзакциялар журналының сегменттерін тексеріп, онда не бар екенін көріңіз. Бұл деректерді жоғалтуға болатынын немесе бұл деректерді шығарып алу үшін ескі шеберді оқшау режимде іске қосу керек пе екенін түсіну үшін.
Осыдан кейін ғана біз бұл деректерді алып тастай аламыз ба, әлде оны қалпына келтіре аламыз ба, осы түйінді кластерге көшірме ретінде қосуға болатынын шешуіміз керек.
Бұған қоса, "maximum_lag_on_failover" параметрі бар. Әдепкі бойынша, егер жадым маған қызмет етсе, бұл параметрдің мәні 1 мегабайт болады.
Ол қалай жұмыс істейді? Егер біздің көшірме репликация лагында 1 мегабайт деректерге артта қалса, онда бұл реплика сайлауға қатыспайды. Егер кенеттен файловер пайда болса, Патрони қай көшірмелердің артта қалғанына қарайды. Егер олар транзакция журналдарының көп санымен артта қалса, олар шебер бола алмайды. Бұл көптеген деректерді жоғалтудан сақтайтын өте жақсы қауіпсіздік мүмкіндігі.
Бірақ Patroni кластеріндегі репликацияның артта қалуы және DCS белгілі бір аралықта жаңартылатын мәселе бар. Менің ойымша, 30 секунд әдепкі ttl мәні.
Тиісінше, DCS-де репликалар үшін бір репликация кешігуі болатын жағдай болуы мүмкін, бірақ іс жүзінде мүлде басқа кешігу болуы мүмкін немесе мүлде кешігу болмауы мүмкін, яғни бұл нәрсе нақты уақыт емес. Және ол әрқашан шынайы суретті көрсете бермейді. Және оған қисынды логика жасаудың қажеті жоқ.
Ал жоғалту қаупі әрқашан сақталады. Ал ең нашар жағдайда бір формула, ал орташа жағдайда басқа формула. Яғни, біз Patroni енгізуді жоспарлағанда және қанша деректерді жоғалтуға болатынын бағалағанда, біз осы формулаларға сүйеніп, қанша деректерді жоғалтуымыз мүмкін екенін елестетуіміз керек.
Және жақсы жаңалық бар. Ескі шебер алға кеткенде, ол кейбір фондық процестерге байланысты алға кете алады. Яғни, автовакуумның қандай да бір түрі болды, ол деректерді жазды, оларды транзакциялар журналына сақтады. Және біз бұл деректерді оңай елемеуіміз және жоғалтуымыз мүмкін. Бұл жерде ешқандай проблема жоқ.
Максимум_lag_on_failover орнатылған болса және файл пайда болса, журналдар осылай көрінеді және жаңа негізгі таңдау қажет. Көшірме өзін сайлауға қатысуға қабілетсіз деп бағалайды. Ал ол көшбасшы үшін жарысқа қатысудан бас тартады. Ол жаңа шебердің таңдалуын күтеді, сонда ол оған қосыла алады. Бұл деректердің жоғалуына қарсы қосымша шара.
Мұнда бізде өз өнімінің Postgres-пен проблемалары бар деп жазған өнім тобы бар. Сонымен қатар, шебердің өзіне қол жеткізу мүмкін емес, себебі ол SSH арқылы қол жетімді емес. Автофайл да болмайды.
Бұл хост қайта жүктеуге мәжбүр болды. Қайта жүктеуге байланысты автоматты файл орын алды, бірақ мен қазір түсінгендей, қолмен автоматты файл жасау мүмкін болды. Қайта жүктеуден кейін біз қазіргі шебермен не болғанын көреміз.
Сонымен бірге, біз дискілерге қатысты проблемалардың бар екенін алдын ала білдік, яғни қайда қазып, нені іздеу керектігін бақылаудан бұрыннан білдік.
Біз postgres журналына кіріп, онда не болып жатқанын көре бастадық. Біз бір, екі, үш секундқа созылатын міндеттемелерді көрдік, бұл қалыпты жағдай емес. Біз автовакуумның өте баяу және біртүрлі іске қосылатынын көрдік. Ал біз дискідегі уақытша файлдарды көрдік. Яғни, бұл дискілердегі ақаулардың барлық көрсеткіштері.
Біз dmesg жүйесін қарастырдық (ядро журналы). Және біз дискілердің бірінде ақаулар бар екенін көрдік. Дискінің ішкі жүйесі Raid бағдарламалық құралы болды. Біз /proc/mdstat қарап, бір диск жетпегенін көрдік. Яғни, 8 дисктен тұратын рейд бар, бізге біреуі жетіспейді. Егер сіз слайдқа мұқият қарасаңыз, онда нәтижеде бізде sde жоқ екенін көре аласыз. Бізде, шартты түрде айтқанда, диск шығып кетті. Бұл диск ақауларын тудырды және Postgres кластерімен жұмыс істеу кезінде қолданбалар да ақауларға тап болды.
Және бұл жағдайда Патрони бізге ешқандай көмек көрсетпес еді, өйткені Патронидің сервердің күйін, дискінің күйін бақылау міндеті жоқ. Ал мұндай жағдайларды сырттан бақылау арқылы қадағалауымыз керек. Біз сыртқы бақылауға диск бақылауын тез қостық.
Және осындай ой болды - қоршау немесе күзетші бағдарламалық қамтамасыз ету бізге көмектесе ала ма? Біз бұл жағдайда ол бізге әрең көмектесетін шығар деп ойладық, өйткені проблемалар кезінде Патрони DCS кластерімен өзара әрекеттесуді жалғастырды және ешқандай проблеманы көрмеді. Яғни, DCS және Patroni тұрғысынан кластермен бәрі жақсы болды, бірақ шын мәнінде дискімен проблемалар болғанымен, деректер базасының қолжетімділігінде проблемалар болды.
Менің ойымша, бұл мен өте ұзақ уақыт бойы зерттеген ең қызықты мәселелердің бірі, мен көптеген журналдарды оқып, қайта таңдадым және оны кластерлік тренажер деп атадым.
Мәселе ескі шебердің қалыпты көшірмеге айналмауында болды, яғни Патрони оны бастады, Патрони бұл түйіннің реплика ретінде бар екенін көрсетті, бірақ сонымен бірге бұл қалыпты көшірме емес. Енді неге екенін көресіз. Мен бұл мәселені талдаудан сақтадым.
Және бәрі қалай басталды? Бұл алдыңғы мәселедегідей, дискілік тежегіштерден басталды. Бізде бір секунд, екі міндеттеме болды.
Байланыстарда үзілістер болды, яғни клиенттер үзілді.
Әртүрлі ауырлықтағы бітелулер болды.
Және, тиісінше, дискінің ішкі жүйесі өте жауап бермейді.
Мен үшін ең жұмбақ нәрсе - дереу өшіру туралы өтініш келді. Postgres-тің үш өшіру режимі бар:
- Біз барлық клиенттердің өздігінен ажыратылуын күткеніміз керемет.
- Клиенттерді ажыратуға мәжбүрлейтін кезде жылдам болады, өйткені біз өшіреміз.
- Және дереу. Бұл жағдайда immediate тіпті клиенттерге өшіруді айтпайды, ол ескертусіз ғана өшеді. Барлық клиенттерге операциялық жүйе қазірдің өзінде RST хабарламасын жібереді (байланыс үзілгені және клиенттің басқа ештеңе ұстамайтыны туралы TCP хабарламасы).
Бұл сигналды кім жіберді? Postgres фондық процестері мұндай сигналдарды бір-біріне жібермейді, яғни бұл kill-9. Олар бір-біріне мұндай нәрселерді жібермейді, олар тек осындай нәрселерге жауап береді, яғни бұл Postgres-тің төтенше қайта іске қосылуы. Оны кім жіберді, білмеймін.
Мен «соңғы» пәрменін қарадым және мен осы серверге бізбен бірге кірген бір адамды көрдім, бірақ мен сұрақ қоюға ұялдым. Мүмкін бұл өлтіру -9 болды. Мен журналдарда kill -9 көретін едім, өйткені Postgres өлтіру -9 қажет болды дейді, бірақ мен оны журналдарда көрмедім.
Әрі қарай қарасам, Патронидің журналға ұзақ уақыт - 54 секунд жазбағанын көрдім. Ал егер екі уақыт белгісін салыстырсақ, шамамен 54 секундта хабарламалар болған жоқ.
Осы уақыт ішінде автофайл болды. Патрони мұнда тағы да тамаша жұмыс жасады. Біздің ескі қожайынымыз қолжетімсіз болды, оған бірдеңе болды. Ал жаңа шеберді сайлау басталды. Мұнда бәрі жақсы болды. Біздің pgsql01 жаңа көшбасшы болды.
Бізде шеберге айналған көшірме бар. Және екінші жауап бар. Ал екінші көшірмеде проблемалар болды. Ол қайта конфигурациялауға тырысты. Менің түсінуімше, ол recovery.conf файлын өзгертуге, Postgres файлын қайта іске қосуға және жаңа шеберге қосылуға тырысты. Ол әр 10 секунд сайын тырысып жатқаны туралы хабарламалар жазады, бірақ ол сәтті емес.
Осы әрекеттер кезінде ескі шеберге дереу өшіру сигналы келеді. Мастер қайта іске қосылды. Сондай-ақ қалпына келтіру тоқтайды, себебі ескі шебер қайта жүктеуге кіріседі. Яғни, реплика оған қосыла алмайды, себебі ол өшіру режимінде.
Бір сәтте ол жұмыс істеді, бірақ репликация басталмады.
Менің болжамым бойынша, recovery.conf файлында ескі негізгі мекенжай болған. Ал жаңа шебер пайда болған кезде, екінші көшірме бұрынғыдай ескі шеберге қосылуға тырысты.
Патрони екінші көшірмеде іске қосылғанда, түйін іске қосылды, бірақ қайталай алмады. Ал репликацияның артта қалуы пайда болды, ол келесідей көрінді. Яғни, барлық үш түйін орнында болды, бірақ екінші түйін артта қалды.
Сонымен қатар, егер сіз жазылған журналдарды қарасаңыз, транзакция журналдары әртүрлі болғандықтан репликацияны бастау мүмкін еместігін көре аласыз. Мастер ұсынатын, recovery.conf ішінде көрсетілген транзакция журналдары біздің ағымдағы түйінге сәйкес келмейді.
Міне, мен қателестім. Мен дұрыс емес шеберге қосылып жатырмыз деген гипотезамды тексеру үшін recovery.conf файлында не бар екенін көруім керек болды. Бірақ содан кейін мен мұнымен айналыстым және бұл менің ойыма келмеді немесе репликаның артта қалғанын және оны қайта толтыру керек екенін көрдім, яғни мен қандай да бір түрде абайсызда жұмыс істедім. Бұл менің қосылым болды.
30 минуттан кейін әкімші келді, яғни мен Патрониді көшірмеде қайта іске қостым. Мен бұған нүкте қойдым, оны қайта толтыру керек деп ойладым. Мен Патрониді қайта іске қосамын, мүмкін жақсы нәрсе шығар деп ойладым. Қалпына келтіру басталды. Ал база тіпті ашылды, ол қосылымдарды қабылдауға дайын болды.
Көшіру басталды. Бірақ бір минуттан кейін ол транзакция журналдары оған сәйкес емес деген қатемен құлап кетті.
Мен қайтадан қайта бастаймын деп ойладым. Мен Patroni-ді қайта іске қостым, мен Postgres-ті қайта іске қоспадым, бірақ деректер базасын сиқырлы түрде іске қосады деген үмітпен Patroni-ны қайта іске қостым.
Репликация қайтадан басталды, бірақ транзакциялар журналындағы белгілер әртүрлі болды, олар алдыңғы бастау әрекетімен бірдей болмады. Қайтадан көшіру тоқтатылды. Ал хабарлама сәл басқаша болды. Және бұл мен үшін өте мазмұнды болмады.
Содан кейін менің ойыма бұл келеді - егер мен Postgres-ті қайта іске қоссам, қалпына келтіру басқа сәттен басталуы үшін транзакциялар журналындағы нүктені сәл алға жылжыту үшін ағымдағы мастерде бақылау нүктесін жасаймын? Сонымен қатар, бізде әлі де WAL қорлары болды.
Мен Патрониді қайта іске қостым, шеберде бірнеше бақылау нүктелерін жасадым, ол ашылған кезде репликада бірнеше қайта іске қосу нүктелерін жасадым. Және бұл көмектесті. Мен бұл неге көмектесті және қалай жұмыс істеді деп ұзақ ойладым. Ал реплика басталды. Ал репликация енді үзілмеді.
Мен үшін мұндай мәселе ең жұмбақтардың бірі болып табылады, мен ол жерде шынымен не болғанын әлі күнге дейін басқатырамын.
Бұл жерде қандай салдарлар бар? Патрони мақсатқа сай және қатесіз жұмыс істей алады. Бірақ сонымен бірге бұл бізде бәрі жақсы екеніне 100% кепілдік бермейді. Реплика басталуы мүмкін, бірақ ол жартылай жұмыс күйінде болуы мүмкін және қолданба мұндай көшірмемен жұмыс істей алмайды, себебі ескі деректер болады.
Ал файлдан кейін кластермен барлығының реттелгенін, яғни репликалардың қажетті санының бар-жоғын, репликацияның кешігуі жоқ екенін әрқашан тексеру керек.
Және осы мәселелерді қарастыра отырып, мен ұсыныстар жасаймын. Мен оларды екі слайдқа біріктіруге тырыстым. Барлық оқиғаларды екі слайдқа біріктіріп, тек айтып беруге болатын шығар.
Patroni пайдаланған кезде сізде мониторинг болуы керек. Автофайлдың қашан болғанын әрқашан білуіңіз керек, себебі сізде автофайл бар екенін білмесеңіз, кластерді басқара алмайсыз. Және бұл жаман.
Әрбір файлдан кейін біз әрқашан кластерді қолмен тексеруіміз керек. Бізде репликалардың әрқашан жаңартылған саны бар екеніне, репликацияның кешігуі жоқтығына, Patroni-мен, DCS жүйесімен ағынды репликацияға қатысты журналдарда қателер жоқ екеніне көз жеткізуіміз керек.
Автоматтандыру сәтті жұмыс істей алады, Patroni - өте жақсы құрал. Ол жұмыс істей алады, бірақ бұл кластерді қажетті күйге әкелмейді. Ал егер бұл туралы білмесек, бәлеге қаламыз.
Ал Патрони – күміс оқ емес. Біз Postgres қалай жұмыс істейтінін, репликация қалай жұмыс істейтінін және Patroni Postgres-пен қалай жұмыс істейтінін және түйіндер арасындағы байланыс қалай қамтамасыз етілетінін әлі де түсінуіміз керек. Бұл өз қолыңызбен ақауларды түзете алу үшін қажет.
Диагностика мәселесіне қалай қараймын? Біз әртүрлі клиенттермен жұмыс істейміз және ешкімде ELK стегі жоқ және 6 консоль мен 2 қойындыны ашу арқылы журналдарды сұрыптауымыз керек. Бір қойындыда бұл әр түйін үшін Patroni журналдары, екінші қойындыда бұл Консул журналдары немесе қажет болса Postgres. Бұл диагноз қою өте қиын.
Мен қандай тәсілдер қабылдадым? Біріншіден, мен әрқашан файлдың қашан келгенін қараймын. Ал мен үшін бұл су айдыны. Мен толтырғышқа дейін, толтыру кезінде және толтырғыштан кейін не болғанын қараймын. Файлдың екі белгісі бар: бұл басталу және аяқталу уақыты.
Әрі қарай, мен файлдан бұрын болған файлдарды тіркеу журналдарынан қараймын, яғни файлдың орын алу себептерін іздеймін.
Бұл не болғанын және болашақта мұндай жағдайлар болмас үшін не істеуге болатынын түсінудің суретін береді (және нәтижесінде файл жоқ).
Ал біз әдетте қайда қараймыз? Мен қараймын:
- Біріншіден, Patroni журналдарына.
- Содан кейін мен Patroni журналдарында не табылғанына байланысты Postgres журналдарын немесе DCS журналдарын қараймын.
- Жүйе журналдары кейде файлға не себеп болғаны туралы түсінік береді.
Мен Патрониге қалай қараймын? Мен Патронимен өте жақсы қарым-қатынастамын. Менің ойымша, бұл бүгінгі күннің ең жақсысы. Мен басқа да көптеген өнімдерді білемін. Бұл Stolon, Repmgr, Pg_auto_failover, PAF. 4 құрал. Мен олардың барлығын сынап көрдім. Патрони менің сүйіктім.
Егер олар менен сұраса: «Мен Патрониді ұсынамын ба?». Мен иә деп айтамын, өйткені маған Патрони ұнайды. Мен оны қалай пісіруді үйрендім деп ойлаймын.
Егер сізді мен айтқан мәселелерден басқа Patroni-де қандай мәселелер бар екенін көргіңіз келсе, сіз әрқашан бетті тексере аласыз. GitHub сайтында. Онда неше түрлі әңгімелер бар, көптеген қызықты мәселелер талқыланады. Нәтижесінде, кейбір қателер енгізілді және шешілді, яғни бұл қызықты оқу.
Аяқ астынан оқ атқан адамдар туралы қызықты оқиғалар бар. Өте мазмұнды. Оқып, мұны істеудің қажеті жоқ екенін түсінесіз. Мен өзімді белгіледім.
Осы жобаны әзірлеген Заландоға, атап айтқанда Александр Кукушкин мен Алексей Клюкинге үлкен рахмет айтқым келеді. Алексей Клюкин - бірлескен авторлардың бірі, ол енді Zalando-да жұмыс істемейді, бірақ бұл өніммен жұмыс істей бастаған екі адам.
Менің ойымша, Патрони өте керемет нәрсе. Мен оның бар екеніне қуаныштымын, онымен қызық. Патрониге патчтар жазған барлық қатысушыларға үлкен рахмет. Патрони жасына қарай жетілген, салқын және тиімді болады деп үміттенемін. Ол қазірдің өзінде жұмыс істейді, бірақ мен одан да жақсырақ болады деп үміттенемін. Сондықтан, егер сіз Patroni пайдалануды жоспарласаңыз, онда қорықпаңыз. Бұл жақсы шешім, оны іске асыруға және пайдалануға болады.
Бар болғаны. Сұрақтарыңыз болса, сұраңыз.
Сіздің сұрақтарыңыз
Есеп үшін рахмет! Егер файлдан кейін сізге әлі де мұқият қарау керек болса, онда бізге автоматты толтырғыш не үшін қажет?
Өйткені бұл жаңа нәрсе. Онымен бар болғаны бір жыл болды. Қауіпсіз болған дұрыс. Біз кіріп, бәрі шынымен де дұрыс болғанын көргіміз келеді. Бұл ересектердің сенімсіздігінің деңгейі - екі рет тексеріп, көрген дұрыс.
Мысалы, таңертең барып қарадық, солай ма?
Таңертең емес, біз әдетте автофайл туралы бірден білеміз. Біз хабарландыруларды аламыз, автофайл орын алғанын көреміз. Дереу барып қарап жатырмыз. Бірақ бұл тексерулердің барлығын бақылау деңгейіне жеткізу керек. Patroni-ге REST API арқылы кірсеңіз, тарих бар. Тарих бойынша файлдың орын алған уақыт белгілерін көре аласыз. Осының негізінде мониторинг жүргізуге болады. Тарихты, қаншама оқиғаларды көруге болады. Егер бізде көбірек оқиғалар болса, автофайл орын алды. Барып көруге болады. Немесе біздің бақылауды автоматтандыру бізде барлық көшірмелердің орнында екенін тексерді, ешқандай кешігу жоқ және бәрі жақсы.
рахмет!
Керемет әңгіме үшін көп рахмет! Егер біз DCS кластерін Postgres кластерінен алыс жерге көшірсек, онда бұл кластерге де мерзімді түрде қызмет көрсету керек пе? DCS кластерінің кейбір бөліктерін өшіру, олармен бірдеңе істеу және т.б. қажет ететін ең жақсы тәжірибелер қандай? Бұл бүкіл құрылым қалай өмір сүреді? Ал сіз бұларды қалай жасайсыз?
Бір компания үшін проблемалардың матрицасын жасау қажет болды, егер құрамдастардың біреуі немесе бірнеше компоненттері істен шыққан болса не болады. Осы матрицаға сәйкес біз барлық құрамдас бөліктерді рет-ретімен өткіземіз және осы құрамдас бөліктер істен шыққан жағдайда сценарийлер құрастырамыз. Сәйкесінше, әрбір сәтсіздік сценарийі үшін қалпына келтіруге арналған әрекет жоспары болуы мүмкін. Ал DCS жағдайында ол стандартты инфрақұрылымның бөлігі ретінде келеді. Әкімші оны басқарады және біз оны басқаратын әкімшілерге және олардың жазатайым жағдайда оны түзете алатындығына сенеміз. Егер DCS мүлде болмаса, біз оны орналастырамыз, бірақ сонымен бірге біз оны ерекше бақыламаймыз, өйткені біз инфрақұрылымға жауап бермейміз, бірақ біз қалай және нені бақылауға болатыны туралы ұсыныстар береміз.
Яғни, мен хосттармен бірдеңе жасамас бұрын Патрониді өшіру, файлды өшіру, бәрін өшіру керек екенін дұрыс түсіндім бе?
Бұл DCS кластерінде қанша түйін бар екеніне байланысты. Егер түйіндер көп болса және түйіндердің біреуін ғана өшірсек (реплика), онда кластер кворумды сақтайды. Ал Патрони жұмыс істеп тұр. Және ештеңе іске қосылмайды. Егер бізде көп түйіндерге әсер ететін күрделі операциялар болса, олардың болмауы кворумды бұзуы мүмкін болса, онда - иә, Патронды кідіртуге қоюдың мағынасы болуы мүмкін. Оның сәйкес командасы бар - patronictl үзіліс, patronictl резюме. Біз жай ғана кідіртеміз және автофилятор сол уақытта жұмыс істемейді. Біз DCS кластерінде техникалық қызмет көрсетеміз, содан кейін үзілістен шығып, өмір сүруді жалғастырамыз.
Үлкен рахмет!
Баяндамаңызға көп рахмет! Өнім тобы деректердің жоғалуына қалай қарайды?
Өнім топтарына мән бермейді, ал топ жетекшілері алаңдайды.
Қандай кепілдіктер бар?
Кепілдіктер өте қиын. Александр Кукушкиннің «RPO және RTO-ны қалай есептеуге болады», яғни қалпына келтіру уақыты және қанша деректерді жоғалтуымыз мүмкін деген есебі бар. Осы слайдтарды тауып, зерттеуіміз керек деп ойлаймын. Менің есімде, бұл заттарды есептеудің нақты қадамдары бар. Қанша транзакцияны жоғалтуымыз мүмкін, қанша деректерді жоғалтуымыз мүмкін. Опция ретінде біз Patroni деңгейінде синхронды репликацияны пайдалана аламыз, бірақ бұл екі жүзді қылыш: бізде деректер сенімділігі бар немесе біз жылдамдықты жоғалтамыз. Синхронды репликация бар, бірақ ол деректерді жоғалтудан 100% қорғауға кепілдік бермейді.
Алексей, керемет есеп үшін рахмет! Нөлдік деңгейдегі қорғаныс үшін Patroni пайдалану тәжірибесі бар ма? Яғни, синхронды күту режимімен бірге? Бұл бірінші сұрақ. Ал екінші сұрақ. Сіз әртүрлі шешімдерді қолдандыңыз. Біз Repmgr қолданбасын пайдаландық, бірақ автофилерсіз, енді автофиляторды қосуды жоспарлап отырмыз. Ал біз Патрониді балама шешім ретінде қарастырамыз. Repmgr-мен салыстырғанда артықшылықтар ретінде не айта аласыз?
Бірінші сұрақ синхронды көшірмелер туралы болды. Мұнда ешкім синхронды репликацияны пайдаланбайды, өйткені бәрі қорқады (бірнеше клиенттер оны қазірдің өзінде пайдаланып жатыр, негізінен олар өнімділік мәселелерін байқамады - Спикер жазбасы). Бірақ біз өзіміз үшін синхронды репликация кластерінде кемінде үш түйін болуы керек деген ережені әзірледік, өйткені егер бізде екі түйін болса және мастер немесе реплика сәтсіз болса, Patroni бұл түйінді дербес режимге ауыстырады, осылайша қолданба жұмысын жалғастырады. жұмыс. Бұл жағдайда деректердің жоғалу қаупі бар.
Екінші сұраққа қатысты біз Repmgr қолданбасын қолдандық және тарихи себептерге байланысты кейбір клиенттермен әлі де айналысамыз. Не деуге болады? Patroni автоматты толтырғышпен бірге келеді, Repmgr қосуды қажет ететін қосымша мүмкіндік ретінде автоматты толтырғышпен бірге келеді. Біз әрбір түйінде Repmgr демонын іске қосуымыз керек, содан кейін біз автофиляторды конфигурациялай аламыз.
Repmgr Postgres түйіндерінің тірі екенін тексереді. Repmgr процестері бір-бірінің бар-жоғын тексереді, бұл өте тиімді тәсіл емес. үлкен Repmgr кластері бірнеше кішігірім кластерге бөлініп, жұмысын жалғастыра алатын желіні оқшаулаудың күрделі жағдайлары болуы мүмкін. Мен Repmgr-ге ұзақ уақыт бойы жазылмадым, мүмкін ол түзетілді ... немесе мүмкін емес. Бірақ Stolon, Patroni сияқты DCS-тегі кластердің күйі туралы ақпаратты жою ең тиімді нұсқа болып табылады.
Алексей, менің сұрағым бар, мүмкін, қиынырақ. Алғашқы мысалдардың бірінде DCS-ті жергілікті құрылғыдан қашықтағы хостқа жылжыттыңыз. Желінің өзіндік ерекшеліктері бар, өздігінен өмір сүретін нәрсе екенін түсінеміз. Қандай да бір себептермен DCS кластері қолжетімсіз болып қалса не болады? Себептерін айтпай-ақ қояйын, олардың көп болуы мүмкін: сетевойшылардың қисық қолдарынан бастап, нақты проблемаларға дейін.
Мен мұны дауыстап айтқан жоқпын, бірақ DCS кластері де істен шығуы керек, яғни кворум орындалуы үшін түйіндердің тақ саны болуы керек. DCS кластері қолжетімсіз болып қалса немесе кворум орындалмаса, яғни желінің бөлінуі немесе түйіннің қандай да бір ақауы болса не болады? Бұл жағдайда Patroni кластері тек оқуға арналған режимге өтеді. Patroni кластері кластердің күйін және не істеу керектігін анықтай алмайды. Ол DCS-мен байланыса алмайды және жаңа кластер күйін сол жерде сақтай алмайды, сондықтан бүкіл кластер тек оқуға өтеді. Және оператордың қолмен араласуын немесе DCS қалпына келуін күтеді.
Дөрекі айтқанда, DCS біз үшін базаның өзі сияқты маңызды қызметке айналады ма?
Иә Иә. Көптеген заманауи компанияларда Service Discovery инфрақұрылымның ажырамас бөлігі болып табылады. Ол тіпті инфрақұрылымда деректер базасы болғанға дейін жүзеге асырылуда. Салыстырмалы түрде айтсақ, инфрақұрылым іске қосылды, DC-де орналастырылды және бізде бірден Service Discovery бар. Егер бұл Консул болса, онда DNS оған салынуы мүмкін. Егер бұл Etcd болса, қалғанының барлығы орналастырылатын Kubernetes кластерінің бір бөлігі болуы мүмкін. Менің ойымша, Service Discovery қазірдің өзінде заманауи инфрақұрылымдардың ажырамас бөлігі болып табылады. Және олар бұл туралы дерекқорға қарағанда әлдеқайда ертерек ойлайды.
рахмет!
Ақпарат көзі: www.habr.com