Во својот извештај, Андреј Бородин ќе ви каже како го зедоа предвид искуството за скалирање на PgBouncer при дизајнирање на спојувачот за поврзување , додека го пуштаа во производство. Дополнително, ќе разговараме за тоа кои функции на извлекувачот би сакале да ги видиме во новите верзии: за нас е важно не само да ги задоволиме нашите потреби, туку и да ја развиеме заедницата на корисници .
Видео:
Здраво на сите! Моето име е Андреј.
Во Yandex, развивам бази на податоци со отворен код. И денес имаме тема за приклучоците на полер на конекција.
Ако знаеш како да се јавиш конекција пулер на руски, тогаш кажи ми. Навистина сакам да најдам добар технички термин што треба да се воспостави во техничката литература.
Темата е доста комплицирана, бидејќи во многу бази на податоци е вграден здружувачот за поврзување и не треба ни да знаете за тоа. Се разбира, има некои поставки насекаде, но во Postgres тоа не функционира така. И паралелно (на HighLoad++ 2019) има извештај од Николај Самохвалов за поставување прашања во Postgres. И како што разбирам, овде дојдоа луѓе кои веќе ги конфигурираа своите прашања совршено, а тоа се луѓе кои се соочуваат со поретки системски проблеми поврзани со мрежата и користењето на ресурсите. А на некои места може да биде доста тешко во смисла дека проблемите не се очигледни.
Yandex има Postgres. Многу услуги на Yandex живеат во Yandex.Cloud. И имаме неколку петабајти податоци кои генерираат најмалку милион барања во секунда во Postgres.
И обезбедуваме прилично стандарден кластер за сите услуги - ова е главниот примарен јазол на јазолот, вообичаените две реплики (синхрони и асинхрони), резервна копија, скалирање на барањата за читање на репликата.
Секој јазол на кластерот е Postgres, на кој, покрај Postgres и системите за следење, е инсталиран и спојувач за поврзување. Поле за поврзување се користи за оградување и за неговата главна намена.
Која е главната цел на поврзувачкиот пулер?
Postgres прифаќа процесен модел кога работи со база на податоци. Ова значи дека една врска е еден процес, еден Postgres backend. И во овој заден дел има многу различни кешови, кои се прилично скапи да се направат различни за различни врски.
Дополнително, кодот на Postgres има низа наречена procArray. Содржи основни податоци за мрежните врски. И скоро сите алгоритми за обработка на procArray имаат линеарна сложеност; тие се движат низ целата низа мрежни врски. Тоа е прилично брз циклус, но со повеќе дојдовни мрежни врски работите стануваат малку поскапи. И кога работите стануваат малку поскапи, може да завршите да платите многу висока цена за многу мрежни врски.
Постојат 3 можни пристапи:
- На страната на апликацијата.
- На страната на базата на податоци.
- И помеѓу, односно секакви комбинации.
За жал, вградениот пулер моментално е во развој. Нашите пријатели во PostgreSQL Professional го прават тоа главно. Тешко е да се предвиди кога ќе се појави. И всушност, имаме две решенија од кои архитектот треба да избере. Тоа се базен од страна на апликацијата и базен за прокси.
Базенот од страна на апликацијата е најлесниот начин. И речиси сите двигатели на клиенти ви обезбедуваат начин: презентирајте милиони ваши врски во код во форма на неколку десетици врски со базата на податоци.
Проблемот што се појавува е тоа што во одреден момент сакате да го зголемите заднината, сакате да го распоредите на многу виртуелни машини.
Тогаш сфаќате дека имате уште неколку зони на достапност, неколку центри за податоци. И пристапот на здружување од страна на клиентот води до големи бројки. Големите се околу 10 врски. Ова е раб што може да работи нормално.
Ако зборуваме за proxy poolers, тогаш постојат двајца poolers кои можат да направат многу работи. Тие не се само здружувачи. Тие се спојници + повеќе кул функционалност. Ова и .
Но, за жал, не секој има потреба од оваа дополнителна функционалност. И тоа води до фактот дека пулерите поддржуваат само здружување на сесии, односно еден дојдовен клиент, еден појдовен клиент во базата на податоци.
Ова не е многу погодно за нашите цели, затоа користиме PgBouncer, кој имплементира здружување на трансакции, односно врските на серверот се совпаѓаат со врските со клиентот само за времетраењето на трансакцијата.
И во нашиот обем на работа, ова е точно. Но, има неколку проблеми.
Проблемите започнуваат кога сакате да дијагностицирате сесија, бидејќи сите ваши дојдовни врски се локални. Сите дојдоа со loopback и некако станува тешко да се следи сесијата.
Се разбира, можете да користите application_name_add_host. Ова е начин на страната на Bouncer да се додаде IP адреса на application_name. Но, името на апликацијата е поставено со дополнителна врска.
На овој график, каде што жолтата линија е вистински барања, а каде сината линија се барањата што летаат во базата на податоци. И оваа разлика е токму инсталацијата на application_name, која е потребна само за следење, но воопшто не е бесплатна.
Дополнително, во Bouncer не можете да ограничите еден базен, т.е. бројот на врски со базата на податоци по конкретен корисник, по одредена база на податоци.
До што води ова? Имате вчитана услуга напишана во C++ и некаде во близина мала услуга на јазол што не прави ништо страшно со базата на податоци, но неговиот двигател полудува. Отвора 20 конекции и се останато ќе чека. Дури и вашиот код е нормален.
Ние, се разбира, напишавме мала закрпа за Bouncer која ја додаде оваа поставка, односно ограничување на клиентите на базенот.
Тоа би било можно да се направи на страната на Postgres, т.е., да се ограничат улогите во базата на податоци според бројот на врски.
Но, тогаш ја губите способноста да разберете зошто немате врски со серверот. PgBouncer не исфрла грешка во врската, секогаш ги враќа истите информации. И не можете да разберете: можеби вашата лозинка е променета, можеби базата на податоци штотуку се изгубила, можеби нешто не е во ред. Но, нема дијагноза. Ако не може да се воспостави седница, нема да знаете зошто не може да се воспостави.
Во одреден момент, ги гледате графиконите на апликациите и гледате дека апликацијата не работи.
Погледнете го горниот дел и видете дека Bouncer е со една нишка. Ова е пресвртница во животот на услугата. Сфаќате дека се подготвувавте да ја зголемите базата на податоци за година и пол, и треба да ја зголемите големината.
Дојдовме до заклучок дека ни требаат повеќе PgBouncers.
Bouncer е закрпен малку.
И тие го направија тоа така што неколку Bouncer може да се подигнат со повторна употреба на TCP портата. И оперативниот систем автоматски ги пренесува дојдовните TCP конекции меѓу нив со помош на круг-робин.
Ова е проѕирно за клиентите, што значи дека изгледа како да имате еден Bouncer, но имате фрагментација на неактивен врски помеѓу активираните Bouncer.
И во одреден момент може да забележите дека овие 3 Bouncer секој го јаде своето јадро за 100%. Ви требаат неколку Bouncers. Зошто?
Затоа што имате TLS. Имате шифрирана врска. И ако го мерите Postgres со и без TLS, ќе откриете дека бројот на воспоставени врски се намалува за речиси два реда на големина со овозможено шифрирање, бидејќи ракувањето со TLS ги троши ресурсите на процесорот.
И на врвот можете да видите неколку криптографски функции кои се извршуваат кога има бран на дојдовни врски. Бидејќи нашата примарна може да се префрла помеѓу зоните на достапност, бранот на дојдовни врски е прилично типична ситуација. Тоа е, поради некоја причина стариот примарен беше недостапен, целото оптоварување беше испратено во друг центар за податоци. Сите ќе дојдат да се поздрават со TLS во исто време.
И голем број TLS ракувања можеби веќе нема да се поздрават со Bouncer, туку ќе го стиснат неговото грло. Поради истекот на времето, бранот на дојдовни врски може да стане незадушен. Ако повторно се обидете во основата без експоненцијално повлекување, тие нема да доаѓаат повторно и повторно во кохерентен бран.
Еве пример за 16 PgBouncers кои вчитуваат 16 јадра на 100%.
Дојдовме до каскадата PgBouncer. Ова е најдобрата конфигурација што може да се постигне на нашето оптоварување со Bouncer. Нашите надворешни Bouncer се користат за TCP ракување, а внатрешните Bouncer се користат за вистинско здружување, за да не се фрагментираат премногу надворешните врски.
Во оваа конфигурација, можно е непречено рестартирање. Можете да ги рестартирате сите овие 18 Bouncers еден по еден. Но, одржувањето на таквата конфигурација е доста тешко. Sysadmins, DevOps и луѓето кои всушност се одговорни за овој сервер нема да бидат многу задоволни со овој аранжман.
Се чини дека сите наши подобрувања може да се промовираат во отворен код, но Bouncer не е многу добро поддржан. На пример, можноста за извршување на неколку PgBouncer на една порта беше извршена пред еден месец. Имаше барање за повлекување со оваа функција пред неколку години.
Или уште еден пример. Во Postgres, можете да откажете барање во тек со испраќање на тајната на друга врска без непотребна автентикација. Но, некои клиенти едноставно испраќаат ресетирање на TCP, односно ја прекинуваат мрежната врска. Што ќе направи Bouncer? Тој нема да направи ништо. Ќе продолжи да го извршува барањето. Ако сте примиле огромен број врски кои создале база на податоци со мали барања, тогаш едноставното исклучување на врската од Bouncer нема да биде доволно; исто така треба да ги завршите оние барања што се извршуваат во базата на податоци.
Ова е закрпено и овој проблем сè уште не е споен во upstream на Bouncer.
И така, дојдовме до заклучок дека ни треба сопствен спојувач за поврзување, кој ќе биде развиен, закрпен, во кој проблемите ќе можат брзо да се коригираат и кој, се разбира, мора да биде со повеќе нишки.
Како главна задача го поставивме multithreading. Треба да можеме добро да се справиме со бранот на дојдовни TLS конекции.
За да го направиме ова, моравме да развиеме посебна библиотека наречена Machinarium, која е дизајнирана да ги опишува машинските состојби на мрежна врска како секвенцијален код. Ако го погледнете изворниот код на libpq, ќе видите неколку прилично сложени повици кои можат да ви вратат резултат и да кажат: „Јави ми се подоцна. Во моментов имам IO за сега, но кога IO ќе исчезне, ќе имам оптоварување на процесорот. И ова е шема на повеќе нивоа. Мрежната комуникација обично се опишува со државна машина. Многу правила како „Ако претходно добив заглавие на пакет со големина N, сега чекам N бајти“, „Ако испратив SYNC пакет, сега чекам пакет со метаподатоци за резултатот“. Резултатот е прилично тежок, контраинтуитивен код, како лавиринтот да е претворен во линиско скенирање. Го направивме тоа така што наместо државна машина, програмерот ја опишува главната патека на интеракција во форма на обичен императивен код. Едноставно, во овој императивен код треба да вметнете места каде што секвенцата на извршување треба да се прекине со чекање податоци од мрежата, пренесувајќи го контекстот на извршување во друга корутина (зелена нишка). Овој пристап е сличен на фактот дека ја запишуваме најочекуваната патека во лавиринтот по ред, а потоа додаваме гранки на неа.
Како резултат на тоа, имаме една нишка која TCP прифаќа и round-robin ја пренесува TPC врската на многу работници.
Во овој случај, секоја клиентска врска секогаш работи на еден процесор. И ова ви овозможува да го направите пријателски за кешот.
Покрај тоа, малку го подобривме собирањето на мали пакети во еден голем пакет со цел да го ослободиме системскиот TCP оџак.
Дополнително, го подобривме здружувањето на трансакциите во смисла дека Одисеја, кога е конфигуриран, може да испрати ОТКАЖУВАЊЕ и ВРАЌАЊЕ во случај на неуспех на мрежната врска, т.е. ако никој не чека барање, Одисеја ќе и каже на базата на податоци да не се обидува да исполнување на барањето што може да ги троши скапоцените ресурси.
И секогаш кога е можно, одржуваме врски со истиот клиент. Со ова се избегнува потребата од повторно инсталирање на application_name_add_host. Ако тоа е можно, тогаш не мора дополнително да ги ресетираме параметрите што се потребни за дијагностика.
Работиме во интерес на Yandex.Cloud. И ако користите управуван PostgreSQL и имате инсталирано здружувач за поврзување, можете да креирате логичка репликација нанадвор, т.е., оставете нè, ако сакате, да користиме логичка репликација. Bouncer нема да го ослободи логичкиот тек на репликација надвор.
Ова е пример за поставување логичка репликација.
Покрај тоа, имаме поддршка за физичка репликација нанадвор. Во Cloud, се разбира, тоа е невозможно, бидејќи тогаш кластерот ќе ви даде премногу информации за себе. Но, во вашите инсталации, ако ви треба физичка репликација преку спојувачот за поврзување во Одисеја, ова е можно.
Одисеја има целосно компатибилен мониторинг со PgBouncer. Ја имаме истата конзола која ги извршува речиси сите исти команди. Ако нешто недостасува, испратете барање за повлекување или барем проблем на GitHub и ние ќе ги завршиме потребните команди. Но, ние веќе ја имаме главната функционалност на конзолата PgBouncer.
И, се разбира, имаме грешка при препраќање. Ќе ја вратиме грешката пријавена од базата на податоци. Ќе добиете информации зошто не сте вклучени во базата на податоци, а не само дека не сте вклучени во неа.
Оваа функција е оневозможена во случај да ви треба 100% компатибилност со PgBouncer. Можеме да се однесуваме на ист начин како Bouncer, само за да бидеме на безбедна страна.
Развој
Неколку зборови за изворниот код Одисеја.
На пример, постојат команди „Пауза / Продолжи“. Тие обично се користат за ажурирање на базата на податоци. Ако треба да го ажурирате Postgres, тогаш можете да го паузирате во спојувачот за поврзување, да направите pg_upgrade, а потоа да продолжите. И од страната на клиентот ќе изгледа како базата на податоци едноставно да забавува. Оваа функционалност ни ја донесоа луѓе од заедницата. Таа сè уште не е замрзната, но наскоро сè ќе биде. (Веќе замрзнат)
- веќе замрзнато
Покрај тоа, една од новите функции во PgBouncer е поддршката за SCRAM Authentication, која исто така ни ја донесе лице кое не работи во Yandex.Cloud. И двете се сложени функционални и важни.
Затоа, би сакал да ви кажам од што е направена Одисеја, ако и вие сакате да напишете мал код сега.
Имате изворна база Одисеја, која се потпира на две главни библиотеки. Библиотеката Киви е имплементација на протоколот за пораки Postgres. Односно, мајчин прото 3 на Postgres се стандардни пораки што предните и задните делови можат да ги разменуваат. Тие се имплементирани во библиотеката Киви.
Библиотеката Machinarium е библиотека за имплементација на нишки. Мал фрагмент од овој Махинариум е напишан на асемблерски јазик. Но, не се вознемирувајте, има само 15 линии.
Одисеја архитектура. Постои главна машина на која работат корутините. Оваа машина имплементира прифаќање на дојдовни TCP конекции и нивно дистрибуирање меѓу работниците.
Ракувач за неколку клиенти може да работи во рамките на еден работник. Главната нишка, исто така, ја извршува конзолата и ги обработува crone задачите за да ги избрише врските што повеќе не се потребни во базенот.
Одисеја се тестира со користење на стандардниот тест пакет Postgres. Само извршиме проверка на инсталација преку Bouncer и преку Odyssey, добиваме нула див. Постојат неколку тестови поврзани со форматирање на датуми кои не поминуваат исто во Bouncer и во Odyssey.
Покрај тоа, има многу возачи кои имаат свое тестирање. И ние ги користиме нивните тестови за да ја тестираме Одисеја.
Дополнително, поради нашата каскадна конфигурација, мораме да тестираме различни пакети: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey за да бидеме сигурни дека ако Одисеја заврши во некој од деловите во каскадата, исто така сè уште работи како што очекуваме.
Рејк
Ние користиме Одисеја во производството. И не би било фер ако кажам дека сè само функционира. Не, тоа е, да, но не секогаш. На пример, во производството сè само работеше, потоа нашите пријатели од PostgreSQL Professional дојдоа и рекоа дека имаме протекување на меморијата. Навистина беа, ги коригиравме. Но, беше едноставно.
Потоа откривме дека спојувачот за поврзување има дојдовни TLS конекции и појдовни TLS конекции. И врските бараат сертификати за клиент и сертификати за сервер.
Сертификатите на серверот Bouncer и Odyssey се препрочитуваат од нивниот pcache, но сертификатите на клиентот не треба да се препрочитуваат од pcache, бидејќи нашата скалабилна Одисеја на крајот навлегува во перформансите на системот за читање на овој сертификат. Ова беше изненадување за нас, бидејќи не му требаше долго да се спротивстави. Отпрвин се скалираше линеарно, но по 20 дојдовни симултани врски овој проблем се покажа.
Pluggable Authentication Method е способност за автентикација со помош на вградени Lunux алатки. Во PgBouncer тоа е имплементирано на таков начин што има посебна нишка за да се чека одговор од PAM и постои главна нишка на PgBouncer која ја сервисира тековната врска и може да побара од нив да живеат во нишката PAM.
Ова не го имплементиравме од една едноставна причина. Имаме многу нишки. Зошто ни треба ова?
Ова на крајот може да создаде проблеми со тоа што ако имате PAM автентикација и не-PAM автентикација, тогаш голем бран на PAM автентикација може значително да ја одложи автентикацијата што не е PAM. Ова е една од оние работи што не сме ја поправиле. Но, ако сакате да го поправите, можете да го направите ова.
Друго гребло беше тоа што имаме една нишка што ги прифаќа сите дојдовни врски. А потоа тие се префрлени во работничкиот базен, каде што ќе се одржи ракувањето со TLS.
Крајна линија, ако имате кохерентен бран од 20 мрежни конекции, сите тие ќе бидат прифатени. И на страната на клиентот, libpq ќе започне да известува за истекот на времето. Стандардно се чини дека е 000 секунди.
Ако сите тие не можат да влезат во базата на податоци во исто време, тогаш тие не можат да влезат во базата на податоци, бидејќи сето тоа може да се покрие со неекспоненцијално повторно обид.
Дојдовме до заклучок дека овде ја копиравме шемата од PgBouncer со фактот дека го намалуваме бројот на TCP конекции на кои прифаќаме.
Ако видиме дека прифаќаме врски, но тие на крајот немаат време за ракување, ги ставаме во ред за да не ги трошат ресурсите на процесорот. Ова води до фактот дека истовремено ракување не може да се изврши за сите пристигнати врски. Но, барем некој ќе влезе во базата на податоци, дури и ако товарот е доста тежок.
патоказот
Што би сакале да видите во иднина во Одисеја? Што сме подготвени да се развиваме и што очекуваме од заедницата?
Од август 2019 година.
Вака изгледаше патоказот Одисеја во август:
- Сакавме автентикација на SCRAM и PAM.
- Сакавме да ги проследиме барањата за читање во мирување.
- Би сакал онлајн рестартирање.
- И можноста за паузирање на серверот.
Половина од овој патоказ е завршен, а не од нас. И ова е добро. Затоа, ајде да разговараме што останува и да додадеме повеќе.
? Имаме реплики кои едноставно ќе го загреат воздухот без да извршуваат барања. Ни требаат тие да обезбедат фајловер и префрлување. Во случај на проблеми во еден од центрите за податоци, би сакал да ги окупирам со некоја корисна работа. Бидејќи не можеме да ги конфигурираме истите централни процесори, иста меморија поинаку, бидејќи во спротивно репликацијата нема да работи.
Во принцип, во Postgres, почнувајќи од 10, можно е да се наведе session_attrs при поврзување. Можете да ги наведете сите хостови на базата на податоци во врската и да кажете зошто одите во базата на податоци: само пишувајте или читајте. И самиот возач ќе го избере првиот домаќин во листата што најмногу му се допаѓа, што ги исполнува барањата на session_attrs.
Но, проблемот со овој пристап е што не го контролира доцнењето на репликацијата. Можеби имате некоја реплика што заостанувала неприфатливо време за вашата услуга. Со цел да се овозможи целосно извршување на прашања за читање на реплика, во суштина треба да ја поддржиме способноста на Одисеја да не работи кога не може да се прочита.
Одисеја мора одвреме-навреме да оди во базата на податоци и да бара растојание за репликација од примарното. И ако ја достигна граничната вредност, не дозволувајте нови барања во базата на податоци, кажете му на клиентот дека треба повторно да иницира врски и, можеби, да избере друг хост за извршување на барањата. Ова ќе и овозможи на базата на податоци брзо да го врати доцнењето на репликацијата и повторно да се врати за да одговори со барање.
Тешко е да се даде временска рамка за имплементација, бидејќи е со отворен код. Но, се надевам, не 2,5 години како моите колеги од PgBouncer. Ова е карактеристиката што би сакал да ја видам во Одисеја.
. Сега можете да креирате подготвена изјава на два начина. Прво, можете да ја извршите командата SQL, имено "подготвен". За да ја разбереме оваа команда SQL, треба да научиме да го разбираме SQL на страната на Bouncer. Ова би било претерување, бидејќи е претерано, бидејќи ни треба целиот парсер. Не можеме да ја анализираме секоја SQL команда.
Но, постои подготвена изјава на ниво на протокол за пораки на proto3. И ова е местото кога информациите дека се креира подготвена изјава доаѓа во структурирана форма. И ние би можеле да го поддржиме разбирањето дека на некоја серверска врска клиентот побарал да креира подготвени изјави. И дури и ако трансакцијата е затворена, сè уште треба да ја одржуваме поврзаноста помеѓу серверот и клиентот.
Но, тука се појавува несовпаѓање во дијалогот, бидејќи некој вели дека треба да разберете какви подготвени изјави создал клиентот и да ја споделите серверската врска помеѓу сите клиенти кои ја создале оваа серверска врска, т.е. кој создал таква подготвена изјава.
Андрес Фројнд рече дека ако дојде кај вас клиент кој веќе создал таква подготвена изјава во друга врска со серверот, тогаш креирајте ја за него. Но, изгледа малку погрешно да се извршуваат барања во базата на податоци наместо клиентот, но од гледна точка на развивачот кој го пишува протоколот за интеракција со базата на податоци, би било погодно ако едноставно му се даде мрежна врска во која има такво подготвено барање.
И уште една карактеристика што треба да ја имплементираме. Сега имаме мониторинг компатибилен со PgBouncer. Можеме да го вратиме просечното време на извршување на барањето. Но, просечното време е просечната температура во болницата: некои се ладни, некои се топли - во просек, сите се здрави. Тоа не е вистина.
Треба да имплементираме поддршка за перцентили кои би укажале дека има бавни прашања кои трошат ресурси и го прават следењето поприфатливо.
Најважно е што сакам верзија 1.0 (верзијата 1.1 е веќе објавена). Факт е дека Одисеја сега е во верзија 1.0rc, односно кандидат за ослободување. И сите проблеми што ги набројав се средени со иста верзија, освен истекувањето на меморијата.
Што ќе значи верзијата 1.0 за нас? Ја пренесуваме Одисеја до нашите бази. Веќе работи на нашите бази на податоци, но кога ќе достигне точка од 1 барања во секунда, тогаш можеме да кажеме дека ова е верзијата за издавање и ова е верзија што може да се нарече 000.
Неколку луѓе во заедницата побараа верзијата 1.0 да вклучува пауза и SCRAM. Но, тоа ќе значи дека ќе треба да ја пуштиме следната верзија во производство, бидејќи ниту SCRAM ниту паузата сè уште не се убиени. Но, најверојатно, ова прашање ќе се реши доста брзо.
Го чекам твоето барање за повлекување. Исто така, би сакал да слушнам какви проблеми имате со Bouncer. Ајде да разговараме за нив. Можеби можеме да имплементираме некои функции што ви се потребни.
Ова е крајот на мојот дел, би сакал да те слушам. Ви благодарам!
прашања
Ако поставам сопствена апликација_име, дали ќе биде препратена правилно, вклучително и при здружување трансакции во Одисеја?
Одисеја или отскокнувач?
Во Одисеја. Во Bouncer се фрла.
Ќе направиме сет.
И ако мојата вистинска врска скокне на други врски, дали ќе се пренесе?
Ќе направиме збир од сите параметри што се наведени во списокот. Не можам да кажам дали апликацијата_име е во оваа листа. Мислам дека го видов таму. Ќе ги поставиме сите исти параметри. Со едно барање, комплетот ќе направи се што е инсталирано од клиентот за време на стартувањето.
Ви благодариме, Андреј, за извештајот! Добар извештај! Мило ми е што Одисеја се развива побрзо и побрзо секоја минута. Сакам да продолжам вака. Веќе ве замоливме да имате поврзување со повеќе извори на податоци за да може Odyssey да се поврзе со различни бази на податоци истовремено, т.е. главен slave, а потоа автоматски да се поврзе со нов господар по откажување.
Да, изгледа се сеќавам на оваа дискусија. Сега има неколку складишта. Но, нема префрлување меѓу нив. Од наша страна, ние мора да го испитаме серверот дека тој е сè уште жив и да разбереме дека се случило откажување, кој ќе го повика pg_recovery. Имам стандарден начин на разбирање дека не дојдовме кај мајсторот. И дали треба да се разбереме некако од грешките или што? Односно, идејата е интересна, се дискутира. Напишете повеќе коментари. Ако имате работници кои знаат C, тогаш тоа е генерално одлично.
Прашањето за скалирање низ репликите е исто така од интерес за нас, бидејќи сакаме да го направиме усвојувањето на реплицирани кластери што е можно поедноставно за развивачите на апликации. Но, тука би сакал повеќе коментари, т.е. точно како да го направи тоа, како да го направи тоа добро.
Прашањето е и за репликите. Излегува дека имате мајстор и неколку реплики. И јасно е дека поретко одат кај репликата отколку кај мајсторот за врски, бидејќи може да имаат разлики. Рековте дека разликата во податоците може да биде таква што нема да го задоволи вашиот бизнис и нема да одите таму додека не се реплицира. Во исто време, ако не сте отишле таму долго време, а потоа сте почнале да одите, тогаш податоците што ви се потребни нема да бидат веднаш достапни. Односно, ако постојано одиме кај мајсторот, тогаш кешот таму се загрева, но во репликата кешот малку заостанува.
Да, тоа е вистина. Pcache-от нема да ги има блоковите на податоци што ги сакате, вистинскиот кеш нема да има информации за табелите што ги сакате, плановите нема да имаат анализирани прашања, нема да има ништо воопшто.
А кога имаш некаков кластер и таму додаваш нова реплика, тогаш додека стартува се е лошо во него, т.е го зголемува кешот.
Ја добив идејата. Точниот пристап би бил прво да се изврши мал процент на прашања на репликата, што ќе го загрее кешот. Грубо кажано, имаме услов дека мора да заостануваме зад мајсторот не повеќе од 10 секунди. И оваа состојба не е вклучена во еден бран, туку непречено за некои клиенти.
Да, зголемете ја тежината.
Ова е добра идеја. Но, прво треба да го спроведеме ова исклучување. Прво треба да се исклучиме, а потоа ќе размислиме како да се вклучиме. Ова е одлична карактеристика за непречено овозможување.
Nginx ја има оваа опција slowly start во кластер за серверот. И тој постепено го зголемува товарот.
Да, одлична идеја, ќе ја пробаме кога ќе стигнеме до неа.
Извор: www.habr.com