Пропоную ознайомитися з розшифровкою доповіді початку 2020 року Георгія Рилова "WAL-G: нові можливості та розширення спільноти"
У меінтейнерів open-source виникає безліч проблем у міру їхнього зростання. Як писати все більше необхідних фіч, лагодити все більше issues'ів і встигати дивитися все більше pull request'ів? На прикладі WAL-G (backup-tool for PostgreSQL) розповім про те, як ми вирішували ці проблеми, запустивши курс з Open-source розробки в університеті, чого ми досягли і куди рухатимемося далі.
Всім ще раз привіт! Я розробник в Яндексі з Єкатеринбургу. І сьогодні я розповім про WAL-G.
У назві доповіді не сказано, що це щось про бекапи. Хтось не знає, що таке WAL-G? Чи всі знають? Підніміть руку, хто не знає. Офігети, ви прийшли на доповідь і не знаєте, про що вона.
Давайте розповім, що сьогодні буде. Так вийшло, що наша команда давно займається бекапом. І це ще одна доповідь у серії, де ми розповідаємо про те, як ми зберігаємо дані безпечно, надійно, зручно та ефективно.
У попередніх серіях було багато доповідей Андрія Бородіна, Володимира Лєскова. Нас було багато. І ми всі розповідали про WAL-G уже багато років.
clck.ru/F8ioz
clck.ru/Ln8Qw -
Ця доповідь трохи відрізнятиметься від інших тим, що там було переважно про технічну частину, а тут я розповім про те, як ми зіткнулися з проблемами, пов'язаними зі зростанням спільноти. І як вигадали невелику ідею, яка нам допомагає з цим справлятися.
Декілька років тому WAL-G був досить невеликим проектом, який нам дістався від Citus Data. І ми лише його взяли. І його розробляла одна людина.
І лише у WAL-G не було:
- Бекап з репліки.
- Не було інкрементальних бекапів.
- Не було WAL-Delta бекапів.
- І ще купи не було.
За ці кілька років WAL-G дуже виріс.
І до 2020 року все вищезгадане вже з'явилося. І до цього ще додалося те, що в нас тепер:
- Більше 1 зірочок на GitHub.
- 150 форків.
- Близько 15 відкритих PR.
- І ще багато контріб'юторів.
- І відкриті цепостійно. І це при тому, що ми туди буквально щодня заходимо, щось із цим робимо.
І ми дійшли висновку, що цей проект потребує більше нашої уваги, навіть тоді, коли нам самим не потрібно щось реалізувати для нашого сервісу Managed Databases в Яндексі.
І десь восени 2018 року нам на думку спала ідея. Зазвичай команда має кілька способів, як пиляти якісь фічі, лагодити баги, якщо у вас не вистачає рук. Наприклад, можна найняти ще одного розробника та платити йому гроші. Або можна взяти стажистка на якийсь час і теж платити йому якусь зарплатню. Але є ще досить великий пласт людей, частина з яких реально вміє писати код. Просто ви не завжди знаєте, якої якості цей код.
Ми подумали та вирішили спробувати залучити студентів. Але студенти братимуть участь у нас не в усьому. Вони робитимуть лише якусь частину роботи. І будуть вони, наприклад, писати тести, лагодити баги, реалізовувати фічі, які не торкаються основної функціональності. Основна функціональність – це створення бекапів та відновлення бекапів. Якщо допустити баг у створенні бекапу, ми отримаємо втрату даних. І ніхто цього, звісно, не хоче. Усі хочуть, щоби все було дуже надійно. Тому код, якому ми довіряємо менше, ніж своєму власному, ми звичайно туди пускати не хочемо. Т. е. будь-який некритичний код - це те, що ми хотіли б отримати від наших додаткових робочих рук.
За яких умов приймається PR студента
- Вони мають покривати свій код тестами. Все має відбуватися у CI.
- І також проходимо 2 ревью. Одне Андрія Бородіна та одне моє.
- І додатково щоб перевірити, що це не зламає нічого в нашому сервісі, я окремо заливаю збірку з цим коммітом. І ми перевіряємо в end-to-end тестах, що у нас нічого не валиться.
Спецкурс з Open Source
Трохи про те, навіщо це потрібно і чому це, мені здається, кльовою ідеєю.
Для нас прибуток очевидний:
- Ми отримуємо додаткові руки.
- І шукаємо кандидатів у команду серед тямущих студентів, які пишуть тямущий код.
Який прибуток для студентів?
Вони можуть бути менш очевидними, тому що студенти, як мінімум, не отримують гроші за той код, який пишуть, а отримують лише оцінки в заліковку.
Я спитав їх про це. І з їхніх слів:
- Досвід контриб'ютора у Open Source.
- Отримати рядок у CV.
- Проявити себе та пройти співбесіду в Яндекс.
- Стати учасником GSoC.
- +1 спецкурс для тих, хто хоче писати код.
Я не розповідатиму про те, як курс був влаштований. Я тільки скажу, що WAL-G був головним проектом. А ще ми в цей курс включили такі проекти як Odyssey, PostgreSQL та ClickHouse.
І давали завдання не тільки на цьому курсі, а ще видавали дипломи та курсові роботи.
А прибуток для користувачів?
Тепер перейдемо до частини, яка цікавить швидше вас. Який вам з цього толк? Толк у тому, що студенти полагодили багато багів. І зробили фічі request, які ви попросили нас зробити.
І давайте я розповім про речі, які ви давно хотіли та які були реалізовані.
Підтримка tablespaces. Tablespaces в WAL-G очікувалися, напевно, з моменту релізу WAL-G, оскільки WAL-G є приймачем іншого інструменту резервного копіювання WAL-E, де було підтримано бекапи баз даних із tablespaces.
Коротко нагадаю, що це таке і навіщо все це потрібно. Як правило, у вас всі дані Postgres займають одну директорію на файловій системі, яка називається базовою. І ця директорія вже містить усі файли та піддиректорії, необхідні Postgres.
Tablespaces є директоріями, в яких лежать дані Postgres, але вони не лежать поза базовою директорією. На слайді видно, що tablespac'и знаходяться поза базовою директорією.
Як це виглядає для самого Postgres? У базовій директорії є окрема піддиректорія pg_tblspc. І в ній лежать симлінки на директорії, в яких реально лежать дані Postgres поза базовою директорією.
Коли ви цим користуєтеся, то для вас ці команди можуть виглядати якось так. Т. е. Ви створюєте табличку в якомусь зазначеному tablespace і дивіться, де вона у вас зараз лежить. Ось ці два останні рядки, два останні викликані команди. І там видно, що є якийсь шлях. Але насправді це не справжній шлях. Це шлях з префіксом з базової директорії до tablespace. І звідти він змочений симлінком, який веде до ваших реальних даних.
У нас це все не використовується в нашій команді, проте використовувалося у багатьох інших користувачів WAL-E, які писали нам, що вони хочуть переїхати на WAL-G, але це їм заважало. Тепер це підтримується.
Інша фіча, яку нам приніс наш спецкурс, це catchup. Про catchup знають люди, які напевно більше працювали з Oracle, ніж з Postgres.
Коротко про те, що це таке. Якось так може виглядати топологія кластера в нашому сервісі. Ми маємо майстер. Є репліка, яка стримає з нього write-ahead log. І репліка говорить майстру, на якому LSN вона зараз знаходиться. І десь паралельно із цим може архівуватися журнал. І окрім архівації журналу ще в хмару оговтуються бекапи. І вирушають дельта-бекапи.
Якою може бути проблема? Коли у вас досить велика база, у вас може бути так, що у вас репліка починає сильно відставати від майстра. І вона відстає так сильно, що наздогнати її вже ніколи не може. Цю проблему зазвичай треба якось вирішувати.
І найпростіший спосіб – це прибрати репліку та переналити її заново, бо вона вже ніколи не наздожене, а з проблемою треба розібратися. Але це досить довго, тому що відновлювати цілий бекап бази в 10 TB – це дуже-дуже довго. І нам хочеться робити це все якнайшвидше, якщо такі проблеми виникають. І саме для цього призначений catchup.
Catchup дозволяє використовувати дельта-бекапи, які зберігаються у хмарі таким чином. Ви говорите на якому LSN зараз відстає репліка і вказуєте його в команді catchup для того, щоб створити дельта-бекап тим часом LSN і LSN, на якому зараз знаходиться ваш кластер. І після цього відновлюєте цей бекап на відстаючу репліку.
Інші бази
Ще нам студенти принесли відразу багато фіч. Оскільки ми в Yandex варимо не тільки Postgres, ми ще маємо MySQL, MongoDB, Redis, ClickHouse, то в якийсь момент нам знадобилося, щоб ми могли робити бекапи з point-in-time recovery для MySQL, і щоб була можливість завантажити їх у хмару.
І ми хотіли це робити якимось схожим чином, яким робить WAL-G. І вирішили поекспериментувати та подивитися, як це все виглядатиме.
І спочатку не поділяючи цю логіку у форці написали код. Побачили, що ми маємо якусь робочу модель і це може полетіти. Потім подумали, що наша основна спільнота – це postgres'істи, вони використовують WAL-G. І тому треба якось ці частини поділити. Т. е. коли правиться код для Postgres ми не ламаємо MySQL, коли правимо MySQL, ми не ламаємо Postgres.
Першою ідеєю про те, як це розділяти, була ідея використати той самий підхід, що використовується в extensions PostgreSQL. І, по суті, щоб зробити бекап MySQL, ви повинні були поставити якусь динамічну бібліотеку.
Але тут одразу видно несиметричність цього підходу. Коли ви бекапіте Postgres, то ви ставите на нього нормальну бекапелку для Postgres і все чудово. А для MySQL виходить, що ви ставите бэкапелку для Postgres і ще ставите для неї динамічну бібліотеку для MySQL. Звучить якось дивно. Ми теж так подумали і вирішили, що це не те рішення, що нам потрібне.
Різні збірки для Postgres, MySQL, MongoDB, Redis
Але це дозволило нам, як нам здається, дійти правильного рішення – виділити різні збірки для різних баз. Це дозволяло ізолювати логіку, зав'язану на бекапа різних баз даних, які будуть звертатися до загального API, які реалізує WAL-G.
Це частина, яку ми написали самі – перед тим, як дати студентам завдання. Т. е. це якраз та частина, де вони могли зробити щось не так, тому ми вирішили, що краще ми зробимо щось так і все буде чудово.
Після цього ми видали завдання. Їх одразу розібрали. Від студентів потрібно підтримати три бази.
Це MySQL, яку ми бекапімо за допомогою WAL-G у такий спосіб вже більше року.
І зараз уже MongoDB наближається до production, там його напилком допилюють. По суті, каркас для цього написали ми. Потім студенти написали якісь працюючі речі. І потім ми доводимо їх до такого стану, який можемо прийняти у себе в production.
Ці завдання не виглядали так, що студентам потрібно було написати цілісні backup tools для кожної з цих баз. У нас такої проблеми не було. Наша проблема була в тому, що ми хотіли point-in-time recovery і ми хотіли бекапити у хмару. І попросили студентів написати якийсь код, який це вирішуватиме. Студенти скористалися існуючими backup tools, які якось знімають бекапи, а потім уже склеювали все це з WAL-G, що переправляло це все в хмару. Також до цього додавали point-in-time recovery.
Що ще приносили студенти? Вони принесли у WAL-G підтримку шифрування Libsodium.
Також у нас з'явилися політики зберігання бекапів. Тепер бекапи можна помічати перманентними. І якось зручніше для вашого сервісу автоматизувати процес їх зберігання.
Що за підсумками цього експерименту вийшло?
На курс спочатку зареєструвалося понад 100 осіб. Я спочатку не сказав, що університет в Єкатеринбурзі це Уральський федеральний університет. Там ми всі анонсували. 100 людей зареєструвалося. Реально щось почало робити набагато менше, приблизно 30 людей.
Закрило курс ще менше людей, бо там треба було написати тести до тих кодів, які вже є. А також полагодити якийсь баг або зробити якусь фічу. І частина студентів все ж таки закрили курс.
На даний момент за цей курс студенти полагодили близько 14 іссу, зробили 10 фіч різного розміру. І, як на мене, це повноцінна заміна одного-двох розробників.
Окрім іншого ми видавали дипломи та курсові роботи. І 12 взяли дипломи. 6 із них уже захистилися на «5». У тих, хто залишився, ще захисту не було, але я думаю, що у них теж все буде добре.
Плани на майбутнє
Які ми маємо плани на майбутнє?
Принаймні фічі-requests, які ми вже від користувачів чули і хочемо їх зробити. Це:
- Відстеження коректності відстеження таймлайну в архіві бекапів HA-кластера. За допомогою WAL-G це можна робити. І, я гадаю, у нас знайдуться студенти, які за цю справу візьмуться.
- За перенесення бекапів і WAL'у між хмарами ми вже маємо відповідальну людину.
- І ми нещодавно публікували ідею, що ми можемо прискорити WAL-G ще більше за допомогою розпакування інкрементальних бекапів без перезапису сторінок та оптимізації архівів, які ми туди відправляємо.
Можете поділитися ними тут
До чого була ця доповідь? До того, що зараз, окрім нас 4 людей, які підтримують цей проект, у нас є додаткові руки, яких досить багато. Особливо якщо їм писати в особу. І якщо ви бекапіте свої дані і робите це за допомогою WAL-G або хотіли б на WAL-G переїхати, то ваші бажання ми можемо досить легко врахувати.
Це qr-код та посилання. Ви можете по них перейти і написати всі ваші хотілки. Наприклад, ми якийсь баг не робимо. Або якусь фічу ви дуже хочете, але чомусь її немає ще в жодній бэкапелці, у тому числі й у нашій. Обов'язково напишіть про це.
Питання
Вітаю! Дякую за доповідь! Питання WAL-G, але не про Postgres. WAL-G бекапіт MySQL і викликає екстра-бекап. Якщо брати сучасні установки на CentOS і якщо ви зробите yum install MySQL, то встановиться MariDB. З версії 10.3 екстра-бекап не підтримується, підтримується MariDB-бекап. Як у вас із цим справи?
На даний момент ми не намагалися бекапит MariDB. Ми мали запити на підтримку FoundationDB, але в цілому, якщо такий запит є, то ми можемо знайти людей, які це зроблять. Це не так довго і не так складно, як на мене.
Добридень! Дякую за доповідь! Питання потенційно нові фічі. Чи готові ви змусити працювати WAL-G зі стрічками, щоб можна було робити бекап на стрічки?
Бекап на стрічковому сховищі мабуть мається на увазі?
Так.
Там є Андрій Бородін, який на це запитання може краще за мене відповісти.
(Андрій) Так, дякую за питання! Ми мали запит на перенесення бекапу на стрічку з хмарного сховища. І для цього перенесення між хмарами. Тому що перенесення між хмарами є деякою узагальненою версією перенесення на стрічку. Крім того, у нас архітектура, що розширюється, в частині Storages. До речі, багато Storoges були студентами написані. І якщо ви напишете Storage для стрічки, він, звичайно, буде підтриманий. Ми готові розглянути pull request. Там треба записати файл, прочитати файл. Якщо ці штуки зробити на Go, то зазвичай виходить 50 рядків коду. І тоді WAL-G буде підтримана стрічка.
Дякую за доповідь! Цікавий процес розробки. Бекап – це серйозна частина функціональності, яка має бути добре покрита тестами. Ви коли для нових баз реалізовували функціональність, тести писали теж студенти або ви самі написали тести, а потім віддали реалізацію студентам?
Тести також писали студенти. Але студенти писали більше для таких фіч, як нові бази. Вони писали інтеграційні випробування. І вони писали unit-тести. Якщо інтеграційні проходять, тобто на даний момент це сценарій, який ви виконуєте руками або у вас це робить cron, наприклад. Т. е. там сценарій дуже зрозумілий.
У студентів не дуже багато досвіду. Чи багато часу на реву йде?
Так, на рев'ю йде досить багато часу. Т. е. зазвичай, коли приходять відразу кілька коммітерів і кажуть, що я зробив те, я зробив це, то треба подумати і виділити десь півдня на те, щоб розібратися з тим, що вони там написали. Тому що код треба читати ретельно. Вони ж не проходили співбесіди. Ми їх не дуже добре знаємо, тому це займає значний час.
Дякую за доповідь! Раніше Андрій Бородін заявляв, що archive_command у WAL-G має викликатися безпосередньо. Але у разі якогось патрон кластера нам потрібна додаткова логіка для визначення ноди, з якої слати вали. Як ви у себе вирішуєте цю проблему?
У чому тут виникає проблема? припустімо, у вас є синхронна репліка, з якою ви знімаєте бекап? Або що?
(Андрій) Справа в тому, що дійсно WAL-G передбачає використання без обв'язування shell-скриптами. Якщо чогось не вистачає, то давайте допишемо логіку, яка має бути всередині WAL-G. Стосується того, звідки має бути архівація, ми вважаємо, що архівація має бути з поточного майстра в кластері. Архівація з репліки – це погана ідея. Там можливі різні сценарії із проблемами. Зокрема, проблеми з архівацією таймлайнів та будь-якої додаткової інформації. Дякую за питання!
(Уточнення: Від обв'язування shell-скриптами позбулися )
Добрий вечір! Дякую за доповідь! Зацікавила фіча catchup, про яку ви розповіли. Зіткнулися із ситуацією відставання репліки, яка ніяк не могла наздогнати. І я у WAL-G не знайшов опису у документах цієї фічі.
Catchup з'явився буквально в 20-х числах січня 2020 року. З документацією, можливо, варто попрацювати краще. Ми самі її пишемо і пишемо не те, щоб супер-відмінно. І від студентів можливо варто почати вимагати, щоб вони її писали.
Вона вже у релізі?
Pull request вже помержений, тобто я його перевірив. Я пробував це на тестовому кластері. Поки ми не мали ситуації, коли ми могли б перевірити це на бойовому прикладі.
Коли чекати?
Я не знаю. Місяць зачекайте, точно перевіримо.
Джерело: habr.com