Бедствието обикновено причинява прекъсване, което означава прекъсване на системата и потенциална загуба на данни. След като открием прекъсването, ние задействаме нашия план за DR за възстановяване от него. Но би било изненада, ако няма резервно копие или след дълги часове на възстановяване, ще видите, че не е този, от който се нуждаете.
Въпреки че прекъсванията могат да бъдат скъпи - често има финансово въздействие , което може да бъде вредно за бизнеса и загубата на данни може да е причина за затваряне на компанията.
За да сведем до минимум загубата на данни, трябва да имаме множество копия на данни на различни места. Можем да проектираме нашата инфраструктура в различни слоеве и да абстрахираме всеки слой от този под него. Например, ние изграждаме слой за клъстери от екземпляри на база данни, за да се предпазим от хардуерна повреда. Ние репликираме бази данни в центрове за данни, за да можем да се защитим срещу повреда в центъра за данни. Всеки допълнителен слой добавя сложност, което може да се превърне в кошмар за управление. Но все пак, по същество, резервното копие ще заеме централното място в възстановяването след бедствие.
Ето защо е изключително важно да сме сигурни, че това е нещо, на което можем да разчитаме. Но как да се постигне това? Е, една от опциите е да проверите дали резервните копия са били изпълнени въз основа на последните няколко реда скрипт за архивиране.
Прост пример:
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fiНо какво ще стане, ако скриптът за архивиране изобщо не стартира? Google предлага доста резултати от търсенето за „Linux cron, не работи“.
За съжаление, базите данни с отворен код често не предлагат архивно хранилище.
Друго тестване на резервно копие. Може да сте чували за котката на Шрьодингер. Известна теория за архивиране на Шрьодингер е . „Състоянието на каквото и да е архивиране е неизвестно, докато не се направи опит за възстановяване.“ Звучи като прост подход, но такъв опит би означавал, че трябва да настроите тестова среда, да копирате файлове, да стартирате възстановяване... след всяко архивиране.
В тази статия ще видим как можете да използвате ClusterControl, за да се уверите, че вашето архивиране се изпълнява , за да постигнете бази данни Enterprise-Grade с бази данни с отворен код.
Резервни отчети
ClusterControl е насочен към оперативни отчети. Оперативното отчитане осигурява подкрепа за ежедневния мониторинг и контрол на дейността на предприятието. Докладът за архивиране е един от многото. Можете да намерите отчети като:
- Ежедневен системен отчет
- Отчет за надграждане на пакета
- Отчет за промяна на схемата
- Наличност
- Резервно копие
Но защо ще имате нужда от това?
Може вече да имате отличен инструмент за наблюдение с всички възможни показатели/графики и вероятно също сте настроили сигнали въз основа на показатели и прагове (някои дори ще имат автоматизирани съветници, които им предоставят препоръки или автоматично коригират нещата.) Това е добре - да имате видимост във вашата система. системата е важна; въпреки това трябва да можете да обработвате много информация.
Как работи това? ClusterControl събира информация за процеса на архивиране, системите, платформите и устройствата в инфраструктурата за архивиране, когато заданието за архивиране се задейства. Цялата тази информация се обобщава и съхранява в CMON (вътрешна база данни), така че няма нужда да се правят допълнителни заявки за конкретни бази данни. Освен това, когато установи, че имате работещ клъстер, но не е имало резервно копие, той също ще бъде докладван.
В подробностите за отчета можете да проследявате резервен идентификатор с подробни данни за местоположението, размера, времето и метода на архивиране. Шаблоните работят с данни за различни типове бази данни, така че когато управлявате вашата смесена среда, ще получите същото усещане и вид. Помага за по-добро управление на различни архиви на база данни.
CLI отчети
За тези, които предпочитат интерфейса на командния ред, добър вариант за проследяване на архиви ClusterControl Command Line Interface (CLI).
CLI ви позволява да изпълнявате повечето от функциите, налични в ClusterControl, като използвате прости команди. Изпълнението на архивиране и отчетите за архивиране са едни от тях.
Използван във връзка с мощния GUI, той дава на потребителите на ClusterControl алтернативни начини за управление на техните среди с отворен код на база данни, използвайки какъвто двигател предпочитат.
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gzЗапочвайки от версия 1.4.1, скриптът за инсталиране автоматично ще инсталира този пакет на възела ClusterControl. CLI е част от пакета s9s-tools. Можете също да го инсталирате отделно на друга машина, за да управлявате дистанционно клъстера на базата данни. Подобно на ClusterControl, той използва защитена SSH комуникация.
Автоматично потвърждаване на архивиране
Архивът не е резервно копие, ако не можем да извлечем данните. Проверката на архивиране е нещо, което обикновено се пренебрегва от много компании. Нека видим как ClusterControl може да автоматизира проверката на резервни копия и да помогне за избягване на всякакви изненади.
В ClusterControl изберете своя клъстер и отидете в секцията „Резервно копие“, след което изберете „Създаване на резервно копие“.
Функцията за автоматично потвърждаване на архивирането е налична за планираните резервни копия, така че нека изберем опцията „График за архивиране“.
Когато планираме архивиране, в допълнение към избора на общи опции като метод или съхранение, ние също трябва да посочим график/честота. В този пример ще настроим проверка на архивиране на MySQL. Същото обаче може да се постигне за PostgreSQL и Timescale бази данни.
Когато проверката на резервното копие е проверена, ще се появи друг раздел.
Тук можем да зададем всички необходими стъпки за подготовка на средата. Когато се предостави IP, можем да отидем и да планираме такова архивиране. Всеки път, когато архивирането приключи, то ще бъде копирано във временна среда за проверка на архивиране (опция „възстановяване на архивиране при“). След успешно опресняване ще видите състоянието на проверката в раздела на архивното хранилище.
Неуспешно архивиране и услуги за интеграция
Друга интересна опция за получаване на повече улики относно изпълнението на архивиране е да използвате услугите за интеграция на ClusterControl. Можете да контролирате състоянието на изпълнение на архивиране с услуги на трети страни.
Интегрирането на инструменти на трети страни ви позволява да автоматизирате сигналите с други популярни системи. Понастоящем ClusterControl поддържа ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram и Webhooks.
По-долу можем да видим пример за интеграция на Slack канал. Всеки път, когато възникне събитие за архивиране, то ще се появи в канала на слабия канал.
Заключение
Архивирането е задължително във всяка среда. Те ви помагат да защитите вашите данни и са в центъра на всеки сценарий за възстановяване при бедствие. ClusterControl може да помогне за автоматизирането на процеса на архивиране на вашите бази данни и, в случай на неуспех, да го възстановите с няколко щраквания. Освен това можете да сте сигурни, че те се изпълняват успешно и надеждни, така че в случай на бедствие няма да загубите данните си.
