Пътна карта на Odyssey: какво още искаме от пулер за връзка. Андрей Бородин (2019)

В своя доклад Андрей Бородин ще ви разкаже как са взели предвид опита от мащабирането на PgBouncer при проектирането на пулера за връзка Одисея, докато го пуснаха в производство. Освен това ще обсъдим какви функции на теглича бихме искали да видим в новите версии: за нас е важно не само да отговорим на нашите нужди, но и да развием потребителската общност Одисея.

Video:

Здравейте всички! Казвам се Андрю.

В Yandex разработвам бази данни с отворен код. И днес имаме тема за връзките на пулера за връзки.

Ако знаете как да се обадите на пулар на връзки на руски, тогава ми кажете. Наистина искам да намеря добър технически термин, който да се утвърди в техническата литература.

Темата е доста сложна, тъй като в много бази данни пулерът за връзки е вграден и дори не е нужно да знаете за него. Разбира се, има някои настройки навсякъде, но в Postgres не работи по този начин. И паралелно (на HighLoad++ 2019) има доклад на Николай Самохвалов за настройка на заявки в Postgres. И доколкото разбирам, тук са дошли хора, които вече са конфигурирали своите заявки перфектно и това са хора, които са изправени пред по-редки системни проблеми, свързани с мрежата и използването на ресурсите. И на някои места може да е доста трудно в смисъл, че проблемите не са очевидни.

Yandex има Postgres. Много услуги на Yandex живеят в Yandex.Cloud. И имаме няколко петабайта данни, които генерират поне милион заявки в секунда в Postgres.

И ние предоставяме доста стандартен клъстер за всички услуги - това е основният първичен възел на възела, обичайните две реплики (синхронна и асинхронна), архивиране, мащабиране на заявките за четене на репликата.

Всеки клъстерен възел е Postgres, на който освен Postgres и системи за наблюдение е инсталиран и пулер за връзка. Connection pooler се използва за ограждане и за основната си цел.

Каква е основната цел на пулера за свързване?

Postgres приема модел на процес, когато работи с база данни. Това означава, че една връзка е един процес, един бекенд на Postgres. И в този бекенд има много различни кешове, които са доста скъпи да се правят различни за различни връзки.

Освен това кодът на Postgres има масив, наречен procArray. Съдържа основни данни за мрежовите връзки. И почти всички алгоритми за обработка на procArray имат линейна сложност; те работят върху целия масив от мрежови връзки. Това е доста бърз цикъл, но с повече входящи мрежови връзки нещата стават малко по-скъпи. И когато нещата станат малко по-скъпи, можете да платите много висока цена за много мрежови връзки.

Има 3 възможни подхода:

• От страна на приложението.
• От страна на базата данни.
• И между, тоест всякакви комбинации.

За съжаление, вграденият пулер в момента е в процес на разработка. Нашите приятели от PostgreSQL Professional правят това предимно. Кога ще се появи е трудно да се предвиди. И всъщност имаме две решения, от които архитектът да избира. Това са пул от страна на приложението и прокси пул.

Пулът от страна на приложението е най-лесният начин. И почти всички клиентски драйвери ви предоставят начин: представяйте милиони от вашите връзки в код като няколко десетки връзки към базата данни.

Проблемът, който възниква, е, че в определен момент искате да мащабирате бекенда, искате да го внедрите на много виртуални машини.

Тогава осъзнавате, че имате още няколко зони за достъпност, няколко центъра за данни. А подходът за групиране от страна на клиента води до големи числа. Големите са около 10 000 връзки. Това е ръбът, който може да работи нормално.

Ако говорим за прокси пулери, тогава има два пулера, които могат да правят много неща. Те не са само пуляри. Те са пулери + още готина функционалност. Това Pgpool и Crunchy-Proxy.

Но, за съжаление, не всеки се нуждае от тази допълнителна функционалност. И това води до факта, че пулърите поддържат само обединяване на сесии, т.е. един входящ клиент, един изходящ клиент към базата данни.

Това не е много подходящо за нашите цели, затова използваме PgBouncer, който реализира групиране на транзакции, т.е. сървърните връзки се съпоставят с клиентските връзки само за времетраенето на транзакцията.

И при нашето натоварване това е вярно. Но има няколко проблема.

Проблемите започват, когато искате да диагностицирате сесия, защото всичките ви входящи връзки са локални. Всеки дойде с loopback и някак си става трудно да се проследи сесията.

Разбира се, можете да използвате application_name_add_host. Това е начин от страна на Bouncer да добави IP адрес към име на_приложение. Но application_name се задава от допълнителна връзка.

На тази графика, където жълтата линия е реални заявки, а синята линия е заявки, които летят в базата данни. И тази разлика е именно инсталирането на application_name, което е необходимо само за проследяване, но не е безплатно.

Освен това в Bouncer не можете да ограничите един пул, т.е. броя на връзките към база данни за конкретен потребител, за конкретна база данни.

До какво води това? Имате заредена услуга, написана на C++ и някъде наблизо малка услуга на възел, която не прави нищо ужасно с базата данни, но нейният драйвер полудява. Отваря 20 000 връзки и всичко останало ще чака. Дори кодът ви е нормален.

Ние, разбира се, написахме малък пач за Bouncer, който добави тази настройка, т.е. ограничаване на клиентите до пула.

Би било възможно да направите това от страна на Postgres, т.е. да ограничите ролите в базата данни с броя на връзките.

Но тогава губите способността да разберете защо нямате връзки към сървъра. PgBouncer не извежда грешка при свързване, винаги връща същата информация. И не можете да разберете: може би паролата ви е променена, може би базата данни просто се е загубила, може би нещо не е наред. Но диагноза няма. Ако една сесия не може да бъде установена, вие няма да знаете защо не може да бъде установена.

В определен момент гледате графиките на приложението и виждате, че приложението не работи.

Погледнете отгоре и вижте, че Bouncer е еднонишков. Това е повратна точка в живота на службата. Разбирате, че сте се подготвяли да мащабирате базата данни за година и половина и трябва да мащабирате пула.

Стигнахме до извода, че имаме нужда от повече PgBouncers.

https://lwn.net/Articles/542629/

Bouncer е малко закърпен.

И те направиха така, че няколко Bouncers да могат да бъдат повдигнати чрез повторно използване на TCP порта. И операционната система автоматично прехвърля входящите TCP връзки между тях с помощта на кръгов режим.

Това е прозрачно за клиентите, което означава, че изглежда, че имате един Bouncer, но имате фрагментирани неактивни връзки между работещи Bouncer.

И в определен момент може да забележите, че всеки от тези 3 Bouncers изяжда сърцевината си на 100%. Имате нужда от доста избивачи. Защо?

Защото имате TLS. Имате криптирана връзка. И ако сравните Postgres с и без TLS, ще откриете, че броят на установените връзки намалява с почти два порядъка с активирано криптиране, тъй като TLS ръкостискането консумира ресурси на процесора.

И в горната част можете да видите доста криптографски функции, които се изпълняват, когато има вълна от входящи връзки. Тъй като нашият първичен може да превключва между зоните на достъпност, вълната от входящи връзки е доста типична ситуация. Тоест по някаква причина старият първичен не беше наличен, целият товар беше изпратен до друг център за данни. Всички те ще дойдат да поздравят TLS едновременно.

И голям брой TLS ръкостискания може вече да не казват здравей на Bouncer, но ще стискат гърлото му. Поради времето за изчакване, вълната от входящи връзки може да стане незатихваща. Ако опитате отново към базата без експоненциално отдръпване, те няма да идват отново и отново в кохерентна вълна.

Ето пример за 16 PgBouncers, които зареждат 16 ядра на 100%.

Стигнахме до каскадата PgBouncer. Това е най-добрата конфигурация, която може да бъде постигната на нашия товар с Bouncer. Нашите външни отбивачи се използват за TCP ръкостискане, а вътрешните отбивачи се използват за реално обединяване, за да не се фрагментират твърде много външните връзки.

В тази конфигурация е възможно плавен рестарт. Можете да рестартирате всички тези 18 Bouncers един по един. Но поддържането на такава конфигурация е доста трудно. Сисадмините, DevOps и хората, които всъщност са отговорни за този сървър, няма да бъдат много доволни от това споразумение.

Изглежда, че всички наши подобрения могат да бъдат повишени към отворен код, но Bouncer не се поддържа много добре. Например възможността за стартиране на няколко PgBouncers на един порт беше ангажирана преди месец. Преди няколко години имаше заявка за изтегляне с тази функция.

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

Или още един пример. В Postgres можете да отмените текуща заявка, като изпратите тайната на друга връзка без ненужно удостоверяване. Но някои клиенти просто изпращат нулиране на TCP, т.е. прекъсват мрежовата връзка. Какво ще направи Bouncer? Той няма да направи нищо. Той ще продължи да изпълнява заявката. Ако сте получили огромен брой връзки, които са създали база данни с малки заявки, тогава простото прекъсване на връзката от Bouncer няма да е достатъчно; вие също трябва да завършите тези заявки, които се изпълняват в базата данни.

Това е коригирано и този проблем все още не е обединен в upstream на Bouncer.

И така стигнахме до извода, че се нуждаем от собствен пул за свързване, който ще бъде разработен, закърпен, в който проблемите могат да бъдат бързо коригирани и който, разбира се, трябва да бъде многонишков.

Поставихме многонишковостта като основна задача. Трябва да можем да се справим добре с вълната от входящи TLS връзки.

За да направим това, трябваше да разработим отделна библиотека, наречена Machinarium, която е предназначена да описва машинните състояния на мрежова връзка като последователен код. Ако погледнете изходния код на libpq, ще видите някои доста сложни извиквания, които могат да ви върнат резултат и да кажат: „Обади ми се по-късно. В момента имам IO за момента, но когато IO изчезне, ще имам натоварване на процесора. И това е многостепенна схема. Мрежовата комуникация обикновено се описва от държавна машина. Много правила като „Ако преди това получих заглавка на пакет с размер N, сега чакам N байта“, „Ако изпратих SYNC пакет, сега чакам пакет с метаданни за резултата.“ Резултатът е доста труден, контраинтуитивен код, сякаш лабиринтът е преобразуван в линейно сканиране. Направихме го така, че вместо държавна машина, програмистът описва основния път на взаимодействие под формата на обикновен императивен код. Просто в този императивен код трябва да вмъкнете места, където последователността на изпълнение трябва да бъде прекъсната чрез изчакване на данни от мрежата, предавайки контекста на изпълнение на друга съпрограма (зелена нишка). Този подход е подобен на факта, че записваме най-очаквания път в лабиринта в един ред и след това добавяме разклонения към него.

В резултат на това имаме една нишка, която TCP приема и кръгово предава TPC връзката на много работници.

В този случай всяка клиентска връзка винаги работи на един процесор. И това ви позволява да го направите удобен за кеша.

И в допълнение, леко подобрихме събирането на малки пакети в един голям пакет, за да облекчим TCP стека на системата.

В допълнение, подобрихме групирането на транзакциите в смисъл, че Odyssey, когато е конфигуриран, може да изпраща CANCEL и ROLLBACK в случай на повреда на мрежовата връзка, т.е. ако никой не чака заявка, Odyssey ще каже на базата данни да не се опитва да изпълнете искането, което може да похаби ценни ресурси.

И винаги, когато е възможно, поддържаме връзки със същия клиент. Това избягва необходимостта от преинсталиране на application_name_add_host. Ако това е възможно, тогава не е необходимо допълнително да нулираме параметрите, които са необходими за диагностика.

Ние работим в интерес на Yandex.Cloud. И ако използвате управляван PostgreSQL и имате инсталиран пул за връзка, можете да създадете логическа репликация навън, т.е. оставете ни, ако искате, да използваме логическа репликация. Bouncer няма да освободи логическия поток на репликация навън.

Това е пример за настройка на логическа репликация.

Освен това имаме поддръжка за физическа репликация навън. В облака, разбира се, това е невъзможно, защото тогава клъстерът ще ви даде твърде много информация за себе си. Но във вашите инсталации, ако имате нужда от физическа репликация чрез пула на връзките в Odyssey, това е възможно.

Odyssey има напълно съвместим мониторинг с PgBouncer. Имаме същата конзола, която изпълнява почти всички едни и същи команди. Ако нещо липсва, изпратете заявка за изтегляне или поне проблем в GitHub и ние ще изпълним необходимите команди. Но вече имаме основната функционалност на конзолата PgBouncer.

И, разбира се, имаме препращане на грешки. Ние ще върнем грешката, отчетена от базата данни. Ще получите информация защо не сте включени в базата данни, а не само, че не сте включени в нея.

Тази функция е деактивирана в случай, че се нуждаете от 100% съвместимост с PgBouncer. Можем да се държим по същия начин като Bouncer, само за по-сигурно.

дизайн

Няколко думи за изходния код на Odyssey.

https://github.com/yandex/odyssey/pull/66

Например, има команди „Пауза / Възобновяване“. Те обикновено се използват за актуализиране на базата данни. Ако трябва да актуализирате Postgres, тогава можете да го поставите на пауза в пула на връзките, да направите pg_upgrade и след това да възобновите. И от страна на клиента ще изглежда така, сякаш базата данни просто се забавя. Тази функционалност ни беше предоставена от хора от общността. Все още не е замръзнала, но скоро всичко ще бъде. (Вече замразено)

https://github.com/yandex/odyssey/pull/73 - вече замразени

В допълнение, една от новите функции в PgBouncer е поддръжката на SCRAM Authentication, която също ни беше предоставена от човек, който не работи в Yandex.Cloud. И двете имат сложна функционалност и са важни.

Затова бих искал да ви кажа от какво е направена Odyssey, в случай че искате да напишете малко код сега.

Имате изходната база на Odyssey, която разчита на две основни библиотеки. Библиотеката Kiwi е реализация на протокола за съобщения Postgres. Тоест родният прото 3 на Postgres е стандартни съобщения, които предните и задните части могат да обменят. Те са внедрени в библиотеката Kiwi.

Библиотеката Machinarium е библиотека за внедряване на нишки. Малък фрагмент от този Machinarium е написан на асемблер. Но не се тревожете, има само 15 реда.

Одисея архитектура. Има основна машина, на която се изпълняват съпрограми. Тази машина изпълнява приемането на входящи TCP връзки и тяхното разпространение между работниците.

В рамките на един работник може да работи манипулатор за няколко клиента. Основната нишка също така изпълнява конзолата и обработката на задачите на crone за изтриване на връзки, които вече не са необходими в пула.

Odyssey се тества с помощта на стандартния тестов пакет Postgres. Просто изпълняваме install-check през Bouncer и през Odyssey, получаваме нулев div. Има няколко теста, свързани с форматирането на дата, които не преминават абсолютно еднакво в Bouncer и в Odyssey.

Освен това има много драйвери, които имат свои собствени тестове. И ние използваме техните тестове, за да тестваме Odyssey.

Освен това, поради нашата каскадна конфигурация, трябва да тестваме различни пакети: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, за да сме сигурни, че ако Odyssey е попаднал в някоя от частите на каскадата, той също все още работи както очакваме.

гребло

Ние използваме Odyssey в производството. И няма да е честно, ако кажа, че всичко просто работи. Не, това е, да, но не винаги. Например, в производството всичко просто работеше, тогава нашите приятели от PostgreSQL Professional дойдоха и казаха, че имаме изтичане на памет. Наистина бяха, коригирахме ги. Но беше просто.

След това открихме, че пулерът на връзки има входящи TLS връзки и изходящи TLS връзки. А връзките изискват клиентски сертификати и сървърни сертификати.

Сертификатите на Bouncer и Odyssey сървъри се препрочитат от техния pcache, но клиентските сертификати не е необходимо да се препрочитат от pcache, тъй като нашият мащабируем Odyssey в крайна сметка се сблъсква с производителността на системата при четене на този сертификат. Това беше изненада за нас, защото не му отне много време да се съпротивлява. Първоначално се мащабираше линейно, но след 20 000 входящи едновременни връзки този проблем се прояви.

Pluggable Authentication Method е възможността за удостоверяване с помощта на вградени инструменти на Lunux. В PgBouncer това е реализирано по такъв начин, че има отделна нишка, която да чака отговор от PAM и има основна нишка PgBouncer, която обслужва текущата връзка и може да ги помоли да живеят в PAM нишката.

Ние не внедрихме това поради една проста причина. Имаме много теми. Защо имаме нужда от това?

Това в крайна сметка може да създаде проблеми, тъй като ако имате PAM удостоверяване и не-PAM удостоверяване, тогава голяма вълна от PAM удостоверяване може значително да забави не-PAM удостоверяване. Това е едно от нещата, които не сме поправили. Но ако искате да го поправите, можете да направите това.

Друг рейк беше, че имаме една нишка, която приема всички входящи връзки. И след това те се прехвърлят към работния пул, където ще се проведе TLS ръкостискането.

В крайна сметка, ако имате кохерентна вълна от 20 000 мрежови връзки, всички те ще бъдат приети. И от страна на клиента libpq ще започне да отчита таймаути. По подразбиране изглежда, че е 3 секунди.

Ако всички те не могат да влязат в базата данни едновременно, тогава те не могат да влязат в базата данни, защото всичко това може да бъде покрито от неекспоненциален повторен опит.

Стигнахме до извода, че сме копирали схемата от PgBouncer тук с факта, че сме ограничили броя на TCP връзките, към които приемаме.

Ако видим, че приемаме връзки, но те в крайна сметка нямат време за ръкостискане, ние ги поставяме на опашка, така че да не губят ресурси на процесора. Това води до факта, че може да не се извърши едновременно ръкостискане за всички пристигнали връзки. Но поне някой ще влезе в базата данни, дори ако натоварването е доста голямо.

Пътна карта

Какво бихте искали да видите в бъдеще в Odyssey? Какво сме готови да развием сами и какво очакваме от общността?

Към август 2019 г.

Ето как изглеждаше пътната карта на Odyssey през август:

• Искахме SCRAM и PAM удостоверяване.
• Искахме да препратим заявките за четене в режим на готовност.
• Бих искал онлайн рестартиране.
• И възможност за пауза на сървъра.

Половината от тази пътна карта е изпълнена и то не от нас. И това е добре. Така че нека обсъдим какво остава и да добавим още.

Относно пренасочване на заявки само за четене към режим на готовност? Имаме реплики, които просто ще затоплят въздуха, без да изпълняват заявки. Имаме нужда от тях, за да осигурим превключване и превключване. В случай на проблеми в някой от центровете за данни, бих искал да ги заема с полезна работа. Тъй като не можем да конфигурираме едни и същи централни процесори, една и съща памет по различен начин, защото в противен случай репликацията няма да работи.

По принцип в Postgres, започвайки от 10, е възможно да се посочи session_attrs при свързване. Можете да изброите всички хостове на базата данни във връзката и да кажете защо отивате в базата данни: само за писане или четене. И самият драйвер ще избере първия хост в списъка, който му харесва най-много, който отговаря на изискванията на session_attrs.

Но проблемът с този подход е, че той не контролира забавянето на репликацията. Може да имате някаква реплика, която е изостанала за неприемливо време за вашата услуга. За да позволим пълнофункционално изпълнение на заявки за четене на реплика, ние по същество трябва да поддържаме способността на Odyssey да не се изпълнява, когато не може да бъде прочетена.

Odyssey трябва да посещава базата данни от време на време и да пита за разстоянието на репликация от основния. И ако е достигнал граничната стойност, не позволявайте нови заявки в базата данни, кажете на клиента, че трябва да инициира отново връзки и, евентуално, изберете друг хост за изпълнение на заявки. Това ще позволи на базата данни бързо да възстанови забавянето на репликацията и да се върне отново, за да отговори със заявка.

Трудно е да се даде времева рамка за внедряване, защото е с отворен код. Но, надявам се, не 2,5 години като колегите от PgBouncer. Това е функцията, която бих искал да видя в Odyssey.

В общността хората поискаха подкрепа за подготвеното изявление. Сега можете да създадете подготвено изявление по два начина. Първо, можете да изпълните SQL командата, а именно "подготвен". За да разберем тази SQL команда, трябва да се научим да разбираме SQL от страната на Bouncer. Това би било излишно, защото е излишно, тъй като имаме нужда от целия анализатор. Не можем да анализираме всяка SQL команда.

Но има подготвено изявление на ниво протокол за съобщения на proto3. И това е мястото, когато информацията, че се създава изготвено изявление, идва в структуриран вид. И бихме могли да подкрепим разбирането, че при някаква сървърна връзка клиентът е поискал да създаде подготвени изрази. И дори ако транзакцията е затворена, все още трябва да поддържаме връзка между сървъра и клиента.

Но тук възниква несъответствие в диалога, защото някой казва, че трябва да разберете какъв вид подготвени изрази е създал клиентът и да споделите сървърната връзка между всички клиенти, които са създали тази сървърна връзка, т.е. кой е създал такъв подготвен оператор.

Андрес Фройнд каза, че ако при вас дойде клиент, който вече е създал такова подготвено изявление в друга сървърна връзка, създайте го за него. Но изглежда малко погрешно да се изпълняват заявки в базата данни вместо клиента, но от гледна точка на разработчика, който пише протокола за взаимодействие с базата данни, би било удобно, ако му се даде просто мрежова връзка, в която има такава подготвена заявка.

И още една функция, която трябва да приложим. Вече имаме мониторинг, съвместим с PgBouncer. Можем да върнем средното време за изпълнение на заявката. Но средното време е средната температура в болницата: някои са студени, други са топли - средно всички са здрави. Не е вярно.

Трябва да внедрим поддръжка за процентили, което ще покаже, че има бавни заявки, които губят ресурси и ще направи наблюдението по-приемливо.

Най-важното е, че искам версия 1.0 (Версия 1.1 вече е пусната). Факт е, че Odyssey вече е във версия 1.0rc, т.е. кандидат за освобождаване. И всички проблеми, които изброих, бяха коригирани с абсолютно същата версия, с изключение на изтичането на памет.

Какво ще означава версия 1.0 за нас? Пускаме Odyssey в нашите бази. Той вече работи в нашите бази данни, но когато достигне точка от 1 000 000 заявки в секунда, тогава можем да кажем, че това е версията за освобождаване и това е версия, която може да се нарече 1.0.

Няколко души в общността поискаха версия 1.0 да включва пауза и SCRAM. Но това ще означава, че ще трябва да пуснем следващата версия в производство, тъй като нито SCRAM, нито паузата все още не са убити. Но най-вероятно този проблем ще бъде решен доста бързо.

Очаквам вашата заявка за изтегляне. Също така бих искал да чуя какви проблеми имаш с Bouncer. Нека ги обсъдим. Може би можем да внедрим някои функции, от които се нуждаете.

Това е краят на моята част, бих искал да ви изслушам. Благодаря ти!

Въпроси

Ако задам мое собствено име на приложение, то ще бъде ли препратено правилно, включително в обединяването на транзакции в Odyssey?

Одисей или бияч?

В Одисей. В Bouncer се хвърля.

Ще направим комплект.

И ако истинската ми връзка прескочи на други връзки, ще бъде ли предадена?

Ние ще направим набор от всички параметри, които са изброени в списъка. Не мога да разбера дали application_name е в този списък. Мисля, че го видях там. Ще зададем всички същите параметри. С една заявка комплектът ще направи всичко, което е инсталирано от клиента при стартиране.

Благодаря ти, Андрей, за репортажа! Добър репортаж! Радвам се, че Odyssey се развива все по-бързо с всяка минута. Искам да продължавам така. Вече ви помолихме да имате връзка с множество източници на данни, така че Odyssey да може да се свърже с различни бази данни едновременно, т.е. главен подчинен, и след това автоматично да се свърже с нов главен след отказ.

Да, изглежда помня тази дискусия. Сега има няколко хранилища. Но няма превключване между тях. От наша страна трябва да проверим сървъра, че все още е жив и да разберем, че е настъпил отказ, който ще извика pg_recovery. Имам стандартен начин да разбера, че не сме дошли при господаря. И да разбираме някак от грешките или какво? Тоест идеята е интересна, обсъжда се. Пишете още коментари. Ако имате работници, които знаят C, тогава това е страхотно.

Въпросът с мащабирането между реплики също ни интересува, защото искаме да направим приемането на репликирани клъстери възможно най-лесно за разработчиците на приложения. Но тук бих искал повече коментари, т.е. как точно да го направя, как да го направя добре.

Въпросът е и за реплики. Оказва се, че имате майстор и няколко реплики. И е ясно, че по-рядко ходят при репликата, отколкото при майстора за връзки, защото може да имат разлики. Казахте, че разликата в данните може да е такава, че да не задоволи бизнеса ви и няма да отидете там, докато не бъде репликирана. В същото време, ако не сте ходили там дълго време и след това сте започнали да ходите, тогава необходимите данни няма да бъдат достъпни веднага. Тоест, ако постоянно отиваме при главния, тогава кешът там се загрява, но в репликата кешът изостава малко.

Да, това е вярно. Pcache няма да има блоковете данни, които искате, истинският кеш няма да има информация за таблиците, които искате, плановете няма да имат анализирани заявки, няма да има нищо.

И когато имаш някакъв клъстер и добавиш нова реплика там, тогава докато тръгне, всичко в него е зле, т.е. увеличава си кеша.

Схванах идеята. Правилният подход би бил първо да се изпълнят малък процент от заявките за репликата, което би затоплило кеша. Грубо казано, имаме условие да изоставаме от капитана с не повече от 10 секунди. И това условие не се включва в една вълна, а плавно за някои клиенти.

Да, увеличаване на теглото.

Това е добра идея. Но първо трябва да приложим това изключване. Първо трябва да изключим и след това ще мислим как да включим. Това е страхотна функция за плавно активиране.

Nginx има тази опция slowly start в клъстер за сървъра. И той постепенно увеличава натоварването.

Да, страхотна идея, ще я пробваме, когато стигнем до нея.

Източник: www.habr.com