Comment mettre à jour votre schéma de base de code de production / base de données sans provoquer de temps d'arrêt?
Quelles sont certaines techniques pour mettre à jour un schéma de base de code/base de données de serveur de production sans provoquer de temps d'arrêt?
En général, les sites Web sur lesquels j'ai travaillé qui avaient ce type d'exigence étaient tous derrière des équilibreurs de charge ou avaient des emplacements de basculement distincts. Dans cet exemple, je suppose que vous avez un seul équilibreur de charge, 2 serveurs Web (A et B) et 2 serveurs de base de données (M et N - généralement les serveurs DB sont liés via l'envoi de journaux - au moins dans le monde SQL Server ).
- Le serveur Web A doit être déconnecté de l'équilibreur de charge (donc tout le trafic entrant est acheminé vers B).
- L'envoi des journaux est arrêté (DB Server M va d'abord être mis à jour).
- Mettre à jour le serveur Web A. Pointez la configuration sur DB Server M.
- Testez et vérifiez que la mise à jour a fonctionné (généralement les gens frappent directement l'adresse IP).
- Définissez l'équilibreur de charge pour que les sessions existantes continuent à aller à B. Les nouvelles sessions vont à A.
- Attendez que toutes les sessions sur B expirent (cela peut durer une demi-heure ou plus, nous surveillons généralement le trafic et une pause d'une heure est prévue).
- Mettre à jour B et N.
- Testez et vérifiez que la mise à jour a fonctionné.
- Configurez à nouveau l'envoi de journaux et testez le fonctionnement.
- Réglez l'équilibreur de charge sur un fonctionnement normal.
Dans des applications Web très compliquées, ce qui est décrit comme les étapes 1 à 5 peut prendre toute la nuit et être une feuille de calcul Excel de 50 pages avec des heures et des numéros de contact d'urgence. Dans de telles situations, la mise à jour de la moitié du système est prévue de 18 h à 6 h tout en laissant le système à la disposition des utilisateurs. La gestion de la mise à jour du site DR est généralement prévue pour la nuit suivante - espérons juste que rien ne casse le premier jour.
Lorsque la disponibilité est une exigence, les correctifs sont d'abord testés sur l'environnement QA, qui est idéalement le même matériel que la production. S'ils ne présentent aucune perturbation, ils peuvent ensuite être appliqués selon le calendrier régulier, qui est généralement le week-end.
Pour les bases de données classiques (Oracle par exemple), il est possible de modifier le schéma de la base de données tout en exécutant des requêtes en parallèle. Cela nécessite cependant une certaine planification.
Voici quelques contraintes pour que le changement soit appliqué:
- il doit fonctionner avec le code existant, ce qui signifie que le code doit traiter à la fois l'ancienne et la nouvelle version du schéma
- cela ne devrait pas entraîner une telle charge sur la base de données que les transactions s'arrêteraient (je vous regarde
CREATE INDEX) - cela ne devrait pas entraîner de perte de données (vous ne pouvez pas supprimer et recréer une table)
Pour que le schéma soit rétrocompatible, vous pouvez généralement AJOUTER ou MODIFIER une colonne, vous ne pouvez DROP quelque chose que si le code existant ne l'utilise plus.
Si votre code ne peut pas gérer la modification de manière transparente, modifiez-le avant de modifier la base de données.
Conseils simples sur la planification prévisionnelle: explicitez toujours les noms de colonne dans vos demandes de base de données (n'utilisez pas SELECT * FROM). De cette façon, vous n'aurez pas de nouvelles colonnes apparaissant dans les anciennes demandes.
Tous les systèmes ne le peuvent pas, il doit être configuré de manière à le prendre en charge.
Par exemple, l'un de nos principaux systèmes que j'ai aidé à mettre à niveau il y a quelques années devrait être disponible 24h/24 et 7j/7. Il se composait de plusieurs niveaux, y compris un niveau de communication pur entre la couche d'interface utilisateur hors site et la couche métier. En raison de la façon dont la couche de communication a été codée, toute modification future de la couche métier ou du schéma de base de données pourrait être mise en œuvre sans véritable panne. Dans le pire des cas, un utilisateur subirait une pause de 10 à 30 secondes lorsque les modifications prendraient effet.
Si les modifications étaient purement des modifications de code de la couche métier, elles pouvaient être mises en file d'attente et "mises en cycle" avec seulement un délai de quelques millisecondes.
Il pourrait le faire parce que:
- La couche communication pourrait contenir des messages. Cela nous a permis d'avoir une panne réelle sur l'un des niveaux autres que la couche UI sans avoir besoin de faire tomber l'interface utilisateur.
- La couche métier gérée par la MVDB appelée niData . Cela contient tout le code en mémoire. Après avoir compilé le code, vous pouvez utiliser une commande pour forcer le nouveau code objet en mémoire, en remplaçant l'ancien.
D'autres techniques impliquent la réplication des transactions vers un autre miroir du système existant. En appliquant la mise à jour à un, en basculant et en relisant toutes les transactions effectuées entre la mise à jour et le commutateur. YMMV en fonction de vos systèmes.
Voici une perspective différente, du monde des systèmes de bases de données embarqués et des systèmes embarqués. Les systèmes embarqués incluent divers équipements d'infrastructure de réseau/télécommunications, et dans ce domaine, ils parlent souvent de 99,999% (cinq 9s) de disponibilité.
Nous (McObject) sommes le fournisseur de la famille eXtremeDB de produits de système de base de données embarquée, y compris eXtremeDB High Availability.
Tout d'abord, comprenez que "base de données intégrée" signifie que le système de base de données est une bibliothèque qui est compilée et liée avec votre code d'application; en ce sens, il est "intégré" à votre application.
Avec eXtremeDB High Availability, il existe une instance MASTER de votre application (qui peut être un ou plusieurs processus) et une ou plusieurs instances REPLICA de votre application. Lorsqu'une réplique établit une connexion avec le maître, elle reçoit une copie de la base de données du maître via un processus appelé "synchronisation initiale". Cela peut être fait pendant que l'application maître continue son travail. Une fois synchronisé, il reçoit les transactions du maître par réplication. Par conséquent, une réplique contient toujours des données actuelles et peut prendre le relais (via un processus appelé basculement) en cas de défaillance du maître.
Une caractéristique de la synchronisation initiale est appelée "évolution du schéma binaire". En clair, cela signifie que le processus de remplissage de la base de données du réplica s'adaptera aux différences entre le schéma de base de données du réplica et le schéma de base de données du maître.
En pratique, cela signifie que vous pouvez créer une version plus récente de votre application (avec des tables nouvelles/supprimées, des champs nouveaux/supprimés/modifiés, des index nouveaux/supprimés), attacher cette nouvelle version de votre application à un maître, puis provoquer cette une réplique plus récente pour devenir le nouveau maître (c'est-à-dire forcer un basculement vers la nouvelle réplique pour qu'elle devienne le maître et que l'ancien maître s'arrête). Voila, vous avez migré votre application de la version N vers N + 1, sans interrompre la disponibilité de votre système. Vous pouvez maintenant mettre à niveau l'ancien maître et toutes les autres répliques vers la version N + 1.