Migration physique depuis MySQL à l'aide de Percona XtraBackup et Amazon S3

Vous pouvez copier les fichiers de sauvegarde complète et incrémentielle de votre base de données MySQL version 5.7 ou 8.0 source vers un compartiment Amazon S3. Vous pouvez ensuite effectuer une restauration sur un cluster de base de données Amazon Aurora MySQL avec la même version majeure du moteur de base de données à partir de ces fichiers.

Cette option peut être considérablement plus rapide que la migration des données à l'aide de mysqldump, parce que l'utilisation de mysqldump réexécute toutes les commandes pour recréer le schéma et les données de votre base de données source dans votre nouveau cluster de base de données Aurora MySQL. En copiant vos fichiers de données MySQL source, Aurora MySQL peut immédiatement utiliser ces fichiers en tant que données d'un cluster de base de données Aurora MySQL.

Vous pouvez également réduire au maximum les temps d'arrêt en utilisant la réplication des journaux binaires pendant le processus de migration. Si vous utilisez la réplication des journaux binaires, la base de données MySQL externe reste ouverte aux transactions pendant que les données sont migrées vers le cluster de base de données Aurora MySQL. Une fois le cluster de base de données Aurora MySQL créé, utilisez la réplication des journaux binaires pour synchroniser le cluster de base de données Aurora MySQL avec les transactions qui ont eu lieu après la sauvegarde. Une fois le cluster de base de données Aurora MySQL synchronisé avec la base de données MySQL, vous terminez la migration en basculant complètement vers le cluster de base de données Aurora MySQL pour les nouvelles transactions. Pour plus d’informations, consultez Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL avec la réplication.

Table des matières

• Limites et considérations
• Avant de commencer
  • Installation de Percona XtraBackup
  • Autorisations nécessaires
  • Création d'un rôle de service IAM
• Sauvegarde de fichiers à restaurer comme cluster de base de données Amazon Aurora MySQL
  • Création d'une sauvegarde complète avec Percona XtraBackup
  • Utilisation de sauvegardes incrémentielles avec Percona XtraBackup
  • Considérations relatives à la sauvegarde
• Restauration d'un cluster de base de données Amazon Aurora MySQL à partir d'un compartiment Amazon S3
• Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL avec la réplication
  • Configuration de votre base de données MySQL externe et de votre cluster de base de données Aurora MySQL pour la réplication chiffrée
  • Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL externe
• Réduction du délai de migration physique vers Amazon Aurora MySQL
  • Types de table non pris en charge
  • Comptes d'utilisateur avec des privilèges non pris en charge
  • Privilèges dynamiques dans Aurora MySQL version 3
  • Objets stockés avec 'rdsadmin'@'localhost' comme définisseur

Limites et considérations

Les limites et considérations suivantes s'appliquent à la restauration vers un cluster de base de données Amazon Aurora MySQL à partir d'un compartiment Amazon S3 :

• Vous pouvez migrer vos données uniquement vers un nouveau cluster de base de données, et non vers un cluster de base de données existant.

• Vous devez utiliser Percona XtraBackup pour sauvegarder vos données sur S3. Pour plus d’informations, consultez Installation de Percona XtraBackup.

• Le compartiment Amazon S3 et le cluster de base de données Aurora MySQL doivent se trouver dans la même AWS région.

• Vous ne pouvez pas restaurer à partir des éléments suivants :

  • Une exportation d'un instantané de cluster de base de données sur Amazon S3. Vous ne pouvez pas non plus migrer des données à partir de l'exportation d'un instantané de cluster de base de données dans votre compartiment S3.

  • Une base de données source chiffrée, mais vous pouvez chiffrer les données en cours de migration. Vous pouvez également laisser les données non chiffrées pendant le processus de migration.

  • Une base de données MySQL 5.5 ou 5.6

• Percona Server for MySQL n'est pas pris en charge en tant que base de données source, car il peut contenir des compression_dictionary* tables dans le mysql schéma.

• Vous ne pouvez pas effectuer de restauration dans un cluster de base de données Aurora Serverless.

• La rétromigration n'est pas prise en charge pour les versions majeurs ni les versions mineures. Par exemple, vous ne pouvez pas migrer de MySQL version 8.0 vers Aurora MySQL version 2 (compatible avec MySQL 5.7). De même, vous ne pouvez pas migrer de MySQL version 8.0.32 vers Aurora MySQL version 3.03, compatible avec la version 8.0.26 de la communauté MySQL.

• Vous ne pouvez pas migrer de certaines anciennes versions de MySQL 8.0, notamment des versions 8.0.11, 8.0.13 et 8.0.15, vers Aurora MySQL 3.05 et versions ultérieures. Nous vous recommandons de passer à MySQL version 8.0.28 avant de procéder à la migration.

• L'importation à partir d'Amazon S3 n'est pas prise en charge sur la classe d'instances de base de données db.t2.micro. Toutefois, vous pouvez procéder à une restauration vers une autre classe d'instance de base de données, puis modifier la classe d'instance de base de données ultérieurement. Pour plus d'informations sur les classes d'instance de base de données, veuillez consulter Classes d'instances de base de données Amazon Aurora.

• Amazon S3 limite la taille d'un fichier chargé dans un compartiment S3 à 5 To. Si un fichier de sauvegarde dépasse 5 To, vous devez diviser celui-ci en plusieurs fichiers plus petits.

• Amazon RDS limite le nombre de fichiers chargés dans un compartiment S3 à 1 million. Si les données de sauvegarde de votre base de données, y compris toutes les sauvegardes complètes et incrémentielles, dépassent 1 million de fichiers, utilisez un fichier Gzip (.gz), tar (.tar.gz) ou Percona xbstream (.xbstream) pour stocker les fichiers de sauvegarde complète et incrémentielle dans le compartiment S3. Percona XtraBackup 8.0 prend uniquement en charge Percona xbstream pour la compression.

• Pour fournir des services de gestion à chaque cluster de base de données, l'utilisateur rdsadmin est créé lors de la création du cluster de base de données. Comme il s'agit d'un utilisateur réservé dans RDS, les limitations suivantes s'appliquent :

  • Les fonctions, les procédures, les vues, les événements et les déclencheurs avec le définisseur 'rdsadmin'@'localhost' ne sont pas importés. Pour plus d’informations, consultez Objets stockés avec 'rdsadmin'@'localhost' comme définisseur et Maîtrisez les privilèges des utilisateurs avec Amazon Aurora My SQL.

  • Lorsque le cluster de base de données Aurora MySQL est créé, un utilisateur principal est créé avec les privilèges maximum pris en charge. Lors de la restauration à partir d'une sauvegarde, tous les privilèges non pris en charge attribués aux utilisateurs importés sont automatiquement supprimés durant l'importation.

    Pour identifier les utilisateurs susceptibles d'être concernés, consultez Comptes d'utilisateur avec des privilèges non pris en charge. Pour plus d'informations sur les privilèges pris en charge dans Aurora MySQL, consultez Modèle de privilège basé sur les rôles.

• Pour Aurora MySQL version 3, les privilèges dynamiques ne sont pas importés. Les privilèges dynamiques pris en charge par Aurora peuvent être importés après la migration. Pour plus d’informations, consultez Privilèges dynamiques dans Aurora MySQL version 3.

• Les tables créées par l'utilisateur dans le schéma mysql ne sont pas migrées.

• Le paramètre innodb_data_file_path doit être configuré avec un seul fichier de données qui utilise le nom de fichier de données par défaut ibdata1:12M:autoextend. Les bases de données comportant deux fichiers de données, ou avec un fichier de données portant un nom différent, ne peuvent pas faire l'objet d'une migration à l'aide de cette méthode.

  Voici des exemples de noms de fichiers non autorisés : innodb_data_file_path=ibdata1:50M, ibdata2:50M:autoextend et innodb_data_file_path=ibdata01:50M:autoextend.

• Vous ne pouvez pas migrer à partir d'une base de données source dotée de tables définies à l'extérieur du répertoire de données MySQL par défaut.

• La taille maximale prise en charge pour les sauvegardes non compressées utilisant cette méthode est actuellement limitée à 64 Tio. Pour les sauvegardes compressées, cette limite est abaissée pour tenir compte de l'espace requis pour la décompression. Dans de tels cas, la taille de sauvegarde maximale prise en charge serait (64 TiB – compressed backup size).

• Aurora MySQL ne prend pas en charge l'importation de MySQL ni d'autres composants et plugins externes.

• Aurora MySQL ne restaure pas tous les éléments de votre base de données. Nous vous recommandons d'enregistrer le schéma de base de données et les valeurs pour les éléments suivants à partir de votre base de données MySQL source et de les ajouter à votre cluster de base de données Aurora MySQL restauré après qu'il a été créé :

  • Comptes utilisateurs

  • Fonctions

  • Procédures stockées

  • Informations de fuseau horaire. Les informations de fuseau horaire sont chargées depuis le système d'exploitation local de votre cluster de base de données Aurora MySQL. Pour plus d’informations, consultez Fuseau horaire local pour les clusters de base de données Amazon Aurora.

Avant de commencer

Avant de pouvoir copier vos données dans un compartiment Amazon S3 et de les restaurer dans un cluster de base de données à partir de ces fichiers, vous devez effectuer les opérations suivantes :

• Installez Percona XtraBackup sur votre serveur local.

• Autoriser Aurora MySQL à accéder à votre compartiment Amazon S3 en votre nom.

Installation de Percona XtraBackup

Amazon Aurora peut restaurer un cluster de base de données à partir de fichiers créés à l'aide de Percona XtraBackup. Vous pouvez installer Percona XtraBackup depuis Téléchargements de logiciels - Percona.

Pour la migration vers MySQL 5.7, utilisez Percona XtraBackup 2.4.

Pour la migration vers MySQL 8.0, utilisez Percona XtraBackup 8.0. Assurez-vous que la version Percona est compatible avec la XtraBackup version du moteur de votre base de données source.

Autorisations nécessaires

Pour migrer vos données MySQL vers un cluster de base de données Amazon Aurora MySQL, plusieurs autorisations sont requises :

• L'utilisateur qui demande à Aurora de créer un nouveau cluster à partir d'un compartiment Amazon S3 doit être autorisé à répertorier les compartiments pour votre AWS compte. Vous accordez cette autorisation à l'utilisateur à l'aide d'une politique AWS Identity and Access Management (IAM).

• Aurora nécessite l'autorisation d'agir en votre nom pour accéder au compartiment Amazon S3 dans lequel vous stockez les fichiers utilisés pour créer votre cluster de base de données Amazon Aurora MySQL. Vous accordez à Aurora les autorisations requises à l'aide d'un rôle de service IAM.

• L'utilisateur qui fait la demande doit avoir également l'autorisation de répertorier les rôles IAM pour votre compte AWS .

• Si l'utilisateur qui fait la demande doit créer le rôle de service IAM ou demander la création du rôle de service IAM par Aurora (à l'aide de la console), cet utilisateur doit avoir l'autorisation de créer un rôle IAM pour votre compte AWS .

• Si vous prévoyez de chiffrer les données pendant le processus de migration, mettez à jour la politique IAM de l'utilisateur qui effectuera la migration afin d'accorder l'accès RDS aux données AWS KMS keys utilisées pour chiffrer les sauvegardes. Pour obtenir des instructions, veuillez consulter Création d'une stratégie IAM pour accéder aux ressources AWS KMS.

Par exemple, la politique IAM suivante accorde à un utilisateur les autorisations minimales requises pour utiliser la console afin de répertorier les rôles IAM, créer un rôle IAM et répertorier les compartiments Amazon S3 de votre compte, ainsi que les clés KMS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListRoles",
                "iam:CreateRole",
                "iam:CreatePolicy",
                "iam:AttachRolePolicy",
                "s3:ListBucket",
                "kms:ListKeys"
            ],
            "Resource": "*"
        }
    ]
}

En outre, pour qu'un utilisateur associe un rôle IAM à un compartiment Amazon S3, l'utilisateur IAM doit avoir l'autorisation iam:PassRole pour ce rôle IAM. Cette autorisation permet à un administrateur de limiter les rôles IAM qu'un utilisateur peut associer aux compartiments Amazon S3.

Par exemple, la stratégie IAM suivante permet à un utilisateur d'associer le rôle nommé S3Access à un compartiment Amazon S3.

{
    "Version":"2012-10-17",
    "Statement":[
        {
            "Sid":"AllowS3AccessRole",
            "Effect":"Allow",
            "Action":"iam:PassRole",
            "Resource":"arn:aws:iam::123456789012:role/S3Access"
        }
    ]
}

Pour de plus amples informations sur les autorisations utilisateur IAM, veuillez consulter Gestion des accès à l’aide de politiques.

Création d'un rôle de service IAM

Vous pouvez AWS Management Console créer un rôle pour vous en choisissant l'option Créer un nouveau rôle (présentée plus loin dans cette rubrique). Si vous sélectionnez cette option et spécifiez un nom pour le nouveau rôle, Aurora crée le rôle de service IAM nécessaire pour qu'Aurora accède à votre compartiment Amazon S3 avec le nom que vous fournissez.

Vous pouvez aussi créer manuellement le rôle à l'aide de la procédure suivante.

Pour créer un rôle IAM permettant à Aurora d'accéder à Amazon S3

1. Suivez les étapes de Création d'une IAM politique d'accès aux ressources Amazon S3.

2. Suivez les étapes de Création d'un rôle IAM pour autoriser Amazon Aurora à accéder aux services AWS.

3. Suivez les étapes de Association d'un rôle IAM à un cluster de bases de données Amazon Aurora MySQL.

Sauvegarde de fichiers à restaurer comme cluster de base de données Amazon Aurora MySQL

Vous pouvez créer une sauvegarde complète de vos fichiers de base de données MySQL à l'aide de Percona XtraBackup et télécharger les fichiers de sauvegarde dans un compartiment Amazon S3. Si vous utilisez déjà Percona XtraBackup pour sauvegarder les fichiers de votre base de données MySQL, vous pouvez également télécharger vos répertoires et fichiers de sauvegarde complets et incrémentiels existants dans un compartiment Amazon S3.

Création d'une sauvegarde complète avec Percona XtraBackup

Pour créer une sauvegarde complète de vos fichiers de base de données MySQL qui peuvent être restaurés depuis Amazon S3 afin de créer un cluster de bases de données Aurora MySQL, utilisez l' XtraBackup utilitaire Percona (xtrabackup) pour sauvegarder votre base de données.

Par exemple, la commande suivante crée une sauvegarde d'une base de données MySQL et stocke les fichiers dans le dossier /on-premises/s3-restore/backup.

xtrabackup --backup --user=<myuser> --password=<password> --target-dir=</on-premises/s3-restore/backup>

Si vous souhaitez compresser votre sauvegarde en un seul fichier (qui peut être divisé, si nécessaire), vous pouvez utiliser l'option --stream pour enregistrer votre sauvegarde dans l'un des formats suivants :

• Gzip (.gz)

• tar (.tar)

• Percona xbstream (.xbstream)

La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers Gzip.

xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \
   --target-dir=</on-premises/s3-restore/backup> | gzip - | split -d --bytes=500MB \
   - </on-premises/s3-restore/backup/backup>.tar.gz

La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers tar.

xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \
   --target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \
   - </on-premises/s3-restore/backup/backup>.tar

La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers xbstream.

xtrabackup --backup --user=<myuser> --password=<password> --stream=xbstream \
   --target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \
   - </on-premises/s3-restore/backup/backup>.xbstream

Note

Si vous obtenez l'erreur suivante, cela indique peut-être que vous avez mélangé des formats de fichiers dans votre commande :

ERROR:/bin/tar: This does not look like a tar archive

Une fois que vous avez sauvegardé votre base de données MySQL à l'aide de l' XtraBackup utilitaire Percona, vous pouvez copier vos répertoires et fichiers de sauvegarde dans un compartiment Amazon S3.

Pour de plus amples informations sur la création et le chargement d'un fichier dans un compartiment Amazon S3, veuillez consulter Mise en route sur Amazon Simple Storage Service dans le Guide de démarrage Amazon S3.

Utilisation de sauvegardes incrémentielles avec Percona XtraBackup

Amazon Aurora MySQL prend en charge les sauvegardes complètes et incrémentielles créées à l'aide de XtraBackup Percona. Si vous utilisez déjà Percona XtraBackup pour effectuer des sauvegardes complètes et incrémentielles de vos fichiers de base de données MySQL, vous n'avez pas besoin de créer une sauvegarde complète et de télécharger les fichiers de sauvegarde sur Amazon S3. Au lieu de cela, vous pouvez économiser beaucoup de temps en copiant vos fichiers et répertoires de sauvegarde existants pour vos sauvegardes complètes et incrémentielles dans un compartiment Amazon S3. Pour plus d'informations, consultez Création d'une sauvegarde incrémentielle (langue française non garantie) sur le site web de Percona.

Lorsque vous copiez les fichiers existants des sauvegardes complètes et incrémentielles dans un compartiment Amazon S3, vous devez copier de façon récursive le contenu du répertoire de base. Ce contenu inclut la sauvegarde complète, ainsi que tous les fichiers et répertoires des sauvegardes incrémentielles. Cette copie doit conserver la structure de répertoire dans le compartiment Amazon S3. Aurora effectue une itération sur l'ensemble des fichiers et répertoires. Aurora utilise le fichier xtrabackup-checkpoints inclus avec chaque sauvegarde incrémentielle pour identifier le répertoire de base et ordonner les sauvegardes incrémentielles selon leur plage de numéros de séquence de journal.

Pour de plus amples informations sur la création et le chargement d'un fichier dans un compartiment Amazon S3, veuillez consulter Mise en route sur Amazon Simple Storage Service dans le Guide de démarrage Amazon S3.

Considérations relatives à la sauvegarde

Aurora ne prend pas en charge les sauvegardes partielles créées à l'aide de Percona XtraBackup. Vous ne pouvez pas utiliser les options suivantes pour créer une sauvegarde partielle lorsque vous sauvegardez les fichiers source pour votre base de données : --tables, --tables-exclude, --tables-file, --databases, --databases-exclude ou --databases-file.

Pour plus d'informations sur la sauvegarde de votre base de données avec Percona XtraBackup, consultez Percona XtraBackup - Documentation et utilisation de journaux binaires sur le site Web de Percona.

Aurora prend en charge les sauvegardes incrémentielles créées à l'aide de Percona XtraBackup. Pour plus d'informations, consultez Création d'une sauvegarde incrémentielle (langue française non garantie) sur le site web de Percona.

Aurora utilise vos fichiers de sauvegarde sur la base des noms de fichier. Veillez à nommer vos fichiers de sauvegarde avec l'extension de fichier appropriée basée sur le format de fichier, par exemple, .xbstream pour les fichiers stockés en utilisant le format Percona xbstream.

Aurora utilise vos fichiers de sauvegarde dans l'ordre alphabétique, ainsi que l'ordre numérique naturel. Utilisez toujours l'option split lorsque vous émettez la commande xtrabackup pour vous assurer que vos fichiers de sauvegarde sont écrits et nommés dans l'ordre approprié.

Amazon S3 limite la taille d'un fichier chargé vers un compartiment Amazon S3 à 5 To. Si les données de sauvegarde de votre base de données dépassent 5 To, utilisez la commande split pour diviser les fichiers de sauvegarde en plusieurs fichiers de moins de 5 To chacun.

Aurora limite le nombre de fichiers source chargés dans un compartiment Amazon S3 à 1 million de fichiers. Dans certains cas, si les données de sauvegarde de votre base de données, y compris toutes les sauvegardes complètes et incrémentielles, comprennent un grand nombre de fichiers. Le cas échéant, utilisez un fichier tarball (.tar.gz) pour stocker les fichiers des sauvegardes complètes et incrémentielles dans le compartiment Amazon S3.

Lorsque vous chargez un fichier dans compartiment Amazon S3, vous pouvez utiliser le chiffrement côté serveur pour chiffrer vos données. Vous pouvez ensuite restaurer un cluster de base de données Amazon Aurora MySQL à partir de ces fichiers chiffrés. Amazon Aurora MySQL peut restaurer un cluster de base de données avec des fichiers chiffrés à l'aide des types de chiffrement côté serveur suivants :

• Chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3) : chaque objet est chiffré à l'aide d'une clé unique utilisant un chiffrement multi-facteur fort.

• Chiffrement côté serveur avec clés AWS KMS gérées (SSE-KMS) : similaire au SSE-S3, mais vous avez la possibilité de créer et de gérer vous-même les clés de chiffrement, ainsi que d'autres différences.

Pour de plus amples informations sur l'utilisation du chiffrement côté serveur lors du chargement de fichiers dans un compartiment Amazon S3, veuillez consulter Protection des données à l'aide d'un chiffrement côté serveur dans le Manuel du développeur Amazon S3.

Restauration d'un cluster de base de données Amazon Aurora MySQL à partir d'un compartiment Amazon S3

Vous pouvez restaurer vos fichiers de sauvegarde à partir de votre compartiment Amazon S3 pour créer un nouveau cluster de base de données Amazon Aurora MySQL à l'aide de la console Amazon RDS.

Pour restaurer un cluster de base de données Amazon Aurora MySQL à partir de fichiers d'un compartiment Amazon S3

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le coin supérieur droit de la console Amazon RDS, choisissez la AWS région dans laquelle vous souhaitez créer votre cluster de base de données. Choisissez la même AWS région que le compartiment Amazon S3 qui contient la sauvegarde de votre base de données.

3. Dans le panneau de navigation, choisissez Bases de données, puis Restaurer à partir de S3.

4. Choisissez Restaurer à partir de S3.

   La page Créer une base de données par restauration à partir de S3 s'affiche.

   

5. Sous Destination S3 :

   1. Sélectionnez le compartiment S3 qui contient vos fichiers de sauvegarde.

   2. (Facultatif) Pour Préfixe du chemin de dossier S3, saisissez un préfixe de chemin de fichier pour les fichiers stockés dans votre compartiment Amazon S3.

      Si vous ne spécifiez pas de préfixe, RDS crée votre cluster/instance de base de données à l'aide de tous les fichiers et dossiers du dossier racine du compartiment S3. Si vous indiquez un préfixe, RDS crée votre instance de base de données à l'aide des fichiers et dossiers du compartiment S3 pour lesquels le chemin du fichier commence par le préfixe spécifié.

      Par exemple, supposons que vous stockez vos fichiers de sauvegarde sur S3 dans un sous-dossier appelé « sauvegardes » et que vous avez plusieurs ensembles de fichiers de sauvegarde, chacun dans son propre répertoire (gzip_backup1, gzip_backup2, etc.). Dans ce cas, vous devez spécifier un préfixe sauvegardes/gzip_backup1 pour restaurer les fichiers dans le dossier gzip_backup1.

6. Sous Options du moteur :

   1. Pour Engine type (Type de moteur), sélectionnez Amazon Aurora.

   2. Pour Version, sélectionnez la version Aurora MySQL du moteur de votre instance de base de données restaurée.

7. Dans le champ Rôle IAM, vous pouvez choisir un rôle IAM existant.

8. (Facultatif) Vous pouvez également créer un nouveau rôle IAM en choisissant Créer un nouveau rôle. Dans ce cas :

   1. Entrez le Nom du rôle IAM.

   2. Déterminez si vous souhaitez Autoriser l'accès à la clé KMS :

      • Si vous n'avez pas chiffré les fichiers de sauvegarde, choisissez Non.

      • Si vous avez chiffré les fichiers de sauvegarde avec AES-256 (SSE-S3) lors de leur chargement dans Amazon S3, choisissez Non. Dans ce cas, les données sont chiffrées automatiquement.

      • Si vous avez chiffré les fichiers de sauvegarde avec un chiffrement côté serveur AWS KMS (SSE-KMS) lorsque vous les avez chargés sur Amazon S3, choisissez Oui. Ensuite, choisissez la clé KMS appropriée pour AWS KMS key.

        AWS Management Console crée une politique IAM qui permet à Aurora de déchiffrer les données.

      Pour de plus amples informations, veuillez consulter Protection des données à l'aide d'un chiffrement côté serveur dans le Manuel du développeur Amazon S3.

9. Choisissez les paramètres de votre cluster de base de données, tels que la configuration du stockage pour le cluster de base de données, la classe d'instance de la base de données, l'identifiant du cluster de base de données et les informations d'identification de connexion. Pour plus d'informations sur chaque paramètre, consultez Paramètres pour les clusters de base de données Aurora.

10. Personnalisez les autres paramètres de votre cluster de base de données Aurora MySQL selon vos besoins.

11. Sélectionnez Create database (Créer une base de données) pour lancer votre instance de base de données Aurora.

Sur la console Amazon RDS, la nouvelle instance de base de données s'affiche dans la liste des instances de bases de données. L'instance de base de données a le statut creating (création en cours) jusqu'à ce qu'elle soit créée et prête à l'emploi. Lorsque l'état devient available, vous pouvez vous connecter à l'instance principale de votre cluster DB. En fonction du stockage et de la classe d'instance de base de données alloués, la mise à disposition de la nouvelle instance de base de données peut nécessiter plusieurs minutes.

Pour afficher le cluster nouvellement créé, choisissez la vue Bases de données dans la console Amazon RDS et choisissez le cluster de base de données. Pour plus d'informations, consultez Affichage d'un cluster de base de données Amazon Aurora.

Notez le port et le point de terminaison enregistreur du cluster de base de données. Utilisez le point de terminaison enregistreur et le port du cluster de base de données dans vos chaînes de connexion JDBC et ODBC pour toute application qui exécute des opérations de lecture et d'écriture.

Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL avec la réplication

Pendant la migration, pour limiter ou éviter les temps d'arrêt, vous pouvez répliquer les transactions validées sur votre base de données MySQL sur votre cluster de base de données Aurora MySQL. La réplication permet au cluster de base de données d'être synchrone avec les transactions de la base de données MySQL traitées pendant la migration. Une fois que le cluster de base de données est totalement synchronisé, vous pouvez arrêter la réplication et terminer la migration vers Aurora MySQL.

Rubriques

• Configuration de votre base de données MySQL externe et de votre cluster de base de données Aurora MySQL pour la réplication chiffrée
• Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL externe

Configuration de votre base de données MySQL externe et de votre cluster de base de données Aurora MySQL pour la réplication chiffrée

Pour répliquer des données en toute sécurité, vous pouvez utiliser la réplication chiffrée.

Note

Si vous n'avez pas besoin d'utiliser la réplication chiffrée, vous pouvez ignorer ces étapes et passer aux instructions de Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL externe.

Pour pouvoir utiliser la réplication chiffrée, vous devez impérativement disposer des éléments suivants :

• Le protocole SSL doit être activé sur la base de données source MySQL principale.

• Une clé client et un certificat client doivent être préparés pour le cluster de base de données Aurora MySQL.

Pendant la réplication chiffrée, le cluster de base de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers.

Pour configurer votre base de données MySQL externe et votre cluster de base de données Aurora MySQL pour la réplication chiffrée

1. Vérifiez bien que vous êtes prêt à procéder à la réplication chiffrée :

   • Si le protocole SSL n'est pas activé sur la base de données source MySQL principale et que vous ne disposez pas d'une clé client et d'un certificat client prêts, activez le protocole SSL sur le serveur de base de données MySQL et générez la clé client et le certificat client requis.

   • Si le protocole SSL est activé sur la base de données source principale, fournissez une clé et un certificat client pour le cluster de base de données Aurora MySQL. En leur absence, générez une nouvelle clé et un nouveau certificat pour le cluster de base de données Aurora MySQL. Pour signer le certificat client, vous devez disposer de la clé d'autorité de certification utilisée pour configurer le protocole SSL sur la base de données source MySQL principale.

   Pour de plus amples informations, veuillez consulter Création de certificats et clés SSL à l'aide d'openssl dans la documentation MySQL.

   Vous avez besoin du certificat de l'autorité de certification, de la clé client et du certificat client.

2. Connectez-vous au cluster de base de données Aurora MySQL en tant qu'utilisateur principal à l'aide du protocole SSL.

   Pour plus d'informations sur la connexion à un cluster de base de données Aurora MySQL avec le protocole SSL, consultez TLSconnexions aux clusters Aurora My SQL DB.

3. Exécutez la procédure stockée mysql.rds_import_binlog_ssl_material pour importer les informations SSL dans le cluster de base de données Aurora MySQL.

   Pour le paramètre ssl_material_value, insérez les informations des fichiers au format .pem pour le cluster de base de données Aurora MySQL dans la charge utile JSON correcte.

   L'exemple suivant importe des informations SSL dans un cluster de base de données Aurora MySQL. Dans les fichiers au format .pem, le code du corps est généralement plus long que le code du corps affiché dans l'exemple.

   call mysql.rds_import_binlog_ssl_material(
   '{"ssl_ca":"-----BEGIN CERTIFICATE-----
   AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
   hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
   lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
   qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
   BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
   -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
   AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
   hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
   lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
   qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
   BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
   -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
   AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
   hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
   lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
   qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
   BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
   -----END RSA PRIVATE KEY-----\n"}');
   

   Pour plus d’informations, consultez mysql.rds_import_binlog_ssl_material et TLSconnexions aux clusters Aurora My SQL DB.

   Note

   Après l'exécution de la procédure, les secrets sont stockés dans les fichiers. Pour supprimer les fichiers ultérieurement, vous pouvez exécuter la procédure stockée mysql.rds_remove_binlog_ssl_material.

Synchronisation du cluster de base de données Amazon Aurora MySQL sur la base de données MySQL externe

Vous pouvez synchroniser votre cluster de base de données Amazon Aurora MySQL sur la base de données MySQL à l'aide de la réplication.

Pour synchroniser votre cluster de base de données Aurora MySQL sur la base de données MySQL à l'aide de la réplication

1. Vérifiez que le fichier /etc/my.cnf de la base de données MySQL externe dispose des entrées correspondantes.

   Si la réplication chiffrée n'est pas obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec des journaux binaires (binlogs) activés et le protocole SSL désactivé. Les entrées correspondantes dans le fichier /etc/my.cnf pour les données non chiffrées sont les suivantes.

   
   log-bin=mysql-bin
   server-id=2133421
   innodb_flush_log_at_trx_commit=1
   sync_binlog=1
   

   Si la réplication chiffrée est obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec le protocole SSL et des fichiers binlogs activés. Les entrées dans le fichier /etc/my.cnf incluent les emplacements de fichier .pem pour le serveur de base de données MySQL.

   
   log-bin=mysql-bin
   server-id=2133421
   innodb_flush_log_at_trx_commit=1
   sync_binlog=1
   
   # Setup SSL.
   ssl-ca=/home/sslcerts/ca.pem
   ssl-cert=/home/sslcerts/server-cert.pem
   ssl-key=/home/sslcerts/server-key.pem
   

   Vous pouvez vérifier que SSL est activé avec la commande suivante.

   
   mysql> show variables like 'have_ssl';
   

   Votre sortie doit ressembler à ce qui suit.

   
   +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
   | Variable_name | Value |
   +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
   | have_ssl      | YES   |
   +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
   1 row in set (0.00 sec)
   

2. Déterminez la position de début de votre journal binaire pour la réplication. Vous spécifiez la position pour démarrer la réplication à une étape ultérieure.

   En utilisant le AWS Management Console

   1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

   2. Dans le volet de navigation, sélectionnez Events.

   3. Dans la liste Événements, notez la position dans l'événement Recovered from Binary log filename (Récupéré à partir du nom de fichier journal binaire).

      

   En utilisant le AWS CLI

   Vous pouvez également obtenir le nom et la position du fichier binlog à l'aide de la commande describe-events AWS CLI . Ce qui suit présente un exemple de commande describe-events.

   PROMPT> aws rds describe-events

   Dans la sortie, identifiez l'événement qui affiche la position du journal binaire.

3. Tandis que vous êtes connecté à la base de données MySQL externe, créez un utilisateur à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. Voici un exemple de.

   
   mysql> CREATE USER '<user_name>'@'<domain_name>' IDENTIFIED BY '<password>';
   

   L'utilisateur nécessite les privilèges REPLICATION CLIENT et REPLICATION SLAVE. Accordez ces privilèges à l'utilisateur.

   
   GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '<user_name>'@'<domain_name>';
   

   Si vous avez besoin d'utiliser la réplication chiffrée, demandez des connexions SSL à l'utilisateur de la réplication. Par exemple, vous pouvez utiliser l'instruction suivante pour demander les connexions SSL sur le compte d'utilisateur <user_name>.

   
   GRANT USAGE ON *.* TO '<user_name>'@'<domain_name>' REQUIRE SSL;
   

   Note

   Si REQUIRE SSL n'est pas inclus, la connexion de réplication peut revenir de façon silencieuse à une connexion non chiffrée.

4. Dans la console Amazon RDS, ajoutez l'adresse IP du serveur qui héberge la base de données MySQL externe au groupe de sécurité VPC du cluster de base de données Aurora MySQL. Pour de plus amples informations sur la modification d'un groupe de sécurité de VPC, veuillez consulter Security Groups for Your VPC (Groupes de sécurité pour votre VPC) dans le Guide de l'utilisateur Amazon Virtual Private Cloud.

   Il se peut aussi que vous ayez besoin de configurer votre réseau local pour autoriser les connexions à partir de l'adresse IP de votre cluster de base de données Aurora MySQL, de telle sorte qu'elle puisse communiquer avec votre base de données MySQL externe. Pour rechercher l'adresse IP du cluster de base de données Aurora MySQL, utilisez la commande host.

   host <db_cluster_endpoint>

   Le nom d'hôte est le nom DNS du point de terminaison du cluster de base de données Aurora MySQL.

5. Activez la réplication des journaux binaires en exécutant la procédure stockée mysql.rds_reset_external_master (Aurora My version 2) SQL ou mysql.rds_reset_external_source (Aurora My version 3) SQL. Cette procédure stockée possède la syntaxe suivante.

   
   CALL mysql.rds_set_external_master (
     host_name
     , host_port
     , replication_user_name
     , replication_user_password
     , mysql_binary_log_file_name
     , mysql_binary_log_file_location
     , ssl_encryption
   );
   
   CALL mysql.rds_set_external_source (
     host_name
     , host_port
     , replication_user_name
     , replication_user_password
     , mysql_binary_log_file_name
     , mysql_binary_log_file_location
     , ssl_encryption
   );
   

   Pour obtenir des informations sur les paramètres, consultez mysql.rds_reset_external_master (Aurora My version 2) SQL et mysql.rds_reset_external_source (Aurora My version 3) SQL.

   Pour mysql_binary_log_file_name et mysql_binary_log_file_location, utilisez la position dans l'événement Recovered from Binary log filename (Récupéré à partir du nom de fichier journal binaire) que vous avez notée précédemment.

   Si les données du cluster de base de données Aurora MySQL ne sont pas chiffrées, le paramètre ssl_encryption doit être défini sur 0. Si les données sont chiffrées, le paramètre ssl_encryption doit être défini sur 1.

   L'exemple suivant présente l'exécution de la procédure pour un cluster de base de données Aurora MySQL dont les données sont chiffrées.

   
   CALL mysql.rds_set_external_master(
     'Externaldb.some.com',
     3306,
     'repl_user'@'mydomain.com',
     'password',
     'mysql-bin.000010',
     120,
     1);
   
   CALL mysql.rds_set_external_source(
     'Externaldb.some.com',
     3306,
     'repl_user'@'mydomain.com',
     'password',
     'mysql-bin.000010',
     120,
     1);
   

   Cette procédure stockée définit les paramètres que le cluster de base de données Aurora MySQL utilise pour se connecter à la base de données MySQL externe et pour lire son journal binaire. Si les données sont chiffrées, il télécharge également le certificat de l'autorité de certification, le certificat du client et la clé du client sur le disque local.

6. Démarrez la réplication des journaux binaires en exécutant la procédure stockée mysql.rds_start_replication.

   
   CALL mysql.rds_start_replication;
   

7. Contrôlez le décalage entre le cluster de base de données Aurora MySQL et la base de données principale de réplication MySQL. Pour cela, connectez-vous au cluster de base de données Aurora MySQL et exécutez la commande suivante.

   
   Aurora MySQL version 2:
   SHOW SLAVE STATUS;
   
   Aurora MySQL version 3:
   SHOW REPLICA STATUS;
   

   Dans la sortie de la commande, le champ Seconds Behind Master indique à quelle distance le cluster de base de données Aurora MySQL se trouve du principal MySQL. Lorsque cette valeur est 0 (zéro), le cluster de base de données Aurora MySQL s'est synchronisé avec le principal, et vous pouvez passer à l'étape suivante pour arrêter la réplication.

8. Connectez-vous à la base de données principale de réplication MySQL et arrêtez la réplication. Pour ce faire, exécutez la procédure stockée mysql.rds_stop_replication.

   
   CALL mysql.rds_stop_replication;