MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Migration de la base de données Azure pour MySQL/MariaDB vers un serveur sur site

Les migrations de bases de données peuvent imposer d'énormes défis lorsque vous considérez comment démarrer, quels outils utiliser et comment réussir une migration complète de base de données. Plus tôt, nous avons répertorié les meilleurs open source que vous pouvez utiliser lors de la migration pour MySQL ou MariaDB. Dans ce blog, nous allons vous montrer comment migrer des données depuis Microsoft Azure Database pour MySQL ou MariaDB.

Microsoft Azure est désormais connu pour être un concurrent face aux deux autres géants de la technologie cloud :AWS et Google Cloud. Il spécialise davantage ses produits Microsoft, en particulier sa base de données propriétaire MSSQL. Mais pas seulement cela, il a également des sources ouvertes comme l'une de leurs bases de données de services entièrement gérées à offrir au public. Parmi ses bases de données prises en charge figurent MySQL et MariaDB.

Déplacer d'Azure Database pour MySQL/MariaDB peut être fastidieux, mais cela dépend du type d'architecture et du type d'ensemble de données que vous avez hébergé dans votre Azure en tant que fournisseur de cloud actuel. Avec les bons outils, cela peut être réalisable et une migration complète peut être effectuée.

Nous nous concentrerons sur les outils que nous pouvons utiliser pour les migrations de données sur MySQL ou MariaDB. Pour ce blog, j'utilise RHEL/CentOS pour installer les packages requis. Passons en revue et définissons les étapes et les procédures pour y parvenir.

Migration depuis Azure Database pour MySQL ou MariaDB

Une approche typique de la migration de vos données d'Azure Database vers un serveur sur site consiste à effectuer une sauvegarde à l'aide d'une copie logique. Cela peut être fait à l'aide de solutions utilitaires de sauvegarde compatibles pour fonctionner avec Azure Database pour MySQL ou MariaDB, qui est un service entièrement géré. Les services de base de données entièrement gérés n'offrent pas de connexions SSH, la copie physique des sauvegardes n'est donc pas une option.

Avant de pouvoir migrer ou vider votre base de données existante à partir d'Azure, vous devez prendre note des considérations suivantes.

Cas d'utilisation courants pour le vidage et la restauration sur site

Les cas d'utilisation les plus courants sont :

  • L'utilisation de la sauvegarde logique (telle que mysqldump, mysqlpump ou mydumper/myloader) et de la restauration est la seule option. Azure Database pour MySQL ou MariaDB ne prend pas en charge l'accès physique au stockage physique car il s'agit d'un service de base de données entièrement géré.
  • Prend uniquement en charge les moteurs de stockage InnoDB et Memory. Migration des moteurs de stockage alternatifs vers InnoDB. Azure Database pour MySQL ou MariaDB prend uniquement en charge le moteur de stockage InnoDB et ne prend donc pas en charge les autres moteurs de stockage. Si vos tables sont configurées avec d'autres moteurs de stockage, convertissez-les au format de moteur InnoDB avant la migration vers Azure Database pour MySQL.
  • Par exemple, si vous avez un WordPress ou une application Web utilisant les tables MyISAM, convertissez d'abord ces tables en migrant au format InnoDB avant de les restaurer vers Azure Database pour MySQL. Utilisez la clause ENGINE=InnoDB pour définir le moteur utilisé lors de la création d'une nouvelle table, puis transférez les données dans la table compatible avant la restauration.
  • Si votre base de données Azure source est sur une version spécifique, votre serveur sur site cible a également été la même version que la base de données Azure source.

Donc, avec ces limitations, vous vous attendez uniquement à ce que vos données d'Azure soient un moteur de stockage InnoDB ou une mémoire, s'il y en a dans votre jeu de données.

Considérations sur les performances pour effectuer une sauvegarde logique à partir d'une base de données Azure

La seule façon d'effectuer une sauvegarde logique avec Azure est d'utiliser mysqldump ou mysqlpump. Pour optimiser les performances lors d'un vidage à l'aide de ces outils, tenez compte de ces considérations lors du vidage de bases de données volumineuses :

  • Utilisez l'option exclude-triggers dans mysqldump lors du vidage des bases de données. Excluez les déclencheurs des fichiers de vidage pour éviter que les commandes de déclencheur ne se déclenchent pendant la restauration des données.
  • Utilisez l'option de transaction unique pour définir le mode d'isolation de transaction sur REPEATABLE READ et envoyer une instruction SQL START TRANSACTION au serveur avant de vider les données. Le vidage de nombreuses tables au sein d'une même transaction entraîne la consommation d'espace de stockage supplémentaire lors de la restauration. L'option de transaction unique et l'option de verrouillage des tables s'excluent mutuellement car LOCK TABLES entraîne la validation implicite de toutes les transactions en attente. Pour vider de grandes tables, combinez l'option de transaction unique avec l'option rapide.
  • Utilisez la syntaxe à plusieurs lignes d'insertion étendue qui inclut plusieurs listes VALUE. Cela se traduit par un fichier de vidage plus petit et accélère les insertions lorsque le fichier est rechargé.
  • Utilisez l'option order-by-primary dans mysqldump lors du vidage des bases de données, afin que les données soient scriptées dans l'ordre de la clé primaire.
  • Utilisez l'option disable-keys dans mysqldump lors du vidage des données, pour désactiver les contraintes de clé étrangère avant le chargement. La désactivation des vérifications de clé étrangère offre des gains de performances. Activez les contraintes et vérifiez les données après le chargement pour garantir l'intégrité référentielle.
  • Utilisez des tables partitionnées, le cas échéant.
  • Charger des données en parallèle. Évitez trop de parallélisme qui vous ferait atteindre une limite de ressources et surveillez les ressources à l'aide des métriques disponibles dans le portail Azure.
  • Utilisez l'option defer-table-indexes dans mysqlpump lors du vidage des bases de données, afin que la création d'index se produise après le chargement des données de la table.
  • Utilisez l'option skip-definer dans mysqlpump pour omettre les clauses de définition et SQL SECURITY des instructions de création pour les vues et les procédures stockées. Lorsque vous rechargez le fichier de vidage, il crée des objets qui utilisent les valeurs par défaut DEFINER et SQL SECURITY.
  • Copiez les fichiers de sauvegarde dans un blob/magasin Azure et effectuez la restauration à partir de là, ce qui devrait être beaucoup plus rapide que d'effectuer la restauration via Internet.

Non pris en charge

Les éléments suivants ne sont pas pris en charge :

  • Rôle DBA :restreint. Vous pouvez également utiliser l'utilisateur administrateur (créé lors de la création d'un nouveau serveur), qui vous permet d'effectuer la plupart des instructions DDL et DML.
  • Privilège SUPER :de même, le privilège SUPER est restreint.
  • DEFINER :nécessite des super privilèges pour créer et est restreint. Si vous importez des données à l'aide d'une sauvegarde, supprimez les commandes CREATE DEFINER manuellement ou en utilisant la commande --skip-definer lors de l'exécution d'un mysqldump.
  • Bases de données système :la base de données système mysql est en lecture seule et utilisée pour prendre en charge diverses fonctionnalités PaaS. Vous ne pouvez pas apporter de modifications à la base de données du système mysql.
  • SELECT ... INTO OUTFILE :non pris en charge dans le service.

Utiliser mysqldump

L'utilisation de mysqldump doit être installée dans votre nœud de base de données cible situé sur site. Il doit être préparé comme un réplica du nœud de la base de données Azure afin que toutes les transactions ultérieures soient répliquées sur le nœud. Pour ce faire, suivez les étapes ci-dessous.

Installer mysqldump

  1. Préparez le référentiel.

# Pour MySQL

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

# Pour MariaDB

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

  1. Installer le paquet mysql-client

# Pour MySQL

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

# Pour MariaDB

$ yum install -y MariaDB-client

  1. Créez un vidage de données à l'aide de mysqldump en l'exécutant à l'intérieur du nœud cible.

$ 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

  1. Installer le serveur MySQL/MariaDB dans le nœud de base de données cible

# Pour MySQL

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

# Pour MariaDB

$ yum install MariaDB-server.x86_64

  1. Configurer l'instance du serveur MySQL/MariaDB (my.cnf, autorisations de fichiers, répertoires) et démarrer le serveur 

# Configuration de my.cnf (en utilisant le déploiement my.cnf utilisé par 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

## Réinitialisez le répertoire de données et réinstallez les fichiers système de la base de données

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

## Créer les répertoires de journaux

$ mkdir /var/log/mysql

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

## Pour MySQL

$ mysqld --initialize

## Pour MariaDB

$ mysql_install_db

  1. Démarrer le serveur MySQL/MariaDB

## Pour MySQL

$ systemctl start mysqld

## Pour MariaDB

$ systemctl start mariadb

  1. Charger le vidage de données que nous avons pris d'Azure Database vers le nœud de base de données cible sur site

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

  1. Créer l'utilisateur de réplication à partir de votre nœud source 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';

Assurez-vous de changer l'adresse IP de l'adresse IP de votre nœud cible en tant que client à partir duquel vous connecter.

  1. Configurer le serveur MySQL/MariaDB en tant que réplica/esclave du nœud source de la base de données Azure

## Tout d'abord, recherchons ou localisons la commande 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;

## Exécutez l'instruction CHANGE MASTER mais ajoutez l'utilisateur/mot de passe de réplication et le nom d'hôte comme suit,

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

## Dans certains cas, vous devrez peut-être ignorer le schéma mysql. Exécutez l'instruction suivante :

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Puis démarrez les threads esclaves

START SLAVE;

## Vérifiez l'état de l'esclave comment ça se passe

SHOW SLAVE STATUS \G

Maintenant que nous avons enfin pu répliquer à partir d'Azure Database soit pour MySQL/MariaDB comme source de votre réplique située sur site.

Utiliser mydumper

Azure Database pour MySQL ou MariaDB suggère en fait que l'utilisation de mydumper spécialement pour les sauvegardes volumineuses telles que 1 To peut être votre option alternative. Il offre parallélisme et rapidité lors de la prise d'un vidage ou d'une copie de sauvegarde de votre jeu de données à partir d'un nœud Azure Database source.

 Suivez les étapes ci-dessous depuis l'installation de mydumper jusqu'à son chargement sur votre serveur de destination sur site.

  1. Installez le binaire. Les binaires peuvent être localisés ici 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

  1. Effectuez la sauvegarde à partir du nœud source de la base de données Azure. Par exemple,

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

….

Comme vous pouvez le voir, il existe une limite à la sauvegarde à partir d'une base de données gérée telle qu'Azure. Vous remarquerez peut-être,

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

C'est parce que SUPER PRIVILEGE n'est pas pris en charge ou restreint. Idéalement, la meilleure option consiste à effectuer la sauvegarde à partir d'un réplica de votre base de données Azure. Nous en reparlerons plus tard.

Maintenant, à ce stade, mydumper prendra des fichiers de sauvegarde sous la forme de fichiers *.gz

  1. Chargez-le sur votre serveur de destination sur site

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

…

….

  1. Configurez le nœud de destination en tant qu'esclave/réplique. MyDumper comprendra un fichier appelé métadonnées qui se compose de coordonnées de journal binaire, y compris les positions GTID, par exemple:

$ 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

## Ensuite, exécutez un maître de modification à partir du réplica ou de votre nœud de base de données MySQL/MariaDB de destination cible

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

## Démarrer l'esclave

START SLAVE;

À ce stade, vous avez maintenant répliqué à partir d'une instance de base de données Azure exécutant MySQL/MariaDB. Une fois que votre application est prête à s'éloigner de votre instance de base de données Azure, configurez le point de terminaison vers votre serveur sur site et toutes les transactions restantes de votre instance Azure seront répliquées sur votre site sur site, ne laissant aucune donnée manquante sur votre serveur sur site. serveur prem.

Limites de gestion avec les bases de données gérées pour MySQL ou MariaDB dans Azure

La gestion des limitations, en particulier lors de la prise d'un vidage de sauvegarde de votre ensemble de données, doit être précise à 100 % à partir du moment où vous avez pris le vidage de sauvegarde. Bien sûr, il s'agit d'une migration idéale vers votre site sur site. Afin de gérer cela, la meilleure configuration d'architecture consiste à disposer d'une topologie de réplication dans votre base de données Azure.

Une fois que vous l'avez et que vous êtes prêt pour la migration, mysqldump/mysqlpump ou mydumper doit utiliser le réplica Azure Database comme source. Dans ce réplica Azure Database, assurez-vous que le SQL_THREAD est arrêté afin que vous puissiez prendre un instantané ou enregistrer le MASTER_LOG_FILE et EXEC_MASTER_LOG_POS corrects à partir du résultat de SHOW SLAVE STATUS.

Bien sûr, une fois la sauvegarde effectuée, n'oubliez pas de démarrer votre réplica Azure Database pour relancer ses threads de réplication.

Vérifier les écarts de données

Une fois que vous avez chargé ou vidé vos données sur votre serveur sur site agissant comme un réplica à partir de l'instance Azure Database, vous devez vérifier cela en exécutant des calculs de somme de contrôle pour déterminer la distance entre vos données et base de données Azure source. Nous vous suggérons d'utiliser l'outil pt-table-checksum de Percona Toolkit, mais vous pouvez créer le vôtre en utilisant des outils de somme de contrôle tels que md5 ou sha256, mais cela prend du temps. De plus, l'utilisation de pt-upgrade de Percona Toolkit peut également vous aider après la migration de vos données à l'aide de cette approche de réplication.

Conclusion

Les limitations de privilèges et les types non pris en charge d'Azure Database peuvent être difficiles, mais avec le flux et l'architecture appropriés, il n'est pas impossible de migrer depuis une base de données entièrement gérée sur site. Tout ce que vous avez à faire est de préparer les étapes requises, de configurer la topologie requise à partir de votre source de base de données Azure, puis de démarrer la migration depuis la prise de sauvegardes, la réplication et la migration totale vers votre site sur site.