Прапаную азнаёміцца з расшыфроўкай даклада пачатку 2019 года Андрэя Барадзіна "Рэзервовыя копіі з WAL-G. Што там у 2019?"
Ўсім прывітанне! Мяне клічуць Андрэй Барадзін. Я распрацоўшчык у Яндэксе. Я цікаўлюся PostgreSQL з 2016-га года, пасля таго, як я пагаварыў з распрацоўшчыкамі, і яны сказалі, што тут усё проста - ты бярэш зыходны код і збіраеш, і ўсё атрымаецца. І з тых часоў не магу спыніцца - пішу ўсякія розныя штукі.
Адна з штук, якой я займаюся, гэта сістэма рэзервовага капіявання . Наогул, у Яндэксе мы займаемся сістэмамі рэзервовага капіявання ў PostgreSQL вельмі даўно. І можна знайсці ў інтэрнэце серыю з шасці дакладаў аб тым, як мы робім сістэмы рэзервовага капіявання. І з кожным годам яны крыху эвалюцыянуюць, крыху развіваюцца, становяцца больш надзейнымі.
Але сёння даклад прысвечаны не толькі таму, што мы зрабілі, але і аб тым, як усё проста і аб тым, што ёсць. Хто з вас ужо глядзеў мае даклады пра WAL-G? Гэта добра, што даволі шмат людзей не глядзелі, таму што я пачну з самай простай рэчы.
Калі раптам у вас ёсць кластар PostgreSQL, а я думаю ў кожнага ён ёсць па парачцы з сабой, і раптам яшчэ няма сістэмы рэзервовага капіявання, тое трэба атрымаць любое S3 сховішча ці Google Cloud сумяшчальнае сховішча.
Напрыклад, вы можаце падысці да нас на стэнд і ўзяць промакод на Yandex Object Storage, які S3 сумяшчальны.
Пасля чаго стварыць Bucket. Гэта проста кантэйнер для інфармацыі.
Стварыць сэрвіснага карыстальніка.
Стварыць сэрвіснаму карыстачу ключ доступу aws-s3-key.
Спампаваць апошні стабільны рэліз WAL-G.
Чым адрозніваюцца нашы прадрэлізы ад рэлізаў? Мяне часта просяць зрабіць рэліз крыху раней. І калі ў версіі не знаходзіцца бага дастатковы час, напрыклад, месяц, то я выпускаю рэліз. Вось гэты рэліз ад лістапада. І гэта азначае, што кожны месяц мы знаходзілі нейкі баг, звычайна ў не крытычнай функцыянальнасці, але да гэтага часу рэліз мы не выпусцілі. Папярэдняя версія толькі лістападаўская. У ёй няма вядомых нам багаў, т. е. багі дадаваліся па ходзе развіцця праекту.
Пасля таго, як вы спампавалі WAL-G, вы можаце выканаць няхітрую каманду "backup list", перадаўшы зменныя асяроддзі. І яна злучыцца з Object Storage, і паведаміць, якія бэкапы ў вас ёсць. Спачатку ў вас, вядома, бэкапаў не павінна быць. Сэнс гэтага слайду паказаць, што ўсё даволі проста. Гэта кансольная каманда, якая прымае зменныя асяроддзі і выконвае падкаманды.
Пасля гэтага вы можаце зрабіць свой першы бэкап. Сказаць у WAL-G "backup-push" і паказаць у WAL-G размяшчэнне pgdata вашага кластара. І, хутчэй за ўсё, PostgreSQL вам скажа, калі ў вас няма яшчэ сістэмы рэзервовага капіявання, што вам трэба ўключыць "archive-mode".
Гэта азначае, што трэба пайсці ў налады і ўключыць "archive_mode=on" і дадаць "archive_command", які сапраўды таксама з'яўляецца падкамандай у WAL-G. Але ў гэтую тэму людзі часта чамусьці выкарыстоўваюць бар-скрыпты і робяць абвязку вакол WAL-G. Калі ласка, не рабіце так. Выкарыстоўвайце функцыянальнасць, якая ёсць у WAL-G. Калі вам чагосьці не хапае, то пішыце ў . WAL-G мяркуе, што ён адзіная праграма, якая запускаецца ў archive_command.
Мы выкарыстоўваем WAL-G у асноўным для стварэння High Availability кластара ў Яндэкс Database management.
І ён выкарыстоўваецца звычайна ў тапалогіі з аднаго Майстра і некалькіх рэплікацый. Пры гэтым робіць рэзервовую копію ў Yandex Object Storage.
Самыя частыя сцэнары - гэта стварэнне копій кластара з выкарыстаннем Point in time recovery. Але ў гэтым выпадку для нас не такая важная прадукцыйнасць сістэмы рэзервовага капіявання. Нам проста трэба наліць новы кластар з бэкапу.
Звычайна прадукцыйнасць сістэмы рэзервовага капіявання нам патрэбна пры даданні новага вузла. Чаму гэта важна? Звычайна людзі дадаюць новы вузел у кластар, таму што існуючы кластар не спраўляецца з якая чытае нагрузкай. Ім трэба дадаць новую рэпліку. Калі дадамо нагрузку ад pg_basebackup на Майстар, то Майстар можа скласціся. Таму нам вельмі важна было, каб мы маглі хутка наліць новы вузел з архіва, ствараючы мінімальную нагрузку на Майстры.
І іншая падобная сітуацыя. Гэта неабходнасць пераналіўкі старога Майстра пасля пераключэння Майстра кластара з Дата-цэнтра, з якім была страчана складнасць.
- У выніку фармулюючы патрабаванні да сістэмы капіявання, мы зразумелі, што pg_basebackup нам не падыходзіць пры эксплуатацыі ў воблаку.
- Мы хацелі мець магчымасць сціскаць нашыя дадзеныя. Але сціск дадзеных падасць амаль любая сістэма рэзервовага капіявання, акрамя таго, што ёсць у скрынцы.
- Мы хацелі паралелізаваць усё, таму што карыстач у воблаку купляе вялікую колькасць працэсарных ядраў. Але калі ў нас няма паралелізмаў у нейкай аперацыі, то вялікая колькасць ядраў становіцца бескарыснай.
- Нам неабходна шыфраванне, таму што часта гэта не нашы дадзеныя і нельга іх захоўваць у адкрытым выглядзе. Дарэчы, менавіта з шыфравання пачаўся наш contribution у WAL-G. Мы дапісалі шыфраванне ў WAL-G, пасля чаго нас спыталі: "Можа быць, хтосьці з нас зоймецца развіццём праекта?". І з таго часу год з лішнім я працую з WAL-G.
- Таксама нам неабходны быў тратлінг рэсурсаў, таму што з часам эксплуатацыі аблокі мы высветлілі, што часам у людзей бывае важная прадуктовая нагрузка ноччу і гэтай нагрузцы нельга перашкаджаць. Таму мы дапісалі тротлінг рэсурсаў.
- А таксама лістынг і кіраванне.
- І верыфікацыя.
Мы разгледзелі шмат розных інструментаў. На шчасце, у нас велізарны выбар у PostgreSQL. І ўсюды нам чагосьці не хапала, нейкай адной невялікай функцыі, нейкай адной невялікай асаблівасці.
І разгледзеўшы наяўныя сістэмы мы прыйшлі да таго, што будзем развіваць WAL-G. Ён тады быў новым праектам. Даволі лёгка было паўплываць на развіццё ў бок менавіта хмарнай інфраструктуры сістэмы рэзервовага капіявання.
Асноўная ідэалогія, якой мы прытрымліваемся - гэта тое, што WAL-G павінен быць простым як балалайка.
У WAL-G 4 каманды. Гэта:
WAL-PUSH - заархіваваць вал.
WAL-FETCH - атрымаць вал.
BACKUP-PUSH - зрабіць бэкап.
BACKUP-FETCH - атрымаць бэкап з сістэмы рэзервовага капіявання.
Насамрэч, у WAL-G ёсць і менеджмент гэтых бэкапаў, т. е. listing і выдаленне валаў і бэкапаў у гісторыі, якія на дадзены момант ужо не патрэбныя.
Адна з важных для нас функцыя - гэта функцыя стварэння дэльта-копій.
Дэльта-копіі азначаюць, што ў нас ствараецца не поўны бэкап усяго кластара, а ўносяцца толькі змененыя старонкі змененых файлаў у кластары. Здавалася б, што функцыянальна гэта вельмі падобна на магчымасць аднавіцца выкарыстоўваючы WAL. Але WAL-аднаструменны, дэльта-бэкап мы можам накаціць паралельна. Адпаведна, калі ў нас ёсць базавы бэкап, зроблены ў суботу, дэльта-бекапы штодзённыя і ў чацвер у нас адбываецца fail, то нам неабходна накаціць 4 дэльта-бекапы і 10 гадзін WAL. Гэта зойме прыкладна адзін і той жа час, таму што дэльта-бекапы коцяцца паралельна.
LSN-based дэльты - гэта азначае, што пры стварэнні рэзервовай копіі, нам неабходна будзе спалучаць кожную старонку і зверыць яе LSN з LSN папярэдняга бэкапу для таго, каб зразумець, што яна змянілася. Любая старонка, якая патэнцыйна можа змяшчаць змененыя дадзеныя, павінна прысутнічаць у дэльта-бэкапе.
Як я казаў, даволі шмат увагі было нададзена паралелізму.
Але API архіва ў PostgreSQL паслядоўная. PostgreSQL архівуе адзін WAL-файл і пры аднаўленні ён запытвае адзін WAL-файл. Але калі база дадзеных запытала адзін WAL-файл пры дапамозе каманды "WAL-FETCH", мы выклікаем каманду "WAL-PREFETCH", якая падрыхтоўвае 8 наступных валаў для таго, каб паралельна пампаваць дадзеныя з аб'ектнага сховішча.
А калі база дадзеных просіць нас заархіваваць адзін вал, мы зазіраем у archive_status і глядзім ці няма іншых WAL-файлаў. І спрабуем запампоўваць WAL таксама раўналежна. Гэта дае істотны выйгрыш па прадукцыйнасці, істотна скарачае адлегласць у колькасці незаархіваваных WAL. Многія распрацоўшчыкі сістэм рэзервовага капіявання лічаць, што гэта такая рызыкоўная сістэма, таму што мы абапіраемся на нашы веды вантроб кода, які не з'яўляецца API PostgreSQL. PostgreSQL не гарантуе наяўнасць нам тэчкі archive_status і не гарантуе семантыку, наяўнасць там сігналаў гатоўнасці ў WAL-файлаў. Тым не менш мы вывучаем зыходны код, бачым, што гэта так і імкнемся гэта эксплуатаваць. І кантралюем у якім напрамку развіваецца PostgreSQL, калі раптам гэты механізм будзе парушаны, то мы спынім яго выкарыстоўваць.
У чыстым выглядзе LSN-based WAL-дэльта патрабуе счытваць любога файла кластара, у якога mode-time у файлавай сістэме змяніўся з папярэдняга бэкапу. Мы доўга з гэтым жылі, амаль год. І ў выніку дашлі да таго, што ў нас ёсць WAL-дэльты.
Гэта азначае, што кожны раз пры архіваванні WAL на Майстры, мы не толькі яго сціскаем, шыфруем і адпраўляем у сетку, але мы яго яшчэ і чытэльны пры гэтым. Аналізуем, чытэльны ў ім рэкорды. Разумеем, якія блокі змяніліся і збіраем delta-файлы.
Delta-файл апісвае некаторы дыяпазон WAL-файлаў, апісвае інфармацыю аб тым, якія блокі былі зменены ў гэтым дыяпазоне WAL. І затым гэтыя delta-файлы таксама архівуюцца.
Тут мы сутыкнуліся з тым, што мы дастаткова ўсё хутка распаралелілі, але нельга паралельна чытаць паслядоўную гісторыю, таму што ў пэўным сегменце, нам можа сустрэцца канец папярэдняга рэкорду WAL, які пакуль нам няма з чым сутыкаваць, таму што паралельнае чытанне прывяло да таго, што мы спачатку аналізуем будучыню, у якой няма яшчэ мінулага.
У выніку нам прыйшлося незразумелыя кавалкі складаць у _delta_partial файлы. У выніку, калі мы вернемся да мінулага, мы склеім кавалкі WAL рэкорду ў адзін, пасля гэтага яго распарссім і зразумеем, што ў ім мянялася.
Калі ў гісторыі нашага парсінгу вала ўтворыцца хаця б адна кропка, дзе мы не разумеем, што адбывалася, то, адпаведна, пры наступным бэкапе мы змушаныя будзем зноў прачытаць увесь кластар, гэтак жа, як мы гэта зрабілі пры звычайнай LSN-based дэльце.
У выніку ўсе нашы пакуты прывялі да таго, што мы заапенсарсілі бібліятэку для парсінгу WAL-G. Наколькі мне вядома, пакуль яе ніхто не выкарыстоўвае, але, калі хто-небудзь хоча - пішыце і выкарыстоўвайце, яна ў адкрытым доступе. (Абноўленая спасылка )
У выніку ўсе інфармацыйныя плыні выглядаюць даволі складана. У нас Майстар архівуе вал і архівуе delta-файлы. А рэпліка, якая робіць рэзервовую копію, яна мусіць атрымаць delta-файлы за той час, які прайшоў паміж бэкапамі. Часткі гісторыі пры гэтым трэба будзе даатрымаць валам і яго дапарсіць, таму што ў буйныя сегменты не ўся гісторыя ўкладваецца. І толькі пасля гэтага рэпліка можа заархіваваць паўнавартасны delta-бэкап.
На графіках усё выглядае значна прасцей. Гэта загрузка з аднаго з нашых рэальных кластараў. У нас ёсць LSN-based, зробленая ў адзін дзень. І мы бачым, што LSN-based delta-бэкап ішоў з трох гадзін ночы да пяці ночы. Гэта загрузка ў колькасці працэсарных ядраў. WAL-delta у нас тут заняла прыкладна хвілін 20. Т. е. яна зрабілася істотна хутчэй, але пры гэтым больш інтэнсіўны абмен па сетцы быў.
Паколькі ў нас ёсць інфармацыя аб тым, якія блокі мяняліся і ў які час у гісторыі базы, мы пайшлі далей і вырашылі інтэграваць функцыянальнасць - пашырэнне PostgreSQL, якое называецца "pg_prefaulter"
Гэта азначае, што, калі база на Stand-by выконвае restore command, яна гаворыць WAL-G прынесці наступны WAL-файл. Мы разумеем прыкладна, да якіх блокаў дадзеных хуткім часам працэс узнаўлення WAL будзе звяртацца і ініцыюем аперацыю чытання на гэтыя блокі. Зроблена гэта для таго, каб павысіць прадукцыйнасць SSD кантролераў. Бо накат WAL дойдзе да старонкі, якую трэба памяняць. Гэтая старонка знаходзіцца на дыску і адсутнічае ў page-кэшы. І ён сінхронна будзе чакаць, калі гэтая старонка прыедзе. Але побач варта WAL-G, які ведае аб тым, што ў найблізкае некалькі сотняў мегабайт WAL нам спатрэбяцца вызначаныя старонкі і раўналежна пачынае іх выграваць. Ініцыюе мноства зваротаў да дыска для таго, каб яны выконваліся паралельна. Гэта добра працуе на SSD-дысках, але, нажаль, гэта абсалютна не дастасавальна для цвёрдай кружэлкі, таму што мы яму толькі мяшаем сваімі падказкамі.
Гэта тое, што ёсць у кодзе зараз.
Ёсць фічы, якія мы хацелі б дапісаць.
На гэтым малюнку відаць, што WAL-delta займае адносна кароткі час. І гэта чытанне тых змен, якія адбыліся ў базе за суткі. Мы маглі б рабіць WAL-delta не толькі ўначы, таму што яна не з'яўляецца ўжо істотнай крыніцай нагрузкі. Мы можам счытваць WAL-delta кожную хвіліну, таму што гэта танна. За адну хвіліну мы можам прасканіраваць усе змены, якія адбыліся з кластарам. І гэта можна было б зваць "instant WAL-delta".
Сутнасць у тым, каб, калі мы аднаўляем кластар, паменшыць колькасць гісторый, якія нам давядзецца накаціць паслядоўна. Т. е. колькасць WAL, якое накатваецца PostgreSQL павінна быць скарочана, таму што гэта займае істотны час.
Але гэта ня ўсё. Калі мы ведаем, што нейкі блок будзе зменены да кропкі кансістэнтнасці бэкапу, мы можам яго не мяняць у мінулым. Т. е. цяпер у нас пафайлавая аптымізацыя накату WAL-delta. Гэта азначае, што калі, напрыклад, у аўторак нейкая табліца была цалкам выдаленая або нейкія файлы былі выдаленыя цалкам з табліцы, то пры накаце delta ў панядзелак і ўзнаўленні суботняга pg_basebackup, мы гэтыя дадзеныя нават ствараць не будзем.
Мы жадаем гэтую тэхналогію распаўсюдзіць на старонкавы ўзровень. Т. е. калі нейкая частка файла змяняецца ў панядзелак, але пры гэтым будзе перазапісана ў сераду, то пры аднаўленні на кропку ў чацвер, нам не трэба першыя некалькі версій старонак запісваць на дыск.
Але гэта пакуль ідэя, якая актыўна абмяркоўваецца ў нас унутры, але да кода пакуль яшчэ не дайшло.
Яшчэ адну фічу мы жадаем зрабіць у WAL-G. Мы жадаем зрабіць пашыральнасць, таму што нам трэба падтрымліваць розныя базы дадзеных і жадалася бы мець магчымасць аднолькава падыходзіць да кіравання бэкапамі. Але праблема ў тым, што API MySQL адрозніваюцца радыкальна. У MySQL PITR заснаваны не на фізічным WAL-логу, а на binlog. І ў нас няма сістэмы архівацыі ў MySQL, якая б сказала нейкай знешняй сістэме, што вось гэты binlog скончаны і трэба яго заархіваваць. Нам трэба дзесьці ў cron стаяць з базай і правяраць а ці няма чагосьці гатовага?
І сапраўды таксама падчас узнаўлення MySQL тамака няма restore command, які мог бы сказаць сістэме, што мне патрэбныя файлы вось такія і такія-то. Да таго, як ты пачаў аднаўленне кластара, табе трэба ведаць, якія файлы табе спатрэбяцца. Табе самому трэба здагадацца, якія файлы табе спатрэбяцца. Але гэтыя праблемы, магчыма, можна будзе як-небудзь абысці. (Удакладненне: MySQL ужо падтрымліваецца)
У дакладзе я яшчэ хацеў сказаць пра тыя выпадкі, калі WAL-G вам не падыходзіць.
Калі ў вас няма сінхроннай рэплікі, WAL-G не гарантуе вам захаванасць апошняга сегмента. І калі архівацыя адстае ад апошніх некалькіх сэгмэнтаў гісторыі, што зьяўляецца рызыкай. У выпадку адсутнасці сінхроннай рэплікі, я не рэкамендаваў бы карыстацца WAL-G. Усёткі галоўным чынам ён праектуецца для хмарнай усталёўкі, якая мае на ўвазе High Availability рашэнні з сінхроннай рэплікай, якая адказвае за захаванасць закаммічаных апошніх байт.
Я часта бачу людзей, якія спрабуюць адначасова эксплуатаваць і WAL-G і WAL-E. Мы падтрымліваем зваротную сумяшчальнасць у тым плане, што WAL-G можа аднавіць вал з WAL-E і можа аднавіць бэкап, зроблены ў WAL-E. Але паколькі абедзве гэтыя сістэмы выкарыстоўваюць раўналежны wal-push, яны пачынаюць красці сябар у сябра файлы. Калі ў WAL-G мы гэта паправім, то ў WAL-E гэта ўсё роўна застанецца. У WAL-E глядзіць archive-status, бачыць гатовыя файлы і архівуе іх, пры гэтым іншыя сістэмы, проста не пазнаюць аб тым, што гэты WAL-файл існаваў, таму што PostgreSQL не будзе спрабаваць заархіваваць яго ў другі раз.
Што мы тут паправім з боку WAL-G? Мы не будзем паведамляць PostgreSQL аб тым, што гэты файл быў занесены паралельна, а калі PostgreSQL нас папросіць яго заархіваваць, мы ўжо будзем ведаць, што такі файл з такім mode-time і з такім md5 ужо быў заархіваваны і проста скажам PostgreSQL - OK, усё гатова, па сутнасці, нічога не робячы.
Але на баку WAL-E ці наўрад гэтая праблема будзе чыніцца, таму зрабіць archive command, які заархівуе файл і ў WAL-G, і ў WAL-E цяпер немагчыма.
Акрамя таго, ёсць выпадкі, калі WAL-G вам не падыходзіць зараз, але мы абавязкова будзем гэта правіць.
Па-першае, у нас зараз няма ўбудаванай верыфікацыі бэкапу. У нас няма верыфікацыі ні падчас бэкапу, ні пры аднаўленні. Вядома, у воблаку гэта рэалізуецца. Але гэта рэалізуецца проста перадправеркай, проста аднаўленнем кластара. Хацелася б даць такую функцыянальнасць карыстальнікам. Але пад верыфікацыяй я мяркую, што ў WAL-G будзе магчымасць аднавіць кластар і запусціць яго, і прагнаць smoke-тэсты: pg_dumpall у /dev/null і amcheck верыфікацыю азначнікаў.
Цяпер у WAL-G няма магчымасці адкласці адзін бэкап з WAL. Т. е. мы падтрымліваем некаторае акно. Напрыклад, захоўванне апошніх сямі дзён, захоўванне апошніх дзесяці бэкапаў, захоўванне апошніх трох поўных бэкапаў. Даволі часта людзі прыходзяць і кажуць: "Нам патрэбен бэкап таго, што было ў Новы год і мы хочам захоўваць гэта вечна". WAL-G пакуль гэтага не ўмее. (Заўвага - Гэта ўжо пачынена. Больш падрабязна - Опцыя backup-mark ў )
І ў нас няма праверкі кантрольных сум старонак і праверкі цэласнасці ўсіх сегментаў вала пры валідацыі PITR.
З усяго гэтага я склаў праект для Google Summer of Code. Калі вы ведаеце талковых студэнтаў, якія хацелі б папісаць штосьці на Go і атрымаць некалькі тысяч даляраў ад адной кампаніі на літару «G», то парэкамендуйце ім наш праект. Я выступлю ментарам гэтага праекту, яны змогуць гэта зрабіць. Калі студэнтаў не знойдзецца, то я вазьму і зраблю гэта сам улетку.
І ў нас ёсць іншых шмат дробных праблем, над якімі мы паступова працуем. І сустракаюцца даволі дзіўныя рэчы.
Напрыклад, калі ў WAL-G даць пусты бэкап, то ён проста ўпадзе. Напрыклад, калі сказаць яму, што трэба забэкапіць пустую тэчку. Там не будзе ляжаць pg_control файла. І ён падумае, што нечага не разумее. Па ідэі ў дадзеным выпадку трэба напісаць звычайнае паведамленне карыстачу, каб растлумачыць яму, як карыстацца прыладай. Але гэта нават фіча не праграмавання, а фіча добрай даходлівай мовы.
Мы не ўмеем рабіць offline-бэкап. Калі база ляжыць, мы не можам яе забэкапіць. Але тут усё вельмі проста. Мы называем бэкапы па LSN, калі ён пачаўся. LSN у ляжалай базы трэба счытваць з control файла. І гэта такая нерэалізаваная фіча. Многія сістэмы рэзервовага капіявання ўмеюць рабіць бэкап ляжалай базы. І гэта зручна.
У нас зараз не апрацоўваецца нармальна недахоп месца для бэкапу. Таму што мы звычайна працуем з вялікімі бэкапамі ў сябе. І рукі да гэтага не дайшлі. Але калі хтосьці хоча праграмаваць на Go прама зараз, дадайце апрацоўку памылкі недахопу месца ў bucket. Я абавязкова пагляджу на pull request.
І самая галоўная рэч, якая нас турбуе, мы хочам, як мага больш докерных інтэграцыйных тэстаў, якія правяраюць розныя сцэнары. Цяпер у нас правяраюцца толькі базавыя сцэнары. На кожным каментары, але мы хочам пакаммітна правяраць усю функцыянальнасць, якую мы падтрымліваем. Напрыклад, нам нахапае падтрымкі PostgreSQL 9.4-9.5. Мы падтрымліваем іх, таму што суполка падтрымлівае PostgreSQL, але пакамітна не правяраем, што ўсё яшчэ не зламалася. І, мне падаецца, што гэта даволі сур'ёзная рызыка.
WAL-G у нас працуе на больш, чым тысяча кластараў у Яндэкс Database management. І штодня бэкапіць некалькі сотняў тэрабайт дадзеных.
У кодзе ў нас вельмі шмат TODO. Калі вам жадаецца праграмаваць, прыходзьце, чакаем pull request, чакаем пытанняў.
пытанні
Добры вечар! Дзякуй! Я так мяркую, што калі вы карыстаецеся WAL-delta, то, мусіць, вы моцна абапіраецеся на full-page writes. І калі так, то ці праводзілі вы тэсты? Вы паказвалі прыгожы графік. Наколькі ён не прыгажэй становіцца, калі FPW выключыць?
Full-page writes у нас уключаны, мы не спрабавалі яго выключаць. Т. е. я, як распрацоўшчык, не спрабаваў яго выключаць. Сістэмныя адміністратары, якія даследавалі, мусіць, даследавалі гэтае пытанне. Але нам FPW неабходзен. Яго практычна ніхто не адключае, бо інакш немагчыма ўзяць бэкап з рэплікі.
Дзякуй за даклад! У мяне два пытанні. Першае пытанне - што будзе з таблічнымі прасторамі?
Мы чакаем на pull request. Нашы базы жывуць на SSD і NMVE кружэлках і нам гэтая фіча не вельмі патрэбна. Я прама зараз не гатовы выдаткаваць сур'ёзны час на тое, каб яе зрабіць добра. Я ўсімі рукамі за тое, каб мы гэта падтрымалі. Ёсць людзі, якія гэта падтрымалі, але падтрымалі ў тым выглядзе, як гэта падыходзіць для іх. Зрабілі форк, але не робяць pull request. (Дададзена ў версіі 0.2.13)
І другое пытанне. Ты ў самым пачатку сказаў, што WAL-G мяркуе, што ён працуе адзін і абгорткі не патрэбны. Я сам выкарыстоўваю абгорткі. А чаму іх не трэба выкарыстоўваць?
Мы хочам, каб ён быў просты, як балалайка. Гэта азначае, што табе ўвогуле нічога, акрамя балалайкі не трэба. Мы жадаем, каб сістэма была простай. Калі ў цябе ёсць функцыянальнасць, якую табе неабходна зрабіць у скрыпце, то прыходзь і расказвай - зробім яе на Go.
Добры вечар! Дзякуй за даклад! У нас не атрымалася прымусіць працаваць WAL-G з GPG дэшыфраваннем. Шыфруе нармальна, дэшыфраваць не жадае. Гэта ў нас нешта не склалася? Сітуацыя засмучае.
Стварайце пытанне на GitHub, давайце разбірацца.
Т. е. не сутыкаліся з такім?
Там ёсць асаблівасць рэпарта памылак, што калі WAL-G не разумее, што гэта за файл, ён пытаецца: "Можа быць, ён зашыфраваны?". Магчыма, праблема зусім не ў шыфраванні. Я хачу паправіць лагіраванне на гэтую тэму. Расшыфраваць ён павінен. На гэтую тэму мы зараз працуем у тым плане, што не вельмі падабаецца, як арганізавана сістэма атрымання публічных і прыватных ключоў. Таму што мы выклікаем вонкавы GPG для таго, каб ён нам аддаў свае ключы. А потым мы гэтыя ключы бярэм і перадаем унутранаму GPG, які open PGP, які да нас кампіляваны ўнутр WAL-G, і там выкліканы шыфраванне. У гэтым плане мы жадаем сістэму палепшыць і жадаем падтрымаць шыфраванне Libsodium (Дададзена ў версіі 0.2.15). Вядома, расшыфраванне павінна працаваць, давайце разбірацца - больш сімптомам трэба, чым пару слоў. Можна неяк сабрацца ў пакоі дакладчыка і паглядзець на сістэму. (PGP encryption without external GPG - v0.2.9)
Прывітанне! Дзякуй за даклад! У мяне два пытанні. У мяне ёсць дзіўнае жаданне для таго, каб рабіць pg_basebackup і WAL log у два правайдэра, т. е. я хачу ў адно воблака і ў іншае. Ці ёсць нейкі спосаб зрабіць гэта?
Цяпер гэтага няма, але ідэя цікавая.
Проста я аднаму правайдэру не давяраю, мне жадаецца ў іншым на ўсякі выпадак мець таксама.
Ідэя цікавая. Тэхнічна гэта рэалізаваць зусім не складана. Каб ідэя не згубілася, ці можна папрасіць зрабіць issue на GitHub?
Так, вядома.
І тады, калі прыйдуць студэнты на Google Summer of Code, мы дадамо ім у праект, каб больш было працы, каб больш атрымаць ад іх.
І другое пытанне. Ёсць issue на GitHub. Ён, па-мойму, ужо зачынены. Ёсць паніка пры restore. І каб яе перамагчы, ты рабіў асобную зборку. Яна ляжыць проста ў issues. І ёсць варыянт, што пераменнае асяроддзе ў адзін паток рабіць. І вельмі марудна таму працуе. І мы сутыкаліся з гэтай праблемай, і пакуль гэта не паправілася.
Праблема ў тым, што чамусьці сховішча (CEPH) скідае злучэнне, калі мы да яго прыходзім з вялікім паралелізмам. Што з гэтым можна зрабіць? Логіка retry выглядае наступным чынам. Мы спрабуем загрузіць файл нанова. За адзін праход у нас колькі файлаў не загрузілася, мы зробім другі для ўсіх тых, хто не зайшоў. І пакуль хаця б адзін файл за ітэрацыю загружаецца, мы паўтараем і паўтараем, і паўтараем. Мы дапрацоўвалі логіку retry - exponential backoff. Але не зусім зразумела, што рабіць з тым, што злучэнне проста абрываецца са боку сістэмы захоўвання. Т. е. калі мы запампоўваем у адзін струмень, яна гэтыя злучэнні не абрывае. Што мы тут можам палепшыць? У нас сеткавы тратлінг у нас ёсць, мы можам кожнае злучэнне абмежаваць па колькасці байт, якое яно адпраўляе. У астатнім, як дужацца з тым, што аб'ектнае сховішча не дае нам раўналежна запампоўваць або з яго выпампоўваць, я не ведаю.
Няма ніякага SLA? Не напісана ў іх, як яны дазваляюць сябе мучыць?
Іста ў тым, што людзі, якія прыходзяць з гэтым пытаннем, звычайна маюць сваё сховішча. Т. е. з Amazon або з Google Cloud, або з Yandex Object Storage ніхто не прыходзіць.
Можа пытанне ўжо не да вас?
Пытанне тут у дадзеным выпадку ўсё роўна да каго. Калі ёсьць нейкія ідэі, як з гэтым змагацца, давайце мы гэта зробім у WAL-G. Але пакуль у мяне добрых ідэй, як з гэтым дужацца няма. Ёсць некаторыя Object Storage, якія па-іншаму падтрымліваюць listing бэкапаў. Ты іх просіш пералічыць аб'екты, а яны туды дадаюць яшчэ folder. WAL-G пры гэтым палохаецца - тут ёсць нейкая штука, якая не файл, я не магу яго аднавіць, значыць, бэкап не аднавіўся. Т. е. на самой справе ў цябе ляжыць цалкам адноўлены кластар, але ён табе вяртае памылковы статус, таму што Object Storage вярнуў нейкую дзіўную інфармацыю, якую ён не да канца зразумеў.
Гэта ў воблаку Mail узнікае такая штука.
Калі можна пабудаваць reproduce…
Яно стабільна прайграваецца...
Калі ёсць reproduce, то, я думаю, што мы паэксперыментуем са стратэгіямі retry і прыдумаем, як рэтраіць і разумець, што ад нас патрабуе воблака. Можа быць, яно нам стабільна на трох злучэннях не будзе ірваць злучэнне, тады мы будзем акуратна даходзіць да трох. Таму што зараз мы злучэнне кідаем вельмі хутка, т. е. калі запусціў аднаўленне ў 16 патокаў, то пасля першага ж retry там будзе 8 патокаў, 4 патокаў, 2 патокаў і адзін. І далей ён будзе па файліку цягнуць у адзін струмень. Калі ёсць нейкія магічныя значэнні тыпу 7,5 струменяў лепш за ўсё пампуецца, то мы будзем на іх затрымоўвацца і спрабаваць яшчэ па 7,5 струменяў рабіць. Вось такая ідэя ёсць.
Дзякуй за даклад! Як выглядае поўны workflow працы з WAL-G? Напрыклад, у дурным выпадку, калі дэльты па старонках няма. І мы бяром і здымаем пачатковы бэкап, потым архівуем вал да ссінення. Тут, як я разумею, ёсць разбіўка. У нейкі момант трэба зрабіць delta-бэкап старонак, т. е. нейкі вонкавы працэс гэта драйвіт ці як гэта здараецца?
API delta-бэкапаў даволі простае. Там ёсць лік - max delta steps, накшталт так называецца. Ён па дэфолце ў нулі. Гэта азначае, што кожны раз, калі ты робіш backup-push, ён запампоўвае поўны бэкап. Калі ты яго мяняеш на любы станоўчы лік, напрыклад, на 3, то, калі ты наступным разам робіш backup-push, ён глядзіць гісторыю папярэдніх бэкапаў. Бачыць, што ты не перавышаеш ланцужок у 3 дэльты і робіць дэльту.
Т. е. кожны раз, калі мы запускаем WAL-G, ён спрабуе зрабіць поўны бэкап?
Не, мы запускаем WAL-G, і ён спрабуе зрабіць дэльту, калі дазволена гэта тваімі палітыкамі.
Грубіянска кажучы, калі кожны раз запускаць яго з нулём, то ён будзе сябе паводзіць як pg_basebackup?
Не, ён усё роўна будзе працаваць хутчэй, таму што ён выкарыстоўвае сціск і паралелізм. Pg_basebackup табе побач пакладзе вал. WAL-G разлічвае на тое, што ў цябе настроена архівацыя. І будзе выдаваць warning, калі яна не настроена.
Pg_basebackup можна запусціць без валаў.
Так, тады яны будуць паводзіць сябе амаль аднолькава. Pg_basebackup капіюе на файлавую сістэму. У нас ёсць, дарэчы, новая фіча, пра якую я забыўся сказаць. Мы зараз можам з pg_basebackup на файлавую сістэму бэкапіцца. Ня ведаю, навошта гэта трэба, але гэта ёсьць.
Напрыклад, на CephFS. Не ўсе жадаюць Object Storage канфігураваць.
Так, мусіць, таму і задавалі пытанне пра гэтую фічу, каб мы яе зрабілі. І мы яе зрабілі.
Дзякуй за даклад! Ёсць як раз пытанне наконт капіравання на файлавую сістэму. Са скрынкі вы зараз падтрымліваеце капіраванне на remote storage, напрыклад, калі нейкая паліца ў ЦАД ці яшчэ што-небудзь?
У такой фармулёўцы - гэта складанае пытанне. Так, мы падтрымліваем, але гэтая функцыянальнасць яшчэ не ўключана ні ў адзін рэліз. Т. е. усе предрелизы гэта падтрымліваюць, але ў рэлізных версіях гэтага няма. Гэта функцыянальнасць дададзена ў версію 0.2. Яна абавязкова хутка апынецца ў рэлізе, як толькі мы паправім усе вядомыя багі. Але прама зараз гэта можна зрабіць толькі ў предрелизе. У предрелизе ёсць два бага. Праблема з аднаўленнем WAL-E, гэта мы не адрамантавалі. І ў апошнім предрелизе дададзены баг пра delta-backup. Таму мы ўсім рэкамендуемы карыстацца рэлізнымі версіямі. Як толькі ў предрелизе перастануць знаходзіцца багі, можна будзе сказаць, што мы падтрымліваем Google Cloud, S3-сумяшчальныя рэчы і файлавы storage.
Прывітанне, дзякуй за даклад. Як я зразумеў, WAL-G - гэта не цэнтралізаваная нейкая сістэма як barmen? Ці плануеце ў гэтым напрамку рухацца?
Праблема ў тым, што мы адышлі ад гэтага напрамку. WAL-G жыве на хасце базы, на хасце кластара, прычым на ўсіх хастах кластара. Калі мы перайшлі ў некалькі тысяч кластараў, у нас было шмат усталёвак бармэна. І кожны раз, калі ў іх нешта развальваецца, гэта вялікая праблема. Таму што іх трэба правіць, трэба зразумець, якія кластары зараз не маюць бэкапаў. У напрамку фізічнага жалеза пад сістэмы рэзервовага капіявання я развіваць WAL-G не планую. Калі супольнасць захоча нейкую функцыянальнасць тут, я ані не супраць.
У нас ёсьць каманды, якія адказваюць за storage. І нам так добра, што гэта не мы, што ёсць спецыяльныя людзі, якія кладуць нашы файлікі туды, дзе файлікам бяспечна. Яны робяць там усякія хітрыя кадаванні так, каб вытрымліваць страты нейкай колькасці файлаў. Яны адказваюць за прапускную здольнасць сеткі. Калі ў цябе ёсць бармэн, у цябе нечакана можа высветліцца, што ў адзін і той жа сервер з'ехаліся маленькія базы з вялікім трафікам. У цябе быццам бы на ім куча месца, але чамусьці не залазіць усё праз сетку. Можа аказацца наадварот. Сеткі шмат там, працэсарныя ядры ёсць, але дыскі тут скончыліся. І гэтая неабходнасць жангляваць чымсьці нам надакучыла, і мы перайшлі да таго, што захоўванне дадзеных - гэта асобны сэрвіс, за які адказвае асобныя спецыяльныя людзі.
PS Выйшла новая версія , у якой можна выкарыстоўваць файл канфігурацыі .walg.json, які па змаўчанні знаходзіцца ў хатняй дырэкторыі postgres. Можна адмовіцца ад bash скрыптоў. Прыклад .walg.json знаходзіцца ў гэтым issue
Відэа:
Крыніца: habr.com