Migrace Azure Database for MySQL/MariaDB na On-Prem Server

Migrace databáze mohou představovat obrovské problémy, když zvažujete, jak začít, jaké nástroje použít a jak úspěšně dosáhnout úplné migrace databáze. Již dříve jsme uvedli nejlepší open source, který můžete použít při migraci na MySQL nebo MariaDB. V tomto blogu vám ukážeme, jak migrovat data z databáze Microsoft Azure pro MySQL nebo MariaDB.

Microsoft Azure je nyní známo, že je soupeřem proti dvěma dalším gigantům cloudových technologií:AWS a Google Cloud. Specializuje se na více svých produktů Microsoft, zejména na jejich domácí proprietární databázi MSSQL. Ale nejen to, má také otevřené zdroje jako jednu z jejich plně spravovaných databází služeb, které mohou veřejně nabízet. Mezi jeho podporované databáze patří MySQL a MariaDB.

Přechod z Azure Database for MySQL/MariaDB může být zdlouhavý, ale záleží na tom, jaký typ architektury a jaký typ datové sady máte v Azure hostovaný jako aktuální poskytovatel cloudu. Se správnými nástroji to může být dosažitelné a může být provedena úplná migrace.

Zaměříme se na nástroje, které můžeme použít pro migraci dat na MySQL nebo MariaDB. Pro tento blog používám RHEL/CentOS k instalaci požadovaných balíčků. Pojďme si projít a definovat kroky a postupy, jak toho dosáhnout.

Migrace z Azure Database for MySQL nebo MariaDB

Typickým přístupem k migraci dat z Azure Database na místní server je vytvoření zálohy pomocí logické kopie. To lze provést pomocí řešení zálohovacích nástrojů, která jsou kompatibilní s Azure Database for MySQL nebo MariaDB, což je plně spravovaná služba. Plně spravované databázové služby nenabízejí přihlášení SSH, takže fyzická kopie záloh nepřichází v úvahu.

Než budete moci migrovat nebo vypsat existující databázi z Azure, musíte vzít na vědomí následující skutečnosti.

Běžné případy použití pro výpis a obnovení na místě

Nejčastější případy použití jsou:

Použít logické zálohování (jako je mysqldump, mysqlpump nebo mydumper/myloader) a obnovit je jedinou možností. Azure Database for MySQL nebo MariaDB nepodporuje fyzický přístup k fyzickému úložišti, protože se jedná o plně spravovanou databázovou službu.
Podporuje pouze InnoDB a paměťové moduly. Migrace z alternativních úložišť na InnoDB. Azure Database for MySQL nebo MariaDB podporuje pouze modul InnoDB Storage, a proto nepodporuje alternativní moduly úložiště. Pokud jsou vaše tabulky nakonfigurovány s jinými moduly úložiště, převeďte je před migrací do Azure Database for MySQL do formátu modulu InnoDB.
Pokud máte například aplikaci WordPress nebo WebApp používající tabulky MyISAM, před obnovením do Azure Database for MySQL tyto tabulky nejprve převeďte migrací do formátu InnoDB. Pomocí klauzule ENGINE=InnoDB nastavte engine použitý při vytváření nové tabulky a poté před obnovením přeneste data do kompatibilní tabulky.
Pokud je vaše zdrojová Azure Database na konkrétní verzi, pak váš cílový místní server má také stejnou verzi jako zdrojová Azure Database.

S těmito omezeními tedy očekáváte pouze to, že vaše data z Azure musí být úložiště InnoDB nebo paměť, pokud to ve vaší datové sadě je.

Úvahy o výkonu pro převzetí logické zálohy z Azure Database

Jediný způsob, jak provést logické zálohování pomocí Azure, je použít mysqldump nebo mysqlpump. Chcete-li optimalizovat výkon při vytváření výpisu pomocí těchto nástrojů, věnujte pozornost těmto úvahám při ukládání velkých databází:

Při dumpingu databází použijte možnost vylučovacích spouštěčů v mysqldump. Vylučte spouštěče ze souborů výpisu, abyste předešli spouštění příkazů spouštěcích během obnovy dat.
Pomocí volby jedné transakce nastavte režim izolace transakcí na REPEATABLE READ a před uložením dat odešlete na server příkaz START TRANSACTION SQL. Vypsání mnoha tabulek v rámci jedné transakce způsobí, že během obnovy bude spotřebováno určité úložiště navíc. Možnost jedné transakce a možnost lock-tables se vzájemně vylučují, protože LOCK TABLES způsobí, že všechny čekající transakce budou potvrzeny implicitně. Chcete-li vypsat velké tabulky, zkombinujte možnost jedné transakce s rychlou možností.
Použijte víceřádkovou syntaxi s rozšířeným vkládáním, která zahrnuje několik seznamů VALUE. Výsledkem je menší soubor výpisu a urychlení vkládání při opětovném načtení souboru.
Při ukládání databází použijte volbu order-by-primary v mysqldump, aby byla data skriptována v pořadí primárního klíče.
Použijte možnost disable-keys v mysqldump při ukládání dat k deaktivaci omezení cizích klíčů před načtením. Zakázání kontroly cizího klíče přináší zvýšení výkonu. Povolte omezení a ověřte data po načtení, abyste zajistili referenční integritu.
V případě potřeby použijte rozdělené tabulky.
Načítat data paralelně. Vyhněte se přílišnému paralelismu, který by způsobil dosažení limitu prostředků, a sledujte prostředky pomocí metrik dostupných na Azure Portal.
Při ukládání databází použijte možnost defer-table-indexes v mysqlpump, aby se index vytvořil až po načtení dat tabulky.
Použijte volbu skip-definer v mysqlpump k vynechání klauzule Definer a SQL SECURITY z příkazů create pro pohledy a uložené procedury. Když znovu načtete soubor výpisu, vytvoří se objekty, které používají výchozí hodnoty DEFINER a SQL SECURITY.
Zkopírujte záložní soubory do Azure blob/store a proveďte obnovu odtud, což by mělo být mnohem rychlejší než provádění obnovy přes internet.

Nepodporováno

Následující položky nejsou podporovány:

Role DBA:Omezená. Případně můžete použít administrátorského uživatele (vytvořeného při vytváření nového serveru), který vám umožní provádět většinu příkazů DDL a DML.
Oprávnění SUPER:Podobně je omezeno oprávnění SUPER.
DEFINER:Vyžaduje super oprávnění k vytvoření a je omezený. Pokud importujete data pomocí zálohy, odstraňte příkazy CREATE DEFINER ručně nebo pomocí příkazu --skip-definer při provádění mysqldump.
Systémové databáze:Systémová databáze mysql je pouze pro čtení a používá se k podpoře různých funkcí PaaS. Nemůžete provádět změny v systémové databázi mysql.
VYBRAT... DO OUTFILE:Služba není podporována.

Použití mysqldump

Použití mysqldump musí být nainstalováno ve vašem cílovém databázovém uzlu umístěném na prem. Musí být připravena jako replika uzlu Azure Database, takže všechny následné transakce se budou replikovat do uzlu. Chcete-li to provést, postupujte podle následujících kroků.

Instalovat mysqldump

Připravte úložiště.

# Pro MySQL

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

# Pro MariaDB

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

Instalovat balíček mysql-client

# Pro MySQL

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

# Pro MariaDB

$ yum install -y MariaDB-client

Vytvořte výpis dat pomocí mysqldump jeho spuštěním v cílovém uzlu.

$ 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

Instalace serveru MySQL/MariaDB do cílového databázového uzlu

# Pro MySQL

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

# Pro MariaDB

$ yum install MariaDB-server.x86_64

Nastavte instanci serveru MySQL/MariaDB (my.cnf, oprávnění k souborům, adresáře) a spusťte server

# Nastavení my.cnf (pomocí nasazení my.cnf pomocí 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

## Resetujte datový adresář a znovu nainstalujte systémové soubory databáze

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

## Vytvořte adresáře protokolů

$ mkdir /var/log/mysql

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

## Pro MySQL

$ mysqld --initialize

## Pro MariaDB

$ mysql_install_db

Spuštění serveru MySQL/MariaDB

## pro MySQL

$ systemctl start mysqld

## Pro MariaDB

$ systemctl start mariadb

Načíst výpis dat, který jsme převzali z Azure Database, do místního uzlu cílové databáze

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

Vytvořte uživatele replikace ze zdrojového uzlu 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';

Ujistěte se, že jste změnili IP adresu IP adresy cílového uzlu jako klienta, ze kterého se chcete připojit.

Nastavení serveru MySQL/MariaDB jako repliky/podřízeného zdrojového uzlu Azure Database

## Nejprve vyhledejte nebo najděte příkaz 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;

## Spusťte příkaz CHANGE MASTER, ale přidejte uživatele/heslo replikace a název hostitele následovně,

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';

## V některých případech možná budete muset schéma mysql ignorovat. Spusťte následující příkaz:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Poté spusťte podřízená vlákna

START SLAVE;

## Zkontrolujte stav slave, jak to jde

SHOW SLAVE STATUS \G

Teď, když jsme konečně mohli replikovat z Azure Database buď pro MySQL/MariaDB jako zdroj vaší repliky umístěné na místě.

Použití mydump

Azure Database for MySQL nebo MariaDB ve skutečnosti naznačuje, že použití mydumper speciálně pro velké zálohy, jako je 1TB, může být vaší alternativní možností. Nabízí paralelnost a rychlost při vytváření výpisu nebo záložní kopie vaší datové sady ze zdrojového uzlu Azure Database.

Postupujte podle níže uvedených kroků od instalace mydumperu až po jeho načtení na váš cílový on-prem server.

Nainstalujte binární soubor. Binární soubory lze nalézt zde 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

Vezměte zálohu ze zdrojového uzlu Azure Database. Například,

[[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

….

Jak vidíte, existuje omezení při zálohování ze spravované databáze, jako je Azure. Možná si všimnete,

** (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

Je to proto, že SUPER PRIVILEGE není podporováno ani omezeno. V ideálním případě je nejlepší možností, jak to udělat, vzít zálohu z repliky vaší Azure Database. Promluvíme si o tom později.

Nyní, v tomto okamžiku, mydumper vezme záložní soubory ve formě *.gz souborů

Načtěte jej na cílový místní server

$ 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`

…

….

Nastavte cílový uzel jako slave/repliku. MyDumper bude zahrnovat soubor s názvem Metadata, který se skládá z binárních souřadnic protokolu, včetně pozic GTID, například:

$ 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

## Poté spusťte master změn z repliky nebo cílového cílového databázového uzlu 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';

## Spustit otroka

START SLAVE;

V tuto chvíli jste se replikovali z instance Azure Database se spuštěnou MySQL/MariaDB. Jakmile bude vaše aplikace připravena přesunout se z vaší instance Azure Database, nastavte koncový bod na váš místní server a všechny zbývající transakce z vaší instance Azure se replikují do vaší místní instance, takže žádná data nepřijdou do vašeho on-prem. prem server.

Zpracování omezení se spravovanými databázemi pro MySQL nebo MariaDB v Azure

Zacházení s omezeními, zejména při vytváření zálohy vaší datové sady, musí být 100% přesné od okamžiku, kdy jste zálohu vytvořili. Samozřejmě je to ideální migrace směřující do vašeho on-prem. Abyste se s tím vypořádali, nejlepším nastavením architektury je přítomnost replikační topologie ve vaší databázi Azure.

Jakmile to budete mít a budete připraveni na migraci, mysqldump/mysqlpump nebo mydumper musí jako zdroj použít repliku Azure Database. V rámci této repliky Azure Database se ujistěte, že je SQL_THREAD zastaveno, abyste mohli pořídit snímek nebo zaznamenat správný MASTER_LOG_FILE a EXEC_MASTER_LOG_POS z výsledku SHOW SLAVE STATUS.

Po provedení zálohy samozřejmě nezapomeňte spustit repliku Azure Database, aby se znovu spustila její replikační vlákna.

Kontrola datových nesrovnalostí

Jakmile budete mít data načtena nebo uložena na místní server fungující jako replika z instance Azure Database, měli byste to zkontrolovat spuštěním výpočtů kontrolního součtu, abyste zjistili, jak daleko jsou vaše data oproti zdrojová databáze Azure. Doporučujeme vám použít nástroj pt-table-checksum z Percona Toolkit, ale můžete si vytvořit svůj vlastní pomocí nástrojů pro kontrolní součty, jako je md5 nebo sha256, ale to nějakou dobu trvá. Po dokončení migrace dat pomocí tohoto replikačního přístupu vám navíc může pomoci pt-upgrade z Percona Toolkit.

Závěr

Omezení oprávnění a nepodporované typy z Azure Database mohou být náročné, ale s vhodným tokem a architekturou není nemožné migrovat z plně spravované databáze běžící na prem. Vše, co musíte udělat, je připravit požadované kroky, nastavit požadovanou topologii z vašeho zdroje Azure Database a poté zahájit migraci od zálohování po replikaci a celkovou migraci do vašeho on-prem.