В план за възстановяване при бедствие, вашата цел за точка на възстановяване (RPO) е ключов параметър за възстановяване, който диктува колко данни можете да си позволите да загубите. RPO е посочен във времето, от секунди до дни. Всъщност RPO е пряко зависим от вашата система за архивиране. Той отбелязва възрастта на вашите архивни данни, които трябва да възстановите, за да възобновите нормалните операции.
Ако правите резервно копие през нощта в 22 ч. и вашата система за база данни се срива без поправка в 15:00 часа. на следващия ден губите всичко, което е променено след последното ви архивиране. Вашето RPO в този конкретен контекст е резервно копие от предишния ден, което означава, че можете да си позволите да загубите стойността на промените за един ден.
Диаграмата по-долу от нашата Бяла книга за възстановяване след бедствие илюстрира концепцията.
За по-строго RPO обаче резервното копие може да не е достатъчно. Когато архивирате вашата база данни, вие всъщност правите моментна снимка на данните в даден момент. Така че, когато възстановявате резервно копие, ще пропуснете промените, настъпили между последното архивиране и неуспеха.
Тук идва идеята за възстановяване във времето (PITR).
Какво е PITR?
Възстановяването на точка във времето (PITR), както се казва в името, включва възстановяване на базата данни във всеки един момент в миналото. За да можем да направим това, ще трябва да възстановим резервно копие и след това да приложим всички промени, настъпили след архивирането, до точно преди грешката.
За PostgreSQL промените се съхраняват в регистрационните файлове на WAL (за повече подробности относно WAL и данните, които съхраняват, можете да разгледате този блог).
Така че има две неща, които трябва да гарантираме, за да можем да извършим PITR:архивите и WAL (трябва да настроим непрекъснато архивиране за тях).
За да извършим PITR, ще трябва да възстановим архива и след това да приложим WAL.
Кога може да е полезно?
Можете да използвате тази стратегия винаги, когато възстановявате от проблем, който е причинил повреда на данните. Трябва да имате предвид, че се опитвате да сведете до минимум загубата на данни, но има някои проблеми, които могат да доведат до това, че данните вече не са полезни след това.
Някои примери за това могат да бъдат непланирани модификации на данни (DML или DDL), отказ на носителя или поддръжка на база данни (като надстройки), които водят до повреда на данните. Няма да можете да възстановите промените в данните, настъпили след проблема.
Да предположим, че потребител неправилно е изпълнил DML, което прави данните на цяла таблица погрешно променени или изтрити. Можете да извършите PITR на базата данни на отделно място и след това да експортирате съдържанието на таблицата. След това можете да възстановите тази таблица в съществуващата база данни, като ефективно се върнете към копие на това как е била таблицата преди да се случи проблемът.
Разбира се, не винаги е възможно да възстановите само част от базата данни по този начин, така че в този случай ще трябва да възстановите цялата база данни до дадена точка и ще имате минимална, но неизбежна загуба на данни (ще пропуснете всички промени, настъпили след възникването на проблема).
Как да го използвам с ClusterControl?
В предишен блог можехме да видим как да внедрим PITR ръчно, сега нека да видим как да използваме ClusterControl за изпълнение на тази задача.
Активиране на възстановяване във времето
За да активираме функцията PITR, трябва да активираме WAL архивирането. За това можем да отидем в ClusterControl -> Изберете PostgreSQL Cluster -> Node actions -> Enable WAL Archiving, или просто отидете на ClusterControl -> Изберете PostgreSQL Cluster -> Backup -> Настройки и активирайте опцията „Активиране на възстановяване във времето (WAL архивиране)“, както ще видим на следващото изображение.
Трябва да имаме предвид, че за да активираме WAL архивирането, трябва да рестартираме нашата база данни. ClusterControl може да направи това и за нас.
В допълнение към опциите, общи за всички резервни копия, като „Директория за архивиране“ и „Период на запазване на резервно копие“, тук можем също да посочим периода на запазване на WAL. По подразбиране е 0, което означава завинаги.
За да потвърдим, че имаме активирано WAL архивиране, можем да изберем нашия главен възел в ClusterControl -> Изберете PostgreSQL Cluster -> Nodes и трябва да видим съобщението WAL Archiving Enabled, както можем да видим на следното изображение.
Създаване на резервно копие, съвместимо с възстановяване във времето
Като активираме архивирането на WAL, както видяхме в предишната стъпка, можем да създадем резервно копие, съвместимо с PITR. За това отидете на ClusterControl -> Изберете PostgreSQL Cluster -> Backup -> Create Backup.
Можем да създадем ново архивиране или да конфигурираме планирано. За нашия пример ще създадем единично резервно копие незабавно.
Тук трябва да изберем метода “pg_basebackup”, съвместим с PITR, сървъра, от който ще бъде взето архивирането (за да е съвместимо с PITR, трябва да е главният) и къде искаме да съхраняваме архива. Можем също да качим нашето резервно копие в облака (AWS, Google или Azure), като активираме съответния бутон.
След това указваме използването на компресиране, криптиране и запазване на нашия архив.
В секцията за архивиране можем да видим напредъка на архивирането и информация като метод, размер, местоположение и други.
Възстановяване във времето от резервно копие
След като архивирането приключи, можем да го възстановим с помощта на функцията ClusterControl PITR. За това в нашия раздел за архивиране (ClusterControl -> Изберете PostgreSQL Cluster -> Backup) можем да изберем „Възстановяване на архива“ или директно „Възстановяване“ на архива, който искаме да възстановим.
Тук избираме кой архив искаме да възстановим и от коя директория.
Оставяме избрана опцията „Възстановяване на възел“ и продължаваме.
Сега трябва да изберем къде да възстановим нашия архив и да активираме опцията PITR. Като посочите времето, това ще бъде времето до когато ще се възстановим. Имайте предвид, че се използва часовата зона UTC и че нашата услуга PostgreSQL в главната ще бъде рестартирана.
Можем да наблюдаваме напредъка на нашето възстановяване от секцията Активност в нашия ClusterControl.
Заключение
PITR е необходима функция, за да се отговори на строго RPO. Трябва да го настроим правилно, за да осигурим правилен план за възстановяване при бедствия. ClusterControl предоставя лесен за използване интерфейс, който да ви помогне да внедрите PITR за вашите PostgreSQL бази данни.
