Резервните копия са много важна част от операциите на вашата база данни, тъй като вашият бизнес трябва да бъде защитен, когато настъпи катастрофа. Когато дойде това време (и ще стане), вашата цел за точка на възстановяване (RPO) и цел за време за възстановяване (RTO) трябва да бъдат предварително определени, тъй като това е колко бързо можете да се възстановите от възникналия инцидент.
Повечето организации променят подхода си към архивирането, опитвайки се да имат комбинация от резервни копия на изображения на сървъра (моментни снимки), логически и физически архиви. След това тези резервни копия се съхраняват на множество места, за да се избегнат местни или регионални бедствия. Това също така означава, че данните могат да бъдат възстановени за най-кратък период от време, като се избягват големи прекъсвания, които могат да повлияят на бизнеса на вашата компания.
Хостирането на вашата база данни с доставчик на облак, като например Microsoft Azure (който ще обсъдим в този блог), не е изключение, все пак трябва да подготвите и дефинирате правилата си за възстановяване след бедствие.
Подобно на други публични облачни предложения, Microsoft Azure (Azure) предлага подход за архивиране, който е практичен, рентабилен и проектиран да ви предостави опции за възстановяване. Решенията за архивиране на Microsoft Azure ви позволяват да конфигурирате и работите и лесно се обработват с помощта на тяхното Azure Backup или чрез Restore Services Vault (ако управлявате базата си данни с помощта на виртуални машини).
Ако искате управлявана база данни в облака, Azure предлага база данни Azure за MySQL. Това трябва да се използва само ако не искате сами да управлявате и управлявате базата данни MySQL. Тази услуга предлага богато решение за архивиране, което ви позволява да създадете резервно копие на вашата база данни, или от локален регион, или чрез гео-излишно местоположение. Това може да бъде полезно за възстановяване на данни. Може дори да успеете да възстановите възел от определен период от време, което е полезно за постигане на възстановяване в момента. Това може да стане само с едно щракване.
В този блог ще разгледаме всички тези сценарии за архивиране и възстановяване с помощта на MySQL база данни в облака на Microsoft Azure.
Извършване на архивиране на виртуална машина в Azure
За съжаление, Microsoft Azure не предлага решение за тип резервно копие, специфично за MySQL (напр. MySQL Enterprise Backup, Percona XtraBackup или Mariabackup на MariaDB).
При създаването на вашата виртуална машина (с помощта на портала) можете да настроите процес за архивиране на вашата виртуална машина с помощта на хранилището на услугите за възстановяване. Това ще ви предпази от всякакви инциденти, бедствия или катастрофи, а съхраняваните данни са криптирани по подразбиране. Добавянето на криптиране не е задължително и, въпреки че се препоръчва от Azure, то идва с цена. Можете да разгледате тяхната страница с цени на Azure Backup за повече подробности.
За да създадете и настроите резервно копие, отидете в левия панел и щракнете върху Всички ресурси → Изчисляване → Виртуална машина. Сега задайте необходимите параметри в текстовите полета. След като сте на тази страница, отидете на раздела Управление и превъртете надолу. Ще можете да видите как можете да настроите или създадете резервното копие. Вижте екранната снимка по-долу:
След това настройте правилата си за архивиране въз основа на вашите изисквания за архивиране. Просто натиснете връзката Създаване на нова в текстовото поле на правилата за архивиране, за да създадете нова политика. Вижте по-долу:
Можете да конфигурирате правилата си за архивиране със запазване по седмица, месечно и годишно .
След като конфигурирате резервното си копие, можете да проверите дали имате активирано архивиране на тази конкретна виртуална машина, която току-що създадохте. Вижте екранната снимка по-долу:
Възстановете и възстановете вашата виртуална машина в Azure
Проектирането на вашето възстановяване в Azure зависи от това какви правила и изисквания изисква вашето приложение. Също така зависи от това дали RTO и RPO трябва да са ниски или невидими за потребителя в случай на инцидент или по време на поддръжка. Можете да настроите вашата виртуална машина с набор за наличност или в друга зона за наличност, за да постигнете по-висок процент на възстановяване.
Можете също да настроите възстановяване при бедствие за вашата виртуална машина, за да репликирате вашите виртуални машини в друг регион на Azure за непрекъснатост на бизнеса и нужди за възстановяване след бедствие. Това обаче може да не е добра идея за вашата организация, тъй като идва с висока цена. Ако е на място, Azure ви предлага опция за възстановяване или създаване на виртуална машина от създаденото резервно копие.
Например, по време на създаването на вашата виртуална машина, можете да отидете в раздела Дискове, след това да отидете на Дискове с данни. Можете да създадете или прикачите съществуващ диск, където можете да прикачите моментната снимка, която имате. Вижте екранната снимка по-долу, за която ще можете да избирате от моментна снимка или блоб за съхранение:
Можете също да възстановите в определен момент от време, точно както е на екранната снимка по-долу:
Възстановяването в Azure може да се извърши по различни начини, но се използва един и същ ресурси, които вече сте създали.
Например, ако сте създали моментна снимка или дисково изображение, съхранено в BLOB-а на Azure Storage, ако създадете нова виртуална машина, можете да използвате този ресурс, стига да е съвместим и достъпен за използване. Освен това може дори да успеете да възстановите някои файлове, освен да възстановите VM, точно както е на екранната снимка по-долу:
По време на възстановяване на файлове може да сте в състояние да избирате от конкретна точка за възстановяване , както и да изтеглите скрипт за разглеждане и възстановяване на файлове. Това е много полезно, когато имате нужда само от конкретен файл, но не и от цялата система или дисков обем.
Възстановяването от резервно копие на съществуваща виртуална машина отнема около три минути. Въпреки това, възстановяването от архивиране до създаване на нова виртуална машина отнема дванадесет минути. Това обаче може да зависи от размера на вашата VM и мрежовата честотна лента, налична в Azure. Хубавото е, че при възстановяване ще ви предостави подробности за това какво е завършено и колко време остава. Например, вижте екранната снимка по-долу:
Архивни копия за база данни Azure за MySQL
Azure Database за MySQL е напълно управлявана услуга за бази данни от Microsoft Azure. Тази услуга предлага много гъвкав и удобен начин за настройка на вашите възможности за архивиране и възстановяване.
След създаването на вашия екземпляр на MySQL сървър, можете да настроите запазването на архивиране и да създадете опциите си за резервно копие; или локално излишен (локален регион) или гео-излишен (в различен регион). Azure ще ви предостави приблизителните разходи, които ще бъдете таксувани за един месец. Вижте примерна екранна снимка по-долу:
Имайте предвид, че гео-излишните опции за архивиране са налични само за общо предназначение и оптимизирани за паметта типове изчислителни възли. Не е налично на базов изчислителен възел, но можете да имате резервирането си в локалния регион (т.е. в рамките на наличните зони за наличност).
След като имате главна настройка, е лесно да създадете реплика, като отидете на Azure Database за MySQL сървъри → Изберете вашия MyQL екземпляр → Репликация → и щракнете върху Добавяне на реплика. Вашата реплика може да се използва като източник или цел за възстановяване, когато е необходимо.
Имайте предвид, че в Azure, когато спрете репликацията между главния и реплика, това ще бъде завинаги и необратимо, тъй като прави репликата самостоятелен сървър. Реплика, създадена с помощта на Microsoft Azure, е в идеалния случай управляван екземпляр и можете да спрете и стартирате нишките за репликация точно както правите при нормална репликация главен-подчинен. Можете да рестартирате и това е всичко. Ако сте създали репликата ръчно, чрез възстановяване или от главен, или от резервно копие (например чрез възстановяване в даден момент), тогава ще можете да спрете/стартирате нишките за репликация или да настроите забавяне на подчинения, ако е необходимо.
Възстановяване на вашата база данни Azure за MySQL от резервно копие
Възстановяването е много лесно и бързо с помощта на портала Azure. Можете просто да натиснете бутона за възстановяване с вашия възел на MySQL екземпляр и просто да следвате потребителския интерфейс, както е показано на екранната снимка по-долу:
След това можете да изберете период от време и да създадете/създадете нов екземпляр въз основа на това резервно копие, заснето:
След като имате наличен възел, този възел няма да бъде реплика на майсторът все още. Трябва ръчно да настроите това с лесни стъпки, като използвате наличните им съхранени процедури:
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');къде,
master_host:име на хост на главния сървър
master_user:потребителско име за главния сървър
master_password:парола за главния сървър
master_log_file:име на двоичен регистрационен файл от стартиране show master status
master_log_pos:позиция на двоичен регистрационен файл от стартиране показване на главен статус
master_ssl_ca:Контекст на CA сертификата. Ако не използвате SSL, предайте празен низ.
След това стартирането на MySQL нишките е както следва,
CALL mysql.az_replication_start;или можете да спрете нишките за репликация, както следва,
CALL mysql.az_replication_stop;или можете да премахнете главния като,
CALL mysql.az_replication_remove_master;или пропуснете грешките в SQL нишката като,
CALL mysql.az_replication_skip_counter;Както споменахме по-рано, когато се създава реплика с помощта на Microsoft Azure под функцията Добавяне на реплика под MySQL екземпляр, тези специфични съхранени процедури не са налични. Въпреки това, процедурата mysql.az_replication_restart ще бъде налична, тъй като нямате право да спирате, нито да стартирате нишките за репликация на управлявана реплика от Azure. Така че примерът, който имаме по-горе, беше възстановен от главен, който взема пълното копие на главния, но действа като един възел и се нуждае от ръчна настройка, за да бъде реплика на съществуващ главен.
Освен това, когато имате ръчна реплика, която сте настроили, няма да можете да видите това под Azure Database за MySQL сървъри → Изберете вашия MyQL екземпляр → Репликация, тъй като сте създали или настройте репликацията ръчно .
Алтернативни решения в облак и архивиране за възстановяване
Има определени сценарии, при които искате да имате пълен достъп, когато правите пълно архивиране на вашата MySQL база данни в облака. За да направите това, можете да създадете свой собствен скрипт или да използвате технологии с отворен код. С тях можете да контролирате как данните във вашата MySQL база данни трябва да бъдат архивирани и как точно да се съхраняват.
Можете също да използвате интерфейса на командния ред на Azure (CLI), за да създадете своя персонализирана автоматизация. Например, можете да създадете моментна снимка, като използвате следната команда с Azure CLI:
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupили създайте своя MySQL сървър реплика със следната команда:
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupОсвен това можете да използвате и корпоративен инструмент, който включва начини да направите резервно копие с опции за възстановяване. Използването на технологии с отворен код или инструменти на трети страни изисква знания и умения за използване и създаване на собствена реализация. Ето списъка, който можете да използвате:
- ClusterControl - Въпреки че може да сме малко предубедени, ClusterControl предлага възможността да управлявате физически и логически архиви на вашата MySQL база данни, използвайки тествани в битка технологии с отворен код (PXB, Mariabackup и mydumper). Поддържа бази данни MySQL, Percona, MariaDB, Galera. Можете лесно да създадете нашата политика за архивиране и да съхранявате резервни копия на вашите бази данни във всеки облак (AWS, GCP или Azure) Моля, имайте предвид, че безплатната версия на ClusterControl не включва функциите за архивиране.
- LVM моментни снимки - Можете да използвате LVM, за да направите моментна снимка на вашия логически обем. Това е приложимо само за вашата VM, тъй като изисква достъп до хранилище на ниво блок. Използването на този инструмент изисква предупреждение, тъй като може да доведе до спиране на възела на базата данни, докато архивирането се изпълнява.
- Percona XtraBackup (PXB) - Технология с отворен код от Percona. С PXB можете да създадете физическо резервно копие на вашата MySQL база данни. Можете също да направите горещо архивиране с PXB за InnoDB хранилище, но се препоръчва да го стартирате на подчинен или незает MySQL db сървър. Това е приложимо само за вашия екземпляр на VM, тъй като изисква бинарен или файлов достъп до самия сървър на база данни.
- Mariabackup - Същото и с PXB, това е технология с отворен код, разклонена от PXB, но се поддържа от MariaDB. По-конкретно, ако вашата база данни използва MariaDB, трябва да използвате Mariabackup, за да избегнете проблеми с несъвместимостта с пространствата за таблици.
- mydumper/myloader - Тези инструменти за архивиране създават логически архивни копия на вашата MySQL база данни. Можете да използвате това с вашата база данни Azure за MySQL, въпреки че не съм пробвал колко успешно е това за вашата процедура за архивиране и възстановяване.
- mysqldump - това е логически инструмент за архивиране, който е много полезен, когато трябва да архивирате и изхвърлите (или възстановите) конкретна таблица или база данни в друг екземпляр. Това обикновено се използва от DBA, но трябва да обърнете внимание на дисковото пространство, тъй като логическите архивни копия са огромни в сравнение с физическите архиви.
- Архивиране на MySQL Enterprise - Доставя горещи, онлайн, неблокиращи архиви на множество платформи, включително Linux, Windows, Mac и Solaris. Това не е безплатен инструмент за архивиране, но предлага много функции.
- rsync - Това е бърз и изключително гъвкав инструмент за копиране на файлове. Може да копира локално, към/от друг хост през всяка отдалечена обвивка или към/от отдалечен rsync демон. Той предлага голям брой опции, които контролират всеки аспект от неговото поведение и позволяват много гъвкава спецификация на набора от файлове, които да бъдат копирани. Най-вече в Linux системи, rsync се инсталира като част от пакета на ОС.
