В основата на ClusterControl е неговата автоматизация, както и гарантирането, че вашите данни са сигурно архивирани и готови за възстановяване, когато нещо се обърка. Наличието на ефективна стратегия за архивиране и план за възстановяване при бедствия е ключът към успеха на всяко приложение или среда.
В последната ни версия, ClusterControl 1.5, въведохме редица подобрения за архивиране на MySQL и базирани на MariaDB системи.
Едно от ключовите подобрения е възможността за архивиране от ClusterControl към доставчик на облак по ваш избор. Доставчиците на облачни услуги като Google Cloud Services и Amazon S3 предлагат практически неограничено съхранение, намалявайки нуждите от локално пространство. Това ви позволява да запазите архивните си файлове по-дълго, толкова дълго, колкото искате, и да нямате притеснения относно локалното дисково пространство.
Нека разгледаме всички вълнуващи нови функции за архивиране за ClusterControl 1.5...
Преработване на съветника за архивиране/възстановяване
На първо място, ще забележите, че съветниците за архивиране и възстановяване са преработени, за да подобрят по-добре потребителското изживяване. Сега ще се зареди като странично меню вдясно на екрана:
Списъкът с архиви също получава незначителна настройка, където подробностите за архивирането се показват, когато щракнете върху конкретното архивиране:
Ще можете да видите местоположението на архива и кои бази данни са вътре в архива. Има и опции за възстановяване на архива или качването му в облака.
Резервно копие, съвместимо с PITR
ClusterControl изпълнява стандартното архивиране на mysqldump с отделни изхвърляния на схеми и данни. Това улеснява възстановяването на частични архиви. Въпреки това, той нарушава последователността на архивирането (схемата и данните се изхвърлят в две отделни сесии), поради което не може да се използва за предоставяне на подчинено или възстановяване в момента.
Архивът, съвместим с mysqldump PITR, съдържа един единствен дъмп файл с GTID информация, binlog файл и позиция. По този начин само възелът на базата данни, който произвежда двоичен дневник, ще има налична опцията „съвместим с PITR“, както е подчертано на екранната снимка по-долу:
Когато опцията за съвместимост с PITR е превключена, полетата на базата данни и таблицата са оцветени в сиво, тъй като ClusterControl винаги ще извършва архивиране спрямо всички бази данни, събития, тригери и рутинни програми на целевия MySQL сървър.
Следните редове ще се появят в първите ~50 реда на завършения дъмп файл:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...Информацията може да се използва за изграждане на подчинени устройства от архивиране или извършване на възстановяване в момента заедно с двоични регистрационни файлове, където можете да стартирате възстановяването от MASTER_LOG_FILE и MASTER_LOG_POS, отчетени в дъмп файла, като използвате помощната програма "mysqlbinlog". Имайте предвид, че двоичните регистрационни файлове не се архивират от ClusterControl.
Създаване на подчинени устройства от резервно копие Друга функция е възможността да се изгражда подчинен директно от PITR-съвместимо архивно копие, вместо да се прави от избран главен. Това е огромно предимство, тъй като разтоварва главния сървър. Тази опция може да се използва с MySQL репликация или Galera Cluster. Съществуващо резервно копие може да се използва за възстановяване на съществуващо подчинено устройство за репликация или за добавяне на ново подчинено на репликация по време на фазата на етапа, както е показано на следната екранна снимка:
След като етапът приключи, подчинения ще се свърже с избрания главен и ще започне да наваксва. Преди това ClusterControl изпълняваше поточно архивиране директно от избрания главен файл, използвайки Percona Xtrabackup. Това може да повлияе на производителността на главния елемент при мащабиране на голям набор от данни, въпреки че операцията не е блокирана на главния. С новата опция, ако архивът се съхранява в ClusterControl, само тези хостове (ClusterControl + подчинения) ще бъдат заети при поставяне на данните на подчинения.
Архивиране в облак
Архивите вече могат да се качват автоматично в облака. Това изисква инсталиране на модул ClusterControl, наречен clustercontrol-cloud (модул за облачна интеграция) и clustercontrol-clud (CLI за изтегляне/качване в облак), които са налични във v1.5 и по-нова версия. Инструкциите за надграждане са включени в тези пакети и те идват без допълнителна конфигурация. В момента поддържаните облачни платформи са Amazon Web Services и Google Cloud Platform. Идентификационните данни в облака се конфигурират в ClusterControl -> Настройки -> Интеграции -> Доставчици на облак.
Когато създавате или планирате архивиране, трябва да видите следните допълнителни опции, когато „Качване на архивно копие в облака“ е включено:
Функцията позволява еднократно качване или планиране на архивиране, което да бъде качено след завършване (Amazon S3 или Google Cloud Storage). След това можете да изтеглите и възстановите резервните копия, както е необходимо.
Персонализирана компресия за mysqldump
Тази функция всъщност беше въведена за първи път с ClusterControl v1.4.2 след нейното пускане. Добавихме ниво на архивиране на компресия въз основа на gzip. Преди това ClusterControl използваше компресията на архивиране по подразбиране (ниво 6), ако дестинацията за архивиране беше на възела на контролера. Най-ниската компресия (ниво 1 – най-бърза, по-малко компресия) беше използвана, ако дестинацията за архивиране беше на самия хост на базата данни, за да се осигури минимално въздействие върху базата данни по време на операцията по компресиране.
В тази версия сме усъвършенствали аспекта на компресията и вече можете да персонализирате нивото на компресия, независимо от дестинацията за архивиране. При надграждане на вашия екземпляр на ClusterControl, всички планирани резервни копия ще бъдат автоматично преобразувани за използване на ниво 6, освен ако не ги редактирате изрично във v1.5.
Компресирането на архиви е жизненоважно, когато вашият набор от данни е голям, в комбинация с дълга политика за запазване на архиви, докато пространството за съхранение е ограничено. Mysqldump, който е базиран на текст, може да се възползва от компресия със спестявания до 60% от дисковото пространство от оригиналния размер на файла. В някои случаи най-високият коефициент на компресия е най-добрият вариант, въпреки че идва с цената на по-дълга декомпресия при възстановяване.
Бонус функция:Автоматична проверка на архивиране
Както казват старите системни администратори - Архивът не е архив, ако не може да бъде възстановен. Проверката на резервно копие е нещо, което обикновено се пренебрегва от мнозина. Някои системни администратори са разработили вътрешни рутинни процедури за това, обикновено повече ръчни, отколкото автоматизирани. Автоматизирането му е трудно, главно поради сложността на операцията като цяло - като се започне от осигуряване на хост, инсталиране и подготовка на MySQL, трансфер на архивни файлове, декомпресия, операция по възстановяване, процедури за проверка и накрая почистване на системата след процеса. Всички тези неприятности карат хората да пренебрегват толкова важен аспект на надеждното архивиране. По принцип тест за възстановяване на резервно копие трябва да се прави поне веднъж месечно или в случай на значителни промени в размера на данните или структурата на базата данни. Намерете график, който работи за вас, и го формализирайте с насрочено събитие.
ClusterControl може да автоматизира проверката на архивиране, като извърши възстановяването на нов хост, без да компрометира някоя от процедурите за проверка, споменати по-горе. Това може да стане след известно забавяне или веднага след приключване на архивирането. Той ще докладва състоянието на архивиране въз основа на кода за изход от операцията по възстановяване, ще извърши автоматично изключване, ако архивирането е потвърдено, или просто ще остави възстановения хост да работи, за да извършите допълнителни ръчни проверки на данните.
Когато създавате или планирате архивиране, ще имате допълнителни опции, ако „Проверка на архивиране“ е включено:
Ако „Инсталиране на софтуер за база данни“ е активирано, ClusterControl ще премахне всяка съществуваща инсталация на MySQL на целевия хост и ще инсталира отново софтуера на базата данни със същата версия като съществуващия MySQL сървър. В противен случай, ако имате конкретна настройка за възстановения хост, можете да пропуснете тази опция. Останалите опции се обясняват сами.
Бонус функция:Не забравяйте PostgreSQL
В допълнение към цялата тази страхотна функционалност за MySQL и MariaDB ClusterControl 1.5 вече предоставя на PostgreSQL допълнителен метод за архивиране (pg_basebackup), който може да се използва за онлайн двоични архиви. Архивите, направени с pg_basebackup, могат да се използват по-късно за възстановяване в даден момент и като отправна точка за резервни сървъри за доставка на регистрационни файлове или поточно репликация.
Това е засега. Опитайте ClusterControl v1.5, поиграйте с новите функции и ни уведомете какво мислите.
