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

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

Видео:

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

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

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

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

В Яндекс има Postgres. В Яндекс.Облака живеят много услуги на Яндекс. И имаме няколко петабайта данни, които генерират не по-малко от милион заявки в секунда в Postgres.

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

Всеки възел на клъстера е Postgres, на който освен Postgres и системите за мониторинг е инсталиран и пул за връзки. Пуловете за връзки се използват за fencing и по основното си предназначение.

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

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

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

Съществуват 3 възможни подхода:

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

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

Application-side pool е най-простият начин. Почти всички клиентски драйвери предлагат начин за представяне на милионите ви връзки в кода под формата на няколко десетки връзки към базата данни.

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

След това осъзнавате, че имате още няколко зони на достъпност, няколко дата-центрове. И подходът с client side pooling води до големи числа. Големи – това е около 10 000 връзки. Това е пределят, при който може да работи нормално.

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

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

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

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

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

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

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

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

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

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

Можеше да се направи и от страна на Postgres, т.е. ролите в базата данни да се ограничат с брой връзки.

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

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

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

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

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

Малко доправихме Bouncer.

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

Това е прозрачно за клиентите, т.е. всичко изглежда така, сякаш имате един Bouncer, но имате фрагментация на idle връзките между стартираните Bouncer-и.

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

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

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

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

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

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

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

На пръв поглед, можем да популяризираме всичките ни подобрения в open source, но Bouncer не се поддържа много добре. Например, възможността да стартирате няколко PgBouncers на един порт бе закомитвана преди месец. А pull request с тази функция е бил направен преди няколко години.

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

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

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

Това беше поправено и този проблем все още не е влеен в upstream на Bouncer-а.

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

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

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

В резултат имаме един поток, който прави TCP accept и с round-robin предава множествo от workers TCP-соединение.

При това всяко клиентско свързване работи винаги на един процесор. И това позволява да бъде cache-friendly.

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

https://github.com/yandex/odyssey/pull/73 — вече е обединена

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

Затова искам да разкажа от какво е направен Odyssey, изведнъж и вие искате да напишете малко код.

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

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

Архитектурата на Odyssey. Има основна машина, в която се изпълняват корутиини. В тази машина се реализира приемането на входящи TCP-съединения и разпределение по работници.

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

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

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

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

Грабли

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

После открихме, че в connection pooler има входящи TLS-свързвания и изходящи TLS-свързвания. И за свързванията са нужни клиентски и сърверни сертификати.

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

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

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

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

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

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

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

Ние стигнахме до извода, че копирахме схемата от PgBouncer, с това че имаме throttling на количеството TCP-свързвания, които приемаме.

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

Roadmap

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

Към август 2019 година.

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

• Искахме SCRAM и PAM удостоверяване.
• Искахме напреднали четящи заявки на standby.
• Бихме искали online-restart.
• И възможност за пауза на сървъра.

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

Що се отнася до напредналите четящи заявки към standby? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С това моята част приключва, бих искал да чуя вас. Благодаря!

Въпроси

Ако зададам моето application_name, ще се предаде правилно, включително в transaction pooling в Odyssey?

В Odyssey или в Bouncer?

В Odyssey. В Bouncer се предава.

Ще направим сет.

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

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

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

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

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

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

Да, това е вярно. В pcache няма да има блокове данни, които желаете, в real cache няма да има информация за таблиците, които искате, в плановете няма да има парснати заявки, изобщо нищо няма да има.

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

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

Да, да увеличим тежестта.

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

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

Да, отлична идея, ще опитаме, когато стигнем до това.

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