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 отворени ПР.
• И уште многу соработници.
• И постојано отворени прашања. И ова и покрај фактот што ние буквално одиме таму секој ден и правиме нешто околу тоа.

И дојдовме до заклучок дека овој проект бара повеќе од нашето внимание, дури и кога ние самите не треба да имплементираме ништо за нашата услуга Управувани бази на податоци во Yandex.

И некаде во есента 2018 година ни дојде идеја. Обично тимот има неколку начини да развие некои функции или да поправа грешки ако немате доволно раце. На пример, можете да ангажирате друг програмер и да му платите пари. Или можете да земете практикант некое време, а исто така да му платите некоја плата. Но, сè уште има доста голема група на луѓе, од кои некои веќе навистина знаат да пишуваат код. Едноставно не секогаш знаете каков квалитет е кодот.

Размисливме и решивме да се обидеме да привлечеме студенти. Но, студентите нема да учествуваат во се кај нас. Тие ќе завршат само дел од работата. И тие, на пример, ќе пишуваат тестови, ќе поправаат грешки, ќе имплементираат функции што не влијаат на главната функционалност. Главната функционалност е создавање резервни копии и враќање на резервните копии. Ако направиме грешка при креирањето на резервна копија, ќе доживееме загуба на податоци. И никој не го сака ова, се разбира. Секој сака сè да биде многу сигурно. Затоа, се разбира, не сакаме да дозволиме код на кој помалку му веруваме од нашиот. Односно, секој некритичен код е она што би сакале да го добиеме од нашите дополнителни работници.

Под кои услови се прифаќа студентски ПР?

• Од нив се бара да го покријат својот код со тестови. Сè треба да се одвива во CI.
• И ние исто така поминуваме низ 2 прегледи. Еден од Андреј Бородин и еден од мене.
• И дополнително, за да проверам дека ова нема да скрши ништо во нашиот сервис, одделно го прикачувам склопот со овој commit. И ние проверуваме во тестовите од крај до крај дека ништо не успева.

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

Малку за тоа зошто е потребно ова и зошто ова, ми се чини, е одлична идеја.

За нас, добивката е очигледна:

• Добиваме дополнителни раце.
• И бараме кандидати за тимот меѓу паметните студенти кои пишуваат паметен код.

Која е користа за студентите?

Тие можеби се помалку очигледни, бидејќи студентите, во најмала рака, не добиваат пари за шифрата што ја пишуваат, туку добиваат само оценки за нивната студентска евиденција.

Ги прашав за ова. И според нивните зборови:

• Искуство на соработници во отворен код.
• Добијте линија во вашето CV.
• Докажете се и поминете интервју во Yandex.
• Станете член на GSoC.
• +1 специјален курс за оние кои сакаат да пишуваат код.

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

И тие дадоа проблеми не само на овој курс, туку и дадоа дипломи и предмети.

Што е со користа за корисниците?

Сега да преминеме на делот што најмногу ве интересира. Што ти носи ова? Поентата е во тоа што студентите поправија многу грешки. И ги направивме карактеристиките на барањето што ни побаравте да ги направиме.

И да ви кажам за работите кои одамна ги посакувавте и кои се реализирани.

Поддршка за простори за маса. Табеларните простори во WAL-G се очекувани веројатно од објавувањето на WAL-G, бидејќи WAL-G е наследник на друга алатка за резервна копија WAL-E, каде што беа поддржани резервните копии на базата на податоци со табели.

Дозволете ми накратко да ве потсетам што е тоа и зошто е сето тоа потребно. Вообичаено, сите ваши податоци на Postgres зафаќаат еден директориум на датотечниот систем, наречен база. И овој директориум веќе ги содржи сите датотеки и поддиректориуми што ги бара Postgres.

Табеларните простори се директориуми кои содржат податоци од Postgres, но тие не се наоѓаат надвор од основниот директориум. Слајдот покажува дека табелите се наоѓаат надвор од основниот директориум.

Како изгледа ова за самиот Postgres? Во основниот директориум има посебен поддиректориум pg_tblspc. И содржи симболи до директориуми кои всушност содржат податоци на Postgres надвор од основниот директориум.

Кога го користите сето ова, тогаш за вас овие команди може да изгледаат вака. Односно, креирате табела во одреден простор за маса и гледате каде е сега. Ова се последните две линии, повикани последните две команди. И таму е јасно дека има некој начин. Но, во реалноста, ова не е вистинскиот начин. Ова е префиксната патека од основниот директориум до просторот на масата. И оттаму се совпаѓа со симболична врска што води до вашите вистински податоци.

Ние не го користиме сето ова во нашиот тим, но го користеа многу други корисници на WAL-E кои ни напишаа дека сакаат да се преселат во WAL-G, но тоа ги спречи. Ова сега е поддржано.

Друга карактеристика што ни ја донесе нашиот посебен курс е catchup. Луѓето кои веројатно работеле повеќе со Oracle отколку со Postgres знаат за catchup.

Накратко за што е тоа. Топологијата на кластерот во нашата услуга обично може да изгледа вака. Имаме мајстор. Постои реплика што го пренесува дневникот за пишување однапред од него. И репликата му кажува на мајсторот на кој LSN е моментално. И некаде паралелно со ова, дневникот може да се архивира. И покрај архивирањето на дневникот, резервните копии се испраќаат и до облакот. И делта резервните копии се испраќаат.

Што може да биде проблемот? Кога имате прилично голема база на податоци, може да испадне дека вашата реплика почнува да заостанува далеку зад мастерот. И таа толку заостанува што никогаш не може да го стигне. Овој проблем обично треба некако да се реши.

А најлесниот начин е да ја отстраните репликата и повторно да ја поставите, бидејќи никогаш нема да стигне, а проблемот треба да се реши. Но, ова е доста долго, бидејќи враќањето на цела резервна копија од базата на податоци од 10 TB е многу, многу долго време. И ние сакаме сето тоа да го направиме што е можно побрзо доколку се појават такви проблеми. И токму за тоа служи catchup.

Catchup ви овозможува да користите делта резервни копии, кои се складираат во облакот на овој начин. Кажувате на кој LSN е моментално на заостанатата реплика и го одредувате во командата catchup за да создадете делта резервна копија помеѓу тој LSN и LSN на кој моментално се наоѓа вашиот кластер. И после тоа ја враќаш оваа резервна копија на репликата што заостануваше.

Други основи

И студентите ни донесоа многу карактеристики одеднаш. Бидејќи во Yandex не готвиме само Postgres, имаме и MySQL, MongoDB, Redis, ClickHouse, во одреден момент ни требаше да можеме да правиме резервни копии со момент-во-време за наплата за MySQL, и така да има можност да се прикачи ги до облакот.

И сакавме да го направиме тоа на некој сличен начин како што прави WAL-G. И решивме да експериментираме и да видиме како ќе изгледа сето тоа.

И прво, без да ја споделат оваа логика на кој било начин, го напишаа кодот во вилушка. Видоа дека имаме некаков работен модел и може да лета. Тогаш мислевме дека нашата главна заедница се постгресисти, тие користат 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 и ако инсталирате MySQL, MariDB ќе се инсталира. Од верзијата 10.3 не е поддржана дополнителна резервна копија, поддржана е резервна копија на MariDB. Како ви оди со ова?

Во моментов не сме се обиделе да направиме резервна копија на MariDB. Имавме барања за поддршка на FoundationDB, но генерално, ако има такво барање, тогаш можеме да најдеме луѓе кои ќе го направат тоа. Не е толку долго или тешко како што мислам.

Добар ден Ви благодариме за извештајот! Прашање за потенцијални нови функции. Дали сте подготвени да направите WAL-G да работи со касети за да можете да направите резервна копија на касетите?

Бекап на складирање касети очигледно значи?

Да.

Има Андреј Бородин, кој може да одговори на ова прашање подобро од мене.

(Андреј) Да, благодарам за прашањето! Имавме барање да префрлиме резервна копија на лента од складирањето облак. И за ова пилање пренос помеѓу облаците. Бидејќи преносот од облак во облак е генерализирана верзија на пренос на лента. Дополнително, имаме проширување на архитектурата во однос на складиштата. Патем, многу Сториге беа напишани од студенти. И ако напишете Складирање за лента, тогаш тоа, се разбира, ќе биде поддржано. Подготвени сме да ги разгледаме барањата за повлекување. Таму треба да напишете датотека, да прочитате датотека. Ако ги правите овие работи во Go, обично завршувате со 50 линии код. И тогаш лентата ќе биде поддржана во WAL-G.

Ви благодариме за извештајот! Интересен процес на развој. Резервната копија е сериозен дел од функционалноста што треба добро да биде покриена со тестови. Кога имплементиравте функционалност за нови бази на податоци, дали и учениците ги пишуваа тестовите или вие самите ги пишувавте тестовите, а потоа им ја дадовте имплементацијата на учениците?

Учениците пишуваа и тестови. Но, студентите пишуваа повеќе за функции како што се новите бази на податоци. Тие напишаа тестови за интеграција. И напишаа единечни тестови. Ако интеграцијата помине, односно во моментот, ова е скрипта што ја извршувате рачно или имате крон да го прави тоа, на пример. Односно, сценариото таму е многу јасно.

Студентите немаат големо искуство. Дали прегледувањето трае многу време?

Да, прегледите одземаат доста време. Тоа е, обично, кога ќе дојдат неколку извршители одеднаш и ќе кажат дека го направив ова, го направив тоа, тогаш треба да размислите и да одвоите околу половина ден за да сфатите што напишале таму. Затоа што кодот мора внимателно да се прочита. Немаа интервју. Не ги знаеме многу добро, па затоа е потребно значително време.

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

Што ти е тука проблемот? Да речеме дека имате синхрона реплика со која правите резервна копија? Или што?

(Андреј) Факт е дека навистина WAL-G е наменет да се користи без скрипти за школка. Ако нешто недостасува, тогаш да ја додадеме логиката што треба да биде внатре во WAL-G. Што се однесува до тоа од каде треба да потекнува архивирањето, сметаме дека архивирањето треба да биде од сегашниот господар во кластерот. Архивирањето од реплика е лоша идеја. Постојат различни можни сценарија со проблеми. Особено, проблеми со архивирање на временските рокови и какви било дополнителни информации. Фала за прашањето!

(Појаснување: Се ослободивме од скриптите на школка во ова издание)

Добро попладне! Ви благодариме за извештајот! Ме интересира функцијата catchup за која зборуваше. Се соочивме со ситуација кога репликата беше зад и не можеше да стигне. И не најдов опис на оваа функција во документите на WAL-G.

Catchup се појави буквално на 20 јануари 2020 година. Документацијата можеби ќе треба уште малку работа. Сами го пишуваме и не го пишуваме одлично. И можеби треба да почнеме да бараме од студентите да го напишат.

Дали е веќе објавен?

Барањето за повлекување е веќе мртво, т.е го проверив. Го пробав ова на тест кластер. Досега не сме имале ситуација да го тестираме ова во борбен пример.

Кога да се очекува?

не знам. Чекај еден месец, ќе провериме сигурно.

Извор: www.habr.com