Nous avons une application qui combine à la fois des migrations de base de données rapides (<1 seconde) et lentes (> 30 secondes). En ce moment, nous exécutons des migrations de base de données dans le cadre de CI, mais notre outil CI doit connaître toutes les chaînes de connexion de base de données pour notre application (dans plusieurs environnements), ce qui n'est pas idéal. Nous voulons modifier ce processus afin que l'application exécute ses propres migrations de base de données au démarrage.
Voici la situation:
Nous avons plusieurs instances de cette application - environ 5 en production. Appelons-les node1, ..., node5
. Chaque application se connecte à une seule instance SQL Server, et nous n'utilisons pas de déploiements continus (toutes les applications sont déployées simultanément pour autant que je sache)
Problème: supposons que notre migration soit longue. Dans ce cas, node1
démarre, puis commence l'exécution de la migration. Maintenant, node4
commence et la migration de longue durée n'est pas encore terminée, donc node4
commence également à exécuter la migration -> possible corruption de données? Comment feriez-vous pour éviter ce problème ou le problème est-il suffisamment important pour vous inquiéter?
Je pensais résoudre ce problème avec un verrou distribué (en utilisant etcd
ou quelque chose dans ce sens). Fondamentalement, toutes les applications tentent d'acquérir le verrou, une seule d'entre elles l'obtient et exécute les migrations, puis se déverrouille. Lorsque les autres applications démarrent et entrent dans la section critique, toutes les migrations ont déjà été exécutées, de sorte que le script de migration se termine.
Cependant, mon instinct dit "c'est exagéré, il doit y avoir une solution plus simple", alors j'ai pensé que je demanderais ici pour voir si quelqu'un d'autre a de meilleures idées.