Как да планирате архивиране на база данни с ClusterControl

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

В тази публикация в блога ще разгледаме как можете да планирате архивирането на вашата база данни с ClusterControl.

Архивиране на база данни с помощта на ClusterControl

ClusterControl поддържа редица методи за архивиране в зависимост от типа на клъстера, както е обобщено в следната таблица:

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

• Намаляване на IOPS на диска
• Намаляване на мрежата
• Резервни ключалки
• Шифроване
• Компресия
• Срок на задържане
• Проверка

ClusterControl автоматично ще зададе редица опции за архивиране, следвайки най-добрата практика от конкретния доставчик на база данни. Например, ако целевият възел на базата данни има активиран двоичен дневник, той ще добави допълнителен флаг, --master-data за да включите координатите на двоичния регистър (име на файла и позиция) на изхвърления сървър. Ако това е възел на Galera и методът за архивиране е xtrabackup, ClusterControl ще добави допълнителен флаг, --galera-info който съдържа състоянието на локалния възел в момента на архивирането.

Планиране на архивиране

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

• Какъв метод за архивиране искате да използвате? Някои методи за архивиране не са блокиращи, но са много ресурсоемки. Разберете компромисите, за да не се изненадате как процесът се държи в производството.
• Колко често искате да архивирате вашите бази данни? Изпълнението на пълно архивиране може да е болезнено, ако интервалът за архивиране е твърде кратък. Вероятно се нуждаете от комбинация от пълно и постепенно архивиране.
• Колко бързо искате да възстановите данните си? Физическото архивиране обикновено е много по-бързо от логическото архивиране по отношение на времето за пълно възстановяване. От друга страна, логическото архивиране обикновено е по-бързо за частично възстановяване.
• Колко голям е размерът на вашите данни? В някои случаи логическото архивиране не е добър избор за огромни бази данни, а двоичното архивиране е единственият начин.
• Колко свободно място имате, за да съхранявате резервното си копие? Резервните копия обикновено изяждат много място. Решете дали е необходима компресия и нивото на компресия, което можете да си позволите. По-добрата компресия изисква по-високо използване на процесора.
• Ами ако сървърът за архивиране не работи по време на времето за архивиране? Трябва ли да прехвърли резервното копие към друг наличен хост? Пропускането на архивиране поради прозорец за поддръжка обикновено не е добра идея.
• Как да гарантираме целостта на създадения архив? Не забравяйте, че резервното копие не е резервно копие, ако не може да се възстанови.
• Доверявате ли се на архивното хранилище? Шифроването може да е добра идея за защита на вашите данни.

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

Разгледахме тази глава подробно в нашия бял документ, Ръководството за DevOps за архивиране на бази данни за MySQL и MariaDB.

Насрочване на резервно копие
 

С ClusterControl планирането е доста лесно. Отидете направо в Архивиране -> Създаване на архивиране -> Планиране на архивиране и ще ви бъде представен следния диалогов прозорец:

В зависимост от типа на клъстера, опциите може да са различни, както е показано на следните екранни снимки за PostgreSQL и MongoDB:

Повечето от опциите се обясняват сами и са разгледани подробно в Ръководството за потребителя. След като графикът е създаден, можете да редактирате резервните копия на конфигурацията, да активирате/деактивирате архивирането или да изтриете графика в раздела „Насрочени архиви“:

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

Можете да наблюдавате напредъка на архивиране, като погледнете Активност -> Работни места, след като му дойде времето. Ако заданието за архивиране е неуспешно, веднага ще видите грешката:

Горният регистър е достъпен и в раздела Архивиране на всеки запис за архивиране:

Проверки и потвърждаване след архивиране

След като работата по архивиране приключи, това не означава, че отговорността ви е приключила. Има няколко неща, които трябва да бъдат проследени. Най-важното е състоянието на създадения архив. ClusterControl предоставя известия по имейл и ще ви уведоми за състоянието. Тази услуга за уведомяване, разбира се, може да се конфигурира въз основа на сериозността в Настройки -> Общи настройки -> Настройки за известия по имейл -> Архивиране:

Доставяне означава, че ClusterControl ще изпрати известие по имейл веднага след повдигане на аларма за този компонент. Можете също да го конфигурирате като Ignore или Digest, където ClusterControl изпраща ежедневно обобщение на повдигнатите аларми.

Ако резервното копие е създадено успешно, силно се препоръчва да проверите дали архивът е възстановим. Можете да използвате функцията за проверка на архивиране, като щракнете върху бутона „Възстановяване“ на избрания резервен идентификатор и ще ви бъдат представени две опции за възстановяване:

„Възстановяване и проверка на самостоятелен хост“ изисква отделен хост, който все още не е част от настройката на базата данни. ClusterControl първо ще разположи MySQL екземпляр на целевия хост, ще стартира услугата, ще копира архива от архивното хранилище и ще започне възстановяването. След като приключите, можете да имате опция или да изключите сървъра, след като бъде възстановен, или да го оставите да работи, за да можете да извършите допълнително разследване на сървъра.

Поддържането на домакинството също е важно, за да запазите само полезните архиви във вашето хранилище. По този начин конфигурирайте запазването на архива, ако е необходимо. По подразбиране ClusterControl изчиства архиви, които са по-стари от 30 дни. Можете също да персонализирате всеки от графиците за архивиране с различни периоди на съхранение.

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

Към момента на писане се поддържат AWS S3 и GCP Cloud Storage. Идентификационните данни в облака трябва да бъдат предварително конфигурирани в страничното меню -> Интеграции -> Доставчици на облак.

Това е, хора. Приятно групиране!