WAL-G: нови функции и разширяване на общността. Георги Рилов

Предлагам ви да прочетете стенограмата на доклада от началото на 2020 г. на Георги Рилов „WAL-G: нови възможности и разширяване на общността“

Поддръжниците на отворен код са изправени пред много предизвикателства, докато растат. Как да напиша все повече и повече необходими функции, да коригирам все повече и повече проблеми и да успявам да преглеждам все повече и повече заявки за изтегляне? Като използвам WAL-G (инструмент за архивиране за PostgreSQL) като пример, ще ви разкажа как решихме тези проблеми, като стартирахме курс за разработка с отворен код в университета, какво постигнахме и накъде ще продължим.

Здравейте отново на всички! Аз съм разработчик на Yandex от Екатеринбург. И днес ще говоря за WAL-G.

Заглавието на доклада не казваше, че става въпрос за резервни копия. Някой знае ли какво е WAL-G? Или всички знаят? Вдигнете ръка, ако не знаете. По дяволите, стигнахте до доклада и не знаете за какво става дума.

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

В предишните серии имаше много репортажи на Андрей Бородин и Владимир Лесков. Бяхме много. И ние говорим за WAL-G от много години.

clck.ru/F8ioz — https://www.highload.ru/moscow/2018/abstracts/3964

clck.ru/Ln8Qw — https://www.highload.ru/moscow/2019/abstracts/5981

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

Преди няколко години WAL-G беше сравнително малък проект, който получихме от Citus Data. И ние просто го взехме. И е разработен от един човек.

И само WAL-G нямаше:

• Архивиране от реплика.
• Нямаше инкрементални архиви.
• Нямаше резервни копия на WAL-Delta.
• И все още липсваше много.

През тези няколко години WAL-G нарасна много.

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

• Повече от 1 звезди в GitHub.
• 150 вилици.
• Около 15 отворени PR.
• И много други сътрудници.
• И отворени въпроси през цялото време. И това въпреки факта, че ние буквално ходим там всеки ден и правим нещо по въпроса.

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

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

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

При какви условия се приема студентски PR?

• От тях се изисква да покрият своя код с тестове. Всичко трябва да се случи в CI.
• И също така преминаваме през 2 прегледа. Един от Андрей Бородин и един от мен.
• Освен това, за да проверя дали това няма да повреди нещо в нашата услуга, отделно качвам сборката с този ангажимент. И ние проверяваме в тестовете от край до край, че нищо не се проваля.

Специален курс по отворен код

Малко за това защо това е необходимо и защо това, струва ми се, е страхотна идея.

За нас печалбата е очевидна:

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

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

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

Попитах ги за това. И по техните думи:

• Опит на сътрудник в Open Source.
• Вземете ред в автобиографията си.
• Докажете се и преминете интервю в Yandex.
• Станете член на GSoC.
• +1 специален курс за тези, които искат да пишат код.

Няма да говоря за това как беше структуриран курсът. Само ще кажа, че WAL-G беше основният проект. В този курс включихме и проекти като Odyssey, PostgreSQL и ClickHouse.

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

Какво ще кажете за ползата за потребителите?

Сега да преминем към частта, която ви интересува най-много. Каква е ползата от това? Въпросът е, че учениците поправиха много грешки. И направихме функциите на заявката, които поискахте от нас.

И нека ви разкажа за нещата, които отдавна сте искали и които сте реализирали.

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

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

Пространствата за таблици са директории, които съдържат данни на Postgres, но не се намират извън основната директория. Слайдът показва, че tablespacs се намират извън основната директория.

Как изглежда това за самия Postgres? В основната директория има отделна поддиректория pg_tblspc. И съдържа символни връзки към директории, които всъщност съдържат данни на Postgres извън основната директория.

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

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

Друга характеристика, която ни донесе нашият специален курс, е наваксването. Хората, които вероятно са работили повече с Oracle, отколкото с Postgres, знаят за наваксването.

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

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

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

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

Други бази

Студентите също ни донесоха много функции наведнъж. Тъй като в Yandex ние готвим не само Postgres, имаме и MySQL, MongoDB, Redis, ClickHouse, в един момент трябваше да можем да правим резервни копия с възстановяване на момента за MySQL и така че да има възможност за качване ги в облака.

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

И в началото, без да споделят тази логика по никакъв начин, те написаха кода във форка. Видяха, че имаме някакъв работещ модел и може да лети. Тогава си помислихме, че нашата основна общност е postgresists, те използват WAL-G. И затова трябва по някакъв начин да разделим тези части. Тоест, когато редактираме код за Postgres, ние не нарушаваме MySQL; когато редактираме MySQL, ние не нарушаваме Postgres.

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

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

Различни компилации за Postgres, MySQL, MongoDB, Redis

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

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

След това дадохме проблеми. Те веднага бяха демонтирани. Студентите трябваше да поддържат три бази.

Това е MySQL, който архивираме с WAL-G по този начин повече от година.

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

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

Какво още донесоха учениците? Те предоставиха поддръжка за криптиране на Libsodium на WAL-G.

Имаме и политики за резервно съхранение. Сега резервните копия могат да бъдат маркирани като постоянни. И някак си е по-удобно за вашата услуга да автоматизирате процеса на съхранението им.

Какъв беше резултатът от този експеримент?

Повече от 100 души първоначално се регистрираха за курса. Първоначално не казах, че университетът в Екатеринбург е Уралският федерален университет. Там обявихме всичко. Регистрирани са 100 души. Реално много по-малко хора започнаха да правят нещо, около 30 човека.

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

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

Освен всичко друго, издадохме дипломи и курсови работи. А 12 получиха дипломи. 6 от тях вече са се защитили на „5”. Тези, които останаха, още нямаха защита, но мисля, че и при тях всичко ще бъде наред.

Планове за бъдещето

Какви планове имаме за бъдещето?

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

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

Можете да ги споделите тук

За какво беше този доклад? Освен това сега, освен 4-мата души, които подкрепят този проект, имаме допълнителни ръце, които са доста. Особено ако им пишеш на лично съобщение. И ако направите резервно копие на вашите данни и го направите с помощта на WAL-G или искате да преминете към WAL-G, тогава можем доста лесно да се съобразим с вашите желания.

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

Въпроси

Здравейте! Благодаря за доклада! Въпрос за WAL-G, но не и за Postgres. WAL-G архивира MySQL и извиква допълнително архивиране. Ако вземем модерни инсталации на CentOS и ако yum инсталирате MySQL, MariDB ще бъде инсталиран. От версия 10.3 не се поддържа допълнително архивиране, поддържа се архивиране на MariDB. Как се справяте с това?

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

Добър ден Благодаря за доклада! Въпрос относно потенциални нови функции. Готови ли сте да накарате WAL-G да работи с ленти, така че да можете да архивирате на ленти?

Архивиране на лента за съхранение очевидно означава?

Да.

Има Андрей Бородин, който може да отговори по-добре от мен на този въпрос.

(Андрей) Да, благодаря за въпроса! Имахме заявка за прехвърляне на резервно копие на лента от облачно хранилище. И за това рязане прехвърляне между облаци. Тъй като прехвърлянето от облак към облак е обобщена версия на прехвърлянето на лента. Освен това имаме разширяема архитектура по отношение на хранилищата. Между другото, много Storoges са написани от студенти. И ако напишете Storage за лента, то, разбира се, ще се поддържа. Готови сме да разгледаме заявки за изтегляне. Там трябва да напишете файл, да прочетете файл. Ако правите тези неща в Go, обикновено се оказвате с 50 реда код. И тогава лентата ще се поддържа в WAL-G.

Благодаря за доклада! Интересен процес на развитие. Архивирането е сериозна част от функционалността, която трябва да бъде добре покрита от тестове. Когато внедрихте функционалност за нови бази данни, студентите също ли написаха тестовете, или вие сами написахте тестовете и след това предоставихте внедряването на студентите?

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

Студентите нямат много опит. Прегледът отнема ли много време?

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

Благодаря за доклада! По-рано Андрей Бородин заяви, че archive_command в WAL-G трябва да се извиква директно. Но в случай на някакъв вид клъстерна касета, имаме нужда от допълнителна логика, за да определим възела, от който да изпратим валовете. Как вие сами решавате този проблем?

Какъв ти е проблема тук? Да кажем, че имате синхронна реплика, с която правите резервно копие? Или какво?

(Андрей) Факт е, че наистина WAL-G е предназначен да се използва без шел скриптове. Ако нещо липсва, тогава нека добавим логиката, която трябва да бъде вътре в WAL-G. Що се отнася до това откъде трябва да идва архивирането, ние вярваме, че архивирането трябва да е от текущия главен в клъстера. Архивирането от реплика е лоша идея. Има различни възможни сценарии с проблеми. По-специално, проблеми с архивирането на времеви линии и всякаква допълнителна информация. Благодаря за въпроса!

(Пояснение: Отървахме се от shell скриптовете в това издание)

Добър вечер! Благодаря за доклада! Интересувам се от функцията за догонване, за която говорихте. Бяхме изправени пред ситуация, в която реплика изоставаше и не можеше да настигне. И не намерих описание на тази функция в документите на WAL-G.

Catchup се появи буквално на 20 януари 2020 г. Документацията може да се нуждае от още работа. Ние го пишем сами и не го пишем супер добре. И може би трябва да започнем да изискваме от учениците да го пишат.

Пуснато ли е вече?

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

Кога да очакваме?

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

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