Migrering af Azure Database til MySQL/MariaDB til en On-Prem Server

Databasemigreringer kan give enorme udfordringer, når du overvejer, hvordan du starter, hvilke værktøjer du skal bruge, og hvordan du opnår en fuld databasemigrering med succes. Tidligere har vi listet den bedste open source, du kan bruge til migrering til MySQL eller MariaDB. I denne blog viser vi dig, hvordan du migrerer data fra Microsoft Azure Database til MySQL eller MariaDB.

Microsoft Azure er nu kendt for at være en konkurrent mod de to andre cloud-teknologigiganter:AWS og Google Cloud. Det specialiserer flere af sine Microsoft-produkter, specielt deres hjemmedyrkede MSSQL proprietære database. Men ikke nok med det, det har også åbne kilder som en af deres fuldt administrerede servicedatabaser at tilbyde offentligt. Blandt dets understøttede databaser er MySQL og MariaDB.

At flytte fra Azure Database til MySQL/MariaDB kan være kedeligt, men det afhænger af hvilken type arkitektur og hvilken type datasæt du har hostet i din Azure som din nuværende cloud-udbyder. Med de rigtige værktøjer kan det opnås, og en fuld migrering kan udføres.

Vi vil fokusere på de værktøjer, vi kan bruge til datamigrering på MySQL eller MariaDB. Til denne blog bruger jeg RHEL/CentOS til at installere de nødvendige pakker. Lad os gå over og definere trinene og procedurerne for, hvordan du gør dette.

Migrering fra Azure Database til MySQL eller MariaDB

En typisk metode til at migrere dine data fra Azure Database til en lokal server er at tage en sikkerhedskopi ved hjælp af en logisk kopi. Dette kan gøres ved hjælp af backup-hjælpeløsninger, der er kompatible til at fungere med Azure Database til MySQL eller MariaDB, som er en fuldt administreret tjeneste. Fuldt administrerede databasetjenester tilbyder ikke SSH-login, så fysisk kopi af sikkerhedskopier er ikke en mulighed.

Før du kan migrere eller dumpe din eksisterende database fra Azure, skal du være opmærksom på følgende overvejelser.

Almindelige brugstilfælde til dump og gendannelse på stedet

De fleste almindelige use-cases er:

Brug af logisk backup (såsom mysqldump, mysqlpump eller mydumper/myloader) og gendannelse er den eneste mulighed. Azure Database til MySQL eller MariaDB understøtter ikke fysisk adgang til det fysiske lager, da dette er en fuldt administreret databasetjeneste.
Understøtter kun InnoDB og Memory storage engines. Migrering fra alternative lagringsmotorer til InnoDB. Azure Database til MySQL eller MariaDB understøtter kun InnoDB Storage Engine og understøtter derfor ikke alternative storage engines. Hvis dine tabeller er konfigureret med andre lagermotorer, skal du konvertere dem til InnoDB-motorformatet før migrering til Azure Database for MySQL.
Hvis du f.eks. har en WordPress eller WebApp, der bruger MyISAM-tabellerne, skal du først konvertere disse tabeller ved at migrere til InnoDB-format, før du gendanner til Azure Database for MySQL. Brug klausulen ENGINE=InnoDB til at indstille den motor, der bruges, når du opretter en ny tabel, og overfør derefter dataene til den kompatible tabel før gendannelsen.
Hvis din Azure-kildedatabase er på en specifik version, har din målserver også været den samme version som Azure-kildedatabasen.

Så med disse begrænsninger forventer du kun, at dine data fra Azure skal være InnoDB storage engine eller Memory, hvis der er sådan i dit datasæt.

Ydeevneovervejelser for at tage logisk sikkerhedskopiering fra Azure-databasen

Den eneste måde at tage en logisk backup med Azure er at bruge mysqldump eller mysqlpump. For at optimere ydeevnen, når du tager et dump ved hjælp af disse værktøjer, skal du være opmærksom på disse overvejelser, når du dumper store databaser:

Brug muligheden for ekskludering-triggere i mysqldump, når du dumper databaser. Udelad triggere fra dumpfiler for at undgå, at triggerkommandoerne udløses under datagendannelsen.
Brug enkelttransaktionsindstillingen til at indstille transaktionsisoleringstilstanden til REPEATABLE READ og send en START TRANSACTION SQL-sætning til serveren, før du dumper data. Dumping af mange tabeller inden for en enkelt transaktion medfører, at der forbruges noget ekstra lager under gendannelse. Enkelttransaktionsmuligheden og låsetabeller er gensidigt udelukkende, fordi LOCK TABLES bevirker, at eventuelle afventende transaktioner begås implicit. For at dumpe store tabeller skal du kombinere muligheden for enkelttransaktion med den hurtige mulighed.
Brug syntaks med udvidet indsættelse af flere rækker, der inkluderer flere VALUE-lister. Dette resulterer i en mindre dumpfil og fremskynder indsættelser, når filen genindlæses.
Brug orden-efter-primær-indstillingen i mysqldump, når du dumper databaser, så dataene er scriptet i primær nøglerækkefølge.
Brug indstillingen disable-keys i mysqldump, når du dumper data, for at deaktivere fremmednøglebegrænsninger før indlæsning. Deaktivering af kontrol af fremmednøgle giver præstationsgevinster. Aktiver begrænsningerne, og bekræft dataene efter indlæsningen for at sikre referentiel integritet.
Brug partitionerede tabeller, når det er relevant.
Indlæs data parallelt. Undgå for meget parallelitet, der ville få dig til at ramme en ressourcegrænse, og overvåg ressourcer ved hjælp af de tilgængelige metrics i Azure-portalen.
Brug muligheden defer-table-indexes i mysqlpump, når du dumper databaser, så indeksoprettelse sker, efter at tabellens data er indlæst.
Brug skip-definer-indstillingen i mysqlpump til at udelade definer- og SQL SECURITY-sætninger fra oprette-sætningerne til visninger og lagrede procedurer. Når du genindlæser dumpfilen, opretter den objekter, der bruger standardværdierne DEFINER og SQL SECURITY.
Kopiér sikkerhedskopifilerne til en Azure-blob/butik og udfør gendannelsen derfra, hvilket burde være meget hurtigere end at udføre gendannelsen på tværs af internettet.

Ikke understøttet

Følgende understøttes ikke:

DBA-rolle:Begrænset. Alternativt kan du bruge administratorbrugeren (oprettet under oprettelse af ny server), som giver dig mulighed for at udføre de fleste DDL- og DML-sætninger.
SUPER-rettigheder:På samme måde er SUPER-rettigheder begrænset.
DEFINER:Kræver superprivilegier for at oprette og er begrænset. Hvis du importerer data ved hjælp af en sikkerhedskopi, skal du fjerne CREATE DEFINER-kommandoerne manuelt eller ved at bruge kommandoen --skip-definer, når du udfører en mysqldump.
Systemdatabaser:Mysql-systemdatabasen er skrivebeskyttet og bruges til at understøtte forskellige PaaS-funktioner. Du kan ikke foretage ændringer i mysql-systemdatabasen.
VÆLG ... INTO OUTFIL:Ikke understøttet i tjenesten.

Brug af mysqldump

Brug af mysqldump skal installeres i din måldatabaseknude, der er lokaliseret. Det skal forberedes som en replika af Azure Database-noden, så alle efterfølgende transaktioner skal replikeres til noden. For at gøre dette skal du følge nedenstående trin.

Installer mysqldump

Forbered lageret.

# Til MySQL

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

# For MariaDB

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

Installer mysql-client-pakken

# Til MySQL

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

# For MariaDB

$ yum install -y MariaDB-client

Opret et datadump ved hjælp af mysqldump ved at udføre det inde i målknuden.

$ 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

Installer MySQL/MariaDB-serveren i måldatabasenoden

# Til MySQL

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

# For MariaDB

$ yum install MariaDB-server.x86_64

Konfigurer MySQL/MariaDB Server-instansen (my.cnf, filtilladelser, mapper), og start serveren

# Opsætning af my.cnf (ved hjælp af my.cnf-implementeringen, der bruges af 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

## Nulstil databiblioteket og geninstaller databasesystemfilerne

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

## Opret logbibliotekerne

$ mkdir /var/log/mysql

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

## Til MySQL

$ mysqld --initialize

## For MariaDB

$ mysql_install_db

Start MySQL/MariaDB-serveren

## til MySQL

$ systemctl start mysqld

## For MariaDB

$ systemctl start mariadb

Indlæs det datadump, vi har taget fra Azure Database, til måldatabasenoden on-prem

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

Opret replikeringsbrugeren fra din Azure Database-kildenode

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

Sørg for at ændre IP-adressen på din målknudes IP-adresse som den klient, der skal oprettes forbindelse fra.

Konfigurer MySQL/MariaDB-serveren som en replika/slave af Azure Database-kildenoden

## Lad os først søge eller finde kommandoen 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;

## Kør CHANGE MASTER-sætningen, men tilføj replikeringsbrugeren/adgangskoden og værtsnavnet som følger,

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

## I nogle tilfælde skal du muligvis ignorere mysql-skemaet. Kør følgende sætning:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Start derefter slavetrådene

START SLAVE;

## Tjek slavestatus, hvordan det går

SHOW SLAVE STATUS \G

Nu hvor vi endelig har været i stand til at replikere fra Azure Database enten for MySQL/MariaDB som kilden til din replika placeret on-prem.

Brug af mydumper

Azure Database til MySQL eller MariaDB antyder faktisk, at brug af mydumper specielt til store sikkerhedskopier såsom 1TB kan være din alternative mulighed. Det giver parallelitet og hastighed, når du tager en dump eller en sikkerhedskopi af dit datasæt fra en Azure-databaseknudekilde.

Følg nedenstående trin fra installation af mydumper til indlæsning af den til din lokale destinationsserver.

Installer det binære. De binære filer kan findes her 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

Tag sikkerhedskopien fra Azure Database-kildenoden. For eksempel,

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

….

Som du kan se, er der en begrænsning i at tage backup fra en administreret database såsom Azure. Du bemærker måske,

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

Dette er fordi SUPERPRIVILEGE ikke er understøttet eller begrænset. Ideelt set er den bedste mulighed for at gøre dette at tage sikkerhedskopien fra en replika af din Azure-database. Vi taler om dette senere.

Nu, på dette tidspunkt vil mydumper tage en sikkerhedskopi af filer i form af *.gz-filer

Indlæs den til din destinationsserver på stedet

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

…

….

Opsæt destinationsknuden som en slave/replika. MyDumper vil indeholde en fil kaldet metadata, der består af binære logkoordinater inklusive GTID -positioner, for eksempel:

$ 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

## Kør derefter en ændringsmaster fra replikaen eller din måldestination MySQL/MariaDB-databaseknude

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 slaven

START SLAVE;

På dette tidspunkt har du nu replikeret fra en Azure Database-instans, der kører MySQL/MariaDB. Når din applikation er klar til at flytte væk fra din Azure Database-instans, skal du konfigurere slutpunktet, der går til din lokale server, og alle resterende transaktioner fra din Azure-instans vil blive replikeret til din lokale, så der ikke går nogen data glip af til din on-prem-instans. prem-server.

Håndtering af begrænsninger med administrerede databaser til MySQL eller MariaDB i Azure

Håndtering af begrænsninger, især når du tager et backup-dump af dit datasæt, skal være 100 % nøjagtigt fra det tidspunkt, hvor du har taget backup-dumpet. Selvfølgelig er dette en ideel migrering til dit lokale. For at håndtere dette er den bedste arkitekturopsætning at have en replikeringstopologi tilstede i din Azure-database.

Når du har den og klar til migrering, skal mysqldump/mysqlpump eller mydumper bruge Azure Database-replikaen som sin kilde. Inden for denne Azure Database-replika skal du sørge for, at SQL_THREAD er stoppet, så du kan snapshot eller optage den korrekte MASTER_LOG_FILE og EXEC_MASTER_LOG_POS fra resultatet af SHOW SLAVE STATUS.

Glem selvfølgelig ikke at starte din Azure Database-replik for at starte replikeringstrådene igen, når sikkerhedskopieringen er udført.

Se efter dataafvigelser

Når du har dine data indlæst eller dumpet til din lokale server, der fungerer som en replika fra Azure Database-instansen, bør du dobbelttjekke dette ved at køre kontrolsumberegninger for at bestemme, hvor langt dine data er i forhold til kilde Azure Database. Vi foreslår, at du bruger pt-table-checksum-værktøjet fra Percona Toolkit, men du kan oprette dit eget ved at bruge kontrolsummeværktøjer såsom md5 eller sha256, men det tager tid at gøre. Derudover kan brug af pt-upgrade fra Percona Toolkit også hjælpe efter din datamigrering ved hjælp af denne replikeringstilgang er færdig.

Konklusion

Begrænsninger af privilegier og ikke-understøttede typer fra Azure Database kan være udfordrende, men med det passende flow og arkitektur er det ikke umuligt at migrere fra en fuldt administreret database, der foregår on-prem. Alt du skal gøre er at forberede de påkrævede trin, konfigurere den påkrævede topologi fra din Azure Database-kilde og derefter starte migreringen fra at tage sikkerhedskopier, til replikering og total migrering til din lokale.