Il y a quelques semaines, je recherchais comment migrer, sur Azure, les données d’un compte Cosmos DB de type NoSQL à un second compte Cosmos DB NoSQL lui aussi.
Sur le papier cela semble à première vue plutôt simple, mais finalement pas tant que cela.
Alors certains pourraient se demander pourquoi ?
En fait pour l’un de mes projets critique, nous étions initialement parti sur le déploiement d’un compte Cosmos DB en mode Serverless, car nous devions avoir exclusivement des utilisateurs en Europe Occidentale.
Mais quelques mois plus tard, on nous apprend que le projet change radicalement de scope, et que les données doivent être accessible mondialement : Ok pas de souci.
1. Solution envisagée : La géo-replication
Cela tombe bien, le service Azure Cosmos DB, propose une fonctionnalité de géo-replication. Le problème c’est que cette fonctionnalité n’est pas disponible avec le mode Serverless, mais seulement avec le mode Provisioned Throughput, ce qui finalement semble cohérent.
2. Solution envisagée : La restauration des données
Après quelques minutes de réflexion, je me dis que ce n’est pas grave, il suffit de restaurer les données via l’option Point In Time Restore (PiTR).
Mais je rencontre une nouvelle déception, car lors de la restauration, le nouveau compte Cosmos DB est le même que celui de la DB initiale, à savoir un compte Serverless.
Bon jusqu’à présent, on ne peut pas dire que j’ai eu de la chance.
Mais comme le dit Franck Ribery : La roue tourne, va tourner.
3. Solution envisagée : Ben faut que je cherche, mais pourquoi pas une migration ?
Je débute donc mes recherches comme Sherlock Holmes avec ma pipe, ma loupe et mon K-way (désolé je n’avais pas d’imperméable sous la main).
Au bout de quelques minutes, je tombe sur une page de documentation officielle de Microsoft dont le titre est
Options de migration de vos données locales ou cloud vers Azure Cosmos DB
Hum, vu le titre cela pourrait m’intéresser alors je commence à enlever mon K-way car cela donne vraiment chaud.
La documentation est plutôt bien faite, comme souvent pour être honnête avec Microsoft, elle propose différents scénarii, et en plus, deux types de migration sont proposés à savoir « En ligne » et/ou « Hors connexion.
4. Solution envisagée : Migration proposée par Microsoft
J’y trouve de nombreux cas d’usage de migration, avec comme source, différents type de DB comme Azure Cosmos DB évidemment, mais aussi des fichiers json ou csv, sans oublier de l’Oracle et de l’Apache Cassandra.
Après quelques instants, je liste ce qui semble convenir à mon cas d’usage :
- Mode hors connexion :
- L’utilisation de Azure Data Factory
- L’utilisation d’un connecteur Spark Azure Cosmos DB
- Mode en ligne :
- L’utilisation d’un connecteur Spark Azure Cosmos DB + Flux de modification
- L’utilisation des fonctions Cosmos DB + API ChangeFeed
- L’utilisation du service de migration personnalisé utilisant ChangeFeed
Avec ma loupe, je regarde les différentes solutions proposées qui s’offrent à moi …
… et plus j’avance, plus je me rend compte qu’elles nécessitent pas mal d’efforts et que pour certaines d’entre elles, le déploiement de nouveaux services est nécessaire.
Hum ok !
Avant d’aller plus loin, je retourne sur mon compte Cosmos DB, afin de voir ce qu’il contient.
Je compte alors 1 DB avec 3 conteneurs, et en plus, elle contient assez peu de données.
Lorsque je pèse le pour et le contre de chacune des solutions, je vois rapidement qu’il faut presque une usine à gaz pour un besoin relativement simple.
Mais d’un autre côté, je n’ai pas le choix, cette migration est obligatoire, et comme le disait Terence Hill et Bud Spencer :
Quand faut y aller, faut y aller !
Mais bon, on n’est pas non plus obligé d’y aller tout de suite, alors je vais voir si je trouve pas quelque chose de plus simple, et au pire des cas, j’aurai toujours une solution de retournement avec celles vues précédemment.
5. Solution envisagée : Migration avec Azure Cosmos DB data migration tool
En continuant mes recherches, je tombe sur une annonce de Microsoft datant de Avril 2015, parlant de l’outil Azure Cosmos DB Data Migration tool.
Bon je reconnais que 2015 c’est loin, mais je vais creuser un peu alors j’échange ma pipe, contre une petite pelle.
Cet outil open source permet d’importer des données vers Azure Cosmos DB, depuis différentes sources de données comme:
- JSON files
- CSV files
- SQL Server
- MongoDB
- Azure Table storage
- Amazon DynamoDB
- HBase
- Azure Cosmos containers
Vous avez vu comme moi, Cosmos DB vers Cosmos DB !
La pupille de mes yeux a commencé à se dilater, mes cheveux, (enfin ce qu’il m’en reste) sont tombés, et je me retrouve en slip en disant :
Mon précieux !
Une fois retrouvé mon aspect normal, enfin, mon aspect tout court, je commence à parcourir les différents liens mentionnés dans l’annonce et tombe sur le repo Git de l’outil.
J’ai l’impression que la chance a enfin changé de camps, quand je tombe sur la 1ère phrase et que je lis :
The Azure Cosmos DB data migration tool is undergoing a full refactor to restructure the project…
Ahhhhhhhhhhhhhhh cela me rend fou, quelqu’un joue avec moi, c’est pas possible autrement !
Mais comme je suis un acharné, je décide tout de même de visiter la branche archive du projet et fini par télécharger la version 1.8.3 qui date de Aout 2021, ce qui n’est pas si pire quand on y pense.
6. Tests de Azure Cosmos DB data migration tool
Je lance l’outil via l’exécutable dtui.exe (Et oui, je travaille sur Windows, et j’en suis fier), je parcours la doc et le fonctionnement semble très simple.
Il y a évidemment des prérequis :
- Un compte Azure Cosmos DB source
- Un compte Azure Cosmos DB destination
- Les chaines de connexion pour chacun des comptes
- Le nom de vos bases de données (DB)
- Le nom de vos containers
Comme vous pouvez le voir sur mon exemple ci-dessous, ma source est aziedb1amo008 et ma destination est aziedb1amo900 :
Je souhaite ainsi migrer ma DB StarWars ainsi que les différents containers, qu’elle possède à savoir People, Planets et Species. Ben quoi ? Je vous avais dit que c’était un projet super critique 😉
Etape 1 :
La première chose à faire est donc de définir notre compte source en spécifiant la chaine de connexion, accompagnée du nom de la base en fin de champs, ainsi que de la collection qui n’est autre que notre container.
On clique sur Verify afin de valider que la connexion au compte s’établie correctement.
Bingo, on peu passer à l’étape suivante.
Etape 2 :
Ensuite, nous allons définir notre compte de destination.
Tout comme à l’étape précédente, on définit la chaine de connexion, le nom de la DB qui sera créé automatiquement si celle-ci n’existe pas, la collection et la partition key.
Etape 3 :
A l’étape suivante vous pourrez définir un fichier de log au format csv.
Etape 4 :
Et enfin la dernière étape vous permet d’avoir un petit récapitulatif, et vous n’avez plus qu’à cliquer sur Import.
Et voila !
Enfin pas tout à fait car je voulais migrer aussi les containers Planets et Species, alors je déroule les mêmes étapes pour arriver à mon objectif.
Après une ou deux minutes, on peut donc s’apercevoir, que je retrouve, ma DB, mes containers, et même mes données sur le nouveau compte Cosmos DB, ce qui est plutôt sympa.
Et évidemment, cela marche aussi avec d’autres données que Star Wars, comme Pikachu ou Marvel !
Maintenant, si vous aussi vous souhaitez tester ou jouer un peu, vous pouvez retrouver mon jeu de données sur le site https://swapi.dev/api/
