Toute migration de base de données doit passer par les phases standard de la migration de données, comme l'analyse de la compatibilité, la validation du schéma, etc. Deux défis qui méritent d'être mentionnés sont la vitesse à laquelle nous serons capables de dumper et de recharger plus d'un milliard de lignes (presque 1 To) et la planification d'une migration qui nous permette de réagir à des situations inattendues en passant à un environnement sécurisé avec un temps d'arrêt minimal et sans perte de données.
Nous avons passé un certain temps à trouver comment charger plus rapidement les données dans Aurora. Le goulot d'étranglement habituel est l'exportation/importation de données. Maintenant, nous savons que l'importation des données doit être terminée avant que le binlog ne tourne. Après avoir essayé différentes options par nous-mêmes, nous nous sommes tournés vers le support AWS pour avoir un deuxième avis. En utilisant l'élasticité d'AWS, et en particulier de RDS Aurora, nous avons pu mettre à l'échelle et terminer la charge de données en quelques heures plutôt qu'en quelques jours, puis la ramener à une utilisation normale.
Le deuxième défi de la migration en direct et du rollforward en cas de catastrophe est une tâche assez compliquée. Tout d'abord, nous avons dû créer notre nouvelle base de données Aurora en tant que réplique de la base de données actuelle. Une fois la réplication terminée, nous avons créé une autre base de données avec l'ancien moteur de DB comme réplique de la nouvelle base de données Aurora. Regarde à quoi ressemble le diagramme. Sur PowerPoint, il a l'air simple, mais en réalité, ce sont des bits et des octets et un peu de magie noire. Grâce à des tests et une planification approfondis, nous avons pu effectuer la migration en direct sans obstacles, et après quelques jours, même le Rollforward a été supprimé.