Azure Database for MySQL/MariaDB migreren naar een lokale server

Databasemigraties kunnen enorme uitdagingen met zich meebrengen als je bedenkt hoe je moet beginnen, welke tools je moet gebruiken en hoe je met succes een volledige databasemigratie kunt realiseren. Eerder hebben we de beste open source vermeld die u kunt gebruiken bij migratie voor MySQL of MariaDB. In deze blog laten we u zien hoe u gegevens migreert vanuit Microsoft Azure Database for MySQL of MariaDB.

Microsoft Azure staat nu bekend als een concurrent van de twee andere cloudtechgiganten:AWS en Google Cloud. Het is gespecialiseerd in meer van zijn Microsoft-producten, met name hun eigen MSSQL-database van eigen bodem. Maar niet alleen dat, het heeft ook open bronnen als een van hun volledig beheerde servicedatabases om publiekelijk aan te bieden. Onder de ondersteunde databases zijn MySQL en MariaDB.

Verhuizen van Azure Database for MySQL/MariaDB kan vervelend zijn, maar het hangt af van welk type architectuur en welk type gegevensset u als uw huidige cloudprovider in uw Azure hebt gehost. Met de juiste tools kan het haalbaar zijn en kan een volledige migratie worden gedaan.

We concentreren ons op de tools die we kunnen gebruiken voor gegevensmigraties op MySQL of MariaDB. Voor deze blog gebruik ik RHEL/CentOS om de vereiste pakketten te installeren. Laten we de stappen en procedures bespreken om dit te doen.

Migreren vanuit Azure Database for MySQL of MariaDB

Een typische benadering voor het migreren van uw gegevens van Azure Database naar een on-premises server is om een back-up te maken met een logische kopie. Dit kan worden gedaan met behulp van back-uphulpprogramma's die compatibel zijn met Azure Database for MySQL of MariaDB, een volledig beheerde service. Volledig beheerde databaseservices bieden geen SSH-aanmeldingen, dus een fysieke kopie van back-ups is geen optie.

Voordat u uw bestaande database vanuit Azure kunt migreren of dumpen, moet u rekening houden met de volgende overwegingen.

Veelgebruikte toepassingen voor dumpen en herstellen op locatie

De meest voorkomende toepassingen zijn:

Logische back-up gebruiken (zoals mysqldump, mysqlpump of mydumper/myloader) en herstellen is de enige optie. Azure Database for MySQL of MariaDB biedt geen ondersteuning voor fysieke toegang tot de fysieke opslag, aangezien dit een volledig beheerde databaseservice is.
Ondersteunt alleen InnoDB- en geheugenopslagengines. Migreren van alternatieve storage-engines naar InnoDB. Azure Database for MySQL of MariaDB ondersteunt alleen InnoDB Storage-engine en ondersteunt daarom geen alternatieve storage-engines. Als uw tabellen zijn geconfigureerd met andere opslag-engines, converteert u deze naar de InnoDB-engine-indeling voordat u migreert naar Azure Database for MySQL.
Als u bijvoorbeeld een WordPress of webapp hebt die de MyISAM-tabellen gebruikt, converteert u deze tabellen eerst door ze naar de InnoDB-indeling te migreren voordat u ze herstelt naar Azure Database for MySQL. Gebruik de clausule ENGINE=InnoDB om de engine in te stellen die wordt gebruikt bij het maken van een nieuwe tabel, en breng vervolgens de gegevens over naar de compatibele tabel vóór het herstel.
Als uw bron-Azure Database een specifieke versie heeft, dan is uw doelserver op locatie ook dezelfde versie als de bron-Azure Database.

Dus met deze beperkingen verwacht je alleen dat je gegevens uit Azure InnoDB storage engine of Memory moeten zijn, als die in je dataset aanwezig zijn.

Prestatieoverwegingen voor het nemen van logische back-up van Azure Database

De enige manier om een logische back-up te maken met Azure is door mysqldump of mysqlpump te gebruiken. Houd rekening met de volgende overwegingen bij het dumpen van grote databases om de prestaties te optimaliseren bij het dumpen met deze tools:

Gebruik de optie uitsluiten-triggers in mysqldump bij het dumpen van databases. Sluit triggers uit van dumpbestanden om te voorkomen dat de triggercommando's worden geactiveerd tijdens het gegevensherstel.
Gebruik de optie voor één transactie om de transactie-isolatiemodus in te stellen op REPEATABLE READ en stuur een START TRANSACTION SQL-instructie naar de server voordat gegevens worden gedumpt. Het dumpen van veel tabellen binnen een enkele transactie zorgt ervoor dat er wat extra opslagruimte wordt verbruikt tijdens het herstellen. De single-transactieoptie en de lock-tables-optie sluiten elkaar uit omdat LOCK TABLES ervoor zorgt dat eventuele lopende transacties impliciet worden vastgelegd. Om grote tafels te dumpen, combineert u de optie voor één transactie met de snelle optie.
Gebruik de uitgebreide syntaxis voor meerdere rijen die meerdere VALUE-lijsten bevat. Dit resulteert in een kleiner dumpbestand en versnelt het invoegen wanneer het bestand opnieuw wordt geladen.
Gebruik de order-by-primary-optie in mysqldump bij het dumpen van databases, zodat de gegevens in de volgorde van de primaire sleutel worden gescript.
Gebruik de optie voor het uitschakelen van sleutels in mysqldump bij het dumpen van gegevens, om beperkingen voor externe sleutels uit te schakelen voordat ze worden geladen. Het uitschakelen van buitenlandse sleutelcontroles levert prestatiewinst op. Schakel de beperkingen in en verifieer de gegevens na het laden om de referentiële integriteit te garanderen.
Gebruik zo nodig gepartitioneerde tabellen.
Laad gegevens parallel. Vermijd te veel parallellisme waardoor u een resourcelimiet zou bereiken, en controleer resources met behulp van de metrieken die beschikbaar zijn in de Azure-portal.
Gebruik de optie defer-table-indexes in mysqlpump bij het dumpen van databases, zodat de index wordt gemaakt nadat de tabelgegevens zijn geladen.
Gebruik de skip-definer-optie in mysqlpump om de definitie- en SQL SECURITY-clausules weg te laten in de create-instructies voor views en opgeslagen procedures. Wanneer u het dumpbestand opnieuw laadt, worden objecten gemaakt die de standaardwaarden DEFINER en SQL SECURITY gebruiken.
Kopieer de back-upbestanden naar een Azure-blob/store en voer het herstel vanaf daar uit, wat een stuk sneller zou moeten zijn dan het herstellen via internet.

Niet ondersteund

Het volgende wordt niet ondersteund:

DBA-rol:beperkt. Als alternatief kunt u de administrator-gebruiker gebruiken (gemaakt tijdens het maken van een nieuwe server), waarmee u de meeste DDL- en DML-instructies kunt uitvoeren.
SUPER-voorrecht:op dezelfde manier is het SUPER-voorrecht beperkt.
DEFINER:vereist superrechten om te maken en is beperkt. Als u gegevens importeert met een back-up, verwijdert u de CREATE DEFINER-opdrachten handmatig of door de --skip-definer-opdracht te gebruiken bij het uitvoeren van een mysqldump.
Systeemdatabases:de mysql-systeemdatabase is alleen-lezen en wordt gebruikt om verschillende PaaS-functionaliteit te ondersteunen. U kunt geen wijzigingen aanbrengen in de mysql-systeemdatabase.
SELECTEER ... INTO OUTFILE:niet ondersteund in de service.

Mysqldump gebruiken

Het gebruik van mysqldump moet worden geïnstalleerd in uw doeldatabaseknooppunt op locatie. Het moet worden voorbereid als een replica van het Azure Database-knooppunt, zodat alle volgende transacties naar het knooppunt worden gerepliceerd. Volg hiervoor de onderstaande stappen.

Installeer mysqldump

Maak de repository gereed.

# Voor MySQL

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

# Voor MariaDB

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

Mysql-client-pakket installeren

# Voor MySQL

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

# Voor MariaDB

$ yum install -y MariaDB-client

Maak een gegevensdump met mysqldump door deze in het doelknooppunt uit te voeren.

$ 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

Installeer de MySQL/MariaDB-server in het doeldatabaseknooppunt

# Voor MySQL

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

# Voor MariaDB

$ yum install MariaDB-server.x86_64

Stel de MySQL/MariaDB Server-instantie in (my.cnf, bestandsrechten, directory's) en start de server

# De my.cnf instellen (met behulp van de my.cnf-implementatie door 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

## Reset de gegevensmap en installeer de databasesysteembestanden opnieuw

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

## Maak de logmappen

$ mkdir /var/log/mysql

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

## Voor MySQL

$ mysqld --initialize

## Voor MariaDB

$ mysql_install_db

Start de MySQL/MariaDB-server

## Voor MySQL

$ systemctl start mysqld

## Voor MariaDB

$ systemctl start mariadb

Laad de gegevensdump die we van Azure Database hebben gehaald naar het doeldatabaseknooppunt op locatie

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

Maak de replicatiegebruiker vanaf uw Azure Database-bronknooppunt

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

Zorg ervoor dat u het IP-adres van het IP-adres van uw doelknooppunt wijzigt als de client om vanaf te verbinden.

Stel de MySQL/MariaDB-server in als een replica/slave van het Azure Database-bronknooppunt

## Laten we eerst het CHANGE MASTER-commando zoeken of lokaliseren

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

## Voer de CHANGE MASTER-instructie uit, maar voeg de replicatie gebruiker/wachtwoord en de hostnaam als volgt toe,

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

## In sommige gevallen moet u misschien het mysql-schema negeren. Voer de volgende instructie uit:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Start dan de slave-threads

START SLAVE;

## Controleer de status van de slave hoe het gaat

SHOW SLAVE STATUS \G

Nu we eindelijk in staat zijn geweest om te repliceren vanuit Azure Database ofwel voor MySQL/MariaDB als de bron van uw replica op locatie.

Mijndumper gebruiken

Azure Database for MySQL of MariaDB suggereert in feite dat het gebruik van mydumper, speciaal voor grote back-ups zoals 1TB, een alternatieve optie kan zijn. Het biedt parallellisme en snelheid bij het nemen van een dump- of back-upkopie van uw dataset vanaf een Azure Database-bronknooppunt.

Volg de onderstaande stappen vanaf het installeren van de mydumper tot het laden op de on-prem-server van uw bestemming.

Installeer het binaire bestand. De binaire bestanden zijn hier te vinden 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

Maak de back-up van het Azure Database-bronknooppunt. Bijvoorbeeld,

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

….

Zoals u kunt zien, is er een beperking voor het maken van back-ups van een beheerde database zoals Azure. Je merkt het misschien,

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

Dit komt omdat SUPER PRIVILEGE niet wordt ondersteund of beperkt. Idealiter is de beste optie om dit te doen de back-up te nemen van een replica van uw Azure Database. We zullen hier later over praten.

Nu, op dit punt zal mydumper een back-up van bestanden maken in de vorm van *.gz-bestanden

Laad het naar de lokale server van uw bestemming

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

…

….

Stel het bestemmingsknooppunt in als een slave/replica. MyDumper bevat een bestand genaamd metadata dat bestaat uit binaire logcoördinaten, waaronder GTID -posities, bijvoorbeeld:

$ 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

## Voer vervolgens een wijzigingsmaster uit vanaf de replica of uw doelbestemming MySQL/MariaDB-databaseknooppunt

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 de slave

START SLAVE;

Op dit moment hebt u het gerepliceerd vanuit een Azure Database-instantie waarop MySQL/MariaDB wordt uitgevoerd. Zodra uw toepassing klaar is om weg te gaan van uw Azure Database-instantie, stelt u het eindpunt in dat naar uw on-premises server gaat en worden alle resterende transacties van uw Azure-instantie gerepliceerd naar uw on-prem, zodat er geen gegevens worden gemist die naar uw on-prem gaan. prem-server.

Omgangsbeperkingen met beheerde databases voor MySQL of MariaDB in Azure

Omgaan met beperkingen, vooral bij het nemen van een back-updump van uw dataset, moet 100% nauwkeurig zijn vanaf het moment dat u de back-updump hebt gemaakt. Dit is natuurlijk een ideale migratie naar uw locatie op locatie. Om hiermee om te gaan, is de beste architectuurconfiguratie een aanwezigheid van een replicatietopologie in uw Azure Database.

Zodra u deze hebt en klaar bent voor migratie, moet de mysqldump/mysqlpump of mydumper de Azure Database-replica als bron gebruiken. Zorg ervoor dat binnen die Azure Database-replica de SQL_THREAD is gestopt, zodat u een momentopname kunt maken of de juiste MASTER_LOG_FILE en EXEC_MASTER_LOG_POS kunt opnemen van het resultaat van SHOW SLAVE STATUS.

Natuurlijk, als de back-up eenmaal is gemaakt, vergeet dan niet om uw Azure Database-replica te starten om de replicatiethreads opnieuw te starten.

Controleren op gegevensverschillen

Zodra u uw gegevens hebt geladen of gedumpt naar uw on-premises server die fungeert als een replica van de Azure Database-instantie, moet u dit dubbel controleren door controlesomberekeningen uit te voeren om te bepalen hoe ver uw gegevens zijn ten opzichte van de bron Azure Database. We raden u aan de tool pt-table-checksum van Percona Toolkit te gebruiken, maar u kunt uw eigen tool maken met behulp van checksumming-tools zoals md5 of sha256, maar dit kost tijd. Bovendien kan het gebruik van pt-upgrade van Percona Toolkit ook helpen nadat uw gegevensmigratie met deze replicatieaanpak is voltooid.

Conclusie

Beperkingen van bevoegdheden en niet-ondersteunde typen van Azure Database kunnen een uitdaging zijn, maar met de juiste stroom en architectuur is het niet onmogelijk om te migreren vanuit een volledig beheerde database die op locatie gaat. Het enige dat u hoeft te doen, is de vereiste stappen voorbereiden, de vereiste topologie instellen vanuit uw Azure Database-bron, vervolgens de migratie starten van het maken van back-ups tot replicatie en de totale migratie naar uw on-premises.