Резервни копия от WAL-G. Какво има през 2019 г.? Андрей Бородин

Предлагам ви да прочетете стенограмата на доклада от началото на 2019 г. на Андрей Бородин „Резервни копия с WAL-G. Какво има през 2019 г.?“

Здравейте всички! Казвам се Андрей Бородин. Аз съм разработчик в Yandex. Интересувам се от PostgreSQL от 2016 г., след като говорих с разработчиците и те казаха, че всичко е просто - взимаш изходния код и го изграждаш, и всичко ще се получи. И оттогава не мога да спра – пиша най-различни неща.

Едно от нещата, върху които работя, е резервна система. WAL-G. Като цяло в Yandex работим върху системи за архивиране в PostgreSQL от много дълго време. И можете да намерите в Интернет поредица от шест доклада за това как правим резервни системи. И всяка година те се развиват малко, развиват се малко и стават по-надеждни.

Но днес докладът не е само за това, което сме направили, но и за това колко просто е и какво е. Колко от вас вече са гледали репортажите ми за WAL-G? Добре, че доста хора не гледаха, защото ще започна от най-простото.

Ако внезапно имате PostgreSQL клъстер и мисля, че всеки има няколко от тях със себе си и внезапно все още няма система за архивиране, тогава трябва да вземете всяко S3 хранилище или съвместимо с Google Cloud хранилище.

Например, можете да дойдете на нашия щанд и да вземете промоционален код за Yandex Object Storage, който е съвместим със S3.

След това създайте кофа. Това е просто контейнер за информация.

Създайте потребител на услугата.

Създайте ключ за достъп за потребителя на услугата: aws-s3-key.

Изтеглете последната стабилна версия на WAL-G.

Как нашите предварителни версии се различават от версиите? Често ме молят да освободя по-рано. И ако във версията няма грешка за достатъчно време, например месец, тогава я пускам. Ето това издание от ноември. И това означава, че всеки месец откриваме някаква грешка, обикновено в некритична функционалност, но все още не сме пуснали версия. Предишната версия е само ноември. В него няма известни грешки, т.е. грешки са добавени с напредването на проекта.

След като изтеглите WAL-G, можете да изпълните проста команда „списък с резервни копия“, предавайки променливите на средата. И ще се свърже с Object Storage и ще ви каже какви резервни копия имате. В началото, разбира се, не трябва да имате резервни копия. Целта на този слайд е да покаже, че всичко е съвсем просто. Това е конзолна команда, която приема променливи на средата и изпълнява подкоманди.

След това можете да направите първото си архивиране. Кажете „backup-push“ в WAL-G и посочете в WAL-G местоположението на pgdata на вашия клъстер. И най-вероятно PostgreSQL ще ви каже, ако все още нямате система за архивиране, че трябва да активирате "архивен режим".

Това означава, че трябва да отидете в настройките и да включите „archive_mode = on“ и да добавите „archive_command“, което също е подкоманда в WAL-G. Но по някаква причина хората често използват бар скриптове по тази тема и я увиват около WAL-G. моля те не прави това Използвайте функционалността на WAL-G. Ако нещо Ви липсва, пишете на GitHub. WAL-G приема, че това е единствената програма, която работи в archive_command.

Ние използваме WAL-G главно за създаване на клъстер с висока наличност в управлението на база данни на Yandex.

И обикновено се използва в топология от един Master и няколко репликации. В същото време прави резервно копие в Yandex Object Storage.

Най-често срещаните сценарии са създаване на копия на клъстер с помощта на възстановяване във времето. Но в този случай производителността на резервната система не е толкова важна за нас. Просто трябва да качим нов клъстер от архива.

Обикновено се нуждаем от резервна производителност на системата, когато добавяме нов възел. Защо е важно? Обикновено хората добавят нов възел към клъстер, защото съществуващият клъстер не може да се справи с натоварването при четене. Те трябва да добавят нова реплика. Ако добавим натоварването от pg_basebackup към Master, тогава Master може да се срине. Затова за нас беше много важно да можем бързо да качим нов възел от архива, създавайки минимално натоварване на Master.

И още една подобна ситуация. Това е необходимостта от рестартиране на стария Master след превключване на Cluster Master от Центъра за данни, с който е загубена свързаността.

• В резултат на това, когато формулирахме изискванията за системата за копиране, разбрахме, че pg_basebackup не е подходящ за нас, когато работим в облака.
• Искахме да можем да компресираме нашите данни. Но почти всяка система за архивиране, различна от тази, която идва в кутията, ще осигури компресиране на данни.
• Искахме да паралелизираме всичко, защото потребител в облака купува голям брой процесорни ядра. Но ако нямаме паралелизъм в някоя операция, тогава голям брой ядра стават безполезни.
• Имаме нужда от криптиране, защото често данните не са наши и не могат да се съхраняват в ясен текст. Между другото, нашият принос към WAL-G започна с криптиране. Завършихме криптирането в WAL-G, след което ни попитаха: „Може би някой от нас ще разработи проекта?“ И оттогава работя с WAL-G повече от година.
• Нуждаехме се също от ограничаване на ресурсите, защото с течение на времето, използвайки облака, установихме, че понякога хората имат важно натоварване с хранителни стоки през нощта и това натоварване не може да бъде намесено. Ето защо добавихме ограничаване на ресурсите.
• Както и листване и управление.
• И проверка.

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

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

Основната идеология, към която се придържаме, е, че WAL-G трябва да бъде прост като балалайка.

WAL-G има 4 команди. Това:

WAL-PUSH – архивиране на вала.

WAL-FETCH – вземете вал.

BACKUP-PUSH – направете резервно копие.

BACKUP-FETCH – вземете резервно копие от системата за архивиране.

Всъщност WAL-G има и управление на тези архиви, т.е. изброяване и изтриване на записи и архиви в историята, които вече не са необходими в момента.

Една от важните функции за нас е функцията за създаване на делта копия.

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

Делта базирани на LSN - това означава, че когато създаваме резервно копие, ще трябва да комбинираме всяка страница и да проверим нейния 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-базираната WAL делта изисква четене на всеки клъстерен файл, чието време на режим във файловата система се е променило след предишното архивиране. Живяхме с това дълго време, почти година. И в крайна сметка стигнахме до заключението, че имаме WAL делта.

Това означава, че всеки път, когато архивираме WAL на Master, ние не само го компресираме, криптираме и изпращаме към мрежата, но и го четем едновременно. Анализираме и четем записите в него. Ние разбираме кои блокове са се променили и събираме делта файлове.

Делта файлът описва определен диапазон от WAL файлове, описва информация за това кои блокове са били променени в този диапазон от WAL. И след това тези делта файлове също се архивират.

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

В резултат на това трябваше да поставим неразбираеми части в _delta_partial файлове. В резултат на това, когато се върнем в миналото, ще слепим парчетата от WAL записа в едно, след което ще го анализираме и ще разберем какво се е променило в него.

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

В резултат на това цялото ни страдание доведе до факта, че отворихме библиотеката за разбор на WAL-G. Доколкото знам още никой не го ползва, но ако някой иска да пише и да го ползва, публичен е. (Актуализиран линк https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

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

Тъй като имаме информация за това кои блокове са се променили и по кое време в историята на базата данни, ние отидохме по-далеч и решихме да интегрираме функционалност - PostgreSQL разширение, наречено „pg_prefaulter“

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

Това е, което е в кода сега.

Има функции, които бихме искали да добавим.

Тази снимка показва, че WAL-делта отнема сравнително кратко време. И това е четене на промените, настъпили в базата данни през деня. Можем да правим WAL-delta не само през нощта, защото вече не е значителен източник на натоварване. Можем да четем WAL-делта всяка минута, защото е евтино. За една минута можем да сканираме всички промени, настъпили в клъстера. И това може да се нарече "незабавна WAL-делта".

Въпросът е, че когато възстановим клъстера, намаляваме броя на историите, които трябва да навиваме последователно. Това означава, че количеството WAL, което PostgreSQL превърта, трябва да бъде намалено, защото отнема значително време.

Но това не е всичко. Ако знаем, че някой блок ще бъде променен до степен на съгласуваност на резервното копие, не можем да го променим в миналото. Тоест, сега имаме оптимизация файл по файл на WAL-делта пренасочване. Това означава, че ако, например, във вторник една таблица е била напълно изтрита или някои файлове са били изтрити изцяло от таблицата, тогава когато делтата се превърти в понеделник и съботният pg_basebackup бъде възстановен, ние дори няма да създадем тези данни.

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

Но това все още е идея, която се обсъжда активно в нас, но все още не е стигнала до кода.

Искаме да направим още една функция в WAL-G. Искаме да го направим разширяем, защото трябва да поддържаме различни бази данни и бихме искали да можем да подходим към управлението на архивирането по същия начин. Но проблемът е, че MySQL API са коренно различни. В MySQL PITR се основава не на физическия WAL журнал, а на binlog. И ние нямаме система за архивиране в MySQL, която да каже на външна система, че този binlog е завършен и трябва да бъде архивиран. Трябва да стоим някъде в cron с базата данни и да проверяваме дали има нещо готово?

И по същия начин, по време на възстановяване на MySQL, няма команда за възстановяване, която да каже на системата, че имам нужда от такива и такива файлове. Преди да започнете да възстановявате вашия клъстер, трябва да знаете какви файлове ще ви трябват. Вие сами трябва да познаете какви файлове ще ви трябват. Но тези проблеми могат да бъдат заобиколени по някакъв начин. (Пояснение: MySQL вече се поддържа)

В доклада исках да говоря и за онези случаи, когато WAL-G не е подходящ за вас.

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

Често виждам хора, които се опитват да управляват WAL-G и WAL-E едновременно. Ние поддържаме обратна съвместимост в смисъл, че WAL-G може да възстанови файл от WAL-E и може да възстанови резервно копие, направено в WAL-E. Но тъй като и двете системи използват паралелен wal-push, те започват да крадат файлове една от друга. Ако го поправим в WAL-G, той пак ще остане в WAL-E. В WAL-E той разглежда състоянието на архива, вижда готовите файлове и ги архивира, докато други системи просто няма да разберат, че този WAL файл съществува, защото PostgreSQL няма да се опита да го архивира втори път.

Какво ще поправим тук от страната на WAL-G? Няма да информираме PostgreSQL, че този файл е прехвърлен паралелно и когато PostgreSQL ни поиска да го архивираме, ние вече ще знаем, че такъв файл с този режим-време и с този md5 вече е архивиран и просто ще кажем PostgreSQL - Добре, всичко е готово, без да правите нищо по същество.

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

Освен това има случаи, в които WAL-G не е подходящ за вас сега, но определено ще го поправим.

Първо, в момента нямаме вградена проверка на резервно копие. Нямаме проверка нито по време на архивиране, нито по време на възстановяване. Разбира се, това е реализирано в облака. Но това се изпълнява просто чрез предварителна проверка, просто чрез възстановяване на клъстера. Бих искал да дам тази функционалност на потребителите. Но чрез проверка предполагам, че в WAL-G ще бъде възможно да възстановите клъстера и да го стартирате и да стартирате димни тестове: pg_dumpall до /dev/null и проверка на индекса amcheck.

В момента в WAL-G няма начин да се отложи едно архивиране от WAL. Тоест поддържаме някакъв прозорец. Например, съхраняване на последните седем дни, съхраняване на последните десет архива, съхраняване на последните три пълни архива. Доста често хората идват и казват: „Имаме нужда от резервно копие на случилото се на Нова година и искаме да го запазим завинаги.“ WAL-G все още не може да направи това. (Забележка – това вече е поправено. Прочетете повече – Опция за резервно маркиране в https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

И ние нямаме контролни суми на страници и проверки на целостта за всички сегменти на вала, когато валидираме PITR.

От всичко това съставих проект за Google Summer of Code. Ако познавате умни студенти, които биха искали да напишат нещо в Go и да получат няколко хиляди долара от една компания с буквата „G“, препоръчайте им нашия проект. Ще действам като ментор за този проект, те могат да го направят. Ако няма ученици, тогава ще го взема и ще го направя сам през лятото.

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

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

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

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

И основното нещо, което ни тревожи, е, че искаме възможно най-много тестове за интегриране на докери, които проверяват различни сценарии. В момента тестваме само основни сценарии. При всеки ангажимент, но искаме да проверяваме комит по ангажимент цялата функционалност, която поддържаме. По-специално, например, ще имаме достатъчно поддръжка за PostgreSQL 9.4-9.5. Поддържаме ги, защото общността поддържа PostgreSQL, но не проверяваме ангажимент по ангажимент, за да сме сигурни, че всичко не е повредено. И ми се струва, че това е доста сериозен риск.

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

Имаме много TODO в нашия код. Ако искате да програмирате, заповядайте, чакаме заявки за изтегляне, чакаме въпроси.

Въпроси

Добър вечер! Благодаря ти! Предполагам, че ако използвате WAL-delta, вероятно разчитате в голяма степен на писане на цяла страница. И ако да, направихте ли тестове? Показахте красива графика. Колко по-красиво става, ако FPW се изключи?

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

Благодаря за доклада! Имам два въпроса. Първият въпрос е какво ще се случи с табличните пространства?

Очакваме заявка за изтегляне. Нашите бази данни живеят на SSD и NMVE дискове и всъщност не се нуждаем от тази функция. Не съм готов да отделям сериозно време в момента, за да го направя добре. С цялото си сърце подкрепям това. Има хора, които го подкрепиха, но го подкрепиха така, както им е удобно. Направиха вилица, но не правят заявки за изтегляне. (Добавено във версия 0.2.13)

И вторият въпрос. Казахте в самото начало, че WAL-G предполага, че работи сам и не са необходими обвивки. Аз самият използвам опаковки. Защо не трябва да се използват?

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

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

Създайте проблем в GitHub и нека го разберем.

Тоест, не сте се сблъсквали с това?

Има функция на доклада за грешка, че когато WAL-G не разбира какъв вид файл е, той пита: „Може би е криптиран?“ Може би проблемът изобщо не е в криптирането. Искам да подобря записването на тази тема. Той трябва да го дешифрира. В момента работим по тази тема в смисъл, че не ни харесва много как е организирана системата за получаване на публични и частни ключове. Защото ние извикваме външен GPG, така че той да ни даде своите ключове. След това вземаме тези ключове и ги прехвърляме към вътрешния GPG, който е отворен PGP, който е компилиран за нас в WAL-G, и там наричаме криптиране. В тази връзка искаме да подобрим системата и да поддържаме Libsodium криптиране (Добавено във версия 0.2.15). Разбира се, декодирането трябва да работи, нека да го разберем - имате нужда от повече симптом, отколкото от няколко думи. Може някой път да се съберете в стаята на говорителя и да разгледате системата. (PGP криптиране без външен GPG - v0.2.9)

Здравейте! Благодаря за доклада! Имам два въпроса. Имам странно желание да направя pg_basebackup и WAL log в два доставчика, т.е. искам да направя един облак и друг. Има ли някакъв начин да направите това?

Сега това не съществува, но е интересна идея.

Просто не вярвам на един доставчик, искам да имам същото в друг, за всеки случай.

Идеята е интересна. Технически това не е никак трудно за изпълнение. За да не се изгуби идеята, мога ли да ви помоля да направите проблем в GitHub?

Да, разбира се.

И след това, когато учениците дойдат в Google Summer of Code, ние ще ги добавим към проекта, така че да има повече работа, за да извлечем повече от тях.

И вторият въпрос. Има проблем в GitHub. Мисля, че вече е затворено. Има паника по време на възстановяване. И за да го победите, направихте отделно събрание. Правилно е в проблемите. И има опция да се направи променлива среда в една нишка. И затова работи много бавно. Срещнахме този проблем и той все още не е отстранен.

Проблемът е, че по някаква причина хранилището (CEPH) нулира връзката, когато стигнем до нея с висока едновременност. Какво може да се направи по въпроса? Логиката за повторен опит изглежда така. Опитваме се да изтеглим файла отново. При едно преминаване имахме няколко несвалени файла, ще направим втори за всички, които не са влезли. И докато поне един файл се зарежда на итерация, ние повтаряме и повтаряме и повтаряме. Подобрихме логиката на повторен опит - експоненциално отстъпление. Но не е съвсем ясно какво да правим с факта, че връзката просто се прекъсва от страната на системата за съхранение. Тоест, когато качваме в един поток, той не прекъсва тези връзки. Какво можем да подобрим тук? Имаме дроселиране на мрежата, можем да ограничим всяка връзка чрез броя байтове, които изпраща. В противен случай не знам как да се справя с факта, че хранилището на обекти не ни позволява да изтегляме или изтегляме от него паралелно.

Няма SLA? Не им ли е писано как се оставят да ги измъчват?

Въпросът е, че хората, които измислят този въпрос, обикновено имат свой собствен трезор. Тоест никой не идва от Amazon или Google Cloud, или Yandex Object Storage.

Може би въпросът вече не е за вас?

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

Това е нещо, което се случва в облака на пощата.

Ако можете да създадете възпроизвеждане...

Възпроизвежда се последователно...

Ако има възпроизвеждане, тогава мисля, че ще експериментираме със стратегии за повторен опит и ще разберем как да опитаме отново и да разберем какво облакът изисква от нас. Може би ще ни е стабилно на три връзки и няма да прекъсне връзката, тогава внимателно ще стигнем до три. Защото сега прекъсваме връзката много бързо, т.е. ако сме стартирали възстановяване с 16 нишки, след първия повторен опит ще има 8 нишки, 4 нишки, 2 нишки и една. И след това ще изтегли файла в един поток. Ако има някои магически стойности като 7,5 нишки са най-добрите за изпомпване, тогава ще се спрем на тях и ще се опитаме да направим още 7,5 нишки. Ето една идея.

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

API за делта архивиране е доста прост. Там има число – максимални делта стъпки, така се нарича. По подразбиране е нула. Това означава, че всеки път, когато направите backup-push, той изтегля пълен архив. Ако го промените на произволно положително число, например 3, тогава следващия път, когато направите резервно копиране, той преглежда хронологията на предишни архиви. Той гледа да не превишите веригата от 3 делти и прави делта.

Тоест всеки път, когато стартираме WAL-G, той се опитва да направи пълен бекъп?

Не, ние управляваме WAL-G и той се опитва да направи делта, ако вашите правила го позволяват.

Грубо казано, ако го стартирате с нула всеки път, ще се държи ли като pg_basebackup?

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

Pg_basebackup може да се изпълнява без валове.

Да, тогава те ще се държат почти по същия начин. Pg_basebackup копира във файловата система. Между другото, имаме нова функция, която забравих да спомена. Вече можем да архивираме във файловата система от pg_basebackup. Не знам защо е необходимо това, но го има.

Например на CephFS. Не всеки иска да конфигурира Object Storage.

Да, вероятно затова те зададоха въпрос за тази функция, за да можем да го направим. И го направихме.

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

В тази формулировка това е труден въпрос. Да, поддържаме, но тази функционалност все още не е включена в никоя версия. Тоест, всички предварителни версии поддържат това, но версиите на изданието не. Тази функционалност беше добавена във версия 0.2. Определено ще бъде пуснат скоро, веднага щом коригираме всички известни грешки. Но в момента това може да се направи само в предварителната версия. Има два бъга в предварителната версия. Проблем с възстановяването на WAL-E, не сме го поправили. И в последната предварителна версия беше добавен бъг за делта-архивиране. Затова препоръчваме на всички да използват версиите за освобождаване. Веднага щом няма повече грешки в предварителната версия, можем да кажем, че поддържаме Google Cloud, S3-съвместими неща и съхранение на файлове.

Здравейте, благодаря за доклада. Доколкото разбирам, WAL-G не е някаква централизирана система като барманите? Смятате ли да се движите в тази посока?

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

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

PS Излезе нова версия 0.2.15, в който можете да използвате конфигурационния файл .walg.json, който се намира в началната директория на postgres по подразбиране. Можете да изоставите bash скриптовете. Пример .walg.json е в този брой https://github.com/wal-g/wal-g/issues/545

Video:

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