Мақалада мен PostgreSQL қателеріне төзімділік мәселесіне қалай қарағанымызды, бұл біз үшін неліктен маңызды болғанын және соңында не болғанын айтамын.
Бізде жоғары жүктелген қызмет бар: бүкіл әлем бойынша 2,5 миллион пайдаланушы, күн сайын 50 мыңнан астам белсенді пайдаланушы. Серверлер Ирландияның бір аймағындағы Amazone қаласында орналасқан: 100-ден астам әртүрлі серверлер тұрақты жұмыс істейді, оның 50-ге жуығы дерекқорлары бар.
Бүкіл сервер клиентпен тұрақты websocket байланысын сақтайтын үлкен монолитті күйі бар Java қолданбасы. Бірнеше пайдаланушы бір тақтада бір уақытта жұмыс істегенде, олардың барлығы өзгерістерді нақты уақыт режимінде көреді, өйткені біз әрбір өзгерісті дерекқорға жазамыз. Біздің дерекқорымызға секундына шамамен 10 мың сұраныс бар. Redis-те ең жоғары жүктеме кезінде біз секундына 80-100K сұраныс жазамыз.
Неліктен біз Redis-тен PostgreSQL-ге ауыстық
Бастапқыда біздің қызмет сервердің жедел жадында барлық деректерді сақтайтын негізгі мәндер қоймасы Redis-пен жұмыс істеді.
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 істен шығу кластерін жасаңыз
Бұл мәселені шешу кезінде біз әртүрлі нұсқаларды қарастырдық: өздігінен жазылған ауыстыру, 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 әдеттегі дананың бағасынан екі есе дерлік қымбат, бұл шешімнен бас тартудың басты себебі болды.
Патрони
Бұл PostgreSQL басқаруға арналған питон үлгісі, жақсы құжаттамасы, автоматты түрде ауыстырылуы және github жүйесіндегі бастапқы код.
Патронидің артықшылықтары:
- Әрбір конфигурация параметрі сипатталған, ол қалай жұмыс істейтіні анық;
- Автоматты ауыстыру қораптан тыс жұмыс істейді;
- Питон тілінде жазылған және біз өзіміз питон тілінде көп жазатындықтан, бізге проблемаларды шешу оңайырақ болады және, мүмкін, тіпті жобаны дамытуға көмектесетін болады;
- PostgreSQL-ті толығымен басқарады, кластердің барлық түйіндеріндегі конфигурацияны бірден өзгертуге мүмкіндік береді және жаңа конфигурацияны қолдану үшін кластерді қайта іске қосу қажет болса, мұны Patroni арқылы қайтадан жасауға болады.
Кемшіліктері:
- Құжаттамада PgBouncer-пен қалай дұрыс жұмыс істеу керектігі анық емес. Мұны минус деп айту қиын, өйткені Патронидің міндеті - PostgreSQL-ті басқару және Patroni-ге қосылудың қалай жүретіні қазірдің өзінде біздің мәселе;
- Патрониді үлкен көлемде енгізудің мысалдары аз, ал нөлден бастап іске асырудың көптеген мысалдары бар.
Нәтижеде біз ауыстырып-қосу кластерін жасау үшін Patroni таңдадық.
Patroni іске асыру процесі
Патрониге дейін бізде асинхронды репликациясы бар бір негізгі және бір реплика конфигурациясында 12 PostgreSQL үзінділері болды. Қолданба серверлері дерекқорларға Network Load Balancer арқылы қол жеткізді, оның артында PgBouncer бар екі данасы және олардың артында барлық PostgreSQL серверлері болды.
Patroni енгізу үшін бізге таратылған сақтау кластерінің конфигурациясын таңдау керек болды. Patroni etcd, Zookeeper, Consul сияқты бөлінген конфигурацияларды сақтау жүйелерімен жұмыс істейді. Бізде нарықта Vault-пен бірге жұмыс істейтін толыққанды Консул кластері бар және біз оны енді пайдаланбаймыз. Консулды мақсатты түрде пайдалануды бастаудың тамаша себебі.
Патрони консулмен қалай жұмыс істейді
Бізде үш түйіннен тұратын Консул кластері және көшбасшы мен репликадан тұратын 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-template Консулдағы PostgreSQL кластерінің конфигурациясын үнемі қадағалап отырады екен. Көшбасшы өзгерген кезде ол PgBouncer конфигурациясын жаңартады және оны қайта жүктеу пәрменін жібереді.
Үлгінің үлкен плюс - ол код ретінде сақталады, сондықтан жаңа үзіндіні қосқанда, жаңа міндеттеме жасап, Инфрақұрылымды код принципі ретінде қолдайтын үлгіні автоматты түрде жаңарту жеткілікті.
Патронимен бірге жаңа архитектура
Нәтижесінде біз келесі жұмыс схемасын алдық:
Барлық қолданба серверлері балансизаторға қол жеткізеді → оның артында 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/Мұны тек құлға жасау керек!
Таза реплика қосылған кезде, Patroni резервтік көшірме жетекшісін жасайды және оны көшірмеге қалпына келтіреді, содан кейін wal журналдарына сәйкес ағымдағы күйге жетеді.
Біз кездестірген тағы бір қиындық - барлық PostgreSQL кластерлері әдепкі бойынша негізгі деп аталады. Әрбір кластер екіншісі туралы ештеңе білмесе, бұл қалыпты жағдай. Бірақ Patroni қолданбасын пайдаланғыңыз келсе, барлық кластерлердің бірегей атауы болуы керек. Шешім PostgreSQL конфигурациясында кластер атауын өзгерту болып табылады.
жүктеме сынағы
Біз тақталардағы пайдаланушы тәжірибесін модельдейтін сынақты іске қостық. Жүктеме орташа тәуліктік мәнге жеткенде, біз дәл сол сынақты қайталадық, PostgreSQL көшбасшысымен бір дананы өшірдік. Автоматты ауыстыру біз күткендей жұмыс істеді: Патрони көшбасшыны ауыстырды, Консул үлгісі PgBouncer конфигурациясын жаңартты және қайта жүктеу пәрменін жіберді. Графанадағы графиктерімізге сәйкес, дерекқорға қосылуға байланысты серверлерден 20-30 секундтық кешігулер және аздаған қателер бар екені анық болды. Бұл қалыпты жағдай, мұндай мәндер біздің істен шығуымыз үшін қолайлы және қызметтің тоқтап қалуынан жақсырақ.
Патрониді өндіріске әкелу
Нәтижесінде біз мынадай жоспар құрдық:
- Consul-үлгіні PgBouncer серверлеріне орналастыру және іске қосу;
- 11.2 нұсқасына PostgreSQL жаңартулары;
- Кластердің атын өзгерту;
- Патрони кластерін бастау.
Сонымен қатар, біздің схема кез келген уақытта дерлік бірінші нүктені жасауға мүмкіндік береді, біз әрбір PgBouncer-ді жұмыстан кезекпен алып тастай аламыз және оған консулдық шаблонды орналастырып, іске қоса аламыз. Біз солай істедік.
Жылдам орналастыру үшін біз Ansible қолданбасын қолдандық, өйткені біз сынақ ортасында барлық оқулықтарды сынап көрдік және толық сценарийдің орындалу уақыты әрбір үзінді үшін 1,5-тен 2 минутқа дейін болды. Біз қызметімізді тоқтатпай-ақ бәрін әр бөлікке кезекпен шығара аламыз, бірақ әр PostgreSQL-ті бірнеше минутқа өшіруіміз керек еді. Бұл жағдайда деректері осы үзіндіде бар пайдаланушылар қазіргі уақытта толық жұмыс істей алмады және бұл біз үшін қолайсыз.
Бұл жағдайдан шығудың жолы 3 ай сайын өтетін жоспарлы жөндеу болды. Бұл қызметімізді толығымен өшіріп, дерекқор даналарын жаңартқанда жоспарланған жұмысқа арналған терезе. Келесі терезеге дейін бір апта қалды, біз жай күтіп, әрі қарай дайындалуды шештік. Күту уақытында біз өзімізді қосымша қорғадық: әрбір PostgreSQL фрагменті үшін соңғы деректер сақталмаған жағдайда біз қосалқы көшірме жасадық және әрбір үзіндіге жаңа дананы қостық, ол 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 сәтті іске қосылғаннан кейін біз әрбір кластерге қосымша көшірме қостық. Енді әрбір кластерде кворумның ұқсастығы бар: ауысу кезінде мидың бөлінуі жағдайында қауіпсіздік желісі үшін бір көшбасшы және екі көшірме.
Патрони өндірісте үш айдан астам уақыт жұмыс істеп жатыр. Осы уақыт ішінде ол бізге көмектесіп үлгерді. Жақында AWS-де кластерлердің бірінің жетекшісі қайтыс болды, автоматты түрде ауыстырып қосу жұмыс істеді және пайдаланушылар жұмысын жалғастырды. Патрони өзінің негізгі міндетін орындады.
Patroni қолданудың шағын қысқаша мазмұны:
- Конфигурацияны өзгертудің қарапайымдылығы. Бір данада конфигурацияны өзгерту жеткілікті және ол бүкіл кластерге тартылады. Жаңа конфигурацияны қолдану үшін қайта жүктеу қажет болса, Patroni сізге хабарлайды. Patroni бір пәрменмен бүкіл кластерді қайта іске қоса алады, бұл да өте ыңғайлы.
- Автоматты істен шығу жұмыс істейді және қазірдің өзінде бізге көмектесе алды.
- Қолданбаның тоқтауынсыз PostgreSQL жаңартуы. Алдымен көшірмелерді жаңа нұсқаға жаңарту керек, содан кейін Patroni кластеріндегі көшбасшыны өзгертіп, ескі көшбасшыны жаңарту керек. Бұл жағдайда автоматты түрде істен шығудың қажетті сынағы орын алады.
Ақпарат көзі: www.habr.com