Présentation
Database Migration Service permet d'effectuer des migrations ponctuelles et continues à partir de bases de données sources vers des bases de données de destination Cloud SQL.
Les bases de données sources compatibles avec MySQL incluent:
- Amazon RDS 5.6, 5.7, 8.0
- MySQL autogéré (sur site ou sur une VM cloud que vous contrôlez entièrement) 5.5, 5.6, 5.7 et 8.0
- Cloud SQL pour MySQL 5.6, 5.7, 8.0 et 8.4
- Amazon Aurora 5.6, 5.7, 8.0
- Microsoft Azure Database pour MySQL 5.7 et 8.0
Pour les sources MySQL 8.0, Database Migration Service est également compatible avec les versions mineures suivantes : 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39 et 8.0.40.
Pour configurer une base de données source, procédez comme suit:
- Pour les sources Cloud SQL:si vous migrez d'une instance Cloud SQL qui utilise une connexion IP privée vers une instance Cloud SQL qui utilise une plage d'adresses IP non RFC 1918, ajoutez la plage non RFC 1918 à la configuration réseau de votre instance Cloud SQL source. Consultez la section Configurer des réseaux autorisés dans la documentation Cloud SQL.
- Avant de migrer des données de la base de données source vers la base de données de destination, assurez-vous d'arrêter toutes les opérations d'écriture du langage de définition de données (DDL) pendant la phase de dump complet. Vous pouvez utiliser un script pour vérifier que les opérations DDL sont arrêtées. Une fois la migration dans la phase CDC, vous pouvez reprendre les opérations DDL.
- Assurez-vous que votre base de données source ne contient pas de métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Créer et exécuter une tâche de migration MySQL contenant des métadonnées avec une clause DEFINER.
- Si votre base de données source contient des objets qui font référence à des tables dans les schémas système
mysql
,performance_schema
,information_schema
,ndbinfo
ousys
, assurez-vous que les bases de données de réplicat contiennent également ces tables de schéma système.Si les bases de données de réplication ne contiennent pas ces tables, votre tâche de migration risque d'échouer avec l' erreur
Unknown table in system schema
. - Vous devez définir l'option server-id sur une valeur égale ou supérieure à 1. Pour en savoir plus, consultez la section Options et variables de la journalisation binaire et de la réplication.
- Configurez la journalisation des identifiants de transaction globaux (GTID) en définissant
GTID_MODE
surON
ouOFF
. La valeurGTID_MODE
deON_PERMISSIVE
n'est pas acceptée.La valeur à utiliser dépend des exigences de migration:
- Si vous
migrez vers une instance de destination existante pour laquelle les instances dupliquées avec accès en lecture sont activées, définissez
GTID_MODE
surON
. - Si vous utilisez un vidage manuel pour migrer vos données, définissez
GTID_MODE
surON
.
GTID_MODE
, consultez la section Variable système d'identifiant de transaction global. - Si vous
migrez vers une instance de destination existante pour laquelle les instances dupliquées avec accès en lecture sont activées, définissez
-
Vous devez configurer le compte utilisateur utilisé pour se connecter à la base de données source de sorte qu'il accepte les connexions de toutes provenances (hôte =
%
). L'accès peut être restreint à cet utilisateur à une étape ultérieure.Pour éviter de compromettre d'autres aspects de la base de données, nous vous recommandons de créer un compte distinct dédié à cette tâche.
Il existe quatre types de combinaisons de migrations et de vidages:
- Type 1: migration continue et vidage géré
- Type 2: migration continue et vidage manuel
- Type 3: migration unique et vidage géré
- Type 4: migration unique et vidage manuel
Les droits pour chaque type de combinaison de migration et de vidage sont listés dans les onglets ci-dessous.
Le compte utilisateur que vous configurez doit disposer des droits suivants :
REPLICATION SLAVE
EXECUTE
SELECT
SHOW VIEW
REPLICATION CLIENT
RELOAD
TRIGGER
- (Pour la migration depuis Amazon RDS et Amazon Aurora uniquement)
LOCK TABLES
MySQL version 8.0 ou ultérieure:pour des performances optimales, veillez à ne pas accorder le droit
BACKUP_ADMIN
à ce compte.Le compte utilisateur que vous configurez doit disposer des droits suivants :
REPLICATION SLAVE
EXECUTE
Le compte utilisateur que vous configurez doit disposer des droits suivants :
SELECT
SHOW VIEW
TRIGGER
- (Pour la migration depuis Amazon RDS et Amazon Aurora uniquement)
LOCK TABLES
- (Pour la migration à partir de sources avec le paramètre
GTID_MODE = ON
uniquement)RELOAD
MySQL version 8.0 ou ultérieure:pour des performances optimales, veillez à ne pas accorder le droit
BACKUP_ADMIN
à ce compte.Aucun droit n'est requis.
- Avant de configurer des journaux binaires, assurez-vous de :
- Activez les journaux binaires sur votre base de données source.
- Utilisez la journalisation binaire basée sur les lignes.
- Conservez les journaux binaires pendant une période suffisamment longue pour permettre la migration de la base de données. En général, une semaine suffit.
Pour configurer les journaux binaires, développez la section de votre source:
MySQL auto-hébergé
Selon votre version de MySQL, spécifiez une période suffisante pour que la réplication puisse avoir lieu:
- MySQL 5.5 - 5.7:
expire_logs_days
- MySQL 8.0:
expire_logs_days
,binlog_expire_logs_seconds
Microsoft Azure Database pour MySQL
La journalisation binaire est activée par défaut sur Microsoft Azure Database pour MySQL. Vous n'avez pas besoin de l'activer. Pour en savoir plus, consultez la documentation Microsoft.
Configurez les paramètres obligatoires suivants:
Définissez
binlog_expire_logs_seconds
sur une période suffisamment longue pour permettre la migration de la base de données.Pour en savoir plus, consultez Configurer les paramètres de serveur dans Azure Database pour PostgreSQL et le paramètre
binlog_expire_logs_seconds
dans la documentation Microsoft.- Redémarrez votre serveur pour que les modifications apportées soient prises en compte.
Amazon RDS
Pour Amazon RDS, vous définissez la configuration basée sur les lignes dans le groupe de paramètres en configurant le paramètre
binlog retention hours
. Ce paramètre permet de spécifier le nombre d'heures pendant lesquelles Amazon RDS doit conserver les fichiers de journaux binaires.Pour définir la durée de conservation des journaux binaires dans Amazon RDS, utilisez la procédure stockée
mysql.rds_set_configuration
et spécifiez une période suffisamment longue pour que la réplication puisse avoir lieu. Exemple :call mysql.rds_set_configuration('binlog retention hours',168);
Amazon Aurora
Pour Amazon Aurora, procédez comme suit:
- Activez la journalisation binaire pour votre base de données MySQL.
- Définissez la durée de conservation du journal binaire:
mysql> call mysql.rds_set_configuration('binlog retention hours', 168);
- Redémarrez votre serveur pour que les modifications apportées soient prises en compte.
- Toutes les tables (à l'exception des tables des bases de données système) utilisent le moteur de stockage InnoDB.
- Le mot de passe du compte utilisateur utilisé pour se connecter à la base de données source ne doit pas dépasser 32 caractères. Il s'agit d'un problème spécifique à la réplication MySQL.
Pour les sources Microsoft Azure Database pour MySQL uniquement: vérifiez la valeur de votre paramètre
require_secure_transport
.Par défaut, les bases de données Microsoft Azure nécessitent le chiffrement SSL/TLS pour toutes les connexions entrantes. Selon la valeur
require_secure_transport
, utilisez l'un des paramètres de chiffrement suivants lorsque vous créez le profil de connexion source:- Si
require_secure_transport
est défini suron
, sélectionnez Basic (Standard), TLS ou mTLS. - Si
require_secure_transport
est défini suroff
, sélectionnez Aucun.
- Si