Мигриране на база данни на Azure за MySQL/MariaDB към On-Prem сървър

Миграциите на бази данни могат да наложат огромни предизвикателства, когато обмислите как да започнете, какви инструменти да използвате и как да постигнете успешно пълно мигриране на база данни. По-рано изброихме най-добрия отворен код, който можете да използвате при миграция за MySQL или MariaDB. В този блог ще ви покажем как да мигрирате данни от Microsoft Azure Database за MySQL или MariaDB.

Повечето е известно, че Microsoft Azure е съперник срещу другите два облачни технологични гиганта:AWS и Google Cloud. Той специализира повече от своите продукти на Microsoft, специално тяхната домашна собствена база данни MSSQL. Но не само това, той също има отворени източници като една от техните напълно управлявани бази данни за услуги, които да предлага публично. Сред поддържаните от него бази данни са MySQL и MariaDB.

Преместването от Azure Database за MySQL/MariaDB може да бъде досадно, но зависи от това какъв тип архитектура и какъв тип набор от данни сте хоствали във вашия Azure като текущ доставчик на облак. С правилните инструменти това може да бъде постижимо и пълна миграция може да се извърши.

Ще се съсредоточим върху инструментите, които можем да използваме за мигриране на данни в MySQL или MariaDB. За този блог използвам RHEL/CentOS, за да инсталирам необходимите пакети. Нека да преминем и да дефинираме стъпките и процедурите как да направите това.

Мигриране от Azure Database за MySQL или MariaDB

Типичен подход за мигриране на вашите данни от Azure Database към локален сървър е да направите резервно копие с помощта на логическо копие. Това може да стане с помощта на помощни решения за архивиране, които са съвместими за работа с Azure Database за MySQL или MariaDB, която е напълно управлявана услуга. Напълно управляваните услуги за бази данни не предлагат SSH влизания, така че физическото копие на резервните копия не е опция.

Преди да можете да мигрирате или изхвърлите съществуващата си база данни от Azure, трябва да вземете под внимание следните съображения.

Общи случаи на употреба за изхвърляне и възстановяване при инсталиране

Най-често срещаните случаи на употреба са:

Използването на логическо архивиране (като mysqldump, mysqlpump или mydumper/myloader) и възстановяване е единствената опция. Azure Database за MySQL или MariaDB не поддържа физически достъп до физическото хранилище, тъй като това е напълно управлявана услуга за база данни.
Поддържа само машини за съхранение на InnoDB и Memory. Мигриране от алтернативни машини за съхранение към InnoDB. Azure Database за MySQL или MariaDB поддържа само InnoDB Storage engine и следователно не поддържа алтернативни машини за съхранение. Ако вашите таблици са конфигурирани с други машини за съхранение, преобразувайте ги във формат на машината InnoDB преди миграция към Azure Database за MySQL.
Например, ако имате WordPress или WebApp, използващи MyISAM таблиците, първо преобразувайте тези таблици, като мигрирате във формат InnoDB, преди да възстановите в Azure Database за MySQL. Използвайте клаузата ENGINE=InnoDB, за да зададете двигателя, използван при създаване на нова таблица, след което прехвърлете данните в съвместимата таблица преди възстановяването.
Ако вашата изходна база данни Azure е на конкретна версия, тогава вашият целеви локален сървър също е бил същата версия като изходната база данни Azure.

Така че с тези ограничения очаквате само вашите данни от Azure да бъдат InnoDB устройство за съхранение или памет, ако има такива във вашия набор от данни.

Съображения за производителност при вземане на логическо архивиране от базата данни Azure

Единственият начин да направите логическо архивиране с Azure е да използвате mysqldump или mysqlpump. За да оптимизирате производителността, когато правите дъмп с помощта на тези инструменти, обърнете внимание на тези съображения, когато изхвърляте големи бази данни:

Използвайте опцията exclude-triggers в mysqldump, когато изхвърляте бази данни. Изключете тригери от дъмп файлове, за да избегнете задействането на тригерните команди по време на възстановяването на данните.
Използвайте опцията за единична транзакция, за да зададете режима на изолация на транзакциите на ПОВТОРЯЩО ЧЕТЕНЕ и да изпратите SQL оператор START TRANSACTION на сървъра, преди да изхвърлите данни. Изхвърлянето на много таблици в рамките на една транзакция води до изразходване на допълнително хранилище по време на възстановяване. Опцията за единична транзакция и опцията lock-tables са взаимно изключващи се, тъй като LOCK TABLES причинява неявно извършване на всички чакащи транзакции. За да изхвърлите големи таблици, комбинирайте опцията за единична транзакция с бързата опция.
Използвайте синтаксиса на разширено вмъкване на няколко реда, който включва няколко VALUE списъка. Това води до по-малък дъмп файл и ускорява вмъкването при презареждане на файла.
Използвайте опцията за подреждане по първичен в mysqldump, когато изхвърляте бази данни, така че данните да бъдат скриптирани в ред на първичен ключ.
Използвайте опцията disable-keys в mysqldump, когато изхвърляте данни, за да деактивирате ограниченията на външния ключ преди зареждане. Деактивирането на проверките на външни ключове осигурява повишаване на производителността. Активирайте ограниченията и проверете данните след зареждането, за да осигурите референтна цялост.
Използвайте разделени таблици, когато е подходящо.
Заредете паралелно данни. Избягвайте твърде много паралелизъм, който би ви навел да достигнете ограничение на ресурсите, и наблюдавайте ресурсите с помощта на показателите, налични в портала Azure.
Използвайте опцията defer-table-indexes в mysqlpump, когато изхвърляте бази данни, така че създаването на индекс да се случи след зареждане на данните на таблицата.
Използвайте опцията skip-definer в mysqlpump, за да пропуснете клаузите за дефиниране и SQL SECURITY от операторите за създаване за изгледи и съхранени процедури. Когато презаредите дъмп файла, той създава обекти, които използват стойностите по подразбиране DEFINER и SQL SECURITY.
Копирайте архивните файлове в Azure blob/store и извършете възстановяването от там, което трябва да е много по-бързо от извършването на възстановяването в интернет.

Не се поддържа

Следните не се поддържат:

Ролята на DBA:Ограничена. Като алтернатива можете да използвате администраторския потребител (създаден по време на създаването на нов сървър), който ви позволява да изпълнявате повечето DDL и DML изрази.
СУПЕР привилегия:По същия начин привилегията СУПЕР е ограничена.
DEFINER:Изисква супер привилегии за създаване и е ограничен. Ако импортирате данни с помощта на резервно копие, премахнете командите CREATE DEFINER ръчно или с помощта на командата --skip-definer, когато изпълнявате mysqldump.
Системни бази данни:Системната база данни mysql е само за четене и се използва за поддръжка на различни PaaS функционалности. Не можете да правите промени в системната база данни на mysql.
ИЗБЕРЕТЕ... В ИЗВЪН ФАЙЛ:Не се поддържа в услугата.

Използване на mysqldump

Използването на mysqldump трябва да бъде инсталирано във вашия целеви възел на базата данни, разположен on-prem. Той трябва да бъде подготвен като реплика на възела на Azure Database, така че всички последващи транзакции да бъдат репликирани на възела. За да направите това, следвайте стъпките по-долу.

Инсталирайте mysqldump

Подгответе хранилището.

# За MySQL

$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

# За MariaDB

$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

Инсталиране на mysql-client пакет

# За MySQL

$ yum install -y mysql-community-client.x86_64

# За MariaDB

$ yum install -y MariaDB-client

Създайте дъмп на данни с помощта на mysqldump, като го изпълните в целевия възел.

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

Инсталирайте MySQL/MariaDB сървъра в целевия възел на базата данни

# За MySQL

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# За MariaDB

$ yum install MariaDB-server.x86_64

Настройте екземпляра на MySQL/MariaDB Server (my.cnf, разрешения за файлове, директории) и стартирайте сървъра

# Настройване на my.cnf (с използване на внедряването my.cnf от ClusterControl)

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF

innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path=ibdata1:100M:autoextend

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=256M

innodb_log_buffer_size=32M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

innodb_flush_method=O_DIRECT

innodb_rollback_on_timeout=ON

innodb_autoinc_lock_mode=2

innodb_stats_on_metadata=0

default_storage_engine=innodb

server_id=1126

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=OFF

report_host=192.168.10.226

key_buffer_size=24M

tmp_table_size=64M

max_heap_table_size=64M

max_allowed_packet=512M

skip_name_resolve=true

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type=0

query_cache_size=0

table_open_cache=1024

lower_case_table_names=0

performance_schema=OFF

performance-schema-max-mutex-classes=0

performance-schema-max-mutex-instances=0



[MYSQL]

socket=/var/lib/mysql/mysql.sock



[client]

socket=/var/lib/mysql/mysql.sock



[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet=512M

## Нулирайте директорията с данни и инсталирайте отново системните файлове на базата данни

$ rm -rf /var/lib/mysql/*

## Създайте директориите на журнала

$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## За MySQL

$ mysqld --initialize

## За MariaDB

$ mysql_install_db

Стартирайте MySQL/MariaDB сървъра

## За MySQL

$ systemctl start mysqld

## За MariaDB

$ systemctl start mariadb

Заредете дъмпа на данни, който сме взели от Azure Database, към целевия възел на базата данни on-prem

$ mysql --show-warnings < backups/dump.sql

Създайте потребителя за репликация от вашия изходен възел на Azure Database

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Уверете се, че сте променили IP адреса на IP адреса на вашия целеви възел като клиент, от който да се свържете.

Настройте MySQL/MariaDB сървъра като реплика/подчинен на изходния възел на Azure Database

## Първо, нека потърсим или намерим командата CHANGE MASTER

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

## Изпълнете оператора CHANGE MASTER, но добавете потребителя/паролата за репликация и името на хоста, както следва,

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## В някои случаи може да се наложи да игнорирате схемата на mysql. Изпълнете следния оператор:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## След това стартирайте подчинените нишки

START SLAVE;

## Проверете състоянието на подчинения как върви

SHOW SLAVE STATUS \G

Сега, когато най-накрая успяхме да репликираме от Azure Database или за MySQL/MariaDB като източник на вашата реплика, намираща се локално.

Използване на mydumper

Azure Database за MySQL или MariaDB всъщност предполага, че използването на mydumper специално за големи архиви като 1TB може да бъде вашата алтернативна опция. Той предлага паралелизъм и скорост при вземане на дъмп или резервно копие на вашия набор от данни от изходен възел на Azure Database.

Следвайте стъпките по-долу от инсталирането на mydumper до зареждането на вашия дестинационен локален сървър.

Инсталирайте двоичния файл. Двоичните файлове могат да се намират тук https://github.com/maxbube/mydumper/releases.

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm

Вземете резервното копие от изходния възел на Azure Database. Например,

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Както можете да видите, има ограничение за вземане на резервно копие от управлявана база данни като Azure. Може да забележите,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Това е така, защото SUPER PRIVILEGE не се поддържа или ограничава. В идеалния случай най-добрият вариант да направите това е да вземете резервно копие от реплика на вашата база данни Azure. Ще говорим за това по-късно.

Сега, в този момент, mydumper ще вземе архивни файлове под формата на *.gz файлове

Заредете го във вашия локален сървър на местоназначение

$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3

** Message: 8 threads created

** Message: Creating database `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

Настройте дестинационния възел като подчинен/реплика. MyDumper ще включва файл, наречен Metadata, който се състои от двоични координати на дневника, включително GTID позиции, например:

$ cat metadata

Started dump at: 2020-10-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## След това стартирайте главен код за промяна от репликата или вашата целева дестинация възел на базата данни MySQL/MariaDB

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Стартирайте подчинения

START SLAVE;

В този момент вече сте репликирали от екземпляр на Azure Database, изпълняващ MySQL/MariaDB. След като приложението ви е готово да се отдалечи от вашия екземпляр на Azure Database, настройте крайната точка, която отива към вашия on-prem сървър и всички останали транзакции от вашия екземпляр на Azure ще бъдат репликирани във вашия on-prem, без да се пропускат данни, отиващи към вашия on-prem prem сървър.

Обработване на ограничения с управлявани бази данни за MySQL или MariaDB в Azure

Справянето с ограниченията, особено когато правите резервно копие на вашия набор от данни, трябва да бъде 100% точно от момента, в който сте направили резервното копие. Разбира се, това е идеална миграция към вашата on-prem. За да се справите с това, най-добрата настройка на архитектурата е да имате топология на репликация във вашата база данни Azure.

След като го имате и сте готови за миграция, mysqldump/mysqlpump или mydumper трябва да използва репликата на базата данни Azure като източник. В тази реплика на база данни на Azure се уверете, че SQL_THREAD е спрян, за да можете да направите моментна снимка или да запишете правилните MASTER_LOG_FILE и EXEC_MASTER_LOG_POS от резултата от SHOW SLAVE STATUS.

Разбира се, след като архивирането е направено, не забравяйте да стартирате вашата реплика на база данни на Azure, за да стартирате отново нейните нишки за репликация.

Проверете за несъответствия в данните

След като данните ви бъдат заредени или изхвърлени на вашия on-prem сървър, действащ като реплика от екземпляра на Azure Database, трябва да проверите това, като изпълните изчисления на контролната сума, за да определите колко далеч са вашите данни спрямо източник на база данни Azure. Предлагаме ви да използвате инструмента pt-table-checksum от Percona Toolkit, но можете да създадете свой собствен, като използвате инструменти за контролно сумиране като md5 или sha256, но това отнема време. Освен това, използването на pt-upgrade от Percona Toolkit може да помогне и след приключване на миграцията на данните ви чрез този подход за репликация.

Заключение

Ограниченията на привилегиите и неподдържаните типове от Azure Database могат да бъдат предизвикателство, но с подходящия поток и архитектура не е невъзможно да се мигрира от напълно управлявана база данни, която се извършва локално. Всичко, което трябва да направите, е да подготвите необходимите стъпки, да настроите необходимата топология от вашия източник на Azure Database, след това да започнете миграцията от вземане на резервни копия, до репликация и пълна миграция към вашия on-prem.