Асноўная мэта Patroni - гэта забеспячэнне High Availability для PostgreSQL. Але Patroni - гэта толькі template, а не гатовы інструмент (што, увогуле, і сказана ў дакументацыі). На першы погляд, наладзіўшы Patroni у тэставай лабе, можна ўбачыць, якая гэта выдатная прылада і як ён лёгка апрацоўвае нашы спробы разваліць кластар. Аднак на практыцы ў вытворчым асяроддзі, не заўсёды ўсё адбываецца так прыгожа і элегантна, як у тэставай лабе.
Раскажу крыху пра сябе. Я пачынаў сістэмным адміністратарам. Працаваў у вэб-распрацоўцы. З 2014-га года працую ў Data Egret. Кампанія займаецца кансалтынгам у сферы Postgres. І мы абслугоўваем менавіта Postgres і кожны дзень працуем з Postgres, таму ў нас ёсць розная экспертыза, звязаная з эксплуатацыяй.
І ў канцы 2018-га года мы пачалі паціху выкарыстоўваць Patroni. І назапасіўся нейкі пэўны досвед. Мы неяк дыягнаставалі яго, цюнілі, дашлі да сваіх best practices. І ў гэтым дакладзе я буду пра іх расказваць.
Апроч Postgres я кахаю Linux. Кахаю ў ім калупацца і даследаваць, кахаю збіраць ядры. Кахаю віртуалізацыю, кантэйнеры, докер, Kubernetes. Мяне гэта ўсё цікавіць, бо адбіваюцца старыя адмінскія звычкі. Кахаю разбірацца з маніторынгамі. І люблю postgres'авыя рэчы, звязаныя з адмінствам, г.зн. рэплікацыя, рэзервовае капіраванне. І у вольны час пішу на Go. Не з'яўляюся software engineer, проста для сябе пішу на Go. І мне гэта дае задавальненне.
- Я думаю, многія з вас ведаюць, што ў Postgres няма HA (High Availability) са скрынкі. Каб атрымаць HA, трэба нешта паставіць, наладзіць, прыкласці намаганні і атрымаць гэта.
- Ёсць некалькі інструментаў і Patroni - гэта адзін з іх, які вырашае HA даволі-такі крута і вельмі добра. Але паставіўшы гэта ўсё ў тэставай лабе і запусціўшы, мы можам паглядзець, што гэта ўсё працуе, мы можам прайграваць нейкія праблемы, паглядзець, як Patroni іх абслугоўвае. І ўбачым, што ўсё гэта цудоўна працуе.
- Але на практыцы мы сутыкаліся з рознымі праблемамі. І пра гэтыя праблемы я буду расказваць.
- Раскажу, як мы гэта дыягнаставалі, што падкручвалі - дапамагло ці гэта нам ці не дапамагло.
- Я не буду расказваць, як усталяваць Patroni, таму што можна нагугліць у інтэрнэце, можна паглядзець файлы канфігурацыі, каб зразумець, як гэта ўсё запускаецца, як наладжваецца. Можна разабрацца ў схемах, архітэктурах, знайшоўшы інфармацыю аб гэтым у інтэрнэце.
- Не буду расказваць пра чужы вопыт. Буду расказваць толькі пра тыя праблемы, з якімі сутыкнуліся менавіта мы.
- І не буду расказваць пра праблемы, якія за межамі Patroni і PostgreSQL. Калі, напрыклад, праблемы, звязаныя з балансаваннем, калі ў нас кластар разваліўся, я пра гэта расказваць не буду.
І невялікі disclaimer перад тым, як пачаць наш даклад.
Усе гэтыя праблемы, з якімі мы сутыкнуліся, яны былі ў нас у першыя 6-7-8 месяцаў эксплуатацыі. З часам мы прыйшлі да сваіх унутраных best practices. І праблемы ў нас зніклі. Таму даклад заяўляўся недзе паўгода таму, калі гэта ўсё было свежа ў галаве і я гэта ўсё цудоўна памятаў.
Па ходзе падрыхтоўкі даклада я ўжо паднімаў старыя постмартэмы, глядзеў логі. І частка дэталяў магла забыцца, альбо частка нейкіх дэталяў магла быць не даследаваная падчас разбору праблем, таму ў нейкіх момантах можа падацца, што праблемы разгледжаны не цалкам, альбо ёсць нейкі недахоп інфармацыі. І таму прашу мяне за гэты момант прабачыць.
Што такое Patroni?
- Гэта шаблон для пабудовы HA. Так напісана ў дакументацыі. І з майго гледзішча, гэта вельмі правільнае ўдакладненне. Patroni - гэта не срэбная куля, якая вырашыць усе вашыя праблемы, т. е. трэба прыкласці намаганне, каб яно пачало працаваць і прыносіць карысць.
- Гэта агенцкая служба, якая ўсталёўваецца на кожным сэрвісе з дадзенай базай, і якая з'яўляецца свайго роду init-сістэмай для вашага Postgres. Яна запускае Postgres, спыняе, перазапускае, мяняе канфігурацыю і мяняе тапалогію вашага кластара.
- Адпаведна, каб захоўваць стан кластара, яго бягучае ўяўленне, як ён выглядае, патрэбнае нейкае сховішча. І з гэтага пункта гледжання Patroni пайшоў па шляху захоўвання state у знешняй сістэме. Гэта сістэма размеркаванага сховішчы канфігурацыі. Гэта могуць быць Etcd, Consul, ZooKeeper, альбо kubernetes'кі Etcd, т. е. нейкі з гэтых варыянтаў.
- І адной з асаблівасцяў Patroni гэта тое, што аўтафайловер вы атрымліваеце са скрынкі, толькі яго наладзіўшы. Калі ўзяць для параўнання Repmgr, то файлавер тамака ідзе ў камплекце. З Repmgr мы атрымліваем switchover, але калі жадаем аўтафайлавер, тое яго трэба дадаткова наладзіць. У Patroni ужо ёсць аўтафайлавер са скрынкі.
- І ёсць шмат яшчэ іншых рэчаў. Напрыклад, абслугоўванне канфігурацый, наліўка новых рэплік, рэзервовае капіраванне і г. д. Але гэта за межамі даклада, пра гэта я расказваць не буду.
І невялікі вынік гэта тое, што асноўная задача Patroni гэта добра і надзейна рабіць аўтафайловер, каб кластар у нас заставаўся працаздольным і прыкладанне не заўважала змен у тапалогіі кластара.
Але калі мы пачынаем выкарыстоўваць Patroni, наша сістэма становіцца крыху больш складана. Калі раней у нас быў Postgres, то пры выкарыстанні Patroni мы атрымоўваем сам Patroni, мы атрымліваем DCS, дзе захоўваецца state. І ўсё гэта павінна неяк працаваць. Таму што можа зламацца?
Можа зламацца:
- Можа зламацца Postgres. Гэта можа быць майстар ці рэпліка, нешта з іх можа выйсці са строю.
- Можа зламацца сам Patroni.
- Можа зламацца DCS дзе захоўваецца state.
- І можа зламацца сетка.
Усе гэтыя моманты я буду разглядаць у дакладзе.
Я буду разглядаць выпадкі па меры іх ускладнення, не з пункту гледжання таго, што кейс закранае шмат кампанентаў. А з гледзішча суб'ектыўных адчуванняў, што гэты кейс быў для мяне складаны, яго было складана разбіраць… і наадварот, нейкі кейс быў лёгкі і яго было лёгка разбіраць.
І першы выпадак самы просты. Гэта той выпадак, калі мы ўзялі кластар баз дадзеных і на гэтым жа кластары разгарнулі нашае сховішча DCS. Гэта самая распаўсюджаная памылка. Гэта памылка пабудовы архітэктур, т. е. сумяшчэнне розных кампанентаў у адным месцы.
Такім чынам, адбыўся файлавер, ідзем разбірацца з тым, што адбылося.
І тут нас цікавіць, калі адбыўся файлавер. Т. е. нас цікавіць вось гэты момант часу, калі адбылося змяненне стану кластара.
Але файлавер не заўсёды аднамаментны, т. е. ён не займае нейкую адзінку часу, ён можа зацягнуцца. Ён можа быць працяглым у часе.
Таму ў яго ёсць час пачатку і час завяршэння, г. зн. гэта працяглая падзея. І мы дзелім усе падзеі на тры інтэрвалы: у нас ёсць час да файлаверу, падчас файлаверу і пасля файлаверу. Т. е. мы разглядаем усе падзеі ў гэтай часовай шкале.
І перш за ўсё, калі адбыўся файлавер, мы шукаем прычыну, што адбылося, што стала прычынай таго, што прывяло да файлавер.
Калі мы паглядзім на логі, то гэта будуць класічныя логі Patroni. Ён у іх нам паведамляе, што сервер стаў майстрам, і роля майстра перайшла на гэты вузел. Тут гэта падсветлена.
Далей нам трэба зразумець, чаму адбыўся файлавер, т. е. якія адбыліся падзеі, якія прымусілі ролю майстра пераехаць з аднаго вузла на іншы. І ў дадзеным выпадку тут усё проста. У нас ёсць памылка ўзаемадзеяння з сістэмай захоўвання. Майстар зразумеў, што ён не можа працаваць з DCS, т. е. узнікла нейкая праблема з узаемадзеяннем. І ён кажа, што не можа быць больш майстрам і складае з сябе паўнамоцтвы. Вось гэты радок "demoted self" кажа менавіта пра гэта.
Калі паглядзець на падзеі, якія папярэднічалі файлавер, то мы там можам убачыць тыя самыя прычыны, якія паслужылі праблемай для працягу працы майстра.
Калі паглядзець на логі Patroni, то мы ўбачым, што ў нас ёсць маса ўсякіх памылак, тайм-аўтаў, т. е. агент Patroni не можа працаваць з DCS. У дадзеным выпадку гэта Consul agent, з якім ідзе зносіны па порце 8500.
І праблема тут заключаецца ў тым, што Patroni і база дадзеных запушчаны на адным хасце. І на гэтым жа вузле былі запушчаны Consul-сервера. Стварыўшы нагрузку на сэрвэры, мы стварылі праблемы і для сэрвэраў Consul. Яны не змаглі нармальна размаўляць.
Праз нейкі час, калі нагрузка спала, наш Patroni змог зноў размаўляць з агентамі. Нармальная праца аднавілася. І той самы сервер Pgdb-2 зноў стаў майстрам. Т. е. быў невялікі фліп, з-за якога вузел склаў з сябе паўнамоцтвы майстра, а потым зноў іх на сябе ўзяў, т. е. усё вярнулася, як было.
І гэта можна расцэньваць як ілжывую спрацоўку, альбо можна расцэньваць, што Patroni зрабіў усё правільна. Т. е. ён зразумеў, што не можа падтрымліваць стан кластара і зняў з сябе паўнамоцтвы.
І тут праблема ўзнікла з-за таго, што Consul-сервера знаходзяцца на тым жа абсталяванні, што і базы. Адпаведна, любая нагрузка: няхай гэта будзе нагрузка на дыскі ці працэсары, яна таксама ўплывае на ўзаемадзеянне з кластарам Consul.
І мы вырашылі, што гэта не павінна жыць разам, мы вылучылі асобны кластар для Consul. І Patroni працаваў ужо c асобным Consul'ом, т. е. быў асобна кластар Postgres, асобна кластар Consul. Гэта базавая інструкцыя, як трэба ўсе гэтыя рэчы разносіць і трымаць, каб яно не жыло разам.
Як варыянт можна пакруціць параметры ttl, loop_wait, retry_timeout, т. е. паспрабаваць за рахунак павелічэння гэтых параметраў перажыць гэтыя кароткачасовыя пікі нагрузкі. Але гэта не самы прыдатны варыянт, таму што вось гэтая нагрузка можа быць працяглай па часе. І мы проста выйдзем за вось гэтыя ліміты гэтых параметраў. І гэта можа не зусім памагчы.
Першая праблема, як вы зразумелі, простая. Мы ўзялі, і DCS паклалі разам з базай, атрымалі праблему.
Другая праблема падобная да першай. Яна падобная да таго, што ў нас зноў ёсць праблемы ўзаемадзеяння з сістэмай DCS.
Калі мы паглядзім на логі, то ўбачым, што ў нас зноў памылка камунікацыі. І Patroni кажа, што я не магу ўзаемадзейнічаць з DCS, таму бягучы майстар пераходзіць у рэжым рэплікі.
Стары майстар становіцца рэплікай, тут Patroni адпрацоўвае, як і належыць. Ён запускае pg_rewind, каб адкруціць часопіс транзакцыі і потым далучыцца да новага майстра, і ўжо дагнаць новы майстар. Тут Patroni адпрацоўвае, як яму і належыць.
Тут мы павінны знайсці тое месца, якое папярэднічала файлаверу, т. е. тыя памылкі, якія прычыніліся, чаму ў нас файлавер адбыўся. І у гэтым плане з логамі Patroni даволі зручна працаваць. Ён з пэўным інтэрвалам піша адны і тыя ж паведамленні. І калі мы пачынаем прамотваць гэтыя логі хутка, то мы па логах убачым, што логі памяняліся, значыць, нейкія праблемы пачаліся. Мы хутка вяртаемся на гэтае месца, глядзім, што адбываецца.
І ў нармальнай сітуацыі логі выглядаюць прыкладна так. Правяраецца ўладальнік блакіроўкі. І калі ўладальнік, дапусцім, памяняўся, то могуць наступіць нейкія падзеі, на якія Patroni павінен адрэагаваць. Але ў дадзеным выпадку ў нас усё ў парадку. Мы шукаем тое месца, калі пачаліся памылкі.
І праматаўшы да таго месца, калі памылкі пачалі з'яўляцца, мы бачым, што ў нас адбыўся аўтафайлавер. І раз у нас памылкі былі звязаныя з узаемадзеяннем з DCS і ў нашым выпадку мы выкарыстоўвалі Consul, мы заадно глядзім і ў логі Consul, што адбывалася там.
Прыкладна супаставіўшы час файлавер і час у логах Consul, мы бачым, што ў нас суседзі па Consul-кластару пачалі сумнявацца ў існаванні іншых удзельнікаў Consul-кластара.
І калі яшчэ паглядзець на логі іншых Consul-агентаў, то тамака таксама бачна, што там нейкі сеткавы калапс адбываецца. І ўсе ўдзельнікі Consul-кластара сумняваюцца ў існаванні адзін аднаго. І гэта паслужыла штуршком да файлавер.
Калі паглядзець, што адбывалася да гэтых памылак, то можна ўбачыць, што ёсць усякія памылкі, напрыклад, deadline, RPC falled, т. е. відавочна нейкая праблема пры ўзаемадзеянні ўдзельнікаў Consul-кластара паміж сабой.
Самы просты адказ - гэта правіць сетку. Але мне, стоячы на трыбуне, лёгка аб гэтым заяўляць. Але акалічнасці складаюцца так, што не заўсёды замовец можа сабе дазволіць правіць сетку. Ён можа жыць у ДЦ і можа не мець магчымасцяў правіць сетку, уплываць на абсталяванне. І таму патрэбны нейкія іншыя варыянты.
Варыянты ёсць:
- Самы просты варыянт, які напісаны, па-мойму, нават у дакументацыі, гэта адключыць Consul-праверкі, т. е. проста перадаць пусты масіў. І мы гаворым Consul-агенту не выкарыстоўваць ніякіх праверак. За кошт гэтых праверак мы можам ігнараваць гэтыя сеткавыя штармы і не ініцыяваць файлавер.
- Іншы варыянт - гэта пераправерыць raft_multiplier. Гэта параметр самога Consul-сервера. Па змаўчанні ён выстаўлены ў значэнне 5. Гэтае значэнне рэкамендавана па дакументацыі для staging акружэнняў. Па сутнасці гэта ўплывае на частату абмену паведамленнямі паміж удзельнікамі Consul сеткі. Па сутнасці, гэты параметр уплывае на хуткасці службовых зносін паміж удзельнікамі Consul-кластара. І для production яго ўжо рэкамендуецца памяншаць, каб вузлы часцей абменьваліся паведамленнямі.
- Іншы варыянт, які мы сталі выкарыстоўваць, гэта павелічэнне прыярытэту Consul працэсаў сярод іншых працэсаў для планавальніка працэсаў аперацыйнай сістэмы. Ёсць такі параметр "nice", ён як раз вызначае прыярытэт працэсаў які ўлічваецца планавальнікам АС пры планаванні. Мы ўзялі і Consul-агентам паменшылі значэнне nice, г.зн. павысілі прыярытэт, каб аперацыйная сістэма давала Consul працэсам больш часу на працу і на выкананне свайго кода. У нашым выпадку гэта вырашыла нашую праблему.
- Іншы варыянт - гэта не выкарыстоўваць Consul. У мяне ёсць таварыш, які вялікі прыхільнік Etcd. І мы з ім рэгулярна спрачаемся, што лепш Etcd ці Consul. Але ў плане, што лепш, мы звычайна з ім сыходзімся ў меркаванні, што ў Consul ёсць агент, які павінен быць запушчаны на кожным вузле з базай дадзеных. Т. е. узаемадзеянне Patroni з Consul-кластарам ідзе праз гэты агент. І вось гэты агент становіцца вузкім месцам. Калі з агентам нешта адбываецца, то Patroni ужо не можа працаваць з Consul-кластарам. І гэта праблема. У плане Etcd ніякага агента няма. Patroni можа працаваць са спісам Etcd-сервераў і ўжо мець зносіны з імі. У гэтым плане, калі вы карыстаецеся ў сябе ў кампаніі Etcd, то Etcd будзе, мусіць, лепшым выбарам, чым Consul. Але мы ў нашых заказчыкаў заўсёды абмежаваны тым, што абраў і выкарыстоўвае ў сябе кліент. І ў нас па большай частцы Consul ва ўсіх кліентаў.
- І апошні пункт - гэта перагледзець значэнні параметраў. Мы можам падняць гэтыя параметры ў большы бок у надзеі, што нашы кароткачасовыя сеткавыя праблемы будуць кароткімі і не патрапяць за інтэрвал гэтых параметраў. Такім чынам мы можам паменшыць агрэсіўнасць Patroni на выкананне аўтафайлаверу, калі нейкія сеткавыя праблемы ўзнікаюць.
Я думаю, многія, хто выкарыстоўваюць Patroni, знаёмыя з гэтай камандай.
Гэтая каманда паказвае бягучы стан кластара. І на першы погляд гэтая карціна можа падацца нармальнай. У нас ёсць майстар, у нас ёсць рэпліка, лага рэплікацыі ніякага няма. Але гэтая карціна нармальная роўна датуль, пакуль мы не ведаем, што ў гэтым кластары павінна быць тры вузла, а не два.
Адпаведна, адбыўся аўтафайлавер. І пасля гэтага аўтафайлавера ў нас рэпліка знікла. Нам трэба высветліць, чаму яна знікла і вярнуць яе назад, аднавіць. І мы зноў ідзем у логі і глядзім, чаму ў нас адбыўся аўтафайлавер.
У дадзеным выпадку другая рэпліка стала майстрам. Тут усё ў парадку.
І нам трэба глядзець ужо на рэпліку, якая адвалілася і якая не ў кластары. Мы адчыняем логі Patroni і глядзім, што ў нас падчас падлучэнняў да кластара ўзнікла праблема на стадыі pg_rewind. Каб падлучыцца да кластара трэба адкруціць часопіс транзакцыі, запытаць патрэбны часопіс транзакцыі з майстра і па ім дагнаць майстра.
У дадзеным выпадку ў нас няма часопіса транзакцый і рэпліка не можа запусціцца. Адпаведна, мы Postgres спыняем з памылкай. І таму яе няма ў кластары.
Трэба зразумець, чаму яе няма ў кластары і чаму не аказалася логаў. Мы ідзём на новы майстар і глядзім, што ў яго ў логах. Аказваецца, калі рабіўся pg_rewind, адбыўся checkpoint. І частка старых часопісаў транзакцыі проста была перайменаваная. Калі стары майстар паспрабаваў далучыцца да новага майстра і запытаць гэтыя логі, яны ўжо былі перайменаваны, іх проста не было.
Я параўноўваў timestamps, калі адбываліся гэтыя падзеі. І там розніца літаральна ў 150 мілісекунд, г. зн. у 369 мілісекунд завяршыўся checkpoint, былі перайменаваны WAL-сегменты. І літаральна ў 517 праз 150 мілісекунд запусціўся rewind на старой рэпліцы. Т. е. літаральна 150 мілісекунд нам хапіла, каб рэпліка не змагла падлучыцца і зарабіць.
Якія ёсць варыянты?
Мы выкарыстоўвалі першапачаткова слоты рэплікацыі. Нам падавалася, што гэта добра. Хаця на першым этапе эксплуатацыі мы слоты адключалі. Нам здавалася, што, калі слоты будуць збіраць шмат WAL-сегментаў, мы можам выпусціць майстар. Ён упадзе. Мы памучыліся нейкі час без слотаў. І зразумелі, што нам слоты патрэбны, мы вярнулі слоты.
Але тут ёсць праблема, што, калі майстар пераходзіць у рэпліку, ён выдаляе слоты і разам са слотамі выдаляе WAL-сегменты. І каб выключыць зьяўленьне гэтай праблемы, мы вырашылі падняць параметр wal_keep_segments. Ён па змаўчанні 8 сегментаў. Мы паднялі да 1 000 і паглядзелі, колькі ў нас вольнага месца. І мы 16 гігабайт падарылі на wal_keep_segments. Т. е. пры пераключэнні ў нас заўсёды на ўсіх вузлах ёсць запас у 16 гігабайтаў часопісаў транзакцый.
І плюс - гэта яшчэ актуальна для працяглых maintenance задач. Дапушчальны, нам трэба абнавіць адну з рэплік. І мы жадаем яе выключыць. Нам трэба абнавіць софт, можа быць, аперацыйную сістэму, яшчэ нешта. І калі мы выключаем рэпліку, для гэтай рэплікі таксама выдаляецца слот. І калі мы выкарыстоўваем маленькі wal_keep_segments, то пры працяглай адсутнасці рэплікі, часопісы транзакцый прайграюцца. Мы падымем рэпліку, яна запытае тыя часопісы транзакцыі, дзе яна спынілася, але на майстру іх можа не аказацца. І рэпліка таксама не зможа далучыцца. Таму мы трымаем вялікі запас часопісаў.
У нас ёсць production-база. Тамака ўжо працуюць праекты.
Адбыўся файлавер. Мы зайшлі і паглядзелі - усё ў парадку, рэплікі на месцы, лага рэплікацыі няма. Памылак па часопісах таксама няма, усё ў парадку.
Прадуктовая каманда кажа, што нібыта як павінны быць нейкія дадзеныя, але мы іх па адной крыніцы бачым, а ў базе мы іх не бачым. І трэба зразумець, што з імі адбылося.
Зразумела, што pg_rewind іх зацёр. Мы адразу гэта зразумелі, але пайшлі глядзець, што адбывалася.
У логах мы заўсёды можам знайсці, калі адбыўся файлавер, хто стаў майстрам і можам вызначыць, хто быў старым майстрам і калі ён захацеў стаць рэплікай, т. е. нам патрэбны вось гэтыя логі, каб высветліць той аб'ём часопісаў транзакцый, які быў страчаны.
Наш стары майстар перазагрузіўся. І ў аўтазапуску быў прапісаны Patroni. Запусціўся Patroni. Ён следам запусціў Postgres. Дакладней перад запускам Postgres'а і перад тым як зрабіць яго рэплікай, Patroni запусціў працэс pg_rewind. Адпаведна, ён сцёр частку часопісаў транзакцый, запампаваў новыя і падключыўся. Тут Patroni адпрацаваў шыкоўна, т. е. як і належыць. Кластар у нас аднавіўся. У нас было 3 ноды, пасля файлавера 3 ноды - усё крута.
Мы страцілі частку звестак. І нам трэба зразумець, колькі мы згубілі. Мы шукаем якраз той момант, калі ў нас адбываўся rewind. Мы можам знайсці гэта па такіх запісах у часопісе. Запусціўся rewind, нешта там зрабіў і завяршыўся.
Нам трэба знайсці тую пазіцыю ў часопісе транзакцый, на якой спыніўся стары майстар. У дадзеным выпадку - гэта вось гэтая адзнака. І нам патрэбна другая адзнака, г. зн. тая адлегласць, на якую адрозніваецца стары майстар ад новага.
Мы бярэм звычайны pg_wal_lsn_diff і параўноўваем гэтыя дзве адзнакі. І ў дадзеным выпадку мы атрымліваем 17 мегабайт. Шмат гэта ці мала кожны для сябе вырашае сам. Таму што для кагосьці 17 мегабайт - гэта няшмат, для кагосьці гэта шмат і недапушчальна. Тут ужо кожны для сябе індывідуальна вызначае ў адпаведнасць з патрэбамі бізнэсу.
Але што мы высветлілі для сябе?
Па-першае, мы для сябе павінны вырашыць – ці заўсёды нам патрэбен аўтазапуск Patroni пасля перазагрузкі сістэмы? Часцей бывае так, што мы павінны зайсці на стары майстар, паглядзець, як далёка ён з'ехаў. Магчыма, праінспектаваць сегменты часопіса транзакцый, паглядзець, што тамака. І зразумець - ці можам мы гэтыя дадзеныя страціць ці нам трэба ў standalone-рэжыме запусціць стары майстар, каб выцягнуць гэтыя дадзеныя.
І толькі ўжо пасля гэтага павінны прыняць рашэнні, што мы можам гэтыя дадзеныя адкінуць ці мы можам іх аднавіць, падлучыць вось гэты вузел у якасці рэплікі ў наш кластар.
Апроч гэтага, ёсць параметр "maximum_lag_on_failover". Па змаўчанні, калі мне не змяняе памяць, гэты параметр мае значэнне 1 мегабайт.
Як ён працуе? Калі нашая рэпліка адстае на 1 мегабайт дадзеных па лазе рэплікацыі, то гэтая рэпліка не прымае ўдзелу ў выбарах. І калі раптам адбываецца файлавер, Patroni глядзіць, якія рэплікі адстаюць. Калі яны адстаюць на вялікую колькасць часопісаў транзакцый, яны не могуць стаць майстрам. Гэта вельмі добрая ахоўная функцыя, якая дазваляе не страціць шмат дадзеных.
Але тут ёсць праблема ў тым, што лаг рэплікацыі ў кластары Patroni і DCS абнаўляецца з пэўным інтэрвалам. Па-мойму, 30 секунд значэнне ttl па змаўчанні.
Адпаведна, можа быць сітуацыя, калі лаг рэплікацыі для рэплік у DCS адзін, а на самой справе можа быць зусім іншы лаг ці ўвогуле лага можа не быць, г. зн. гэтая штука не realtime. І яна не заўсёды адлюстроўвае рэальную карціну. І рабіць на ёй наварочаную логіку не варта.
І рызыка страт заўсёды застаецца. І ў горшым выпадку адна формула, а ў сярэднім выпадку іншая формула. Т. е. мы, калі плануем ўкараненне Patroni і ацэньваем, колькі дадзеных мы можам страціць, мы павінны закладвацца на гэтыя формулы і прыкладна прадстаўляць, колькі дадзеных мы можам страціць.
І добрая навіна ёсць. Калі стары майстар з'ехаў наперад, ён можа з'ехаць наперад за рахунак нейкіх фонавых працэсаў. Т. е. нейкі быў аўтавакуум, ён напісаў дадзеныя, захаваў іх у часопіс транзакцыі. І гэтыя дадзеныя мы можам папросту ігнараваць і страціць. У гэтым няма ніякай праблемы.
І вось так выглядаюць логі ў выпадку, калі выстаўлены maximum_lag_on_failover і адбыўся файлавер, і трэба абраць новага майстра. Рэпліка ацэньвае сябе як няздольную прымаць удзел у выбарах. І яна адмаўляецца ад удзелу ў гонцы за лідара. І яна чакае, калі будзе абраны новы майстар, каб потым да яго далучыцца. Гэта дадатковая мера ад страты даных.
Тут у нас прадуктовая каманда напісала, што іх прадукт мае праблемы пры працы з Postgres. Пры гэтым на сам майстар нельга зайсці, бо ён недаступны па SSH. І аўтафайлавер таксама не адбываецца.
Гэты хост адправілі прымусова ў перазагрузку. З-за перазагрузкі адбыўся аўтафайлавер, хоць можна было зрабіць і ручны аўтафайлавер, як я зараз разумею. І пасля перазагрузкі мы ўжо ідзем глядзець, што ў нас было з бягучым майстрам.
Пры гэтым мы загадзя ведалі, што ў нас праблемы былі з кружэлкамі, т. е. мы ўжо па маніторынгу ведалі, дзе капаць і што шукаць.
Мы залезлі ў postgres'авы лог, пачалі глядзець, што тамака адбываецца. Мы ўбачылі коміты, якія доўжацца там па адной-дзве-тры секунды, што зусім не нармальна. Мы ўбачылі, што ў нас аўтавакуум запускаецца вельмі доўга і дзіўна. І мы ўбачылі часовыя файлы на дыску. Т. е. гэта ўсё паказчыкі праблем з дыскамі.
Мы зазірнулі ў сістэмны dmesg (у лог ядзерных паведамленняў). І ўбачылі, што ў нас у нас ёсць праблемы з адным з дыскаў. Дыскавая падсістэмная ўяўляла сабой software Raid. Мы паглядзелі /proc/mdstat і ўбачылі, што ў нас бракуе адной кружэлкі. Г. зн. тут Raid з 8 дыскаў, у нас аднаго не хапае. Калі ўважліва паразглядаць слайд, то ў выснове можна ўбачыць, што ў нас там sde адсутнічае. У нас, умоўна кажучы, выпаў дыск. Гэта стрыгеравала дыскавыя праблемы, і прыкладанні таксама выпрабавалі праблемы пры працы з кластарам Postgres.
І ў дадзеным выпадку Patroni нам ніяк не дапамог бы, таму што ў Patroni няма задачы адсочваць стан сэрвера, стан дыска. І мы павінны такія сітуацыі адсочваць вонкавым маніторынгам. Мы ў знешні маніторынг дадалі маніторынг дыскаў аператыўна.
І была такая думка - а мог бы нам дапамагчы фенсінг, або софт watchdog? Мы падумалі, што ці наўрад бы ён нам дапамог у гэтым выпадку, таму што падчас праблем Patroni працягваў узаемадзейнічаць з кластарам DCS і не бачыў ніякай праблемы. Т. е. з пункту гледжання DCS і Patroni з кластарам было ўсё добра, хоць па факце былі праблемы з дыскам, былі праблемы з даступнасцю базы.
На мой погляд, гэта адна з самых дзіўных праблем, якую я даследаваў вельмі доўга, вельмі шмат логаў перачытаў, перакалупаў і назваў яе кластар-сімулянтам.
Праблема складалася ў тым, што стары майстар не мог стаць звычайнай рэплікай, т. е. Patroni яго запускаў, Patroni паказваў, што гэты вузел прысутнічае як рэпліка, але ў той жа час ён не быў звычайнай рэплікай. Цяпер вы ўбачыце, чаму. Гэта ў мяне захавалася з разбору той праблемы.
І з чаго ўсё пачалося? Пачалося, як і ў папярэдняй праблеме, з дыскавых тармазоў. У нас былі коміты па секундзе, па дзве.
Былі абрывы злучэнняў, г. зн. кліенты рваліся.
Былі блакіроўкі рознай цяжкасці.
І, адпаведна, дыскавая падсістэма не вельмі спагадная.
І самае загадкавае для мяне гэта прыляцеў immediate shutdown request. У Postgres ёсць тры рэжыму выключэння:
- Гэта graceful, калі мы чакаем, калі ўсе кліенты адключацца самастойна.
- Ёсць fast, калі мы прымушаем кліентаў адключыцца, таму што мы ідзем на выключэнне.
- І immediate. У дадзеным выпадку immediate нават не паведамляе кліентам, што трэба адключацца, ен проста выключаецца без папярэджання. А ўсім кліентам ужо аперацыйнай сістэмай адпраўляецца паведамленне RST (TCP-паведамленне, што злучэнне перапынена і кліенту больш няма чаго лавіць).
Хто паслаў гэты сыгнал? Фонавыя працэсы Postgres адзін аднаму такія сігналы не пасылаюць, т. е. гэта kill-9. Яны адзін аднаму такое не шлюць, яны на такое толькі рэагуюць, т. е. гэта экстраны перазапуск Postgres. Хто яго паслаў, я не ведаю.
Я паглядзеў па камандзе "last" і я ўбачыў аднаго чалавека, хто таксама залагініў гэты сервер разам з намі, але я пасаромеўся задаваць пытанне. Магчыма, гэта быў kill-9. Я б у логах убачыў kill -9, т.я. Postgres піша, што прыняў kill -9, але я не ўбачыў гэтага ў логах.
Разбіраючыся далей, я ўбачыў, што Patroni не пісаў у лог даволі доўга 54 секунды. І калі параўнаць два timestamp, тут прыкладна 54 секунды не было паведамленняў.
І за гэты час адбыўся аўтафайлавер. Patroni тут зноў адпрацаваў выдатна. У нас стары майстар быў недаступны, нешта з ім адбывалася. І пачаліся выбары новага майстра. Тут усё адпрацавалася добра. У нас pgsql01 стаў новым лідарам.
У нас ёсць рэпліка, якая стала майстрам. І ёсць другая рэпліка. І з другой рэплікай якраз былі праблемы. Яна спрабавала пераканфігуравацца. Як я разумею, яна спрабавала памяняць recovery.conf, перазапусціць Postgres і падключыцца да новага майстра. Яна кожныя 10 секундаў піша паведамленні, што яна спрабуе, але ў яе не атрымліваецца.
І падчас гэтых спроб на стары майстар прылятае immediate-shutdown сігнал. Майстар перазапускаецца. І таксама recovery спыняецца, таму што стары майстар сыходзіць у перазагрузку. Т. е. рэпліка не можа да яго падлучыцца, таму што ён у рэжыме выключэння.
У нейкі момант яна зарабіла, але рэплікацыя пры гэтым не запусцілася.
У мяне ёсьць адзіная гіпотэза, што ў recovery.conf быў адрас старога майстра. І калі з'явіўся новы майстар, то другая рэпліка па-ранейшаму спрабавала далучыцца да старога майстра.
Калі Patroni запусціўся на другой рэпліцы, вузел запусціўся, але не змог падлучыцца па рэплікацыі. І ўтварыўся лаг рэплікацыі, які выглядаў прыкладна так. Т. е. усе тры вузлы былі на месцы, але другі вузел адставаў.
Пры гэтым, калі паглядзець на логі, якія пісаліся, можна было ўбачыць, што рэплікацыя не можа запусціцца, бо часопісы транзакцый адрозніваюцца. І тыя часопісы транзакцый, якія прапануе майстар, якія пазначаны ў recovery.conf, проста не падыходзяць нашаму бягучаму вузлу.
І тут я дапусціў памылку. Мне трэба было прыйсці паглядзець, што тамака ў recovery.conf, каб праверыць сваю гіпотэзу, што мы падлучаемся не да таго майстра. Але я тады толькі-толькі разбіраўся з гэтым і мне гэта ў галаву не прыйшло, альбо я ўбачыў, што рэпліка адстае і яе давядзецца пераналіваць, т. е. я неяк праз рукавы адпрацаваў. Гэта быў мой вушак.
Праз 30 хвілін ужо прыйшоў адмін, т. е. я перазапусціў Patroni на рэпліцы. Я ўжо на ёй крыж паставіў, я думаў, што яе давядзецца пераналіваць. І падумаў перазапушчу Patroni, можа быць, атрымаецца што-небудзь добрае. Запусціўся recovery. І база нават адкрылася, яна была гатова прымаць злучэнні.
Рэплікацыя запусцілася. Але праз хвіліну яна адвалілася з памылкай, што ёй не падыходзіць часопісы транзакцый.
Я падумаў, што яшчэ раз перазапушчу. Я перазапусціў яшчэ раз Patroni, прычым я не перазапускаў Postgres, а перазапускаў менавіта Patroni у надзеі, што ён магічнай выявай запусціць базу.
Рэплікацыя зноў запусцілася, але адзнакі ў часопісе транзакцый адрозніваліся, яны былі не тымі, якія былі пры папярэдняй спробе запуску. Рэплікацыя зноў спынілася. І паведамленне было ўжо крыху іншае. І яно было для мяне не асабліва інфарматыўнае.
І тут мне прыходзіць у галаву а што, калі я перазапушчу Postgres, тым часам на бягучым майстру зраблю checkpoint, каб пасунуць кропку ў часопісе транзакцый ледзь наперад, каб recovery пачалося з іншага моманту? Плюс тамака яшчэ былі запасы WAL у нас.
Я перазапусціў Patroni, зрабіў пару checkpoints на майстру, пару рэстарт-паінтаў на рэпліцы, калі яна адкрылася. І гэта дапамагло. Я доўга думаў, чаму гэта дапамагло і як гэта спрацавала. І рэпліка запусцілася. І рэплікацыя больш не рвалася.
Такая праблема для мяне адна з больш загадкавых, над якой я да гэтага часу ламаю галаву, што там адбывалася насамрэч.
Якія высновы тут? Patroni можа адпрацаваць, як задумана і без усялякіх памылак. Але пры гэтым - гэта не 100% гарантыя, што ў нас усё добра. Рэпліка можа запусціцца, але пры гэтым можа знаходзіцца ў паў-працоўным стане, і з дадаткам нельга працаваць з такой рэплікай, таму што там будуць старыя дадзеныя.
І пасля файлавер заўсёды трэба правяраць, што ў нас усё ў парадку з кластарам, т. е. ёсць патрэбную колькасць рэплік, няма лага рэплікацыі.
І падчас разгляду гэтых праблем я сфармулюю рэкамендацыі. Я паспрабаваў іх аб'яднаць у два слайды. Напэўна, усе гісторыі можна было аб'яднаць у два слайды і толькі іх расказаць.
Калі вы карыстаецеся Patroni, у вас абавязкова павінен быць маніторынг. Вы заўсёды павінны ведаць, калі адбыўся аўтафайлавер, таму што, калі вы не ведаеце, што ў вас быў аўтафайлавер, вы не кантралюеце кластар. І гэта дрэнна.
Пасля кожнага файлавер мы заўсёды павінны рукамі праверыць кластар. Мы павінны пераканацца, што ў нас заўсёды актуальная колькасць рэплік, няма лага рэплікацыі, у логах няма памылак, звязаных з струменевай рэплікацыяй, з Patroni, з сістэмай DCS.
Аўтаматыка можа паспяхова адпрацаваць, Patroni – гэта вельмі добрая прылада. Ён можа адпрацаваць, але гэта не прывядзе кластар да патрэбнага стану. І калі мы пра гэта не даведаемся, то ў нас будуць праблемы.
І Patroni - гэта не срэбная куля. Мы ўсё роўна павінны мець уяўленне, як працуе Postgres, як працуе рэплікацыя і пра тое, як Patroni працуе з Postgres, і як забяспечваецца ўзаемадзеянне паміж вузламі. Гэта трэба для таго, каб умець правіць рукамі якія ўзнікаюць праблемы.
Як я падыходжу да пытання дыягностыкі? Так склалася, што мы працуем з рознымі кліентамі і стэка ELK ні ў каго няма, і даводзіцца ў логах разбірацца, адкрыўшы 6 кансоляў і 2 укладкі. У адной укладцы - гэта логі Patroni для кожнага вузла, у іншай укладцы - гэта логі Consul, альбо Postgres пры неабходнасці. Дыягнаставаць гэта вельмі цяжка.
Якія я выпрацаваў падыходы? Па-першае, я заўсёды гляджу, калі прыйшоў файлавер. І для мяне гэта нейкі водападзел. Я гляджу, што адбылося да файлаверу, падчас файлаверу і пасля файлаверу. Файловер мае дзве адзнакі: гэты час пачатку і канца.
Далей я ў логах гляджу падзеі да файлаверу, што папярэднічала файлаверу, т. е. я шукаю чыннікі, чаму адбыўся файловер.
І гэта дае карціну разумення, што адбывалася і што можна зрабіць у будучыні, каб такія абставіны не наступілі (і як следства не адбылося файлавер).
І куды мы глядзім звычайна? Я гляджу:
- Спачатку ў логі Patroni.
- Далей гляджу логі Postgres, альбо логі DCS у залежнасці ад таго, што знайшлося ў логах Patroni.
- І логі сістэмы таксама часам даюць разуменне таго, што прычынілася для файлаверу.
Як я стаўлюся да Patroni? Да Patroni я стаўлюся вельмі добра. На мой погляд, гэта найлепшае, што ёсць сёння. Я ведаю шмат іншых прадуктаў. Гэта Stolon, Repmgr, Pg_auto_failover, PAF. 4 інструменты. Я спрабаваў іх усе. Patroni мне спадабаўся больш за ўсё.
Калі мяне спытаюць: "Ракамендую я Patroni?". Я скажу, што так, таму што Patroni мне падабаецца. І, мне здаецца, я навучыўся яго гатаваць.
Калі вам цікава паглядзець, якія яшчэ бываюць праблемы з Patroni, акрамя тых праблем, якія я агучыў, вы заўседы можаце схадзіць на старонку на GitHub. Там шмат розных гісторый і там абмяркоўваецца шмат цікавых праблем. І па выніку нейкія багі былі заведзены і вырашаны, г. зн. гэта цікавае чытво.
Там ёсць цікавыя гісторыі аб тым, як людзі страляюць сабе ў нагу. Вельмі пазнавальна. Ты чытаеш і разумееш, што рабіць так не трэба. Паставіў сабе галачку.
І хацелася б сказаць вялікі дзякуй кампаніі Zalando за тое, што яны развіваюць гэты праект, а менавіта Аляксандру Кукушкіну і Аляксею Клюкіну. Аляксей Клюкін - гэта адзін з суаўтараў, ён ужо ў Zalando не працуе, але гэта два чалавекі, якія пачыналі працаваць з гэтым прадуктам.
І я лічу, што Patroni гэта вельмі крутая штука. Я задаволены, што яна ёсць, з ёю цікава. І вялікі дзякуй усім кантрыб'ютарам, якія пішуць патчы ў Patroni. Я спадзяюся, што Patroni будзе з узростам станавіцца больш сталым, крутым і працаздольным. Ён і так працаздольны, але, я спадзяюся, што ён будзе станавіцца яшчэ лепшым. Таму калі вы плануеце выкарыстоўваць у сябе Patroni, то не бойцеся. Гэта добрае рашэнне, яго можна ўкараняць і выкарыстоўваць.
На гэтым усё. Калі ў вас ёсць пытанні, задавайце.
пытанні
Дзякуй за даклад! Калі пасля файлавер усё роўна трэба туды глядзець вельмі ўважліва, то навошта нам аўтаматычны файлавер?
Бо гэта новая штука. Мы працуем з ёй усяго толькі год. Лепш перастрахавацца. Мы жадаем зайсці і паглядзець, што сапраўды ўсё адпрацавала так, як трэба. Гэта ўзровень дарослага недаверу - лепш пераправерыць і паглядзець.
Напрыклад, мы раніцай зайшлі і паглядзелі, так?
Не раніцай, мы звычайна даведаемся аб аўтафайловеры практычна адразу. У нас прыходзяць апавяшчэнні, мы бачым, што адбыўся аўтафайловер. Мы практычна адразу заходзім і глядзім. Але ўсе гэтыя праверкі павінны быць вынесены на ўзровень маніторынгу. Калі звяртацца да Patroni па REST API, есць history. Па history можна глядзець часавыя адзнакі, калі адбываўся файлавер. На аснове гэтага можна зрабіць маніторынг. Можна глядзець history, колькі тамака падзей было. Калі ў нас дадалося падзей, значыць, адбыўся аўтафайлавер. Можна схадзіць і паглядзець. Або наша аўтаматыка ў маніторынгу праверыла, што ў нас усе рэплікі на месцы, лага няма і ўсё добра.
Дзякуй!
Вялікі дзякуй за выдатны аповяд! Калі мы вынеслі кластар DCS кудысьці ўдалячынь ад кластара Postgres, то гэты кластар таксама трэба абслугоўваць перыядычна? Якія best practices у тым, што нейкія кавалкі кластара DCS трэба выключаць, нешта з імі рабіць і г. д.? Як пры гэтым жыве ўся гэтая канструкцыя? І якім чынам гэтыя рэчы рабіць?
Для адной кампаніі трэба было зрабіць матрыцу праблем, што адбываецца, калі які-небудзь з кампанентаў або некалькі кампанентаў выходзіць з ладу. Па гэтай матрыцы мы паслядоўна перабіраем усе кампаненты і які будуецца сцэнары ў выпадку адмовы гэтых кампанентаў. Адпаведна на кожны сцэнарый адмовы можна мець план дзеянняў для аднаўлення. І ў выпадку DCS гэта ідзе як частка стандартнай інфраструктуры. І адмін гэта адмініструе, і мы ўжо належым на адмінаў, якія гэта адмініструюць і на яго здольнасці правіць гэта ў выпадку аварый. Калі DCS наогул няма, тое яго разгортваем мы, але пры гэтым асоба за ім не сочым, таму што мы не адказваем за інфраструктуру, але даем рэкамендацыі як і што заманіторыць.
Т. е. ці правільна я зразумеў, што трэба адключыць Patroni, адключыць файлавер, адключыць усё перад тым, як рабіць нешта з хастамі?
Гэта залежыць ад таго, колькі ў нас вузлоў у DCS-кластары. Калі вузлоў шмат і калі мы выводзім са строю ўсяго толькі адзін з вузлоў (рэпліку), то ў кластары захоўваецца кворум. І Patroni застаецца працаздольным. І нічога не трыгіруецца. Калі ў нас нейкія складаныя аперацыі, якія закранаюць больш вузлоў, адсутнасць якіх можа разваліць кворум, то так, магчыма, мае сэнс паставіць Patroni на паўзу. У яго ёсць адпаведная каманда - patronictl pause, patronictl resume. Мы проста ставім на паўзу, і аўтафайлавер не спрацоўвае тым часам. Мы робім maintenance на DCS-кластары, потым здымаем паўзу і працягваем жыць.
Дзякуй вялікі!
Вялікі дзякуй за даклад! Як прадуктовая каманда ставіцца да таго, што дадзеныя могуць згубіцца?
Прадуктовым камандам па дуль, а тымліды хвалююцца.
Якія там ёсць гарантыі?
З гарантыямі вельмі цяжка. Ёсць даклад у Аляксандра Кукушкіна "Як разлічваць RPO і RTO", г.зн. час аднаўлення і колькі дадзеных можам страціць. Я думаю, трэба знайсці гэтыя слайды і іх вывучыць. Наколькі я памятаю, тамака ёсць пэўныя крокі, як разлічваць гэтыя рэчы. Колькі транзакцый можам страціць, колькі звестак мы можам страціць. Як варыянт можам выкарыстоўваць сінхронную рэплікацыю на ўзроўні Patroni, але гэта палка аб двух канцах: мы альбо маем надзейнасць дадзеных, альбо губляем у хуткасці. Ёсць сінхронная рэплікацыя, але яна таксама не гарантуе 100%-ную абарону ад страты дадзеных.
Аляксей, дзякуй за цудоўны даклад! Ці ёсць досвед выкарыстання Patroni для zero level protection? Т. е. у купэ з сінхронным standby? Гэта першае пытанне. І другое пытанне. Вы выкарыстоўвалі розныя рашэнні. Мы выкарыстоўвалі Repmgr, але без аўтафайлавера і зараз плануем падключаць аўтафайлавер. І разглядаем Patroni як альтэрнатыўнае рашэнне. Што вы можаце сказаць у якасці плюсаў менавіта ў параўнанні з Repmgr?
Першае пытанне пра сінхронныя рэплікі было. У нас ніхто сінхронную рэплікацыю не выкарыстоўвае, таму што ўсім страшна (Ужо выкарыстоўваюць некалькі кліентаў, праблем з прадукцыйнасцю ў прынцыпе не заўважалі - Заўвага дакладчыка). Але мы для сябе выпрацавалі правіла, што ў кластары сінхроннай рэплікацыі павінна быць тры вузлы мінімум, таму што, калі ў нас два вузлы і калі майстар або рэпліка выйшлі са строю, то Patroni перакладае гэты вузел у Standalone-рэжым, каб прыкладанне працягвала працаваць. У гэтым выпадку ёсць рыскі страты дадзеных.
Адносна другога пытання, то мы выкарыстоўвалі Repmgr і да гэтага часу выкарыстоўваем у некаторых кліентах па гістарычных прычынах. Што можна сказаць? У Patroni аўтафайлавер са скрынкі, у Repmgr аўтафайлавер ідзе ўжо як дадатковая фіча, якую трэба ўключыць. Трэба запусціць Repmgr daemon на кожным вузле і тады мы можам аўтафайлавер наладзіць.
Repmgr правярае - ці жывыя вузлы Postgres. Repmgr працэсы правяраюць існаванне адзін аднаго, гэта не вельмі эфектыўны падыход. могуць быць складаныя выпадкі сеткавай ізаляцыі пры якой вялікі Repmgr кластар можа разваліцца на некалькі невялікіх і працягнуць працу. Даўно не сачу за Repmgr, можа гэта пафіксілі… а можа і не. А вось вынас інфармацыі аб стане кластара ў DCS, як робіць Stolon, Patroni, гэта найболей жыццяздольны варыянт.
Аляксей, у мяне пытанне, можа быць, ламерскае. Вы ў адным з першых прыкладаў DCS вынеслі з лакальнай машыны на выдалены вузел. Разумеем, што сетка - гэта рэч, якая мае свае асаблівасці, яна сама па сабе жыве. І што адбудзецца, калі па нейкім чынніку DCS-кластар стаў недаступны? Чыннікі казаць не буду, іх можа быць маса: ад крывых рук сецявікоў да рэальных праблем.
Я не прамовіў гэта ўслых, але кластар DCS павінен быць таксама адмоваўстойлівасцю, т. е. гэта няцотная колькасць вузлоў, каб кворум мог сабрацца. Што адбываецца, калі кластар DCS стаў недаступны, ці не можа сабрацца кворум, т. е. нейкі сеткавы спліт ці адмова вузлоў? У гэтым выпадку кластар Patroni пераходзіць у read only рэжым. Кластар Patroni не можа вызначыць стан кластара і што яму рабіць. Ён не можа звязацца з DCS і захаваць тамака новы стан кластара, таму ўвесь кластар пераходзіць у read only. І чакае ці ручнога ўмяшання ад аператара ці калі DCS адновіцца.
Грубіянска кажучы, DCS для нас становіцца сэрвісам гэтак жа важным, як і сама база?
Так так. У вельмі шматлікіх сучасных кампаніях Service Discovery - гэта неад'емная частка інфраструктуры. Ён укараняецца нават раней, чым з'явілася нават база даных у інфраструктуры. Умоўна кажучы, запусціліся інфраструктуру, разгарнуліся ў ДЦ, а ў нас адразу Service Discovery ёсць. Калі гэта Consul, то на ім і DNS можа быць пабудаваны. Калі гэта Etcd, то можа быць частка з кластара Kubernetes, у якім будзе ўжо ўсё астатняе разгортвацца. Мне здаецца, што Service Discovery - гэта ўжо неад'емная частка сучасных інфраструктур. І аб ім думаюць значна раней, чым аб базах дадзеных.
Дзякуй!
Крыніца: habr.com