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

Migration d'Amazon RDS (MySQL ou MariaDB) vers un serveur sur site

Amazon Web Services est un géant de la technologie, en particulier lorsqu'il s'agit d'être le pionnier des services de cloud computing haut de gamme. Ses produits de services entièrement gérés (Amazon RDS) sont uniques en leur genre. Mais encore une fois, même si cela peut être une plate-forme parfaite pour certaines organisations, il peut être difficile de s'en éloigner si ce n'est pas le cas. On craint toujours d'être coincé dans une situation de verrouillage du fournisseur.

Certaines choses à garder à l'esprit lors de la migration de RDS vers une plate-forme sur site sont les contraintes budgétaires, la sécurité et l'autonomie des données. En effet, les données sont votre atout le plus précieux et en gardant le contrôle où qu'elles se trouvent, il est toujours impératif pour l'organisation et l'entreprise de toujours rester compétitives. Aucune organisation ne peut se permettre d'avoir un cloud verrouillé, et pourtant, de nombreuses entreprises se retrouvent exactement dans cette situation et commencent à rechercher toutes les solutions existantes alternatives qui peuvent être opérationnelles via sur site.

Ce blog vous expliquera comment migrer d'Amazon RDS vers un serveur sur site. Notre base de données cible sur le serveur sur site se trouve sur un serveur Linux RHEL/CentOS, mais la procédure applicable s'applique aux autres versions de Linux ainsi que tant que les packages sont correctement installés.

Certaines solutions tierces existantes proposent la migration des données, mais elles ne s'appliquent pas à une plate-forme sur site. De plus, ce n'est pas gratuit et migrer en utilisant gratuitement avec des solutions open source est toujours favorable et avantageux. Bien que des doutes et des inquiétudes existent également puisque la garantie et le support ne sont pas liés aux technologies open source, nous vous montrerons ici comment y parvenir dans une procédure simple.

Étant donné qu'Amazon RDS prend en charge la compatibilité avec MySQL et MariaDB. Nous nous concentrerons sur eux pour ce blog.

Migration depuis Amazon RDS pour MySQL ou MariaDB

Une approche typique de la migration de vos données d'Amazon RDS 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 Amazon RDS 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.

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 une réplique du nœud AWS RDS afin que toutes les transactions ultérieures soient répliquées sur le nœud. Pour ce faire, suivez les étapes ci-dessous.

Hôte source AWS RDS :base de données-1.xxxxxxx.us-east-2.rds.amazonaws.com

Hébergeur de serveur sur site :192.168.10.226 (testnode26)

Avant de démarrer le vidage, assurez-vous que les heures de rétention binlog sont définies. Pour le définir, vous pouvez faire comme l'exemple d'appel de procédure ci-dessous dans votre instance Amazon RDS,

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

Query OK, 2 rows affected (0.23 sec)



mysql> CALL mysql.rds_show_configuration;

+------------------------+-------+------------------------------------------------------------------------------------------------------+

| name                   | value | description                                                                                          |

+------------------------+-------+------------------------------------------------------------------------------------------------------+

| binlog retention hours | 24    | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |

+------------------------+-------+------------------------------------------------------------------------------------------------------+

1 row in set (0.23 sec)



Query OK, 0 rows affected (0.23 sec)

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. Notez qu'avec --master-data=2 spécifié comme option, cela ne fonctionne que pour MariaDB mais pas dans MySQL. Donc, un travail supplémentaire pour MySQL doit être fait. Nous en reparlerons plus tard.

## Applicable à l'approche MariaDB

[[email protected] ~]# mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --master-data=2 --databases db1 db2 db3  > backups/dump.sql

Enter password:

[[email protected] ~]# ls -alth backups/dump.sql

-rw-r--r--. 1 root root 196M Oct 18 02:34 backups/dump.sql

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

# Pour MySQL (vérifiez toujours quelle version du référentiel est activée dans votre référentiel yum. À ce stade, j'utilise MySQL 5.7)

$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server

# 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'AWS RDS sur 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 du nœud source AWS RDS

MariaDB [(none)]> CREATE USER 'repl_user'@'149.145.213.%' IDENTIFIED BY 'repl_passw0rd';

Query OK, 0 rows affected (0.242 sec)



MariaDB [(none)]>  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO repl_user'@'149.145.213.%'  IDENTIFIED BY 'repl_passw0rd' ;

Query OK, 0 rows affected (0.229 sec)

  1. Configurer le serveur MySQL/MariaDB en tant que réplique/esclave du nœud source AWS RDS

## Tout d'abord, recherchons ou localisons la commande CHANGE MASTER

[[email protected] ~]# grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421;

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

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='database-1.xxxxxxx.us-east-2.rds.amazonaws.com', MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

Query OK, 0 rows affected (0.004 sec)

## Puis démarrez les threads esclaves

MariaDB [(none)]> START SLAVE;

Query OK, 0 rows affected (0.001 sec)

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

MariaDB [(none)]> SHOW SLAVE STATUS \G

*************************** 1. row ***************************

                Slave_IO_State: Waiting for master to send event

                   Master_Host: database-1.xxxxxxx.us-east-2.rds.amazonaws.com

                   Master_User: repl_user

                   Master_Port: 3306

                 Connect_Retry: 60

               Master_Log_File: mysql-bin-changelog.000584

           Read_Master_Log_Pos: 421

                Relay_Log_File: relay-bin.000001

                 Relay_Log_Pos: 4

         Relay_Master_Log_File: mysql-bin-changelog.000584

              Slave_IO_Running: Yes

             Slave_SQL_Running: Yes

               Replicate_Do_DB:

           Replicate_Ignore_DB:

            Replicate_Do_Table:

        Replicate_Ignore_Table:

       Replicate_Wild_Do_Table:

   Replicate_Wild_Ignore_Table:

                    Last_Errno: 0

                    Last_Error:

                  Skip_Counter: 0

           Exec_Master_Log_Pos: 421

               Relay_Log_Space: 256

               Until_Condition: None

                Until_Log_File:

                 Until_Log_Pos: 0

            Master_SSL_Allowed: No

            Master_SSL_CA_File:

            Master_SSL_CA_Path:

               Master_SSL_Cert:

             Master_SSL_Cipher:

                Master_SSL_Key:

         Seconds_Behind_Master: 0

 Master_SSL_Verify_Server_Cert: No

                 Last_IO_Errno: 0

                 Last_IO_Error:

                Last_SQL_Errno: 0

                Last_SQL_Error:

   Replicate_Ignore_Server_Ids:

              Master_Server_Id: 1675507089

                Master_SSL_Crl:

            Master_SSL_Crlpath:

                    Using_Gtid: No

                   Gtid_IO_Pos:

       Replicate_Do_Domain_Ids:

   Replicate_Ignore_Domain_Ids:

                 Parallel_Mode: optimistic

                     SQL_Delay: 0

           SQL_Remaining_Delay: NULL

       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

              Slave_DDL_Groups: 0

Slave_Non_Transactional_Groups: 0

    Slave_Transactional_Groups: 0

1 row in set (0.000 sec)

Maintenant que nous avons enfin pu répliquer à partir de RDS en tant que source ou maître de notre réplica situé sur site. Ce n'est pas encore fait. Dans certains cas, vous rencontrerez des erreurs de réplication telles que,      

Last_SQL_Errno: 1146

                Last_SQL_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1602988485784) ON DUPLICATE KEY UPDATE value = 1602988485784'

 Puisque sur site n'a pas besoin de répliquer les données provenant de la base de données mysql pour les tables préfixées par 'rds%', nous ignorons simplement ces tables lors de la réplication. En outre, vous ne souhaitez peut-être pas qu'AWS RDS mette à jour et modifie votre table mysql.user. Pour ce faire, vous pouvez éventuellement ignorer le schéma ou simplement une liste de tables telles que,

STOP SLAVE;

Alors,

SET GLOBAL replicate_wild_ignore_table='mysql.rds%';

ou

SET GLOBAL replicate_wild_ignore_table='mysql.%';

Le problème MySQL avec --master-data=2

Prendre le mysqldump avec --master-data=2 nécessite des privilèges suffisants qui nécessitent les privilèges SUPER et RELOAD. Le problème est qu'AWS RDS ne le fournit pas à l'utilisateur administrateur lors de la configuration et de la création de la base de données. Pour contourner ce problème, il faut que votre AWS RDS dispose d'un maître et d'un réplica ou d'une configuration esclave. Une fois que vous avez une configuration esclave, prenez-la comme hôte source cible lors de la prise de mysqldump. Arrêtez ensuite les threads esclaves de votre réplica AWS RDS comme suit,

rds-replica-mysql> CALL mysql.rds_stop_replication;

Ensuite, prenez mysqldump sans l'option --master-data comme ci-dessous,

mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3  > backups/dump.sql

Ensuite, exécutez SHOW SLAVE STATUS\G à partir de votre réplica AWS RDS et notez les Master_Log_File et Exec_Master_Log_Pos que vous utiliserez lors de la connexion au maître AWS RDS répliqué sur votre serveur sur site. Utilisez ces coordonnées lors de l'exécution de CHANGE MASTER TO… MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=. Bien entendu, une fois la sauvegarde effectuée, n'oubliez pas de démarrer votre réplica RDS pour relancer ses threads de réplication,

rds-replica-mysql> CALL mysql.rds_start_replication;

Utiliser mydumper

mydumper peut être votre option alternative ici, en particulier lorsque l'ensemble de données est très volumineux, car il offre le parallélisme et la vitesse lors de la prise d'un vidage ou d'une copie de sauvegarde de votre ensemble de données à partir d'un nœud RDS 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 RDS. Par exemple,

[[email protected] mydumper-2]# /usr/bin/mydumper --outputdir=. --verbose=3 --host=database-1.xxxxxxx.us-east-2.rds.amazonaws.com --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(db1\.|db2\.|db3\.|mydb4\.|testdb5\.)' -u admin --password=admin123

** Message: Connected to a MySQL server



** (mydumper:18904): CRITICAL **: Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'admin'@'%' (using password: YES)

** Message: Started dump at: 2020-10-18 09:34:08



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 1109

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

** Message: Creating table `db1`.`folders_rel`

** Message: Creating table `db2`.`p`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`AddressCodeTest`

  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-18 10:23:35

SHOW MASTER STATUS:

        Log: mysql-bin-changelog.000680

        Pos: 676

        GTID:0-1675507089-3044

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

MariaDB [jbmrcd_date]> CHANGE MASTER TO MASTER_HOST='database-1.cmu8qdlvkepg.us-east-2.rds.amazonaws.com', MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd',  MASTER_LOG_FILE='mysql-bin-changelog.000680', MASTER_LOG_POS

=676;

Query OK, 0 rows affected (0.002 sec)

## Démarrer l'esclave

MariaDB [jbmrcd_date]> start slave;

Query OK, 0 rows affected (0.001 sec)

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

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 une réplique de l'instance AWS RDS, 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 le source Amazon RDS. Je vous suggère d'utiliser l'outil pt-table-checksum de Percona, 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 peut également vous aider après la migration de vos données à l'aide de cette approche de réplication.

Conclusion

L'utilisation de mysqldump ou mydumper sont des outils open source gratuits, ce qui est également un grand avantage, surtout si vos données sont très confidentielles et que vous ne voulez pas qu'un tiers y accède. Bien qu'il puisse être simple d'adopter cette approche, il peut y avoir un travail fastidieux et important qui peut être impliqué car les tests et les doubles vérifications suivent toujours afin de prouver que la migration est entièrement réalisée sans aucune incohérence des données.