Текущото състояние на управление на архивиране с отворен код за PostgreSQL

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

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

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

• pg_basebackup или pg_start_backup()/pg_stop_backup
• физическо копие
• архивиране на WAL или стрийминг репликация

Има няколко добри продукта и решения, някои са с отворен код и безплатни за използване, докато други са комерсиални. Доколкото ми е известно, това са:

• pgbarman от 2ndquadrant (безплатно)
• pgbackrest (безплатно)
• pg_probackup от Postgres Professional (безплатно)
• BART от EDB (търговски)

Нямах възможност да изпробвам BART, тъй като той работи на разновидности на Linux, които не използвам. В този блог ще включа собствените си мисли и впечатления, докато общувам със съответните автори/общност/поддръжници на всяко решение, тъй като това е много важен аспект, който обикновено се подценява в началото. Малко терминология, за да разберете по-добре различните термини във всеки от инструментите:

pgbarman

Pgbarman или просто барман е най-старият от тези инструменти. Последната версия е 2.6 (издадена, докато имах този блог в работата! което е страхотна новина).

Pgbarman поддържа базово архивиране чрез два метода:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

и прехвърляне на WAL чрез:

• WAL архивиране
  • чрез rsync
  • чрез barman-wal-archive / put-wal
• WAL чрез поточно репликация със слот за репликация
  • Асинхронно
  • Синхронно

Това ни дава 8 нестандартни комбинации, чрез които можем да използваме барман. Всеки има своите плюсове и минуси.

Базово архивиране чрез pg_basebackup (backup_method =postgres)

Плюсове:

• най-новият/модерен начин
• разчита на доказана основна технология PostgreSQL
• препоръчан от официалните документи

Минуси:

• без допълнително архивиране
• няма паралелно архивиране
• няма компресия на мрежата
• няма премахване на дублиране на данни
• няма ограничение на честотната лента на мрежата

Базово архивиране чрез rsync (backup_method =rsync)

Плюсове:

• стари и доказани
• Постепенно архивиране
• дедупликация на данни
• компресия на мрежата
• паралелно архивиране
• ограничение на честотната лента на мрежата

Минуси:

• не е препоръчания (от авторите) начин

Прехвърляне на WAL чрез WAL архивиране (чрез rsync)

Плюсове:

• по-лесен за настройка

Минуси:

• Без RPO=0 (нулева загуба на данни)
• няма начин за възстановяване от дълги и продължителни мрежови сривове

Прехвърляне на WAL чрез WAL архивиране (чрез barman-wal-archive / put-wal)

Плюсове:

• най-новият и препоръчан начин (въведен в 2.6)
• по-надежден/безопасен от rsync

Минуси:

• Без RPO=0 (нулева загуба на данни)
• все още няма начин за възстановяване от дълги и продължаващи мрежови повреди

Прехвърляне на WAL чрез поточно предаване на WAL със слот за репликация (чрез pg_receivewal)

Плюсове:

• по-модерно (и препоръчително)
• RPO=0 (нулева загуба на данни) в синхронен режим

Минуси:

• винаги се свързва със слот за репликация. Може да нарасне в случай на повреди в мрежата

Така че, докато pg_basebackup (метод postgres) изглежда като бъдещето за pgbarman, в действителност всички фантастични функции идват с метода rsync. Така че нека изброим всички характеристики на Barman по-подробно:

• Отдалечена работа (архивиране/възстановяване)
• Постепенно архивиране. Една от страхотните характеристики на barman, инкременталните архиви се основават на сравнение на файловото ниво на файловете на базата данни с тези на последното архивиране в каталога. В барман терминът „диференциал“ се отнася до различна концепция:Според барманската терминология диференциалното архивиране е последното архивиране + отделните промени от последното архивиране. Документите на Barman казват, че предоставят диференциални архиви чрез WAL. Постепенното архивиране на Barman работи на ниво файл, което означава, че ако файл се промени, целият файл се прехвърля. Това е като pgbackrest и за разлика от някои други предложения като pg_probackup или BART, които поддържат диференциално/инкрементално архивиране на ниво блок. Постепенните резервни копия на Barman са посочени чрез:reuse_backup =връзка или копие. Чрез дефинирането на „копиране“ постигаме намалено време на архивиране, тъй като само променените файлове се прехвърлят и архивират, но все още няма намаляване на пространството, тъй като непроменените файлове се копират от предишния архив. Чрез дефиниране на „връзка“ непроменените файлове се свързват твърдо (не се копират) от последното архивиране. По този начин постигаме както намаляване на времето, така и намаляване на пространството. Не искам по никакъв начин да внасям повече объркване в това, но в действителност инкременталните архиви на barman са директно сравними с инкременталните архиви на pgbackrest, тъй като barman третира (чрез връзка или копие) инкременталното архивиране ефективно като пълно архивиране. Така че и в двете системи инкременталното архивиране се занимава с файловете, които са били променени след последното архивиране. Въпреки това, по отношение на диференциалното архивиране, това означава различно нещо във всяка от гореспоменатите системи, както ще видим по-долу.
• Резервно копие от режим на готовност. Barman дава възможност за извършване на основната част от операциите за архивиране на базата от режим на готовност, като по този начин освобождава основното от добавеното IO натоварване. Имайте предвид обаче, че все пак WAL трябва да идват от първичния. Няма значение дали използвате archive_command или WAL стрийминг чрез слотове за репликация, все още не можете (към това писане, като барман е на версия 2.6) да прехвърлите тази задача в режим на готовност.
• паралелни задачи за архивиране и възстановяване
• Богат и изчерпателен набор от настройки за задържане, базирани на едно от следните:
  • Редундантност (брой резервни копия, които трябва да се съхраняват)
  • Прозорец за възстановяване (как в миналото трябва да се съхраняват резервните копия)
  Според мен от гледна точка на потребителя, горното е страхотно. Потребителят може да дефинира reuse_backup =link и прозорец за възстановяване и да остави barman (нейната cron работа) да се справи с останалото. Без diff/incr/full etc архивиране, за което да се притеснявате или да планирате или управлявате. Системата (барман) просто прави правилното нещо прозрачно.
• Програмиране на вашите собствени скриптове за кука преди/след събитие.
• Пренасочване на пространството за таблици

Това са най-добрите силни страни на бармана. И наистина това е почти повече, отколкото средният DBA би поискал от инструмент за архивиране и възстановяване. Въпреки това, има някои точки, които биха могли да бъдат по-добри:

• Пощенският списък не е толкова активен и поддържащите рядко пишат или отговарят на въпроси
• Няма функция за възобновяване на неуспешно/прекъснато архивиране
• Слотовете за репликация или използването на rsync/barman-wal-archive за архивиране не са прощаващи в случай на неуспешна мрежа или други повреди на сайта за архивиране. И в двата случая, ако прекъсването на мрежата е достатъчно дълго и промените в DB струват много WAL файлове, тогава основният ще страда от „не остава място на устройството“ и в крайна сметка ще се срине. (не е хубаво нещо). Това, което е обещаващо тук, е, че barman сега предоставя алтернативен (на rsync) начин за прехвърляне на WAL, така че допълнителната защита срещу напр. pg_wal изчерпването на пространството може да бъде приложено в бъдеще, което заедно с резервната автобиография наистина ще направи бармана перфектен, поне за мен.

pgbackrest

Pgbackrest е текущата тенденция сред инструментите за архивиране с отворен код, главно поради неговата ефективност при справяне с много големи обеми данни и изключителната грижа, която създателите му влагат при валидирането на архиви чрез контролни суми. Към момента на писане е на версия v2.09 и документите се намират тук. Ръководството за потребителя може да е малко остаряло, но останалите документи са много актуални и точни. Pgbackrest разчита на WAL архивиране, използвайки своя собствена команда archive_command и собствен механизъм за прехвърляне на файлове, който е по-добър и по-безопасен от rsync. Така че pgbackrest е доста напред, тъй като не дава по-големия набор от възможности за избор, който барманът предлага. Тъй като няма включен синхронен режим, естествено pgbackrest не гарантира RPO=0 (нулева загуба на данни). Нека опишем концепциите на pgbackrest:

• Резервното копие може да бъде:
  • Пълен. Пълно архивиране копира целия клъстер на базата данни.
  • Диференциал (разл.). Диференциалното архивиране копира само файловете, които са били променени след последното пълно архивиране. За успешно възстановяване, както диференциалното архивиране, така и предишното пълно архивиране трябва да са валидни.
  • Постепенно (incr). Инкременталното архивиране копира само файловете, които са били променени след последното архивиране (което може да бъде пълно архивиране, диференциално или дори инкрементално). Подобно на диференциалното архивиране, за да се извърши успешно възстановяване, всички предишни необходими архиви (включително това архивиране, най-новата разлика и предишното пълно) трябва да са валидни.
• Строфата е дефиницията на всички необходими параметри на PostgreSQL клъстер. Обикновено PostgreSQL сървърът има своя собствена строфа, докато резервните сървъри ще имат една строфа за всеки PostgreSQL клъстер, който архивират.
• Конфигурацията е мястото, където се съхранява информация за строфи (обикновено /etc/pgbackrest.conf)
• Хранилище е мястото, където pgbackrest съхранява WAL и резервни копия

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

• Паралелно архивиране и възстановяване
• Не е необходим директен SQL достъп до PostgreSQL сървъра
• Локална/дистанционна работа
• Задържане въз основа на:
  • запазване на пълно резервно копие (брой пълни резервни копия, които трябва да се съхраняват)
  • запазване на резервни копия на diff (брой резервни копия на diff, които трябва да се съхраняват)
  Инкременталните архиви нямат собствено задържане и изтичат веднага щом изтече предишното архивиране. Така потребителят може да дефинира график за вземане на пълни архиви и непрекъснат набор от резервни копия на разлика между тях.
• Резервно копие от режим на готовност. Някои файлове все още трябва да идват от основния, но груповото копие се извършва в режим на готовност. Все пак WAL трябва да произхождат от първичния.
• Цялост на архивиране. Хората зад pgbackrest са изключително внимателни, когато става въпрос за целостта на резервните копия. Всеки файл се сумира по време на архивиране и също така се проверява след възстановяването, за да се гарантира, че няма проблемна хардуерна или софтуерна грешка, която може да доведе до неправилно възстановяване. Също така, ако контролните суми на ниво страница са разрешени в клъстера PostgreSQL, те също се изчисляват за всеки файл. В допълнение, контролните суми се изчисляват за всеки WAL файл.
• Ако компресирането е деактивирано и твърдите връзки са разрешени, е възможно да се изведе клъстерът директно от каталога. Това е изключително важно за много TB големи бази данни.
• Възобновяване на неуспешно/прекъснато връщане. Много удобно в случай на ненадеждни мрежи.
• Делта възстановяване:Изключително бързо възстановяване за големи бази данни, без почистване на целия клъстер.
• Асинхронно и паралелно насочване на WAL към резервния сървър. Това е една от най-силните страни на pgbackrest. Архиваторът на PostgreSQL копира само в пулта чрез archive-push и тежката работа по прехвърлянето и обработката се случва в отделен процес на pgbackrest. Това позволява масивни прехвърляния на WAL, като същевременно гарантира ниско време за реакция на PostgreSQL.
• Пренасочване на пространството за таблици
• Поддръжка на Amazon S3
• Поддръжка за максимален размер на опашката за WAL. Когато сайтът за архивиране не работи или мрежата не работи, използването на тази опция ще се подиграва, сякаш архивирането е било успешно, позволявайки на PostgreSQL да изтрие WAL, предотвратявайки запълването на pg_wal, и по този начин да спаси pgsql сървъра от потенциална ПАНИКА.

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

• Наистина би било удобно да има по-„либерална“ опция, що се отнася до запазването, т.е. да се осигури начин за декларативно уточняване на някакъв период на задържане и след това да се остави pgbackrest да се занимава с пълни/diff/incr резервни копия, ако е необходимо.

pg_probackup

Pg_proback е друг обещаващ инструмент за архивиране. Първоначално е базиран на pg_arman. Акцентът му е върху производителността на архивирането. Той се основава на каталози и екземпляри, много подобни на останалите инструменти, така че имаме. Основните му характеристики включват:

• Богата поддръжка на ниво архивиране, варираща от:
  • Пълни архиви
  • Нарастващи от три типа:
    • Резервно копие на PAGE. Промени в нивата, открити чрез WAL сканиране. Изисква пълен достъп до непрекъснатата последователност на WAL след предишното архивиране.
    • Резервно копие на DELTA. Само променените страници се копират в архива. Независимо от WAL архивирането, натоварва сървъра.
    • Резервно копие на PTRACK. Изисква специално коригиране на ядрото на pgsql. Работи чрез поддържане на растерно изображение в движение, веднага щом страниците бъдат променени. Наистина бързо архивиране с минимално натоварване на сървъра.
• Резервните копия могат да бъдат разделени и на:
  • Автономни архиви. Те нямат изисквания за WAL извън архива. Няма PITR.
  • Архивиране на резервни копия. Те разчитат на непрекъснато архивиране и поддържат PITR.
• многонишков модел (за разлика от barman, pgbackrest и разбира се самия PostgreSQL, които следват многопроцесен модел)
• Съгласуваност на данните и проверка при поискване без възстановяване
• Резервно копие от режим на готовност без достъп до основния.
• Изразителна спецификация на политиката за задържане, при която излишъкът може да се използва по начин И заедно с прозорец. Обединяването на резервни копия (чрез сливане) се поддържа чрез преобразуване на предишни инкрементални резервни копия в пълни като начин за освобождаване на място и за осигуряване на метод за плавна ротация на архивиране.

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

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

Можем да обобщим горните параграфи с матрица на характеристиките като по-долу.

ClusterControl

ClusterControl предоставя функционалността или за генериране на незабавно архивиране, или за планиране на такова и автоматизиране на задачата по прост и бърз начин.

Можем да избираме между два метода за архивиране, pgdump (логически) и pg_basebackup (двоичен). Можем също да посочим къде да съхраняваме резервните копия (на сървъра на базата данни, на сървъра на ClusterControl или в облака), нивото на компресия и криптиране.

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