Макалада мен сизге PostgreSQL катачылыкка чыдамдуулук маселесине кандай мамиле кылганыбызды, эмне үчүн бул биз үчүн маанилүү болуп калганын жана аягында эмне болгонун айтып берем.
Бизде өтө жүктөлгөн кызмат бар: дүйнө жүзү боюнча 2,5 миллион колдонуучу, күн сайын 50 миңден ашуун активдүү колдонуучулар. Серверлер Ирландиянын бир аймагындагы Амазонада жайгашкан: 100+ ар кандай серверлер тынымсыз иштейт, алардын дээрлик 50ү маалымат базалары менен.
Бүткүл backend кардар менен туруктуу websocket байланышын камсыз кылган чоң монолиттүү Java колдонмосу. Бир нече колдонуучу бир эле учурда бир тактада иштегенде, алардын бардыгы өзгөрүүлөрдү реалдуу убакыт режиминде көрүшөт, анткени биз ар бир өзгөрүүнү маалымат базасына каттайбыз. Биздин маалымат базаларыбызга секундасына болжол менен 10 миң сурообуз бар. Редистеги эң жогорку жүктөөдө биз секундасына 80-100K суроо-талаптарды жазабыз.
Эмне үчүн биз Redisтен PostgreSQLге өттүк
Башында биздин кызмат сервердин оперативдүү эсинде бардык маалыматтарды сактаган негизги баалуулуктар дүкөнү болгон Redis менен иштеген.
Редистин жакшы жактары:
- Жогорку жооп ылдамдыгы, анткени баары эс тутумда сакталат;
- Камдык көчүрмөнү жана репликациялоонун оңойлугу.
Redis биз үчүн терс жактары:
- Чыныгы транзакциялар жок. Биз аларды колдонуу деңгээлинде туураганга аракет кылдык. Тилекке каршы, бул дайыма эле жакшы иштеген эмес жана өтө татаал кодду жазууну талап кылган.
- Маалыматтын көлөмү эстутумдун көлөмү менен чектелет. Маалыматтын көлөмү көбөйгөн сайын, эс тутум өсөт жана акырында биз тандалган инстанциянын мүнөздөмөлөрү менен таанышабыз, ал AWSде инстанциянын түрүн өзгөртүү үчүн кызматыбызды токтотууну талап кылат.
- Төмөнкү кечигүү деңгээлин дайыма кармап туруу зарыл, анткени. бизде суроо-талаптар абдан көп. Биз үчүн оптималдуу кечигүү деңгээли 17-20 мс. 30-40 мс деңгээлинде биз колдонмобуздун суроо-талаптарына узак жоопторду алабыз жана кызматтын начарлашы. Тилекке каршы, бул биз менен 2018-жылдын сентябрь айында болгон, анда Redis менен болгон учурлардын бири кандайдыр бир себептерден улам адаттагыдан 2 эсе көп кечиктирилген. Маселени чечүү үчүн, пландан тышкаркы тейлөө үчүн кызматты күндүн ортосунда токтоттук жана көйгөйлүү Redis инстанциясын алмаштырдык.
- Коддогу кичинекей каталар менен да берилиштердин дал келбестигин алуу оңой жана андан кийин бул маалыматтарды оңдоо үчүн код жазууга көп убакыт сарпталат.
Биз кемчиликтерди эске алып, кадимки транзакциялар менен жана күтүү убактысынан азыраак көз каранды болгон ыңгайлуураак нерсеге өтүү керек экенин түшүндүк. Биз изилдөө жүргүздүк, көптөгөн варианттарды талдап чыктык жана PostgreSQLди тандадык.
Биз жаңы маалымат базасына 1,5 жылдан бери өтүп жатабыз жана маалыматтардын аз гана бөлүгүн жылдырдык, ошондуктан азыр Redis жана PostgreSQL менен бир убакта иштеп жатабыз. Маалымат базаларынын ортосунда маалыматтарды жылдыруу жана которуу этаптары жөнүндө көбүрөөк маалымат жазылган .
Биз алгач көчүп баштаганда, биздин тиркеме түз маалымат базасы менен иштеп, мастер Redis жана PostgreSQLге кирди. PostgreSQL кластери мастерден жана асинхрондук репликациялуу репликадан турган. Берилиштер базасынын схемасы ушундай болгон:
PgBouncer ишке ашырылууда
Биз көчүп баратканда продукт да өнүгүп жатты: колдонуучулардын саны жана PostgreSQL менен иштеген серверлердин саны көбөйүп, бизде байланыштар жетишпей баштады. PostgreSQL ар бир туташуу үчүн өзүнчө процессти түзөт жана ресурстарды сарптайт. Белгилүү бир чекитке чейин туташуулардын санын көбөйтсөңүз болот, антпесе маалымат базасынын оптималдуу эмес иштешине мүмкүнчүлүк бар. Мындай кырдаалда идеалдуу вариант базанын алдында турган байланыш менеджерин тандоо болот.
Бизде байланыш менеджери үчүн эки вариант бар болчу: Pgpool жана PgBouncer. Бирок биринчиси маалымат базасы менен иштөөнүн транзакциялык режимин колдобойт, ошондуктан биз PgBouncerди тандадык.
Биз төмөнкү иш схемасын орноттук: биздин тиркеме бир PgBouncerге жетет, анын артында PostgreSQL мастерлери турат, ал эми ар бир мастердин артында асинхрондук репликациялуу бир реплика турат.
Ошол эле учурда биз PostgreSQLде маалыматтардын бардык көлөмүн сактай алган жокпуз жана маалымат базасы менен иштөө ылдамдыгы биз үчүн маанилүү болгондуктан, PostgreSQLди тиркеме деңгээлинде бөлүштүрө баштадык. Бул үчүн жогоруда сүрөттөлгөн схема салыштырмалуу ыңгайлуу: жаңы PostgreSQL сыныгын кошууда PgBouncer конфигурациясын жаңыртуу жетиштүү жана тиркеме дароо жаңы сынык менен иштей алат.
PgBouncer аткарбоо
Бул схема жалгыз PgBouncer инстанциясы өлгөнгө чейин иштеген. Биз AWSдебиз, анда бардык инстанциялар мезгил-мезгили менен өчүп турган жабдыкта иштейт. Мындай учурларда, инстанция жөн гана жаңы жабдыкка өтүп, кайра иштейт. Бул PgBouncer менен болду, бирок ал жеткиликсиз болуп калды. Бул күздүн натыйжасы биздин кызматтын 25 мүнөткө жеткиликсиздиги болду. AWS мындай жагдайлар үчүн колдонуучу тараптын резервин колдонууну сунуштайт, ал ошол учурда биздин өлкөдө ишке ашырылган эмес.
Андан кийин, биз PgBouncer жана PostgreSQL кластерлеринин катачылыкка чыдамкайлыгы жөнүндө олуттуу ойлондук, анткени AWS эсебибиздеги бардык инстанцияларда ушундай жагдай болушу мүмкүн.
Биз PgBouncer катачылыкка чыдамкайлык схемасын төмөнкүдөй курдук: бардык тиркеме серверлери Network Load Balancerге кире алышат, анын артында эки PgBouncer бар. Ар бир PgBouncer ар бир сыныктын бир эле PostgreSQL мастерин карайт. Эгерде AWS инстанциясынын бузулушу кайталанса, бардык трафик башка PgBouncer аркылуу багытталат. Network Load Balancer алмаштыргыч AWS тарабынан камсыз кылынат.
Бул схема жаңы PgBouncer серверлерин кошууну жеңилдетет.
PostgreSQL Failover кластерин түзүү
Бул маселени чечүүдө биз ар кандай варианттарды карап чыктык: өз алдынча жазылган жаңылыштык, repmgr, AWS RDS, Patroni.
Өз алдынча жазылган сценарийлер
Алар мастердин ишин көзөмөлдөп, эгер ал ишке ашпай калса, репликаны мастерге жылдырат жана PgBouncer конфигурациясын жаңырта алат.
Бул ыкманын артыкчылыктары - бул максималдуу жөнөкөйлүк, анткени сиз сценарийлерди өзүңүз жазасыз жана алардын кантип иштешин так түшүнөсүз.
жактары:
- Мастер өлбөй калган болушу мүмкүн, анын ордуна тармак иштебей калышы мүмкүн. Буну билбестен, репликаны кожоюнга жылдырат, ал эми эски мастер ишин улантат. Натыйжада, биз мастердин ролунда эки серверге ээ болобуз жана алардын кайсынысында эң акыркы маалыматтар бар экенин билбейбиз. Бул абалды сплит-мээ деп да аташат;
- Биз жоопсуз калдык. Биздин конфигурацияда мастер жана бир реплика, которулгандан кийин, реплика мастерге чейин жылат жана бизде репликалар мындан ары жок, ошондуктан жаңы репликаны кол менен кошууга туура келет;
- Бизде 12 PostgreSQL сыныктары бар, ал эми бизде 12 кластер мониторинг жүргүзүү керек дегенди билдирет, иштебей калуу операциясына кошумча мониторинг керек. Сыныктардын санынын көбөйүшү менен, сиз иштен чыгууну жаңыртууну да унутпашыңыз керек.
Өзүн-өзү жазылган жаңылыштык абдан татаал көрүнөт жана маанилүү эмес колдоону талап кылат. Жалгыз PostgreSQL кластери менен бул эң оңой вариант болмок, бирок ал масштабдуу эмес, ошондуктан ал бизге ылайыктуу эмес.
Repmgr
PostgreSQL кластерлеринин ишин башкара ала турган PostgreSQL кластерлери үчүн репликация менеджери. Ошол эле учурда, ал кутудан автоматтык түрдө иштебейт, андыктан иштөө үчүн даяр чечимдин үстүнө өзүңүздүн "ороочу" жазууңуз керек болот. Ошентип, баары өз алдынча жазылган скрипттерге караганда татаалыраак болушу мүмкүн, ошондуктан биз Repmgr аракетин да көргөн жокпуз.
AWS RDS
Бизге керектүү нерселердин бардыгын колдойт, камдык көчүрмөлөрдү кантип жасоону билет жана байланыштардын көлмөсүн сактайт. Анын автоматтык түрдө которулушу бар: кожоюн өлгөндө, реплика жаңы мастер болуп калат, ал эми AWS dns жазуусун жаңы мастерге алмаштырат, ал эми репликалар ар кандай AZларда жайгашышы мүмкүн.
Кемчиликтерге майда тууралоолордун жоктугу кирет. Жакшы жөндөөнүн мисалы катары: биздин инстанцияларда tcp туташуулары үчүн чектөөлөр бар, тилекке каршы, RDSте жасоо мүмкүн эмес:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Мындан тышкары, AWS RDS кадимки инстанция баасынан дээрлик эки эсе кымбат, бул чечимден баш тартуунун негизги себеби болгон.
Patroni
Бул PostgreSQLди башкаруу үчүн Python үлгүсү, жакшы документтери, автоматтык иштебей калышы жана githubдагы баштапкы код.
Patroni жакшы жактары:
- Ар бир конфигурация параметри сүрөттөлөт, ал кандайча иштейт экени түшүнүктүү;
- Автоматтык иштен чыгуу кутудан тышкары иштейт;
- Питондо жазылганбыз жана биз өзүбүз питондо көп жазгандыктан, көйгөйлөр менен күрөшүү жана, балким, долбоордун өнүгүшүнө жардам берүү бизге жеңил болот;
- PostgreSQLди толугу менен башкарат, кластердин бардык түйүндөрүндөгү конфигурацияны бир убакта өзгөртүүгө мүмкүндүк берет жана жаңы конфигурацияны колдонуу үчүн кластерди кайра иштетүү керек болсо, анда муну Patroni аркылуу кайра жасоого болот.
жактары:
- PgBouncer менен кантип туура иштөө керектиги документациядан түшүнүксүз. Муну минус деп айтуу кыйын, анткени Патронинин милдети PostgreSQLди башкаруу жана Patroni менен байланыштар кандай болору биздин көйгөйүбүз;
- Патрониди чоң көлөмдө ишке ашыруунун бир нече мисалдары бар, ал эми нөлдөн баштап ишке ашыруунун көптөгөн мисалдары бар.
Натыйжада биз иштен чыгуу кластерин түзүү үчүн Patroni тандадык.
Patroni ишке ашыруу процесси
Патрониге чейин бизде 12 PostgreSQL сыныктары бар болчу. Конфигурацияда бир мастер жана асинхрондук репликациялуу бир реплика бар. Колдонмо серверлери маалымат базаларына Network Load Balancer аркылуу кирди, анын артында PgBouncer менен эки инстанция жана алардын артында бардык PostgreSQL серверлери турган.
Patroni ишке ашыруу үчүн, биз бөлүштүрүлгөн сактоо кластеринин конфигурациясын тандоо керек болчу. Patroni etcd, Zookeeper, Consul сыяктуу бөлүштүрүлгөн конфигурацияларды сактоо системалары менен иштейт. Бизде базарда толук кандуу консулдук кластер бар, ал Vault менен биргеликте иштейт жана биз аны мындан ары колдонбойбуз. Консулду өз максатына ылайык колдонууга чоң себеп.
Патрони консул менен кантип иштейт
Бизде үч түйүндөн турган Консул кластери жана лидер жана репликадан турган Patroni кластери бар (Патрониде кожоюн кластердин лидери, ал эми кулдар репликалар деп аталат). Patroni кластеринин ар бир инстанциясы дайыма кластердин абалы жөнүндө маалыматты консулга жөнөтөт. Ошондуктан, Консулдан сиз дайыма Patroni кластеринин учурдагы конфигурациясын жана учурда ким лидер экенин биле аласыз.
Patroni менен Консулду туташтыруу үчүн расмий документтерди изилдөө жетиштүү, анда сиз http же https форматында хостту көрсөтүү керек, Консул менен кантип иштешкенибизге жана байланыш схемасына жараша:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpБул жөнөкөй көрүнөт, бирок бул жерде тузактар башталат. Консул менен биз https аркылуу коопсуз туташуунун үстүндө иштейбиз жана биздин байланыш конфигурациябыз төмөнкүдөй болот:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Бирок бул иштебейт. Ишке киргенде Патрони Консулга туташа албайт, анткени ал баары бир http аркылуу өтүүгө аракет кылат.
Патронинин баштапкы коду көйгөйдү чечүүгө жардам берди. Питондо жазылганы жакшы. Көрсө, хост параметри эч кандай талданбайт жана протокол схемада көрсөтүлүшү керек. Консул менен иштөө үчүн жумушчу конфигурация блогу биз үчүн ушундай көрүнөт:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}консул-шаблон
Ошентип, конфигурация үчүн сактагычты тандап алдык. Эми биз Patroni кластериндеги лидерди алмаштырууда PgBouncer конфигурациясын кантип которорун түшүнүшүбүз керек. Документте бул суроого жооп жок, анткени. ал жерде, негизинен, PgBouncer менен иштөө сүрөттөлгөн эмес.
Чечүүнү издеп, биз макаланы таптык (тилекке каршы аталышы эсимде жок), анда Консул-шаблон PgBouncer менен Patroni жупташтырууга көп жардам бергени жазылган. Бул бизге Консул-шаблон кантип иштээрин иликтөөгө түрткү болду.
Consul-шаблон Консулдагы PostgreSQL кластеринин конфигурациясын такай көзөмөлдөп турат экен. Лидер өзгөргөндө, ал PgBouncer конфигурациясын жаңыртат жана аны кайра жүктөө буйругун жөнөтөт.
Шаблондун чоң артыкчылыгы - ал код катары сакталат, андыктан жаңы сыныктарды кошууда инфраструктураны код принциби катары колдоп, жаңы милдеттенмени аткаруу жана шаблонду автоматтык түрдө жаңыртуу жетиштүү.
Patroni менен жаңы архитектура
Натыйжада, биз төмөнкү иш схемасын алдык:
Бардык тиркеме серверлери баланстоочуга кире алышат → анын артында PgBouncer эки нускасы бар → ар бир инстанцияда Консул-шаблон ишке киргизилет, ал ар бир Patroni кластеринин абалын көзөмөлдөйт жана PgBouncer конфигурациясынын актуалдуулугун көзөмөлдөйт, ал учурдагы лидерге суроо-талаптарды жөнөтөт. ар бир кластердин.
Кол менен сыноо
Биз бул схеманы кичинекей сыноо чөйрөсүндө ишке киргизүүдөн мурун иштетип, автоматтык которуунун иштешин текшердик. Алар тактаны ачып, стикерди жылдырып, ошол маалда кластердин лидерин “өлтүрүштү”. AWSде бул консол аркылуу инстанцияны өчүрүү сыяктуу жөнөкөй.
Чаптама 10-20 секунданын ичинде кайтып келип, кайра кадимкидей кыймылдай баштады. Бул Patroni кластери туура иштеген дегенди билдирет: ал лидерди алмаштырып, маалыматты Консулга жөнөттү, ал эми Консул-шаблон дароо бул маалыматты алып, PgBouncer конфигурациясын алмаштырып, кайра жүктөө буйругун жөнөттү.
Кантип жогорку жүктөм астында аман калуу жана токтоп калууларды минималдуу сактоо керек?
Баары кемчиликсиз иштейт! Бирок, жаңы суроолор бар: ал жогорку жүктөм астында кантип иштейт? Кантип өндүрүштө бардыгын тез жана коопсуз жайылтуу керек?
Биз жүктөө тестин өткөргөн тест чөйрөсү биринчи суроого жооп берүүгө жардам берет. Ал архитектура жагынан өндүрүшкө толугу менен окшош жана көлөмү боюнча болжол менен өндүрүшкө барабар болгон сыноо маалыматтарын түздү. Сыноо учурунда PostgreSQL мастерлеринин бирин жөн эле "өлтүрүүнү" чечип, эмне болорун көрөбүз. Бирок ага чейин автоматтык түрдө жылдырууну текшерүү маанилүү, анткени бул чөйрөдө бизде бир нече PostgreSQL сыныктары бар, андыктан өндүрүш алдында конфигурация скрипттерин эң сонун сынап алабыз.
Эки тапшырма тең дымактуу көрүнөт, бирок бизде PostgreSQL 9.6. Биз дароо 11.2ге жаңырта алабызбы?
Биз муну 2 кадам менен жасоону чечтик: адегенде 11.2ге жаңыртып, андан кийин Patroni ишке киргизебиз.
PostgreSQL жаңыртуу
PostgreSQL версиясын тез жаңыртуу үчүн, опцияны колдонуңуз -k, дискте катуу шилтемелер түзүлөт жана маалыматыңызды көчүрүүнүн кереги жок. 300-400 ГБ базасында жаңыртуу 1 секундду талап кылат.
Бизде сыныктар көп, андыктан жаңыртуу автоматтык түрдө аткарылышы керек. Бул үчүн биз Ansible оюн китебин жаздык, ал биз үчүн жаңыртуу процессин башкарат:
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='Бул жерде белгилей кетүү маанилүү, жаңыртууну баштоодон мурун, аны параметр менен аткаруу керек --текшерүүжаңырта ала турганыңызды текшерүү үчүн. Биздин скрипт жаңыртуу учурунда конфигурацияларды алмаштырууну да жасайт. Биздин сценарий 30 секундда бүттү, бул эң сонун натыйжа.
Patroni ишке киргизиңиз
Экинчи маселени чечүү үчүн, жөн гана Patroni конфигурациясын караңыз. Расмий репозиторийде initdb менен конфигурациянын үлгүсү бар, ал Patroni биринчи баштаганда жаңы маалымат базасын инициализациялоого жооптуу. Бирок бизде даяр маалымат базасы бар болгондуктан, биз бул бөлүмдү жөн гана конфигурациядан алып салдык.
Биз буга чейин эле бар PostgreSQL кластерине Patroni орнотуп, аны иштетип баштаганда, биз жаңы көйгөйгө туш болдук: эки сервер тең лидер катары иштей баштады. Патрони кластердин алгачкы абалы жөнүндө эч нерсе билбейт жана эки серверди бирдей аталыштагы эки өзүнчө кластер катары баштоого аракет кылат. Бул көйгөйдү чечүү үчүн, сиз кулдагы маалыматтар менен каталогду жок кылышыңыз керек:
rm -rf /var/lib/postgresql/Муну кулга гана кылуу керек!
Таза реплика туташтырылганда, Патрони базалык резервдик лидерди жасап, аны репликага калыбына келтирет, андан кийин wal журналдарына ылайык учурдагы абалга жетет.
Биз кабылган дагы бир кыйынчылык - бардык PostgreSQL кластерлери демейки боюнча негизги деп аталат. Ар бир кластер бири-бири жөнүндө эч нерсе билбесе, бул нормалдуу көрүнүш. Бирок сиз Patroni колдонгуңуз келгенде, бардык кластерлердин уникалдуу аталышы болушу керек. Чечим - PostgreSQL конфигурациясында кластердин атын өзгөртүү.
жүк сыноо
Биз такталардагы колдонуучу тажрыйбасын окшоштурган тестти ишке киргиздик. Жүктөө биздин орточо күнүмдүк мааниге жеткенде, биз дал ушундай сыноону кайталадык, PostgreSQL лидери менен бир инстанцияны өчүрдүк. Автоматтык өчүрүү биз күткөндөй иштеди: Патрони лидерди алмаштырды, Консул-шаблон PgBouncer конфигурациясын жаңыртты жана кайра жүктөө буйругун жөнөттү. Графанадагы биздин графиктерибизге ылайык, маалымат базасына туташуу менен байланышкан серверлерден 20-30 секунддук кечигүүлөр жана аз сандагы каталар бар экени айкын болду. Бул нормалдуу жагдай, мындай баалуулуктар биздин үзгүлтүккө учурашыбыз үчүн алгылыктуу жана кызматтын токтоп калган убактысынан жакшыраак.
Patroni өндүрүшкө алып келүү
Жыйынтыгында биз төмөнкү планга келдик:
- Consul-шаблонду PgBouncer серверлерине жайгаштыруу жана ишке киргизүү;
- PostgreSQL жаңыртуулары 11.2 версиясына;
- Кластердин атын өзгөртүү;
- Патрони кластерин баштоо.
Ошол эле учурда, биздин схема дээрлик каалаган убакта биринчи пунктту жасоого мүмкүндүк берет, биз ар бир PgBouncerди өз кезегинде иштен алып салып, ага консулдук шаблонду орнотуп, иштете алабыз. Ошентип, биз кылдык.
Тез жайылтуу үчүн биз Ansible колдондук, анткени биз бардык окуу китептерин тестирлөө чөйрөсүндө сынап көрдүк жана толук скрипттин аткарылуу убактысы ар бир сынык үчүн 1,5 мүнөттөн 2 мүнөткө чейин болду. Биз кызматыбызды токтотпостон, ар бир сыныкка кезеги менен баарын чыгара алмакпыз, бирок ар бир PostgreSQLди бир нече мүнөткө өчүрүшүбүз керек. Бул учурда, маалыматтары ушул сыныкта турган колдонуучулар толук иштей алышпайт жана бул биз үчүн кабыл алынгыс.
Бул абалдан чыгуунун жолу 3 айда бир өткөрүлүүчү пландуу оңдоо болду. Бул биз кызматыбызды толугу менен өчүрүп, маалымат базасынын инстанцияларын жаңыртканда пландаштырылган иш үчүн терезе. Кийинки терезеге бир жума калды, биз жөн гана күтүп, дагы даярданууну чечтик. Күтүү учурунда биз өзүбүздү кошумча коргодук: ар бир PostgreSQL сыныгы үчүн биз акыркы маалыматтар сакталбай калса, запастык репликаны түздүк жана ар бир сынык үчүн жаңы нусканы коштук, ал Patroni кластеринде жаңы реплика болуп калышы керек, маалыматтарды жок кылуу буйругун аткарбоо үчүн. Мунун баары ката коркунучун азайтуу үчүн жардам берди.
Биз кызматыбызды кайра ишке киргиздик, баары каалагандай иштеди, колдонуучулар иштөөнү улантышты, бирок графиктерде биз консулдук серверлерде анормалдуу чоң жүктү байкадык.
Эмне үчүн биз муну сыноо чөйрөсүндө көргөн жокпуз? Бул көйгөй инфраструктураны код принциби катары кармануу жана тесттик чөйрөлөрдөн өндүрүшкө чейин бүт инфраструктураны тактоо зарыл экендигин абдан жакшы көрсөтүп турат. Болбосо, биз алган көйгөйдү алуу абдан оңой. Эмне болду? Консул адегенде өндүрүштө пайда болгон, андан кийин тест чөйрөлөрүндө, натыйжада, тест чөйрөлөрүндө Консулдун версиясы өндүрүшкө караганда жогору болгон. Чыгарылгандардын биринде эле консулдук шаблон менен иштөөдө CPU агып кетиши чечилди. Ошондуктан, биз жөн гана консулду жаңылап, маселени чечтик.
Patroni кластерин кайра иштетиңиз
Бирок, биз шектенбеген жаңы көйгөйдү алдык. Консулду жаңыртууда биз жөн гана консулдук түйүндү кластерден алып салабыз, консул отпуск буйругу → Patroni башка Консул серверине кошулат → баары иштейт. Бирок биз консулдук кластердин акыркы инстанциясына жетип, ага консулдук уруксат берүү буйругун жөнөткөнүбүздө, бардык Patroni кластерлери жөн эле кайра иштетилип, журналдарда төмөнкү катаны көрдүк:
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>Patroni кластери өз кластери жөнүндө маалымат ала албай, кайра иштетилди.
Чечим табуу үчүн биз githubдагы маселе аркылуу Патрони авторлору менен байланыштык. Алар конфигурация файлдарыбызды жакшыртууну сунушташты:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Биз көйгөйдү сыноо чөйрөсүндө кайта алдык жана ал жерде бул опцияларды сынап көрдүк, бирок, тилекке каршы, алар иштеген жок.
Маселе дагы эле чечиле элек. Биз төмөнкү чечимдерди сынап көрүүнү пландап жатабыз:
- Ар бир Patroni кластер инстанциясында Консул-агентти колдонуу;
- Коддогу маселени чечиңиз.
Ката кайдан болгонун түшүнөбүз: көйгөй, балким, конфигурация файлы аркылуу жокко чыгарылбаган демейки таймауттун колдонулушу. Акыркы Консул сервери кластерден чыгарылганда, бүт Консул кластери бир секунддан ашык убакытка токтоп турат, ушундан улам Patroni кластердин статусун ала албайт жана бүт кластерди толугу менен өчүрүп күйгүзөт.
Бактыга жараша, биз мындан ары каталарга туш болгон жокпуз.
Patroni колдонуунун натыйжалары
Patroni ийгиликтүү ишке киргизилгенден кийин, биз ар бир кластерге кошумча репликаны коштук. Азыр ар бир кластерде кворумдун окшоштугу бар: которуштурууда мээнин бөлүнүүсүндө коопсуздук сеткасы үчүн бир лидер жана эки реплика.
Патрони үч айдан ашык убакыттан бери өндүрүштө иштеп жатат. Бул убакыттын ичинде ал бизге жардам бергенге жетишти. Жакында AWSде кластерлердин биринин лидери каза болуп, автоматтык түрдө иштен чыгып, колдонуучулар ишин уланта беришти. Патрони өзүнүн негизги милдетин аткарды.
Patroni колдонуунун кыскача кыскача баяндамасы:
- Конфигурацияны өзгөртүү оңой. Бир инстанциядагы конфигурацияны өзгөртүү жетиштүү жана ал бүткүл кластерге тартылат. Жаңы конфигурацияны колдонуу үчүн кайра жүктөө талап кылынса, Patroni сизге кабарлайт. Patroni бир команда менен бүт кластерди кайра иштете алат, бул да абдан ыңгайлуу.
- Автоматтык өчүрүү иштеп жатат жана бизге буга чейин жардам берген.
- PostgreSQL жаңыртуу тиркеме токтоп турбастан. Сиз адегенде репликаларды жаңы версияга жаңыртыңыз, андан кийин Patroni кластериндеги лидерди алмаштырып, эски лидерди жаңыртыңыз. Бул учурда, автоматтык иштен чыгуунун зарыл болгон сыноосу ишке ашат.
Source: www.habr.com