Mise à jour de la base de données et déploiement sans interruption de service

De nombreux articles ont été écrits sur la mise à jour des systèmes à la volée sans les arrêter (déploiement sans temps d'arrêt) et de nombreux aspects de cette approche sont assez évidents. À mon avis, la partie la plus difficile du déploiement dans ce cas est la mise à jour des entrepôts de données si leur contrat (schéma) a changé. C'est cet aspect que je voudrais considérer dans cet article.

Quelle que soit la base de données - avec un schéma de données explicite comme relationnel ou arbitraire comme NoSQL - le schéma de données est toujours présent, même au niveau de l'application. Les données lues dans la base de données doivent être compréhensibles pour le client, même si le référentiel lui-même n'impose aucune restriction à sa structure.

Supposons qu'un système avec une structure de données spécifique et des téraoctets de données dans la base de données fonctionne déjà en production. Dans la nouvelle version du système, nous devons légèrement modifier la structure pour implémenter de nouvelles fonctionnalités ou améliorer les performances. Considérez quels changements dans le circuit peuvent se produire:

• Ajout d'un nouveau champ
• Suppression de champs
• Renommer le champ
• Modifications du type de champ
• Transfert d'un champ vers une autre structure de données (par exemple, en cas de dénormalisation)

L'ajout d'un nouveau champ ainsi que l'ajout de tout autre objet de base de données est une modification rétrocompatible et ne nécessite aucune étape supplémentaire en termes de mise en œuvre du déploiement sans interruption (avec une mise en garde - si ce nouveau champ ou objet ne dépend pas fonctionnellement des autres déjà stockés dans la base de données données). Appliquez simplement les modifications à la base de données à la volée, puis déployez une nouvelle version du code qui utilise les nouveaux objets de base de données.

La suppression d'un champ ou de tout autre objet de base de données n'est pas une modification rétrocompatible, mais l'approche de sa mise en œuvre est très simple - les objets de base de données inutiles doivent être supprimés uniquement après que la nouvelle version du système est complètement bloquée.

Les trois autres types de modifications sont plus complexes en termes de déploiement sans interruption de service. En général, tous peuvent être effectués en copiant des données vers d'autres champs / entités et en supprimant les «anciens» après une migration réussie des données: pour renommer, vous pouvez copier les données de l'ancien champ vers un champ avec un nouveau nom, puis supprimer l'ancien champ, changer le type de données peut être fait avec renommer, etc. D'une manière ou d'une autre, sur une période de temps, la base de données doit prendre en charge les anciens et les nouveaux contrats. Il existe au moins deux façons d'effectuer de telles modifications à la volée:

Si la base de données prend en charge les déclencheurs

1. Créez des déclencheurs qui copient les données de l'ancien emplacement vers le nouveau lors de tout changement / ajout et définissez-les en production.
2. Appliquez un utilitaire de conversion de données qui fait de même, mais pour tous les enregistrements de la base de données. Comme les déclencheurs sont déjà installés, l'utilitaire ne peut rien faire de plus compliqué qu'une simple mise à jour «fictive» de chaque enregistrement (UPDATE table SET champ = champ ...). Un point très important ici est que l'action de lire les données de l'ancien endroit et d'écrire dans le nouveau doit être atomique et protégée des changements perdus. Selon la structure de la base de données, vous pouvez utiliser un verrouillage pessimiste via SELECT FOR UPDATE ou ses analogues, ou optimiste si la table a un champ avec une version d'enregistrement.
3. Une fois que l'utilitaire a terminé son travail (selon la quantité de données et la complexité de la mise à jour, le temps d'exécution peut prendre des jours), il est déjà possible d'installer une nouvelle version du système qui prend en charge le nouveau schéma de données. À ce stade, tous les enregistrements de la base de données qui existaient au moment du lancement de l'utilitaire seront convertis avec succès, et tous les nouveaux qui sont apparus pendant son fonctionnement seront également convertis par des déclencheurs.
4. Supprimez les déclencheurs et tous les champs (ou autres objets de base de données) qui ne sont plus nécessaires.

S'il n'est pas possible d'utiliser des déclencheurs (comme c'est le cas avec de nombreuses solutions NoSQL)

1. Créez et déployez une nouvelle version de l'application (version temporaire 1 sur la figure), qui lit toujours à partir de l'ancien champ, mais lors de l'écriture dans ce champ, elle met à jour à la fois l'ancien et le nouvel emplacement correspondant (dans la figure «C» - l'ancien, «H» - nouveau). Zadeplit cette version sur tous les nœuds sur lesquels les instances d'application s'exécutent.
2. Appliquez un utilitaire qui copie les données de l'ancien emplacement vers le nouveau. Comme pour les déclencheurs, vous devez prendre des mesures pour éviter les modifications perdues.
3. Créez et, une fois l'utilitaire terminé, installez une autre version de l'application (version temporaire 2), qui lit les données d'un nouveau champ, mais écrit toujours à deux endroits. Cette étape est nécessaire, car lors de la mise à jour séquentielle de chacun des nœuds, il y aura toujours un écart lorsque les instances de la version précédente de l'application lisant l'ancien champ fonctionneront simultanément avec la nouvelle.
4. Créez et à la fin du balayage complet de la précédente déployez la version finale, qui n'interagit déjà pas avec l'ancien champ.
5. Supprimez les anciens champs.

La deuxième approche nécessite la création et l'installation de trois versions différentes de l'application, ce qui peut être très gênant et encombrant. Au lieu de cela, vous pouvez utiliser le basculement des fonctionnalités - pour regrouper la logique des trois versions en une seule, mais changez de mode en fonction du paramètre de configuration, qui pourrait idéalement être activé à la volée. Ainsi, au lieu d'installer chaque version suivante, il suffira de changer la valeur du paramètre (et de redémarrer le service si la mise à jour de la configuration à la volée n'est pas fournie). Une fois l'installation de la version finale terminée avec succès, tout le code relatif à la migration des données doit être complètement supprimé de la branche de travail, même s'il "vivra" en production jusqu'à la prochaine mise à jour du système.

Il est facile de remarquer que garantir un temps d'indisponibilité nul lors de la mise à jour du système est une procédure lourde et fragile, il est donc logique de ne s'en préoccuper que s'il existe une exigence correspondante de la part de l'entreprise. Mais même si les exigences de disponibilité du système sont assez faibles (par exemple, 99% par an et que la fenêtre de mise à jour du système prévue est de 24 heures), la conversion des données requise pour installer la nouvelle version peut encore prendre plus de temps. Par conséquent, vous devez être préparé à l'avance pour l'utilisation de ces solutions si vous prévoyez de stocker de grandes quantités de données.

Une autre approche peut être le rejet intentionnel de modifications incompatibles en amont dans le schéma de la base de données, mais, malheureusement, dans la pratique, ce n'est pas toujours réalisable, car souvent le moyen le plus efficace d'améliorer les performances d'accès aux données est de restructurer le schéma.