Les modifications de schéma "interrompent" les groupes de disponibilité ou sont-elles gérées de manière transparente?

Mon organisation prévoit d'adopter des groupes de disponibilité SQL Server 2012 et j'essaie de comprendre quel impact (le cas échéant) cela aura sur notre processus de mise à niveau d'application.

Nous publions des mises à jour d'application sur un cycle de 8 semaines et toute version peut inclure des modifications de schéma et / ou des migrations de données.

Ce que j'essaie de comprendre, c'est si la solution HA / DR gère les modifications de schéma de manière transparente (de nouvelles colonnes, des index sont ajoutés aux secondaires) ou si une intervention manuelle est requise pour créer le schéma sur chaque instance, puis réactiver Always On.

Je suppose que la migration des données est gérée de manière transparente, mais je voudrais également le confirmer.

Je suppose que je fais également l'hypothèse générale qu'il n'y a pas de différence dans ces comportements en fonction de la configuration des groupes de disponibilité, ce qui peut également être faux. S'il vous plaît, faites-moi savoir.

En un mot; Dans n'importe quelle version de mon application, je peux modifier un très grand tableau (de 10 à 100 millions de documents) en y ajoutant des colonnes. Certaines colonnes peuvent être "net new" afin qu'elles puissent utiliser la fonctionnalité de modification de schéma Enterprise Online. D'autres colonnes peuvent être une refactorisation d'une colonne existante (FullName est divisé en FirstName et LastName) et une migration sera exécutée pour chaque ligne du tableau pour remplir ces champs. L'un de ces comportements nécessite-t-il que les administrateurs de base de données modifient la configuration AlwaysOn ou est-ce géré par défaut et tous les secondaires reçoivent les instructions DDL et DML "gratuitement"?

Merci pour toute clarté que vous pouvez apporter.

Les modifications de schéma et les modifications de données sont essentiellement les mêmes. Cela fonctionne comme la mise en miroir traditionnelle aujourd'hui: ce qui s'est passé dans le journal sur le primaire se produit sur le secondaire. Tout ce qui se passe à Vegas ne doit pas rester à Vegas. :-)

Vous devrez peut-être faire attention lorsque vous avez une application qui pointe vers la principale et que vous la mettez à jour pour correspondre aux modifications de schéma. Mais vous pouvez avoir une application différente qui pointe vers le secondaire (par exemple avec une intention de lecture seule), et ce changement d'application devrait également être synchronisé.

Un autre problème potentiel se produit lorsque votre base de données qui fait partie d'un groupe de disponibilité a des références à des objets dans d'autres bases de données (par exemple, une table de recherche statique qui est stockée dans une base de données utilitaire). Si ceux-ci changent et que l'AG dépend de ces objets, vous devrez pousser ces changements manuellement. Il en va de même pour les travaux, les connexions au niveau du serveur, les serveurs liés, etc. - tout ce qui vit en dehors de la base de données et / ou qui n'est pas transactionnel. Les utilisateurs de base de données peuvent devenir orphelins (utilisateurs confinés mis à part). Je sais que c'est probablement évident, mais je voulais l'énumérer explicitement pour être complet.

Plus de réponses ici de Remus, les utilisateurs demandent de supprimer éventuellement les requêtes sur le réplica secondaire et de vérifier l'état de la taille de la file d'attente dans le tableau: sys.dm_hadr_database_replica_states AlwaysOn DDL et modifications de schéma