Modifications du schéma SQL Server 2014 dans un environnement multi-utilisateurs 24/7

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

sql-server sql-server-2014

— Shmitov Michael
source

Quelle est votre disposition actuelle de SQL? En cluster? AlwaysOn? Miroir? Une seule instance?

— LowlyDBA

De nos jours, nous avons une seule instance, mais nous pouvons la changer en fonction des besoins, ajouter un nouveau serveur, etc.

— Shmitov Michael

Vous devez suivre l'approche bleu-vert, de cette façon, vous pouvez avoir un système actif (vert) et effectuer la mise à niveau sur la mise en scène (bleu), puis changer de rôle. C'est ce que nous avons implémenté en utilisant AlwaysON et cela fonctionne pour nous - presque le même scénario. Cela nécessite une planification, une mise en œuvre et des tests appropriés.

— Kin Shah

Pourriez-vous me donner un scénario plus détaillé, par exemple pour les modifications de schéma de suppression de colonne?

— Shmitov Michael

Explication du commentaire précédent, j'ai changé de nœud principal (S1) / secondaire (S2) dans l'infrastructure AlwaysOn, puis j'ai décidé de supprimer certaines colonnes du schéma sur la réplique (S1, c'était principal avant le commutateur), mais je peux toujours obtenir des données de réplication de S2 avec cette colonne dans le tableau .... comment puis-je résoudre ce problème?

— Shmitov Michael

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.

(Source de l'image)

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

— Kin Shah
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 recompilation

sp_recompile 'myproc'

— Krismorte
source