Nous avons installé SQL Server 2014 Enterprise pour exécuter une base de données qui devrait être disponible 24/7. Notre base de données est assez énorme (200 Go +). Nous avons également de nombreux services qui consultent notre base de données chaque minute pour lire, mettre à jour ou insérer de nouvelles données. Nous voulons fournir une fonctionnalité de redéploiement "à chaud" pour nos clients et rendre nos mises à jour quotidiennes (mises à jour .net et schémas) transparentes pour les clients. Nous avons trouvé une solution basée sur un cluster avec équilibreur de charge pour mettre à jour les binaires de notre application, mais nous avons encore des malentendus sur le processus de déploiement des mises à jour de la base de données et quelles sont les meilleures pratiques pour résoudre ce problème.
Pour les modifications de schéma, arrêtez un serveur, appliquez les modifications de schéma, remettez-le en place, puis appliquez les mêmes modifications à la deuxième instance. Peut-il être accompli avec les outils SQL Server, et est-ce une approche courante? Comment synchroniser les données après la sauvegarde du serveur? Ou est-ce que je pense complètement dans la mauvaise direction et y a-t-il de meilleures solutions?
Nos modifications de schéma courantes: ajouter / supprimer une colonne, ajouter / supprimer une procédure stockée
la source
Réponses:
Ci-dessous, il faudra un peu plus de planification et de tests.
Concept bleu-vert:
L'essentiel de Blue-Green Concept est de diviser votre production en 2 environnements et ils sont identiques à tout moment (synchronisation des données) où
Le bleu (actuel) aura la version actuelle du schéma / build ou du produit et sera votre environnement "LIVE".
En même temps, Green sera votre environnement de test / de test dans lequel vous mettrez à niveau votre schéma / build ou votre produit vers la version NEXT, effectuerez un test de régression complet et serez approuvé par les utilisateurs de votre entreprise. Une fois satisfait, pendant une période de transition, vous promouvez le vert comme environnement "LIVE" et rétrogradez le bleu pour qu'il soit préprod / mise en scène ou test pour la prochaine version.
De cette façon, vous avez un temps d'arrêt très inférieur et le risque d'échec de déploiement sur un système en direct (qui est dans la fenêtre de maintenance, car vous effectuez une mise à niveau) sera fortement minimisé. De plus, en suivant l'approche Blue-Green, vous oscillerez entre la version LIVE et la version PRÉCÉDENTE qui sera mise en scène pour la prochaine version.
Encore une fois, cela nécessitera plus de matériel / de licences ainsi que de planification et de tests.
La plupart des étapes peuvent être automatisées à l'aide de DACPAC et de PowerShell. De plus, si vous installez plusieurs instances sur un serveur, assurez-vous de rééquilibrer les paramètres de la mémoire lors du basculement entre le bleu et le vert. L'environnement LIVE obtient plus de mémoire que l'environnement passif.
Dans mon environnement actuel, nous avons implémenté un modèle bleu / vert pour le déploiement de code agile qui nous permet de promouvoir le code toutes les 2 semaines avec suffisamment de temps pour les tests et la validation de l'entreprise. De plus, c'est un jeu d'enfant de revenir en arrière en cas de problème horrible. Nous avons automatisé la majorité des tâches de déploiement à l'aide de Dacpacs et de PowerShell.
Reportez-vous également à l'article de Grant Fritchey sur la résolution des problèmes de restauration et de récupération; Défis et stratégies
la source
Si votre base de données n'est pas répliquée, les colonnes d'ajout et de suppression seront exécutées très rapidement. Parce que l'ajout de colonne n'est qu'une position vide créée par SQL. La colonne de dépôt effacera simplement la référence.
Sinon, s'il y a une contrainte ou un index, faites attention.
ADD/DELETEles procédures auront juste un effet sur l'exécution elle-même. La recommandation est avant toute modification, exécutez la recompilationla source