Бекап од WAL-G. Што има во 2019 година? Андреј Бородин

Ви предлагам да го прочитате преписот на извештајот од почетокот на 2019 година од Андреј Бородин „Резервни копии со WAL-G. Што има во 2019 година?“

Здраво на сите! Јас се викам Андреј Бородин. Јас сум програмер во Yandex. Ме интересира PostgreSQL од 2016 година, откако разговарав со програмерите и ми рекоа дека сè е едноставно - земете го изворниот код и изградите го, и сè ќе успее. И оттогаш не можам да престанам - пишувам секакви различни работи.

Една од работите на кои работам е резервниот систем. ВОЛ-Г. Во принцип, во 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“.

Ова значи дека треба да отидете во поставките и да го вклучите „archive_mode = on“ и да додадете „archive_command“, што исто така е подкоманда во WAL-G. Но, поради некоја причина, луѓето често користат бар скрипти на оваа тема и ја обвиткуваат околу WAL-G. Ве молам, не го правете ова. Користете ја функционалноста пронајдена во WAL-G. Ако нешто пропуштите, пишете GitHub. WAL-G претпоставува дека тоа е единствената програма што работи во archive_command.

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

И обично се користи во топологија од еден Master и неколку репликации. Во исто време, прави резервна копија во Yandex Object Storage.

Најчестите сценарија се создавање копии од кластер со помош на Point in time recovery. Но, во овој случај, перформансите на резервниот систем не ни се толку важни. Треба само да прикачиме нов кластер од резервната копија.

Вообичаено, ни требаат резервни перформанси на системот кога додаваме нов јазол. Зошто е важно? Обично луѓето додаваат нов јазол во кластерот бидејќи постојниот кластер не може да се справи со оптоварувањето за читање. Треба да додадат нова реплика. Ако го додадеме оптоварувањето од 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. Многу развивачи на резервни системи веруваат дека ова е толку ризичен систем бидејќи се потпираме на нашето знаење за внатрешните делови на кодот што не е PostgreSQL API. PostgreSQL не гарантира присуство на папката archive_status за нас и не ја гарантира семантиката, присуството на сигнали за подготвеност за WAL датотеките таму. Сепак, ние го проучуваме изворниот код, гледаме дека е така и се обидуваме да го искористиме. И ние ја контролираме насоката во која се развива PostgreSQL; ако одеднаш овој механизам се скрши, ќе престанеме да го користиме.

Во својата чиста форма, WAL делта базирана на LSN бара читање на која било кластер-датотека чие време на режим во датотечниот систем е променето од претходната резервна копија. Со ова живеевме долго време, скоро една година. И на крајот дојдовме до заклучок дека имаме WAL делти.

Ова значи дека секогаш кога го архивираме WAL на Master, не само што го компресираме, шифрираме и испраќаме до мрежата, туку и го читаме во исто време. Ги анализираме и читаме записите во него. Ние разбираме кои блокови се променети и собираме делта-датотеки.

Делта-датотеката опишува одреден опсег на WAL-датотеки, опишува информации за тоа кои блокови се сменети во овој опсег на WAL. И тогаш овие делта-датотеки се исто така архивирани.

Овде сме соочени со фактот дека доста брзо паралелизиравме сè, но не можеме паралелно да читаме секвенцијална историја, бидејќи во одреден сегмент може да наидеме на крајот на претходниот рекорд на WAL, со кој сè уште немаме што да се поврземе, бидејќи Паралелното читање доведе до тоа прво да ја анализираме иднината, која сè уште нема минато.

Како резултат на тоа, моравме да ставиме неразбирливи парчиња во _delta_partial датотеки. Како резултат на тоа, кога ќе се вратиме во минатото, ќе ги залепиме парчињата од WAL рекордот во едно, потоа ќе го анализираме и ќе разбереме што се сменило во него.

Ако во историјата на нашето парсирање на вратилото има барем една точка каде што не разбираме што се случува, тогаш, соодветно, за време на следната резервна копија ќе бидеме принудени повторно да го прочитаме целиот кластер, исто како што направивме со обичен LSN - заснована на делта.

Како резултат на тоа, сите наши страдања доведоа до фактот дека ја отворивме библиотеката за парсирање на WAL-G. Колку што знам, никој не го користи сеуште, но ако некој сака, пишете го и употреби, е во јавна сопственост. (Ажурирана врска https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

На графиконите сè изгледа многу поедноставно. Ова е преземање од еден од нашите вистински кластери. Имаме LSN-базирани, направени за еден ден. И гледаме дека делта резервната копија базирана на LSN работеше од три наутро до пет наутро. Ова е оптоварување во бројот на јадра на процесорот. WAL-delta овде ни одзеде околу 20 минути, односно стана значително побрз, но во исто време имаше поинтензивна размена преку мрежата.

Бидејќи имаме информации за тоа кои блокови се сменија и во кое време во историјата на базата на податоци, отидовме понатаму и решивме да ја интегрираме функционалноста - екстензија PostgreSQL наречена „pg_prefaulter“

Ова значи дека кога стенд-бај базата ја извршува командата за обновување, му кажува на WAL-G да ја преземе следната WAL-датотека. Ние разбираме приближно до кои блокови на податоци ќе пристапи процесот на обновување на WAL во блиска иднина и ќе започне операција за читање на овие блокови. Ова е направено со цел да се зголемат перформансите на контролорите на SSD. Бидејќи ролната WAL ќе стигне до страницата што треба да се смени. Оваа страница е на дискот и не е во кешот на страницата. И тој ќе чека синхроно да пристигне оваа страница. Но, во близина е WAL-G, кој знае дека во следните неколку стотици мегабајти WAL ќе ни требаат одредени страници и во исто време почнува да ги загрева. Иницира повеќекратни пристапи на дискот, така што тие се извршуваат паралелно. Ова работи добро на SSD-дискови, но, за жал, апсолутно не е применливо за хард диск, бидејќи ние се мешаме со него само со нашите инструкции.

Ова е она што е во кодот сега.

Постојат карактеристики што би сакале да ги додадеме.

Оваа слика покажува дека WAL-delta трае релативно кратко време. И ова е читање на промените што се случија во базата на податоци во текот на денот. Можевме да правиме WAL-delta не само ноќе, бидејќи тоа веќе не е значаен извор на оптоварување. Можеме да читаме WAL-delta секоја минута бидејќи е евтин. За една минута можеме да ги скенираме сите промени што се случиле во кластерот. И ова може да се нарече „инстант ВАЛ-делта“.

Поентата е дека кога го обновуваме кластерот, го намалуваме бројот на приказни што треба последователно да ги навиваме. Односно, количината на WAL што ја рола PostgreSQL треба да се намали, бидејќи за тоа е потребно значително време.

Но, тоа не е се. Ако знаеме дека некој блок ќе биде променет до точка на конзистентност на резервната копија, не можеме да го промениме во минатото. Односно, сега имаме оптимизација од датотека по датотека за препраќање WAL-делта. Ова значи дека ако, на пример, во вторник табела е целосно избришана или некои датотеки се целосно избришани од табелата, тогаш кога delta се превртува во понеделник и саботата се обновува pg_basebackup, ние дури и нема да ги создадеме овие податоци.

Сакаме да ја прошириме оваа технологија на ниво на страница. Односно, ако некој дел од датотеката се промени во понеделник, но ќе биде препишан во среда, тогаш при враќање на точка во четврток, не треба да ги пишуваме првите неколку верзии на страници на дискот.

Но, ова е сè уште идеја за која активно се дискутира во нас, но сè уште не е стигната до кодот.

Сакаме да направиме уште една карактеристика во WAL-G. Сакаме да го направиме проширување затоа што треба да поддржуваме различни бази на податоци и би сакале да можеме да му пристапиме на управувањето со резервни копии на ист начин. Но, проблемот е што MySQL API-ите се радикално различни. Во MySQL, PITR не се базира на физичкиот дневник на WAL, туку на бинлогот. И ние немаме систем за архивирање во MySQL што ќе му каже на некој надворешен систем дека овој бинлог е завршен и треба да се архивира. Треба да застанеме некаде во 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 и да добијат неколку илјади долари од една компанија со буквата „Г“, тогаш препорачајте им го нашиот проект. Ќе дејствувам како ментор за овој проект, тие можат да го направат тоа. Ако нема студенти, тогаш ќе земам и ќе го направам сам на лето.

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

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

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

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

И главната работа што не загрижува е што сакаме што е можно повеќе тестови за интеграција на докерот кои проверуваат различни сценарија. Во моментов тестираме само основни сценарија. На секој commit, но сакаме да ја провериме commit-by-commit целата функционалност што ја поддржуваме. Конкретно, на пример, ќе имаме доволно поддршка за PostgreSQL 9.4-9.5. Ги поддржуваме бидејќи заедницата поддржува PostgreSQL, но не проверуваме commit-by-commit за да се увериме дека сè не е скршено. И ми се чини дека ова е прилично сериозен ризик.

Имаме 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 да се логирам во два провајдери, т.е. сакам да направам еден облак и друг. Дали има некој начин да се направи ова?

Ова сега не постои, но тоа е интересна идеја.

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

Идејата е интересна. Технички, ова воопшто не е тешко да се спроведе. За да не се изгуби идејата, може ли да ве замолам да направите проблем на 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 е прилично едноставен. Има голем број таму - максимални чекори делта, така се нарекува. Стандардно е нула. Ова значи дека секој пат кога правите резервна копија-притиснување, презема целосна резервна копија. Ако го промените на кој било позитивен број, на пример, 3, тогаш следниот пат кога ќе направите резервна копија-притиснување, ќе ја погледне историјата на претходните резервни копии. Гледа дека не го надминуваш синџирот од 3 делти и прави делта.

Односно, секогаш кога ќе го стартуваме WAL-G, тој се обидува да направи целосна резервна копија?

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

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

Не, сепак ќе работи побрзо бидејќи користи компресија и паралелизам. Pg_basebackup ќе го стави вратилото до вас. WAL-G претпоставува дека сте го конфигурирале архивирањето. И ќе издаде предупредување ако не е конфигуриран.

Pg_basebackup може да се работи без шахти.

Да, тогаш тие ќе се однесуваат речиси исто. Pg_basebackup копира во датотечниот систем. Патем, имаме нова функција која заборавив да ја спомнам. Сега можеме да направиме резервна копија во датотечниот систем од pg_basebackup. Не знам зошто е тоа потребно, но го има.

На пример, на CephFS. Не секој сака да го конфигурира објектот за складирање.

Да, веројатно затоа поставија прашање за оваа функција за да можеме да го направиме тоа. И го направивме тоа.

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

Во оваа формулација, ова е тешко прашање. Да, поддржуваме, но оваа функционалност сè уште не е вклучена во ниту едно издание. Тоа е, сите пред-изданија го поддржуваат ова, но верзиите за издавање не. Оваа функционалност е додадена во верзијата 0.2. Дефинитивно ќе биде објавен наскоро, штом ќе ги поправиме сите познати грешки. Но, во моментов ова може да се направи само во предиздавање. Има две грешки во предиздавањето. Проблем со обновувањето на WAL-E, не го решивме. И во последното предиздание беше додадена грешка за делта-резервна копија. Затоа, на сите им препорачуваме да ги користат верзиите за издавање. Штом нема повеќе грешки во предиздавањето, можеме да кажеме дека поддржуваме Google Cloud, работи компатибилни со S3 и складирање датотеки.

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

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

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

П.С. Издадена е нова верзија 0.2.15, во која можете да ја користите конфигурациската датотека .walg.json, која стандардно се наоѓа во домашниот директориум на postgres. Можете да ги напуштите баш скриптите. Пример .walg.json е во ова издание https://github.com/wal-g/wal-g/issues/545

Видео:

Извор: www.habr.com