Migrer des données de MySQL local vers Azure Database pour MySQL : Test Plans
Le développement de plans de test complets est essentiel pour migrer des bases de données MySQL à partir d’environnements locaux vers Azure Database pour MySQL. Cet article fournit un examen approfondi des composants essentiels des Test Plans efficaces, ce qui garantit que votre processus de migration est fluide et réussi. Vous pouvez atténuer les risques en décrivant les stratégies de test clés, en identifiant les problèmes potentiels, en établissant des critères de validation clairs, et en veillant à ce que vos bases de données migrées s’exécutent de manière optimale dans l’environnement Azure. Vous pouvez vous concentrez sur les tests fonctionnels, les tests de performances ou les tests de sécurité. Ce guide vous fournit les connaissances et les meilleures pratiques nécessaires pour créer des Test Plans robustes qui prennent en charge une migration transparente.
Prérequis
Migrer MySQL local vers Azure Database pour MySQL : méthodes de migration
Vue d’ensemble
WWI a créé un plan de test qui comprenait un ensemble de tâches informatiques et commerciales. Pour que les migrations réussissent, tous les tests doivent être exécutés.
Tests :
Assurez-vous que la base de données migrée est cohérente (même nombre d’enregistrements et mêmes résultats de requêtes) avec les tables locales.
Assurez-vous que les performances sont acceptables (elles doivent correspondre aux mêmes performances que si elles étaient exécutées localement).
Assurez-vous que les performances des requêtes cibles répondent aux spécifications indiquées.
Assurez-vous que la connectivité entre le réseau local et le réseau Azure est acceptable.
Vérifiez que toutes les applications et tous les utilisateurs identifiés peuvent se connecter à l’instance de données migrée.
WWI a identifié un week-end et une fenêtre temporelle de migration qui a commencé à 22 h et s’est terminée à 2 h (heure du Pacifique). Si la migration ne s’est pas terminée avant l’objectif de 2 h (temps d’arrêt ciblé de 4 heures) avec tous les tests réussis, les procédures de restauration ont été démarrées. Des problèmes ont été documentés pour les futures tentatives de migration. Toutes les fenêtres de migration ont été avancées et replanifiées en fonction de délais commerciaux acceptables.
Exemples de requêtes
Une série de requêtes a été exécutée sur la source et la cible pour vérifier la réussite de la migration de la base de données. Les requêtes et scripts suivants permettent de déterminer si les actions de migration ont déplacé tous les objets de base de données requis de la source vers la cible.
Lignes de table
Vous pouvez utiliser cette requête pour obtenir toutes les tables et une estimation du nombre de lignes :
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';
Notes
La table INFORMATION_SCHEMA fournit un ensemble estimé de valeurs dans les tables. Pour obtenir une vue plus précise des métriques telles que la taille de la table, augmentez la taille de l’échantillon de pages à l’aide du paramètre de serveur innodb_stats_transient_sample_pages. L’augmentation de cette valeur de serveur force l’analyse de davantage de pages et donne des résultats plus précis.
Exécutez l’instruction SQL count(*) sur chaque table pour obtenir un compte précis des lignes. L’exécution de cette commande peut prendre beaucoup de temps sur les tables volumineuses. Le script suivant génère un ensemble d’instructions SQL qui peuvent être exécutées pour obtenir les comptes exacts :
SELECT CONCAT(
'SELECT "',
table_name,
'" AS table_name, COUNT(*) AS exact_row_count FROM `',
table_schema,
'`.`',
table_name,
'` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';
Fragmentation des tables
Les tables de données sont susceptibles de continuer à croître avec l’utilisation continue de l’application. Dans certains cas, il est possible que les données ne se développent pas, mais elles changent constamment via des suppressions et des mises à jour. Si c’est le cas, il est possible qu’il y ait de nombreuses fragmentations dans les fichiers de la base de données. L’instruction MySQL OPTIMIZE TABLE peut réduire les besoins en espace de stockage physique et améliorer l’efficacité des E/S.
Vous pouvez optimiser les tables MySQL en exécutant la commande suivante :
optimize table TABLE_NAME
Objets de base de données
Utilisez la requête suivante pour vous assurer que tous les autres objets de base de données sont pris en compte. Bien que ces requêtes puissent calculer le nombre de lignes de table, il est possible qu’elles ne tiennent pas compte de la version de l’objet de base de données donné. Par exemple, même si une procédure stockée existe, elle peut avoir été modifiée entre le début et la fin de la migration. Il est recommandé de geler le développement des objets de base de données pendant la migration.
Utilisateurs
SELECT DISTINCT
USER
FROM
mysql.user
WHERE
user <> '' order by user
Index
SELECT DISTINCT
INDEX_NAME
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Contraintes
SELECT DISTINCT
CONSTRAINT_NAME
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
CONSTRAINT_SCHEMA = '{SchemaName}'
Views
SELECT
TABLE_NAME
FROM
information_schema.VIEWS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Procédures stockées
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = '{SchemaName}'
Fonctions
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = '{SchemaName}'
Événements
SELECT
EVENT_NAME
FROM
INFORMATION_SCHEMA.EVENTS
WHERE
EVENT_SCHEMA = '{SchemaName}'
Stratégies de restauration
Les requêtes ci-dessus fournissent une liste de noms et de nombres d’objets utilisés dans une décision de restauration. Les utilisateurs de la migration peuvent effectuer la première étape de vérification des objets en vérifiant le nombre d’objets source et cible. Une différence dans le nombre d’objets ne signifie pas nécessairement qu’une restauration est nécessaire. Une évaluation approfondie peut montrer que la différence est légère et facilement récupérable. La migration manuelle de quelques objets en échec peut être la solution. Par exemple, si toutes les tables et lignes de données ont été migrées, mais que seules quelques fonctions ont été manquées, corrigez ces objets en échec et finalisez la migration. Si la base de données est relativement petite, il est possible d’effacer l’instance Azure Database pour MySQL et de recommencer la migration. Il est possible que des bases de données volumineuses aient besoin de plus de temps que celui disponible dans la fenêtre de migration pour déterminer les objets manquants. La migration doit être arrêtée et restaurée.
L’identification des objets de base de données manquants doit se faire rapidement pendant la fenêtre de migration. Chaque minute compte. Une option pourrait être d’exporter les noms des objets de l’environnement dans un fichier et d’utiliser un outil de comparaison de données pour identifier rapidement les objets manquants. Une autre solution consiste à exporter les noms des objets de base de données sources et à importer les données dans une table temporaire de l’environnement de base de données cible. Comparez les données à l’aide d’une instruction SQL scriptée et testée. La vitesse et la précision de la vérification des données sont essentielles au processus de migration. Ne vous fiez pas à la lecture et à la vérification manuelles d’une longue liste d’objets de base de données pendant une fenêtre de migration. Le risque d’erreur humaine est trop important. Il serait préférable de gérer par exception à l’aide d’outils.
Scénario WWI
Le DSI de WWI a reçu un rapport de confirmation indiquant que tous les objets de base de données ont été migrés de la base de données locale vers l’instance Azure Database pour MySQL. L’équipe chargée de la base de données a exécuté les requêtes ci-dessus sur la base de données avant le début de la migration et a enregistré tous les résultats dans une feuille de calcul.
Les informations sur le schéma de la base de données source ont été utilisées pour vérifier la fidélité des objets de migration cibles.
Liste de vérification des plans de test
Ayez des requêtes de test scriptées, testées et prêtes à être exécutées.
Connaissez la durée d’exécution des requêtes de test et intégrez-la dans la chronologie de migration documentée.
Préparez une stratégie d’atténuation des risques et de restauration prête pour différents résultats potentiels.
Disposez d’une chronologie bien définie des événements pour la migration.