Patroni негизги максаты PostgreSQL үчүн жогорку жеткиликтүүлүгүн камсыз кылуу болуп саналат. Бирок Patroni даяр инструмент эмес, жөн гана шаблон (бул, жалпысынан, документтерде айтылган). Бир караганда, Patroni'ни сыноо лабораториясында орнотуп, анын кандай сонун курал экенин жана кластерди бузуу аракетибиздин канчалык оңой экенин көрө аласыз. Бирок, иш жүзүндө, өндүрүш чөйрөсүндө, ар дайым эле сыноо лабораториясындагыдай кооз жана жарашыктуу боло бербейт.
Мен өзүм жөнүндө бир аз айтып берейин. Мен системалык администратор болуп иштей баштадым. Веб иштеп чыгууда иштеген. Мен Data Egret компаниясында 2014-жылдан бери иштейм. Компания Postgres тармагында консалтинг менен алектенет. Жана биз так Postgres кызматын көрсөтөбүз жана биз Postgres менен күн сайын иштейбиз, ошондуктан операцияга байланыштуу ар кандай тажрыйбага ээбиз.
Ал эми 2018-жылдын аягында биз акырындык менен Patroni колдоно баштадык. Ал эми кандайдыр бир тажрыйба топтолду. Кандайдыр бир жол менен диагноз коюп, жөндөп, мыкты тажрыйбабызга келдик. Ал эми бул баяндамада мен алар жөнүндө сөз кылам.
Postgresтен тышкары, мен Linuxту жакшы көрөм. Мен аны тешип, изилдегенди жакшы көрөм, өзөктөрдү чогултканды жакшы көрөм. Мен виртуалдаштырууну, контейнерлерди, докерди, Кубернеттерди жакшы көрөм. Мунун баары мени кызыктырат, анткени эски администратордук адаттар таасир этүүдө. Мен мониторинг менен алектенгенди жакшы көрөм. Мен башкарууга байланыштуу postgres нерселерди жакшы көрөм, б.а. репликация, резервдик. Ал эми бош убактымда Go программасында жазам. Мен программалык камсыздоо инженери эмесмин, мен жөн гана Go программасында өзүм үчүн жазам. Жана бул мага ырахат тартуулайт.
- Менин оюмча, көпчүлүгүңүздөр Postgresте HA (Жогорку жеткиликтүүлүк) жок экенин билесиздер. HA алуу үчүн бир нерсени орнотуп, конфигурациялап, аракет кылып, аны алышыңыз керек.
- Бир нече инструменттер бар жана Patroni алардын бири HA абдан сонун жана абдан жакшы чечет. Бирок мунун бардыгын сыноо лабораториясына коюу жана аны иштетүү менен, биз анын бардыгы иштеп жатканын, кээ бир көйгөйлөрдү кайра чыгара алабыз, Патрони аларды кантип тейлеп жатканын көрө алабыз. Жана биз мунун баары сонун иштеп жатканын көрөбүз.
- Бирок иш жүзүндө ар кандай көйгөйлөргө туш болдук. Ал эми мен бул көйгөйлөр тууралуу сөз кылам.
- Мен сизге кантип диагноз койгонубузду, эмнени оңдогонубузду айтып берем - бул бизге жардам бердиби же жокпу.
- Мен сизге Patroni кантип орнотуш керек экенин айтпай эле коёюн, анткени сиз Интернетте гуглга кайрылсаңыз болот, анын баары кантип башталарын, кантип конфигурацияланганын түшүнүү үчүн конфигурация файлдарын карап көрсөңүз болот. Сиз схемаларды, архитектураларды түшүнө аласыз, Интернеттен ал жөнүндө маалымат таба аласыз.
- Башка бирөөнүн башынан өткөн окуяны айтпай эле коёюн. Мен биз башыбыздан өткөн көйгөйлөр жөнүндө гана айтам.
- Жана мен Patroni жана PostgreSQLден тышкаркы көйгөйлөр жөнүндө айтпай эле коёюн. Эгерде, мисалы, балансташтырууга байланыштуу көйгөйлөр болсо, биздин кластер кыйрап калганда, мен бул тууралуу айтпай эле коёюн.
Ал эми баяндамабызды баштаардан мурун бир аз баш тартуу.
Бул көйгөйлөрдүн бардыгы бизде операциянын алгачкы 6-7-8 айында эле болгон. Убакыттын өтүшү менен биз өзүбүздүн ички мыкты тажрыйбабызга келдик. Ошондо биздин көйгөйлөрүбүз жок болду. Ошондуктан, отчёт болжол менен алты ай мурун жарыяланган, ошондо анын баары менин оюмда жаңы эле, мен мунун бардыгын эстеп калдым.
Докладды даярдоонун жүрүшүндө мен буга чейин эле эски постмортемдерди көтөрүп, журналдарды карадым. Ал эми кээ бир майда-чүйдөсүнө чейин унутулуп калышы мүмкүн, же кээ бир майда-чүйдөсүнө чейин проблемаларды талдоо учурунда толук изилденбей калышы мүмкүн, ошондуктан кээ бир учурда көйгөйлөр толук каралбай калгандай сезилиши мүмкүн, же кандайдыр бир маалымат жетишсиз. Ошентип, ушул учур үчүн кечирим сурайм.
Patroni деген эмне?
- Бул HA куруу үчүн шаблон болуп саналат. Документте ушундай деп жазылган. Ал эми менин көз карашым боюнча, бул абдан туура тактоо. Патрони сиздин бардык көйгөйлөрүңүздү чече турган күмүш ок эмес, башкача айтканда, анын иштеши жана пайда алып келиши үчүн аракет кылуу керек.
- Бул ар бир маалымат базасы кызматына орнотулган агент кызматы жана Postgres үчүн баштапкы системанын бир түрү. Ал Postgresти баштайт, токтотот, кайра баштайт, конфигурациялайт жана кластериңиздин топологиясын өзгөртөт.
- Демек, кластердин абалын сактоо үчүн, анын учурдагы өкүлчүлүгү, көрүнүп тургандай, кандайдыр бир сактагыч керек. Жана ушул көз караштан алганда, Патрони тышкы системада мамлекетти сактоо жолуна түшкөн. Бул бөлүштүрүлгөн конфигурацияларды сактоо системасы. Бул Etcd, Consul, ZooKeeper же kubernetes Etcd болушу мүмкүн, б.а. ушул варианттардын бири.
- Патронинин өзгөчөлүктөрүнүн бири - сиз автофилерди кутудан чыгарып, аны орнотуу менен гана аласыз. Салыштыруу үчүн Repmgr ала турган болсок, анда филер ошол жерде камтылган. Repmgr менен биз которууну алабыз, бирок биз автофилер керек болсо, анда аны кошумча конфигурациялашыбыз керек. Патрониде кутудан чыккан автофилер мурунтан эле бар.
- Жана башка көптөгөн нерселер бар. Мисалы, конфигурацияларды тейлөө, жаңы репликаларды куюу, резервдик көчүрүү ж.б.
Ал эми кичинекей натыйжасы - Patroni негизги милдети - биздин кластер иштеши үчүн жана колдонмо кластердин топологиясындагы өзгөрүүлөрдү байкабашы үчүн автофайлды жакшы жана ишенимдүү жасоо.
Бирок биз Patroni колдоно баштаганда, биздин система бир аз татаалдашат. Эгерде мурун бизде Postgres болсо, анда Patroni колдонгондо биз Patroni алабыз, мамлекет сакталган жерде DCS алабыз. Анан баары кандайдыр бир жол менен иштеши керек. Анда эмне туура эмес болушу мүмкүн?
бузулушу мүмкүн:
- Postgres бузулушу мүмкүн. Бул мастер же реплика болушу мүмкүн, алардын бири иштебей калышы мүмкүн.
- Патрони өзү сынып калышы мүмкүн.
- Мамлекет сакталган DCS бузулушу мүмкүн.
- Ал эми тармак бузулушу мүмкүн.
Ушул пункттардын бардыгын мен докладда карап чыгам.
Мен иштин көптөгөн компоненттерин камтыган көз караштан эмес, алар татаалдашып кеткендиктен карап чыгам. Ал эми субъективдүү сезимдердин көз карашынан алганда, бул иш мен үчүн оор болгон, аны ажыратуу кыйын болгон ... жана тескерисинче, кээ бир иш жеңил болгон жана аны ажыратуу оңой болгон.
Ал эми биринчи учур эң оңой. Бул биз маалымат базасы кластерин алып, ошол эле кластерге DCS сактагычыбызды орнотконубузда. Бул эң кеңири таралган ката. Бул архитектура курууда ката, башкача айтканда, бир жерде ар кандай компоненттерди бириктирүү.
Ошентип, бир филер бар болчу, келгиле, эмне болгонун чечүүгө баралы.
Жана бул жерде биз филер качан болгонуна кызыгып жатабыз. Башкача айтканда, биз кластердик абал өзгөргөн учурга кызыкдарбыз.
Бирок файл берүүчү дайыма эле көз ирмемдик боло бербейт, б.а. эч кандай убакыт бирдигин талап кылбайт, кечиктирилиши мүмкүн. Бул узакка созулушу мүмкүн.
Демек, анын башталышы жана аяктоо убактысы бар, б.а. бул үзгүлтүксүз окуя. Жана биз бардык окуяларды үч интервалга бөлөбүз: бизде филерге чейин, филер учурунда жана файлдан кийин убакыт бар. Башкача айтканда, биз бул хронологиядагы бардык окуяларды карайбыз.
Ал эми биринчи нерсе, филер болгон кезде, биз эмненин себебин издейбиз, эмнеге эмне себеп болгон?
Биз журналдарды карасак, алар классикалык Patroni журналдары болот. Аларда сервер кожоюн болуп калганын, кожоюндун ролу ушул түйүнгө өткөнүн айтат. Бул жерде баса белгиленет.
Андан кийин, биз филер эмне үчүн болгонун, башкача айтканда, башкы ролдун бир түйүндөн экинчи түйүнгө өтүшүнө себеп болгон кандай окуялар болгонун түшүнүшүбүз керек. Жана бул учурда, баары жөнөкөй. Сактоо тутуму менен иштешүүдө ката кетти. Мастер DCS менен иштей албасын түшүндү, башкача айтканда, өз ара аракеттенүүдө кандайдыр бир көйгөй бар. Анан эми кожоюн боло албасын айтып, кызматтан кетет. Бул сап "менчиктештирүү" дал ушуну айтат.
Эгерде биз файлдын алдында болгон окуяларды карасак, анда устанын улантуусунун көйгөйү болгон себептерди көрө алабыз.
Эгерде биз Patroni журналдарын карасак, бизде көп каталар, тайм-ауттар бар экенин көрөбүз, б.а. Patroni агенти DCS менен иштей албайт. Бул учурда, бул 8500 портунда байланышып жаткан консул агенти.
Ал эми бул жерде көйгөй Patroni жана маалымат базасы бир хостто иштеп жатат. Ошол эле түйүндө консулдук серверлер ишке киргизилген. Серверде жүктү түзүү менен биз консулдук серверлер үчүн да көйгөйлөрдү жараттык. Алар туура сүйлөшө алышкан жок.
Бир нече убакыт өткөндөн кийин, жүк басаңдагандан кийин, биздин Patroni агенттер менен кайрадан байланыша алды. Кадимки иш кайра жанданды. Жана ошол эле Pgdb-2 сервери кайрадан кожоюн болуп калды. Башкача айтканда, түйүн кожоюндун ыйгарым укуктарынан баш тартып, андан кийин аларды кайра тартып алган, башкача айтканда, баары мурункудай болуп кайтып келген кичинекей бурулуу болду.
Жана бул жалган сигнал катары каралышы мүмкүн, же Патрони баарын туура кылган деп эсептесе болот. Башкача айтканда, кластердин абалын сактай албасын түшүнүп, бийлигин алып салды.
Жана бул жерде маселе консулдук серверлер базалар менен бир аппараттык жабдыкта болгондугуна байланыштуу келип чыкты. Демек, ар кандай жүктөө: дисктердеги же процессорлордогу жүк болобу, Консул кластери менен өз ара аракеттенүүгө да таасирин тийгизет.
Анан чогуу жашабаш керек деп чечтик, Консулга өзүнчө кластер бөлүп бердик. Ал эми Патрони буга чейин өзүнчө Консул менен иштеп жаткан, башкача айтканда өзүнчө Postgres кластери, өзүнчө Консул кластери бар болчу. Бул чогуу жашабашы үчүн булардын баарын алып жүрүү жана сактоо боюнча негизги көрсөтмө.
Опция катары, сиз ttl, loop_wait, retry_timeout параметрлерин бура аласыз, б.а. бул параметрлерди көбөйтүү менен бул кыска мөөнөттүү жүктүн эң жогорку чегинен чыгууга аракет кылыңыз. Бирок бул эң ылайыктуу вариант эмес, анткени бул жүк көп убакытка созулушу мүмкүн. Жана биз жөн гана бул параметрлердин бул чегинен чыгабыз. Жана бул чындап жардам бербеши мүмкүн.
Биринчи маселе, сиз түшүнгөндөй, жөнөкөй. ДКСти алып база менен кошо койдук, маселе чыкты.
Экинчи маселе биринчисине окшош. Ушундай эле нерсе, бизде дагы DCS системасы менен өз ара аракеттенүү көйгөйлөрү бар.
Эгерде биз журналдарды карасак, бизде кайрадан байланыш катасы бар экенин көрөбүз. Ал эми Патрони мен DCS менен иштеше албайм, андыктан учурдагы мастер реплика режимине өтөт дейт.
Эски кожоюн репликага айланат, бул жерде Патрони иштеп чыгат, ошондой болушу керек. Ал транзакциялар журналын артка түрүү үчүн pg_rewind иштетет, андан кийин жаңы мастерди кууп чыгуу үчүн жаңы мастерге туташат. Бул жерде Patroni, ал керек болсо, иштеп жатат.
Бул жерде биз файлдан мурунку жерди табышыбыз керек, башкача айтканда, бизде файлды түзүүгө себеп болгон каталар. Бул жагынан алганда, Patroni журналдары менен иштөө үчүн абдан ыңгайлуу болуп саналат. Ошол эле билдирүүлөрдү белгилүү бир аралыкта жазат. Ал эми биз бул журналдарды тез сыдырып баштасак, анда журналдардан журналдар өзгөргөнүн көрөбүз, бул кээ бир көйгөйлөр башталганын билдирет. Биз тез эле бул жерге кайтып келебиз, эмне болгонун көрөбүз.
Ал эми кадимки кырдаалда, журналдар ушундай көрүнөт. Кулпунун ээси текшерилет. Ал эми ээси, мисалы, өзгөргөн болсо, анда Patroni жооп бериши керек болгон кээ бир окуялар болушу мүмкүн. Бирок бул учурда биз жакшыбыз. Биз каталар башталган жерди издеп жатабыз.
Жана каталар пайда боло баштаган чекитке чейин жылдырып, биз автоматтык түрдө файлды которууну көрдүк. Жана биздин каталар DCS менен өз ара аракеттенүүгө байланыштуу болгондуктан жана биздин учурда биз Консулду колдонгондуктан, биз консулдук журналдарды да карайбыз, ал жерде эмне болгон.
Долбоордун убактысын жана консулдук журналдардагы убакытты болжолдуу түрдө салыштырып көрсөк, консулдук кластердеги кошуналарыбыз консулдук кластердин башка мүчөлөрүнүн бар экендигинен күмөн санай баштаганын көрөбүз.
Эгер сиз башка консулдук агенттердин журналдарын карасаңыз, анда тармактын кандайдыр бир кыйроосу болуп жатканын көрө аласыз. Ал эми консулдук кластердин бардык мүчөлөрү бири-биринин бар экенинен күмөн санашат. Жана бул филер үчүн түрткү болду.
Эгерде сиз бул каталарга чейин эмне болгонун карасаңыз, анда ар кандай каталар бар экенин көрүүгө болот, мисалы, мөөнөтү, RPC түшүп калды, башкача айтканда, консулдук кластердин мүчөлөрүнүн бири-бири менен өз ара аракеттенүүсүндө кандайдыр бир көйгөй бар экени анык. .
Эң жөнөкөй жооп - тармакты оңдоо. Бирок подиумда турган мен үчүн муну айтуу оңой. Бирок жагдайлар дайыма эле кардар тармагын оңдоого мүмкүн эмес экенин көрсөтүп турат. Ал DCда жашайт жана тармакты оңдоого, жабдууларга таасир эте албайт. Анан дагы башка варианттар керек.
Варианттар бар:
- Менин оюмча, документацияда жазылган эң жөнөкөй вариант - бул консулдук текшерүүлөрдү өчүрүү, башкача айтканда, бош массивди өткөрүү. Жана биз консулдук агентке эч кандай чек колдонбогула деп айтабыз. Бул текшерүүлөр менен биз бул тармак бороондорун этибарга албайбыз жана файлды баштабайбыз.
- Дагы бир вариант - raft_multiplierди эки жолу текшерүү. Бул Консул серверинин өзүнүн параметри. Демейки боюнча, ал 5 деп коюлган. Бул маани чөйрөлөр үчүн документация тарабынан сунушталат. Чынында, бул Консул тармагынын мүчөлөрүнүн ортосундагы билдирүүлөрдүн жыштыгына таасир этет. Чынында, бул параметр консулдук кластердин мүчөлөрүнүн ортосундагы кызматтык байланыштын ылдамдыгына таасир этет. Ал эми өндүрүш үчүн, түйүндөр тез-тез кабар алмашуу үчүн аны азайтуу сунушталат.
- Биз ойлоп тапкан дагы бир вариант - бул операциялык системанын процесс пландоочусу үчүн башка процесстердин арасында Консул процесстеринин артыкчылыктуулугун жогорулатуу. Мындай "жакшы" параметр бар, ал пландаштырууда OS пландоочусу тарабынан эске алынган процесстердин артыкчылыктуулугун аныктайт. Биз ошондой эле консулдук агенттер үчүн жакшы бааны азайттык, б.а. операциялык тутум Консул процесстерине иштөөгө жана кодун аткарууга көбүрөөк убакыт берүү үчүн артыкчылыкты жогорулатты. Биздин учурда бул биздин көйгөйдү чечти.
- Дагы бир вариант - Консулду колдонбоо. Менин 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 бизге дайыма керекпи? Көбүнчө эски кожоюнга барышыбыз керек, анын канчалык алыс кеткенин көрүүгө туура келет. Балким, транзакциялар журналынын сегменттерин текшерип, анда эмне бар экенин көрүңүз. Жана биз бул дайындарды жоготуп алабызбы же бул маалыматтарды чыгарып алуу үчүн эски мастерди өз алдынча режимде иштетүү керекпи же жокпу, түшүнүү үчүн.
Ошондон кийин гана биз бул маалыматты жокко чыгара турган чечимдерди кабыл алышыбыз керек же биз аны калыбына келтирип, бул түйүндү биздин кластерге реплика катары туташтыра алабыз.
Мындан тышкары, "maksimum_lag_on_failover" параметри бар. Демейки боюнча, эстутум мага кызмат кылса, бул параметр 1 мегабайтка барабар.
Ал кантип иштейт? Эгерде биздин реплика репликация лагында 1 мегабайт маалыматка артта калса, анда бул реплика шайлоого катышпайт. Эгер күтүлбөгөн жерден файл пайда болсо, Патрони кайсы репликалар артта калганын карайт. Алар транзакция журналдарынын көп саны менен артта калса, алар кожоюн боло алышпайт. Бул көп маалыматтарды жоготуп алуудан сактай турган абдан жакшы коопсуздук өзгөчөлүгү.
Бирок Patroni кластеринде жана DCSде репликациядан артта калуу белгилүү бир аралыкта жаңыланып турганында көйгөй бар. Мен 30 секунд демейки ttl мааниси деп ойлойм.
Демек, DCSдеги репликалар үчүн бир репликация лагы болгон жагдай болушу мүмкүн, бирок чындыгында такыр башка артта калуу болушу мүмкүн же такыр лаг болбошу мүмкүн, б.а. бул нерсе реалдуу убакыт эмес. Ал дайыма эле чыныгы сүрөттү чагылдыра бербейт. Анан ага кооз логика кылуунун кереги жок.
Ал эми жоготуу коркунучу дайыма бойдон калууда. Ал эми эң начар учурда бир формула, ал эми орточо учурда башка формула. Башкача айтканда, биз Patroni ишке ашырууну пландаштырып, канча маалыматтарды жоготуп алышыбызга баа бергенде, биз бул формулаларга таянышыбыз керек жана канча маалыматтарды жоготуп алышыбыз мүмкүн экенин элестетүүбүз керек.
Жана жакшы кабар бар. Эски кожоюн алдыга кеткенде, кээ бир фон процесстеринен улам алдыга кете алат. Башкача айтканда, кандайдыр бир автовакуум болгон, ал маалыматтарды жазып, транзакциялар журналына сактап койгон. Жана биз оңой эле көңүл бурбай, бул маалыматтарды жоготуп алабыз. Бул жерде эч кандай көйгөй жок.
Жана эгер maximum_lag_on_failover орнотулуп, файл пайда болсо, журналдар ушундай көрүнөт жана сиз жаңы мастерди тандооңуз керек. Реплика өзүн шайлоого катышууга жөндөмсүз деп баалап жатат. Ал эми лидерлик үчүн жарышка катышуудан баш тартат. Жана ал жаңы кожоюндун тандалышын күтөт, ошондо ал ага кошула алат. Бул маалымат жоготууга каршы кошумча чара болуп саналат.
Бул жерде бизде өнүмдөр командасы бар, алар өнүмүнүн Postgres менен көйгөйлөрү бар деп жазган. Ошол эле учурда мастердин өзүнө кирүү мүмкүн эмес, анткени ал SSH аркылуу жеткиликтүү эмес. Жана автофайл да болбойт.
Бул хост кайра жүктөлүүгө аргасыз болду. Кайра жүктөөдөн улам, автофайл болду, бирок мен азыр түшүнгөндөй, кол менен автоматтык файлды жасоо мүмкүн болгон. Ал эми кайра жүктөөдөн кийин, биз учурдагы мастер менен эмне болгонун көрөбүз.
Ошол эле учурда биз дисктерде көйгөйлөр бар экенин алдын ала билчүбүз, башкача айтканда, кайда казып, эмнени издеш керек экенин мониторингден мурун эле билчүбүз.
Биз постгрес журналына кирип, ал жерде эмне болуп жатканын көрө баштадык. Биз ал жерде бир, эки, үч секундга созулган милдеттенмелерди көрдүк, бул нормалдуу эмес. Биздин автовакуум абдан жай жана кызыктай иштей баштаганын көрдүк. Жана биз дискте убактылуу файлдарды көрдүк. Башкача айтканда, бул дисктер менен көйгөйлөрдүн бардык көрсөткүчтөрү.
Биз dmesg системасын карап чыктык (ядро журналы). Жана биз дисктердин биринде көйгөйлөр бар экенин көрдүк. Диск подсистемасы программалык Raid болгон. Биз /proc/mdstat карадык жана бизде бир диск жок экенин көрдүк. Башкача айтканда, 8 дисктен турган рейд бар, бизге бирөө жетишпей жатат. Эгерде сиз слайдды кылдаттык менен карасаңыз, анда бизде sde жок экендигин көрө аласыз. Бизде, шарттуу түрдө айтканда, диск чыгып кетти. Бул диск көйгөйлөрүн жаратты, ошондой эле Postgres кластери менен иштөөдө тиркемелер да көйгөйлөргө туш болушту.
Жана бул учурда Patroni бизге эч кандай жардам бербейт эле, анткени Patroni сервердин абалына, дисктин абалына мониторинг жүргүзүү милдетин албайт. Ал эми мындай жагдайларды сырттан мониторинг жүргүзүү аркылуу көзөмөлдөшүбүз керек. Биз тез эле тышкы мониторингге диск мониторингин коштук.
Анан ушундай ой пайда болду - тосмо же күзөтчү программа бизге жардам бере алабы? Бул учурда ал бизге жардам бербейт деп ойлогонбуз, анткени көйгөйлөр учурунда Патрони DCS кластери менен иштешүүнү улантып, эч кандай көйгөйдү көргөн эмес. Башкача айтканда, DCS жана Patroni көз карашы боюнча, кластер менен баары жакшы болчу, бирок чындыгында дискте көйгөйлөр бар, маалымат базасынын болушу менен көйгөйлөр бар.
Менин оюмча, бул мен көптөн бери изилдеп жүргөн эң кызык көйгөйлөрдүн бири, мен көп журналдарды окуп, кайра тандап, кластердик симулятор деп атадым.
Маселе эски кожоюндун кадимки реплика боло албаганында болгон, б.а. Патрони аны баштаган, Патрони бул түйүн реплика катары бар экенин көрсөткөн, бирок ошол эле учурда ал кадимки реплика эмес. Эми эмне үчүн экенин көрөсүз. Мен бул маселени талдоодон сактадым.
Анан баары кантип башталды? Бул мурунку көйгөйдөгүдөй эле, диск тормоздору менен башталды. Бизде бир секунд, эки милдеттенме бар болчу.
Байланыштарда үзгүлтүккө учураган, б.а., кардарлар үзүлгөн.
Ар кандай оордуктагы бөгөттөр болгон.
Жана, ошого жараша, диск подсистемасы абдан жооп бербейт.
Ал эми мен үчүн эң сырдуу нерсе - бул дароо өчүрүү өтүнүчү. Postgresтин үч өчүрүү режими бар:
- Бардык кардарлардын өз алдынча ажыратылышын күткөнүбүз жагымдуу.
- Биз кардарларды өчүрүүгө мажбурлаганда тез болот, анткени биз жабыла турган болдук.
- Жана дароо. Бул учурда, дароо кардарларга жабууну айтпайт, ал эскертүүсүз эле жабылат. Ал эми бардык кардарларга операциялык система мурунтан эле RST билдирүүсүн жөнөтөт (байланыш үзгүлтүккө учураган жана кардар кармай турган эч нерсеси жок деген TCP билдирүүсү).
Бул сигналды ким жиберди? Postgres фон процесстери бири-бирине мындай сигналдарды жөнөтпөйт, башкача айтканда, бул өлтүрүү-9. Алар мындай нерселерди бири-бирине жөнөтүшпөйт, алар мындай нерселерге гана реакция кылышат, б.а. бул Postgresтин шашылыш түрдө кайра башталышы. Ким жиберди, билбейм.
Мен "акыркы" буйругун карадым жана бул серверге биз менен кирген бир адамды көрдүм, бирок мен суроо берүүгө уялып кеттим. Балким, бул өлтүрүү болгон -9. Мен журналдарда өлтүрүү -9 көрмөкмүн, анткени Postgres өлтүрүү үчүн -9 талап кылынат дейт, бирок мен аны журналдарда көргөн жокмун.
Андан ары карасам, Патрони бир топ убакыт журналга жазбаганын көрдүм - 54 секунд. Ал эми эки убакыт белгисин салыштырсак, болжол менен 54 секунда эч кандай билдирүү болгон эмес.
Жана бул убакыттын ичинде автофайл бар болчу. Патрони бул жерде дагы жакшы иштеди. Биздин эски агайыбыз жеткиликсиз болуп калыптыр, ага бир нерсе болду. Ал эми жаңы кожоюнду шайлоо башталды. Бул жерде баары жакшы болду. Биздин pgsql01 жаңы лидер болуп калды.
Бизде устат болуп калган реплика бар. Анан экинчи жооп бар. Ал эми экинчи реплика менен көйгөйлөр бар болчу. Ал кайра конфигурациялоого аракет кылды. Мен түшүнгөндөй, ал recovery.conf файлын өзгөртүп, Postgresти өчүрүп күйгүзүп, жаңы мастерге туташууга аракет кылды. Ал аракет кылып жатат деп ар бир 10 секундда билдирүү жазат, бирок ал ийгиликке жетпейт.
Жана бул аракеттердин учурунда эски устага токтоосуз өчүрүү сигналы келет. Мастер кайра иштетилди. Жана ошондой эле калыбына келтирүү токтойт, анткени эски кожоюн кайра жүктөлөт. Башкача айтканда, реплика ага туташа албайт, анткени ал өчүрүү режиминде.
Кайсы бир убакта ал иштеген, бирок репликация башталган эмес.
Менин бир гана божомолум, recovery.conf ичинде эски башкы дарек бар болчу. Ал эми жаңы кожоюн пайда болгондо, экинчи реплика дагы эле эски кожоюнуна кошулууга аракет кылган.
Патрони экинчи репликада иштей баштаганда, түйүн иштей баштады, бирок кайталай алган жок. Жана ушул сыяктуу көрүнгөн репликация лагы пайда болду. Башкача айтканда, үч түйүн тең ордунда болчу, бирок экинчи түйүн артта калган.
Ошол эле учурда, эгер сиз жазылган журналдарды карасаңыз, транзакция журналдары башка болгондуктан, репликация башталбай калганын көрө аласыз. Мастер сунуштаган, recovery.conf дарегинде көрсөтүлгөн транзакция журналдары биздин учурдагы түйүнүбүзгө туура келбейт.
Бул жерде мен ката кетирдим. Мен келип, биз туура эмес кожоюнга туташып жаткан гипотезамды текшерүү үчүн recovery.conf файлында эмне болгонун көрүшүм керек болчу. Бирок кийин мен муну менен эле алектенип жүрдүм жана бул менин оюма да келген жок, же реплика артта калып, кайра толтурулушу керек экенин көрдүм, башкача айтканда, мен кандайдыр бир көңүл бурбай иштедим. Бул менин биргелешкен болчу.
30 мүнөттөн кийин админ келди, б.а. мен Патрониди репликада кайра иштеттим. Мен буга чейин эле чекит койдум, кайра толтуруу керек деп ойлогом. Анан мен ойлодум - мен Патрониди кайра иштетем, балким жакшы нерсе чыгат. Калыбына келтирүү башталды. Ал эми база да ачылган, ал байланыштарды кабыл алууга даяр болчу.
Репликация башталды. Бирок бир мүнөттөн кийин, ал транзакция журналдары ага ылайыктуу эмес деген ката менен кулады.
Мен кайра баштайм деп ойлогом. Мен Patronini кайра иштеттим, Postgresти кайра иштеткен жокмун, бирок ал сыйкырдуу түрдө маалымат базасын баштайт деген үмүт менен Patroni кайра иштеттим.
Репликация кайрадан башталды, бирок транзакциялар журналындагы белгилер ар кандай болгон, алар мурунку баштоо аракетине окшош эмес. Репликация кайра токтотулду. Ал эми билдирүү буга чейин бир аз башкача болгон. Анан мен үчүн абдан маалыматтуу болгон жок.
Анан мага ушундай болуп жатат - Postgresти кайра иштетсем эмне болот, ушул учурда мен транзакциялар журналындагы чекитти бир аз алдыга жылдыруу үчүн учурдагы мастерде текшерүү пунктун жасайм, ошондо калыбына келтирүү башка учурдан башталат? Мындан тышкары, бизде дагы эле WAL запастары бар болчу.
Мен Патрониди кайра иштеттим, мастерде бир нече текшерүү пункттарын жасадым, ал ачылганда репликада бир нече кайра баштоо чекиттерин жасадым. Жана жардам берди. Мен көпкө ойлондум, бул эмне үчүн жардам берет жана кандайча иштейт. Жана реплика башталды. Жана репликация мындан ары тытылган.
Мен үчүн мындай көйгөй эң табышмактуу маселелердин бири, мен ал жерде чындап эле эмне болгонун дагы эле табышмак.
Бул жерде кандай кесепеттер бар? Patroni каалагандай жана эч кандай катасыз иштей алат. Бирок, ошол эле учурда, бул бизде баары жакшы экенине 100% кепилдик бербейт. Реплика башталышы мүмкүн, бирок ал жарым жумушчу абалында болушу мүмкүн жана тиркеме мындай реплика менен иштей албайт, анткени эски маалыматтар болот.
Жана файлдан кийин, сиз дайыма кластерге баары туура келгенин текшерип турушуңуз керек, башкача айтканда, репликалардын талап кылынган саны бар, репликациядан артта калуу жок.
Жана ушул маселелердин үстүнөн жүрүп, мен сунуштарды берем. Мен аларды эки слайдга бириктирүүгө аракет кылдым. Кыязы, бардык окуяларды эки слайдга бириктирип, бир гана айтууга болот.
Patroni колдонгондо, сизде мониторинг болушу керек. Сиз автофайлдын качан болгонун ар дайым билишиңиз керек, анткени сизде автофайл бар экенин билбесеңиз, анда кластерди башкара албайсыз. Жана бул жаман.
Ар бир файлдан кийин кластерди кол менен текшерип турушубуз керек. Биз ар дайым репликалардын заманбап санына ээ болушубуз керек, репликациянын артта калуусу жок, агымдык репликацияга байланыштуу журналдарда каталар жок, Patroni менен, DCS системасы менен.
Автоматташтыруу ийгиликтүү иштей алат, Patroni абдан жакшы курал. Ал иштей алат, бирок бул кластерди керектүү абалга алып келбейт. А эгер муну билбесек, башыбызга кыйынчылык туулат.
Ал эми Патрони күмүш ок эмес. Биз дагы эле Postgres кантип иштээрин, репликация кантип иштээрин жана Patroni Postgres менен кантип иштээрин жана түйүндөрдүн ортосундагы байланыш кантип камсыз кылынарын түшүнүшүбүз керек. Бул өз колу менен көйгөйлөрдү чечүү үчүн зарыл.
Диагноз маселесине кантип кайрылам? Ошентип, биз ар кандай кардарлар менен иштейбиз жана эч кимде ELK стек жок жана биз 6 консолду жана 2 өтмөктү ачуу менен журналдарды иргешибиз керек. Бир өтмөктө бул ар бир түйүн үчүн Patroni журналдары, экинчи өтмөктө булар консулдук журналдар же керек болсо Postgres. Бул диагноз коюу абдан кыйын.
Мен кандай ыкмаларды колдондум? Биринчиден, мен ар дайым филер келгенде карап турам. Ал эми мен үчүн бул суу сактагыч. Мен толтуруучуга чейин, филер учурунда жана филерден кийин эмне болгонун карайм. Fileover эки белгиге ээ: бул башталуу жана аяктоо убактысы.
Андан кийин, мен файлдан мурун болгон окуяларды журналдардан карайм, б.а., мен файлдын эмне үчүн болгонун издейм.
Ал эми бул эмне болгонун жана мындай жагдайлар пайда болбошу үчүн келечекте эмне кылуу керек экенин түшүнүүнүн сүрөтүн берет (жана натыйжада эч кандай файл жок).
Анан биз көбүнчө кайда карайбыз? Мен көрүп атам:
- Биринчиден, Patroni журналдарында.
- Андан кийин, мен Patroni журналдарынан табылган нерсеге жараша Postgres журналдарын же DCS журналдарын карайм.
- Жана системалык журналдар кээде файлга эмне себеп болгонун түшүнүшөт.
Мен Патрониге кандай карайм? Мен Патрони менен абдан жакшы мамиледемин. Менин оюмча, бул бүгүнкү күндө эң жакшысы. Мен башка көптөгөн буюмдарды билем. Булар Stolon, Repmgr, Pg_auto_failover, PAF. 4 куралдар. Мен алардын баарын сынап көрдүм. Патрони менин сүйүктүүм.
Алар менден сурашса: "Мен Patroni сунуш кыламбы?". Мен ооба деп айтам, анткени мен Патронини жакшы көрөм. Анан кантип тамак жасаганды үйрөндүм деп ойлойм.
Эгер сиз Patroni менен мен айтып өткөн көйгөйлөрдөн башка дагы кандай көйгөйлөр бар экенин билгиңиз келсе, анда сиз ар дайым баракчаны текшере аласыз GitHub боюнча. Ал жерде ар кандай окуялар жана көптөгөн кызыктуу маселелер талкууланат. Натыйжада, кээ бир каталар киргизилген жана чечилген, башкача айтканда, бул кызыктуу окуу.
Бутуна ок аткандар тууралуу кызыктуу окуялар бар. Абдан маалыматтуу. Окуп, түшүнүп жатасың, мунун кереги жок. Мен өзүмдү тыкылдаттым.
Бул долбоорду иштеп чыккан Заландого, тактап айтканда Александр Кукушкин менен Алексей Клюкинге чоң рахмат айткым келет. Алексей Клюкин - авторлордун бири, ал Zalandoдо иштебейт, бирок бул эки адам бул продукт менен иштей баштаган.
Анан мен Патрони абдан сонун нерсе деп ойлойм. Мен анын бар экенине кубанычтамын, аны менен кызыктуу. Патрониге патчтарды жазган бардык салым кошкондорго чоң рахмат. Мен Патрони жаш өткөн сайын жетилген, салкын жана натыйжалуу болуп калат деп ишенем. Бул мурунтан эле иштеп жатат, бирок мен андан да жакшыраак болот деп үмүттөнөм. Ошондуктан, эгерде сиз Patroni колдонууну пландаштырсаңыз, анда коркпоңуз. Бул жакшы чечим, аны ишке ашырууга жана колдонууга болот.
Баары болду. Суроолоруңуз болсо, бериңиз.
суроолор
Баяндама үчүн рахмат! Эгер файлдан кийин дагы эле кылдаттык менен карап чыгышыңыз керек болсо, анда эмне үчүн бизге автоматтык толтургуч керек?
Анткени бул жаңы нерсе. Аны менен болгонубузга бир эле жыл болду. коопсуз болгон жакшы. Биз кирип, бардыгы чындап эле каалагандай болгонун көргүбүз келет. Бул чоңдорго ишенбөөчүлүктүн деңгээли - эки жолу текшерип, көрүп турган жакшы.
Мисалы, эртең менен барып карадык, туурабы?
Эртең менен эмес, биз адатта автофайл жөнүндө дароо билебиз. Биз эскертмелерди алабыз, биз автофайл пайда болгонун көрөбүз. Биз дээрлик дароо барып карап жатабыз. Бирок бул текшерүүлөрдүн баарын мониторинг деңгээлине жеткирүү керек. Эгер сиз Patroniге REST API аркылуу кирсеңиз, анда тарых бар. Тарых боюнча сиз файлдын качан болгон убакыт белгилерин көрө аласыз. Анын негизинде мониторинг жүргүзүүгө болот. Тарыхты, канча окуялар болгонун көрүүгө болот. Эгер бизде көбүрөөк окуялар болсо, анда автофайл пайда болду. Барып көрө аласыз. Же биздин мониторингди автоматташтыруу бизде бардык репликалар бар экенин текшерди, эч кандай артта калуу жок жана баары жакшы.
рахмат!
Улуу окуя үчүн чоң рахмат! Эгерде биз DCS кластерин Postgres кластеринен алысыраак жерге көчүрсөк, анда бул кластерди да мезгил-мезгили менен тейлөө керекпи? DCS кластеринин кээ бир бөлүктөрүн өчүрүү керек болгон мыкты тажрыйбалар кандай, алар менен бир нерсе кылуу керек ж.б.? Бул бүт түзүлүш кантип жашайт? Анан кантип буларды кыласың?
Бир компания үчүн көйгөйлөрдүн матрицасын түзүү керек болчу, эгерде компоненттердин бири же бир нече компоненттери иштебей калса эмне болот. Бул матрицага ылайык, биз бардык компоненттерди ырааттуу түрдө карап чыгабыз жана бул компоненттер иштебей калган учурда сценарийлерди курабыз. Демек, ар бир ийгиликсиздик сценарийи үчүн сизде калыбына келтирүү боюнча иш-аракеттер планы болушу мүмкүн. Ал эми DCS учурда, ал стандарттык инфраструктуранын бир бөлүгү катары келет. Ал эми администратор аны башкарат, биз буга чейин аны башкарган админдерге жана кырсык болгон учурда аны оңдоого ишенебиз. Эгерде DCS такыр жок болсо, анда биз аны жайгаштырабыз, бирок ошол эле учурда биз аны өзгөчө көзөмөлдөбөйбүз, анткени биз инфраструктура үчүн жооп бербейбиз, бирок кантип жана эмнени көзөмөлдөө боюнча сунуштарды беребиз.
Башкача айтканда, мен туура түшүндүмбү, мен Патрониди өчүрүп, файлды өчүрүп, хосттор менен эч нерсе жасаардан мурун баарын өчүрүшүм керекпи?
Бул DCS кластеринде канча түйүнүбүз бар экенине жараша болот. Эгерде түйүндөр көп болсо жана түйүндөрдүн бирин гана өчүрсөк (реплика), анда кластер кворумду сактайт. Ал эми Patroni иштеп жатат. Жана эч нерсе козголбойт. Эгерде бизде көбүрөөк түйүндөргө таасир этүүчү татаал операциялар бар болсо, алардын жоктугу кворумду бузушу мүмкүн, анда - ооба, Патрониди тыныгууга коюу акылга сыярлык болушу мүмкүн. Анын тиешелүү буйругу бар - patronictl тыныгуу, patronictl резюме. Биз жөн гана тындырабыз жана автофилер ошол убакта иштебейт. Биз DCS кластеринде техникалык тейлөө жүргүзөбүз, андан кийин тыныгууну алып, жашоону улантабыз.
Чоң рахмат!
Кабарыңыз үчүн чоң рахмат! Өндүрүм командасы дайындардын жоголушуна кандай карайт?
Продукциянын бригадалары кам көрүшпөйт, ал эми команда жетекчилери тынчсызданышат.
Кандай кепилдиктер бар?
Кепилдиктер абдан кыйын. Александр Кукушкиндин "RPO жана RTO кантип эсептөө керек" деген доклады бар, б.а. калыбына келтирүү убактысы жана биз канча маалыматтарды жоготуп алабыз. Бул слайддарды таап, изилдешибиз керек деп ойлойм. Менин эсимде, бул нерселерди кантип эсептөө боюнча конкреттүү кадамдар бар. Канча транзакцияларды жоготуп алабыз, канча маалыматтарды жоготуп алабыз. Опция катары биз Patroni деңгээлинде синхрондуу репликацияны колдоно алабыз, бирок бул эки миздүү кылыч: бизде же маалымат ишенимдүүлүгү бар, же ылдамдыкты жоготобуз. Синхрондуу репликация бар, бирок ал ошондой эле маалыматтарды жоготуудан 100% коргоого кепилдик бербейт.
Алексей, чоң отчет үчүн рахмат! Нөл деңгээлдеги коргоо үчүн Patroni колдонуу тажрыйбасы барбы? Башкача айтканда, синхрондуу күтүү менен бирге? Бул биринчи суроо. Жана экинчи суроо. Сиз ар кандай чечимдерди колдонгонсуз. Биз Repmgr колдондук, бирок автофилерсиз, эми биз автофилердик файлды кошууну пландап жатабыз. Ал эми биз Patroni альтернативалуу чечим катары эсептейбиз. 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 болсо, анда Кубернетес кластеринин бир бөлүгү болушу мүмкүн, анда калганынын баары жайгаштырылат. Менин оюмча, Service Discovery заманбап инфраструктуралардын ажырагыс бөлүгү болуп саналат. Жана алар бул тууралуу маалымат базаларына караганда алда канча эрте ойлонушат.
рахмат!
Source: www.habr.com