Прапаную азнаёміцца з расшыфроўкай даклада пачатку 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 000 зорачак на GitHub.
- 150 форкаў.
- Каля 15 адкрытых PR.
- І яшчэ шмат кантрыб'ютараў.
- І адкрытых issues увесь час. І гэта пры тым, што мы туды літаральна кожны дзень заходзім, нешта з гэтым які робіцца.
І мы дашлі да высновы, што гэты праект патрабуе больш нашай увагі, нават тады, калі нам самім не патрабуецца нешта рэалізаваць для нашага сэрвісу 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 issues, зрабілі 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/XNUMX экстра-бэкап не падтрымліваецца, падтрымліваецца 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