Информацията е един от най-ценните активи в една компания и е от само себе си, че човек трябва да има план за възстановяване при бедствия (DRP), за да предотврати загуба на данни в случай на авария или хардуерна повреда. Резервното копие е най-простата форма на DR. Може да не винаги е достатъчно, за да гарантира приемлива цел за точка на възстановяване (RPO), но е добър първи подход.
Независимо дали става въпрос за 24x7 високо натоварен сървър или среда с нисък обем на транзакции, ще трябва да направите резервни копия безпроблемна процедура, без да нарушавате производителността на сървъра в производствена среда.
Ако говорим за TimescaleDB, има различни видове архивиране за този нов двигател за данни от времеви серии. Типът резервно копие, което трябва да използваме, зависи от много фактори, като среда, инфраструктура, натоварване и т.н.
В този блог ще видим тези различни видове резервни копия, които са налични, и как ClusterControl може да ни помогне да централизираме управлението на архивирането за TimescaleDB.
Резервни типове
Има различни видове архиви за бази данни. Нека разгледаме всеки от тях подробно.
- Логически:Архивът се съхранява в четим от човека формат като SQL.
- Физически:Архивът съдържа двоични данни.
- Пълно/инкрементално/диференциално:Дефиницията на тези три типа архиви е имплицитна в името. Пълното архивиране е пълно копие на всички ваши данни. Инкременталното архивиране архивира само данните, които са се променили след предишното архивиране, а диференциалното архивиране съдържа само данните, които са се променили от последното изпълнено пълно архивиране. Инкременталното и диференциалното архивиране бяха въведени като начин за намаляване на времето и използването на дисково пространство, необходими за извършване на пълно архивиране.
- Съвместимост с възстановяване във времето:PITR Включва възстановяване на базата данни във всеки даден момент в миналото. За да можем да направим това, ще трябва да възстановим пълно архивно копие и след това да приложим всички промени, които са се случили след архивирането, до точно преди грешката.
Функция за управление на архивиране на ClusterControl
Нека видим как ClusterControl може да ни помогне да управляваме различни видове архиви.
Създаване на резервно копие
За тази задача отидете на ClusterControl -> Изберете TimescaleDB Cluster -> Архивиране -> Създаване на архив .
Можем да създадем ново архивиране или да конфигурираме планирано. За нашия пример ще създадем единично резервно копие незабавно.
Тук имаме един метод за всеки тип архивиране, който споменахме по-рано.
Резервно копие | Инструмент | Определение |
---|---|---|
Логически | pg_dumpall | Това е помощна програма за изписване на всички TimescaleDB бази данни на клъстер в един скриптов файл. Файлът на скрипта съдържа SQL команди, които могат да се използват за възстановяване на базите данни. |
Физически | pg_basebackup | Използва се за създаване на двоично копие на клъстерните файлове на базата данни, като същевременно се уверява, че системата автоматично се включва и излиза от режим на архивиране. Винаги се правят резервни копия на целия клъстер от база данни на работещ клъстер на база данни TimescaleDB. Те се вземат, без да се засягат други клиенти в базата данни. |
Пълен/Incr/Diff | pgbackrest | Това е просто, надеждно решение за архивиране и възстановяване, което може безпроблемно да се разшири до най-големите бази данни и работни натоварвания, като използва алгоритми, оптимизирани за специфичните за базата данни изисквания. Една от най-важните функции е поддръжката за пълно, инкрементално и диференциално архивиране. |
PITR | pg_basebackup+WALs | За да създаде съвместимо с PITR архивиране, ClusterControl ще използва pg_basebackup и WAL файловете, за да може да възстанови базата данни във всеки един момент в миналото. |
Трябва да изберем един метод, сървъра, от който ще бъде взето архивирането и къде искаме да съхраняваме архива. Можем също да качим нашето резервно копие в облака (AWS, Google или Azure), като активираме съответния бутон.
Имайте предвид, че ако искате да създадете резервно копие, съвместимо с PITR, трябва да използваме pg_basebackup в тази стъпка и трябва да вземем архива от главния възел.
След това указваме използването на компресиране, криптиране и запазване на нашия архив.
В секцията за архивиране можем да видим напредъка на архивирането и информация като метод, размер, местоположение и други.
Активиране на възстановяване във времето
Ако искаме да използваме функцията PITR, трябва да активираме WAL архивирането. За това можем да отидем на ClusterControl -> Изберете TimescaleDB Cluster -> Действия на възел -> Активиране на WAL архивиране , или просто отидете на ClusterControl -> Изберете TimescaleDB Cluster -> Архивиране -> Настройки и активирайте опцията „Активиране на възстановяване по време (WAL архивиране) ” както ще видим на следващото изображение.
Трябва да имаме предвид, че за да активираме WAL архивирането, трябва да рестартираме нашата база данни. ClusterControl може да направи това и за нас.
В допълнение към опциите, общи за всички архиви, като „Резервна директория ” и „Период на запазване на резервно копие “, тук можем също да посочим Периода на задържане на WAL. По подразбиране е 0, което означава завинаги.
За да потвърдим, че имаме активирано WAL архивиране, можем да изберем нашия главен възел в ClusterControl -> Изберете TimescaleDB Cluster -> Nodes , и трябва да видим съобщението за активирано архивиране на WAL, както можем да видим на следното изображение.
Възстановяване на резервно копие
След като архивирането приключи, можем да го възстановим с помощта на ClusterControl. За това в нашия раздел за архивиране (ClusterControl -> Изберете TimescaleDB Cluster -> Backup ), можем да изберем „Възстановяване на архива“ или директно „Възстановяване“ на архива, който искаме да възстановим.
Имаме три опции за възстановяване на архива. Можем да възстановим архива в съществуващ възел на базата данни, да възстановим и потвърдим архива на самостоятелен хост или да създадем нов клъстер от архива.
Ако се опитваме да възстановим резервно копие, съвместимо с PITR, също трябва да посочим часа.
Данните ще бъдат възстановени както са били в посочения момент. Имайте предвид, че се използва часовата зона UTC и че нашата услуга TimescaleDB в главната ще бъде рестартирана.
Можем да наблюдаваме напредъка на нашето възстановяване от секцията Активност в нашия ClusterControl.
Автоматично потвърждаване на архивиране
Архивът не е резервно копие, ако не може да се възстанови. Проверката на архивиране е нещо, което обикновено се пренебрегва от мнозина. Нека видим как ClusterControl може да автоматизира проверката на резервните копия на TimescaleDB и да помогне за избягване на всякакви изненади.
В ClusterControl изберете своя клъстер и отидете на „Резервно копие ", след което изберете "Създаване на архивиране “.
Функцията за автоматично потвърждаване на архивиране е налична за планираните архиви. И така, нека изберем „График за архивиране ” опция.
Когато планираме архивиране, в допълнение към избора на общи опции като метод или съхранение, ние също трябва да посочим график/честота.
В следващата стъпка можем да компресираме и криптираме нашия архив и да посочим периода на запазване. Тук също имаме „Проверка на архивиране ” функция.
За да използваме тази функция, се нуждаем от специален хост (или VM), който не е част от клъстера.
ClusterControl ще инсталира софтуера и ще възстанови архива в този хост. След възстановяване можем да видим иконата за проверка в секцията за архивиране на ClusterControl.
Заключение
В днешно време архивирането е задължително във всяка среда. Те ви помагат да защитите вашите данни. Постепенното архивиране може да помогне за намаляване на времето и пространството за съхранение, използвани за процеса на архивиране. Регистраторите на транзакциите са важни за възстановяване във време. ClusterControl може да помогне за автоматизиране на процеса на архивиране на вашите бази данни TimescaleDB и, в случай на неуспех, да го възстановите с няколко щраквания. Освен това можете да сведете до минимум RPO, като използвате съвместимото с PITR архивиране и да подобрите своя план за възстановяване при бедствия.