В последните четири публикации от поредицата от блогове разгледахме внедряването на клъстериране/репликация (MySQL/Galera, MySQL репликация, MongoDB и PostgreSQL), управление и наблюдение на вашите съществуващи бази данни и клъстери, наблюдение на производителността и здравето, а в последната публикация, как да направите вашата настройка високо достъпна чрез HAProxy и ProxySQL.
И така, сега, когато базите ви данни работят и работят и са много достъпни, как да гарантирате, че имате резервни копия на вашите данни?
Можете да използвате резервни копия за множество неща:възстановяване при бедствия, за предоставяне на производствени данни за тестване срещу разработка или дори за предоставяне на подчинен възел. Този последен случай вече е обхванат от ClusterControl. Когато добавите нов (реплика) възел към вашата настройка за репликация, ClusterControl ще направи резервно копие/моментна снимка на главния възел и ще го използва за изграждане на репликата. Той може също да използва съществуващо архивиране, за да постави репликата, в случай че искате да избегнете това допълнително натоварване на главния. След като резервното копие бъде извлечено, подготвено и базата данни стартира и работи, ClusterControl автоматично ще настрои репликацията.
Създаване на незабавно архивиране
По същество създаването на резервно копие е същото за Galera, MySQL репликация, PostgreSQL и MongoDB. Можете да намерите секцията за архивиране под ClusterControl> Архивиране и по подразбиране ще видите списък на създадения архив на клъстера (ако има такъв). В противен случай ще видите заместител за създаване на резервно копие:
От тук можете да щракнете върху бутона „Създаване на резервно копие“, за да направите незабавно архивиране или да планирате ново архивиране:
Всички създадени резервни копия също могат да бъдат качени в облака чрез превключване на „Качване на архивиране в облака“, при условие че предоставите работещи облачни идентификационни данни. По подразбиране всички архиви, по-стари от 31 дни, ще бъдат изтрити (конфигурирани чрез настройките за запазване на архивиране) или можете да изберете да ги запазите завинаги или да дефинирате персонализиран период.
„Създаване на архивиране“ и „График на архивиране“ споделят подобни опции, с изключение на частта за планиране и опциите за инкрементално архивиране за последното. Затова ще разгледаме по-задълбочено функцията за създаване на архивиране (известна още като моментално архивиране).
Тъй като всички тези различни бази данни имат различни инструменти за архивиране, очевидно има известна разлика в опциите, които можете да изберете. Например с MySQL можете да избирате между mysqldump и xtrabackup (пълен и инкрементален). За MongoDB ClusterControl поддържа mongodump и mongodb-consistent-backup (бета), докато PostgreSQL, pg_dump и pg_basebackup се поддържат. Ако се съмнявате кой да изберете за MySQL, разгледайте този блог за разликите и случаите на използване на mysqldump и xtrabackup.
Архивиране на MySQL и Galera
Както бе споменато в предишния параграф, можете да правите архиви на MySQL, като използвате mysqldump или xtrabackup (пълни или инкрементални). В съветника „Създаване на архивиране“ можете да изберете на кой хост искате да стартирате архивирането, местоположението, където искате да съхранявате архивните файлове, и неговата директория и конкретни схеми (xtrabackup) или схеми и таблици (mysqldump).
Ако възелът, който архивирате, получава (производствен) трафик и се страхувате, че допълнителните записи на диска ще станат натрапчиви, препоръчително е да изпратите резервните копия до хоста на ClusterControl, като изберете опцията „Съхраняване на контролера“. Това ще накара архивирането да предава поточно файловете през мрежата към хоста на ClusterControl и трябва да се уверите, че има достатъчно място на този възел и портът за стрийминг е отворен на хоста на ClusterControl.
Има и няколко други опции дали искате да използвате компресия и нивото на компресия. Колкото по-високо е нивото на компресия, толкова по-малък ще бъде размерът на архива. Въпреки това, той изисква по-високо използване на процесора за процеса на компресиране и декомпресия.
Ако изберете xtrabackup като метод за архивиране, това ще отвори допълнителни опции:десинхронизиране, блокиране на архивиране, компресия и xtrabackup паралелни нишки/gzip. Опцията за десинхронизиране е приложима само за десинхронизиране на възел от клъстер на Galera. Backup locks използва нов тип MDL заключване за блокиране на актуализации на нетранзакционни таблици и DDL изрази за всички таблици, което е по-ефективно за специфично за InnoDB работно натоварване. Ако работите с Galera Cluster, се препоръчва активиране на тази опция.
След като насрочите незабавно архивиране, можете да следите напредъка на заданието за архивиране в Дейност> Задачи :
След като приключи, трябва да можете да видите новия запис под списъка за архивиране.
Архивиране на PostgreSQL
Подобно на мигновените архиви на MySQL, можете да стартирате архивиране на вашата база данни Postgres. С архивирането на Postgres се поддържат два метода за архивиране - pg_dumpall или pg_basebackup. Обърнете внимание, че ClusterControl винаги ще извършва пълно архивиране, независимо от избрания метод за архивиране.
Разгледахме този аспект в тези подробности в Станете PostgreSQL DBA – Логически и физически резервни копия на PostgreSQL.
Архивиране на MongoDB
За MongoDB ClusterControl поддържа стандартните mongodump и mongodb-consistent-backup, разработени от Percona. Последният все още е в бета версия, която осигурява съвместими с клъстери резервни копия на MongoDB, подходящи за настройки на разчленени клъстери. Тъй като разчлененият клъстер MongoDB се състои от множество набори реплики, конфигурационен набор от реплики и сървъри на сегменти, е много трудно да се направи последователно архивиране, използвайки само mongodump.
Имайте предвид, че в съветника не е нужно да избирате възел на базата данни, за да бъде архивирано. ClusterControl автоматично ще избере най-здравата вторична реплика като резервен възел. В противен случай ще бъде избран основният. Когато архивирането се изпълнява, избраният възел за архивиране ще бъде заключен, докато процесът на архивиране завърши.
Насрочване на архивиране
След като поиграхме със създаването на незабавни архиви, сега можем да разширим това, като планираме архивирането.
Планирането е много лесно за изпълнение:можете да изберете в кои дни да се направи архивирането и в кое време трябва да се изпълнява.
За xtrabackup има допълнителна функция:инкрементални архиви. Инкременталното архивиране ще архивира само данните, които са се променили след последното архивиране. Разбира се, инкременталните архиви са безполезни, ако няма да има пълно архивиране като отправна точка. Между две пълни резервни копия можете да имате толкова инкрементални архиви, колкото искате. Но възстановяването им ще отнеме повече време.
Веднъж насрочени заданията трябва да станат видими в раздела „Насрочено архивиране“ и можете да ги редактирате, като щракнете върху бутона „Редактиране“. Подобно на мигновеното архивиране, тези задачи ще планират създаването на резервно копие и можете да следите напредъка чрез раздела Активност.
Резервен списък
Можете да намерите списъка с архиви под ClusterControl> Backup и това ще ви даде общ преглед на ниво клъстер на всички направени архиви. Щракването върху всеки запис ще разшири реда и ще покаже повече информация за архива:
Всяко архивиране е придружено от архивен дневник, когато ClusterControl изпълни заданието, което е достъпно под бутона „Още действия“.
Архивиране извън сайта в облак
Тъй като вече имаме много резервни копия, съхранявани или на хостовете на базата данни, или на хоста на ClusterControl, ние също искаме да гарантираме, че те няма да се загубят, в случай че се сблъскаме с пълен прекъсване на инфраструктурата. (напр. DC запален или наводнен) Следователно ClusterControl ви позволява да съхранявате или копирате резервните си копия извън сайта в облак. Поддържаните облачни платформи са Amazon S3, Google Cloud Storage и Azure Cloud Storage.
Процесът на качване се случва веднага след успешното създаване на архива (ако превключите „Качване на архивно копие в облака“) или можете ръчно да щракнете върху бутона с иконата на облак в списъка с архивиране:
Изберете идентификационните данни в облака и съответно посочете местоположението за архивиране:
Възстановяване и/или проверка на архивиране
От интерфейса на Backup List можете директно да възстановите резервно копие на хост в клъстера, като щракнете върху бутона „Възстановяване“ за конкретния архив или щракнете върху бутона „Възстановяване на резервно копие“:
Една приятна функция е, че може да възстанови възел или клъстер, използвайки пълните и инкременталните архиви, тъй като ще следи последното направено пълно архивиране и ще започне инкременталното архивиране от там. След това ще групира пълно архивиране заедно с всички инкрементални архиви до следващото пълно архивиране. Това ви позволява да възстановите, като започнете от пълното архивиране и приложите инкременталните архиви върху него.
ClusterControl поддържа възстановяване на съществуващ възел на база данни или възстановяване и проверка на нов самостоятелен хост:
Тези две опции са доста сходни, освен че тази за проверка има допълнителни опции за новата информация за хоста. Ако следвате съветника за възстановяване, ще трябва да посочите нов хост. Ако „Инсталиране на софтуер за база данни“ е активирано, ClusterControl ще премахне всяка съществуваща инсталация на MySQL на целевия хост и ще инсталира отново софтуера на базата данни със същата версия като съществуващия MySQL сървър.
След като резервното копие бъде възстановено и потвърдено, ще получите известие за състоянието на възстановяването и възелът ще бъде изключен автоматично.
Възстановяване в определен момент
За MySQL, както xtrabackup, така и mysqldump могат да се използват за извършване на възстановяване в момента, както и за осигуряване на нов подчинен репликация за репликация главен-подчинен или Galera Cluster. Архивът, съвместим с mysqldump PITR, съдържа един единствен дъмп файл с GTID информация, binlog файл и позиция. По този начин само възелът на базата данни, който произвежда двоичен регистрационен файл, ще има налична опцията "PITR compatible":
Когато опцията за съвместимост с PITR е включена, полетата на базата данни и таблицата са оцветени в сиво, тъй като ClusterControl винаги ще извършва пълно архивиране на всички бази данни, събития, тригери и рутинни програми на целевия MySQL сървър.
Сега се възстановява резервното копие. Ако архивът е съвместим с PITR, ще бъде представена опция за извършване на възстановяване в момента. Ще имате две опции за това - „Въз основа на времето“ и „Въз основа на позицията“. За „Въз основа на времето“ можете просто да минете деня и часа. За „Въз основа на позиция“ можете да предадете точната позиция до мястото, където искате да възстановите. Това е по-точен начин за възстановяване, въпреки че може да се наложи да получите позицията на binlog с помощта на помощната програма mysqlbinlog. Повече подробности за възстановяването в даден момент можете да намерите в този блог.
Резервно шифроване
Универсално ClusterControl поддържа криптиране на резервно копие за MySQL, MongoDB и PostgreSQL. Резервните копия се криптират в състояние на покой с помощта на алгоритъм AES-256 CBC. Автоматично генериран ключ ще се съхранява в конфигурационния файл на клъстера под /etc/cmon.d/cmon_X.cnf (където X е идентификаторът на клъстера):
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='Ако местоназначението за архивиране не е локално, архивните файлове се прехвърлят в криптиран формат. Тази функция допълва резервното копие извън сайта в облак, където нямаме пълен достъп до основната система за съхранение.
Последни мисли
Показахме ви как да архивирате данните си и как да ги съхранявате безопасно извън сайта. Възстановяването винаги е различно нещо. ClusterControl може да възстанови автоматично вашите бази данни от направените в миналото архиви, които се съхраняват на място или са копирани обратно от облака.
Очевидно има повече за защитата на вашите данни, особено от страна на защитата на вашите връзки. Ще разгледаме това в следващата публикация в блога!
