Migrera Azure Database for MySQL/MariaDB till en lokal server

Databasmigreringar kan innebära enorma utmaningar när du tänker på hur du ska börja, vilka verktyg du ska använda och hur du kan uppnå en fullständig databasmigrering framgångsrikt. Tidigare har vi listat den bästa öppna källkoden du kan använda vid migrering för MySQL eller MariaDB. I den här bloggen visar vi dig hur du migrerar data från Microsoft Azure Database for MySQL eller MariaDB.

Microsoft Azure är nu känt för att vara en utmanare mot de två andra molnteknikjättarna:AWS och Google Cloud. Det specialiserar sig på fler av sina Microsoft-produkter, speciellt deras egenutvecklade MSSQL-databas. Men inte bara det, den har också öppna källor som en av deras helt hanterade tjänstedatabaser att erbjuda offentligt. Bland dess stödda databaser finns MySQL och MariaDB.

Att flytta ut från Azure Database för MySQL/MariaDB kan vara tråkigt men det beror på vilken typ av arkitektur och vilken typ av datauppsättning du har värd i din Azure som din nuvarande molnleverantör. Med rätt verktyg kan det vara möjligt och en fullständig migrering kan göras.

Vi kommer att fokusera på verktygen vi kan använda för datamigreringar på MySQL eller MariaDB. För den här bloggen använder jag RHEL/CentOS för att installera de nödvändiga paketen. Låt oss gå över och definiera stegen och procedurerna för hur man gör detta.

Migrera från Azure Database for MySQL eller MariaDB

En typisk metod för att migrera dina data från Azure Database till en lokal server är att ta en säkerhetskopia med en logisk kopia. Detta kan göras med hjälp av säkerhetskopieringsverktyg som är kompatibla att arbeta med Azure Database for MySQL eller MariaDB som är en helt hanterad tjänst. Fullt hanterade databastjänster erbjuder inte SSH-inloggningar så fysisk kopia av säkerhetskopior är inte ett alternativ.

Innan du kan migrera eller dumpa din befintliga databas från Azure måste du tänka på följande.

Vanliga användningsfall för dumpning och återställning på plats

De vanligaste användningsfallen är:

Att använda logisk säkerhetskopiering (som mysqldump, mysqlpump eller mydumper/myloader) och återställning är det enda alternativet. Azure Database for MySQL eller MariaDB stöder inte fysisk åtkomst till den fysiska lagringen eftersom detta är en fullständigt hanterad databastjänst.
Stöder endast InnoDB- och minneslagringsmotorer. Migrera från alternativa lagringsmotorer till InnoDB. Azure Database for MySQL eller MariaDB stöder endast InnoDB Storage-motor och stöder därför inte alternativa lagringsmotorer. Om dina tabeller är konfigurerade med andra lagringsmotorer, konvertera dem till InnoDB-motorformatet innan migreringen till Azure Database for MySQL.
Om du till exempel har en WordPress eller WebApp som använder MyISAM-tabellerna, konvertera först dessa tabeller genom att migrera till InnoDB-format innan du återställer till Azure Database for MySQL. Använd satsen ENGINE=InnoDB för att ställa in motorn som används när du skapar en ny tabell, överför sedan data till den kompatibla tabellen före återställningen.
Om din Azure-källdatabas finns på en specifik version, har din målserver också varit samma version som Azure-källdatabasen.

Så med dessa begränsningar förväntar du dig bara att dina data från Azure måste vara InnoDB-lagringsmotor eller minne, om det finns sådana i din datauppsättning.

Prestandaöverväganden för att ta logisk säkerhetskopiering från Azure Database

Det enda sättet att ta en logisk säkerhetskopia med Azure är att använda mysqldump eller mysqlpump. För att optimera prestandan när du tar en dumpning med dessa verktyg bör du tänka på följande när du dumpar stora databaser:

Använd alternativet exclude-triggers i mysqldump när du dumpar databaser. Uteslut triggers från dumpfiler för att undvika att triggerkommandona aktiveras under dataåterställningen.
Använd alternativet för en transaktion för att ställa in transaktionsisoleringsläget till REPEATABLE READ och skicka en START TRANSACTION SQL-sats till servern innan du dumpar data. Att dumpa många tabeller inom en enda transaktion gör att en del extra lagringsutrymme förbrukas under återställning. Alternativet för en transaktion och alternativet för låsta tabeller är ömsesidigt uteslutande eftersom LOCK TABLES gör att alla pågående transaktioner genomförs implicit. För att dumpa stora tabeller, kombinera alternativet för en transaktion med snabbalternativet.
Använd syntaxen för utökad infogning av flera rader som innehåller flera VALUE-listor. Detta resulterar i en mindre dumpfil och snabbare infogning när filen laddas om.
Använd alternativet order-by-primary i mysqldump när du dumpar databaser, så att data skriptas i primärnyckelordning.
Använd alternativet disable-keys i mysqldump när du dumpar data, för att inaktivera begränsningar för främmande nycklar före laddning. Att inaktivera kontroller av främmande nyckel ger prestandavinster. Aktivera begränsningarna och verifiera data efter laddningen för att säkerställa referensintegritet.
Använd partitionerade tabeller när det är lämpligt.
Ladda data parallellt. Undvik för mycket parallellitet som skulle få dig att nå en resursgräns och övervaka resurser med hjälp av mätvärdena som finns tillgängliga i Azure-portalen.
Använd alternativet defer-table-indexes i mysqlpump när du dumpar databaser, så att index skapas efter att tabellens data har laddats.
Använd skip-definer-alternativet i mysqlpump för att utelämna definier- och SQL SECURITY-satser från skapa-satserna för vyer och lagrade procedurer. När du laddar om dumpfilen skapar den objekt som använder standardvärdena DEFINER och SQL SECURITY.
Kopiera säkerhetskopieringsfilerna till en Azure-blob/butik och utför återställningen därifrån, vilket borde vara mycket snabbare än att utföra återställningen över Internet.

Stöds inte

Följande stöds inte:

DBA-roll:Begränsad. Alternativt kan du använda administratörsanvändaren (som skapades när en ny server skapades), som låter dig utföra de flesta DDL- och DML-satser.
SUPER-behörighet:På samma sätt är SUPER-behörighet begränsad.
DEFINER:Kräver superprivilegier för att skapa och är begränsad. Om du importerar data med hjälp av en säkerhetskopia, ta bort CREATE DEFINER-kommandona manuellt eller genom att använda kommandot --skip-definer när du utför en mysqldump.
Systemdatabaser:Mysql-systemdatabasen är skrivskyddad och används för att stödja olika PaaS-funktioner. Du kan inte göra ändringar i mysql-systemets databas.
VÄLJ ... INTO UTFIL:Stöds inte i tjänsten.

Använda mysqldump

Att använda mysqldump måste installeras i din måldatabasnod som finns på plats. Den måste förberedas som en replik av Azure Database-noden så att alla efterföljande transaktioner ska replikeras till noden. För att göra detta, följ stegen nedan.

Installera mysqldump

Förbered arkivet.

# för MySQL

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

# För MariaDB

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

Installera mysql-client-paketet

# För MySQL

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

# För MariaDB

$ yum install -y MariaDB-client

Skapa en datadump med mysqldump genom att köra den inuti målnoden.

$ 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

Installera MySQL/MariaDB-servern i måldatabasnoden

# för MySQL

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

# För MariaDB

$ yum install MariaDB-server.x86_64

Ställ in MySQL/MariaDB Server-instansen (my.cnf, filbehörigheter, kataloger) och starta servern

# Konfigurera my.cnf (med my.cnf-distributionen som används av 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

## Återställ datakatalogen och installera om databassystemfilerna

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

## Skapa loggkatalogerna

$ mkdir /var/log/mysql

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

## För MySQL

$ mysqld --initialize

## För MariaDB

$ mysql_install_db

Starta MySQL/MariaDB-servern

## för MySQL

$ systemctl start mysqld

## För MariaDB

$ systemctl start mariadb

Läs in datadumpen som vi har tagit från Azure Database till måldatabasnoden på plats

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

Skapa replikeringsanvändaren från din Azure Database-källnod

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

Se till att du ändrar IP-adressen för din målnods IP-adress som klienten att ansluta från.

Konfigurera MySQL/MariaDB-servern som en replika/slav av Azure Database-källnoden

## Låt oss först söka eller hitta kommandot 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-satsen men lägg till replikeringsanvändaren/lösenordet och värdnamnet enligt följande,

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 vissa fall kan du behöva ignorera mysql-schemat. Kör följande programsats:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Starta sedan slavtrådarna

START SLAVE;

## Kontrollera slavstatusen hur det går

SHOW SLAVE STATUS \G

Nu när vi äntligen har kunnat replikera från Azure Database antingen för MySQL/MariaDB som källan till din replika lokaliserad.

Använda mydumper

Azure Database for MySQL eller MariaDB tyder faktiskt på att användning av mydumper speciellt för stora säkerhetskopior som 1TB kan vara ditt alternativa alternativ. Det erbjuder parallellitet och hastighet när du tar en dump eller säkerhetskopia av din datauppsättning från en källnod för Azure Database.

Följ stegen nedan från installation av mydumper till att ladda den till din lokala destinationsserver.

Installera binären. Binärfilerna finns här 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

Ta säkerhetskopian från Azure Database-källnoden. Till exempel,

[[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 finns det en begränsning för att säkerhetskopiera från en hanterad databas som Azure. Du kanske märker,

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

Detta beror på att SUPER PRIVILEGE inte stöds eller är begränsad. Helst är det bästa alternativet att göra detta att ta säkerhetskopian från en replik av din Azure-databas. Vi kommer att prata om detta senare.

Nu, vid denna tidpunkt, kommer mydumper att ta en säkerhetskopia av filer i form av *.gz-filer

Ladda den till din destinationsserver på plats

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

…

….

Ställ in destinationsnoden som en slav/replika. MyDumper kommer att innehålla en fil som heter Metadata som består av binära logkkoordinater inklusive GTID -positioner, till exempel:

$ 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 sedan en ändringsmaster från repliken eller din måldestinationsnod 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';

## Starta slaven

START SLAVE;

Vid det här laget har du nu replikerat från en Azure Database-instans som kör MySQL/MariaDB. När din applikation är redo att flytta bort från din Azure Database-instans, konfigurerar du slutpunkten som går till din lokala server och alla återstående transaktioner från din Azure-instans kommer att replikeras till din lokala och lämnar ingen data som missas som går till din on-prem. prem-server.

Hantera begränsningar med hanterade databaser för MySQL eller MariaDB i Azure

Att hantera begränsningar, särskilt när du tar en säkerhetskopieringsdump av din datauppsättning, måste vara 100 % korrekt från den tidpunkt då du har tagit backupdumpen. Naturligtvis är detta en idealisk migrering till din lokala plats. För att hantera detta är den bästa arkitekturinställningen att ha en replikeringstopologi i din Azure-databas.

När du har den och redo för migrering måste mysqldump/mysqlpump eller mydumper använda Azure Database-repliken som sin källa. Inom den Azure Database-repliken, se till att SQL_THREAD är stoppad så att du kan ögonblicksbilda eller spela in rätt MASTER_LOG_FILE och EXEC_MASTER_LOG_POS från resultatet av SHOW SLAVE STATUS.

Glöm naturligtvis inte att starta din Azure Database-replik för att starta replikeringstrådarna igen när säkerhetskopieringen har gjorts.

Kontrollera efter dataavvikelser

När du har din data laddad eller dumpad till din lokala server som fungerar som en replik från Azure Database-instansen, bör du dubbelkolla detta genom att köra checksummeberäkningar för att avgöra hur långt din data ligger mot källa Azure Database. Vi föreslår att du använder pt-table-checksum-verktyget från Percona Toolkit, men du kan skapa ditt eget genom att använda kontrollsummarverktyg som md5 eller sha256, men det tar tid att göra. Dessutom kan användning av pt-upgrade från Percona Toolkit hjälpa till efter att din datamigrering med denna replikeringsmetod är klar.

Slutsats

Begränsningar av privilegier och typer som inte stöds från Azure Database kan vara utmanande men med lämpligt flöde och arkitektur är det inte omöjligt att migrera från en helt hanterad databas på plats. Allt du behöver göra är att förbereda de nödvändiga stegen, ställa in den nödvändiga topologin från din Azure Database-källa och sedan starta migreringen från att ta säkerhetskopior, till replikering och total migrering till din lokala.