Les groupes de disponibilité peuvent-ils remplacer la réplication transactionnelle?

J'ai regardé les nouvelles fonctionnalités de SQL Server 2012 et comment cela peut aider ma situation actuelle.

Actuellement, nous utilisons SQL Server 2008 R2 et répliquons les bases de données de deux serveurs OLTP sur un seul serveur de rapports via la réplication transactionnelle. Nous utilisons ensuite ces bases de données répliquées pour les rapports.

Je suis intéressé à savoir si SQL Server 2012 et les groupes de disponibilité peuvent remplacer cela - donc au lieu de la réplication transactionnelle, j'utiliserais les nouveaux groupes de disponibilité et mettrais en miroir les bases de données des deux serveurs OLTP sur le serveur de rapports - où les rapports pourront pour accéder aux répliques en lecture seule.

Je ne sais pas si cela fonctionnera bien, ou même pas du tout.

Je voudrais m'éloigner de la réplication, car cela cause des problèmes avec ma stratégie de déploiement (Utilisation de VSDBCMD.exe). Je voudrais également éviter les délais de réinitialisation de la réplication sur les grandes bases de données.

Quelqu'un at-il de bons exemples ou une bonne expérience à ce sujet? Est-il possible de mettre en miroir avec des réplicas lisibles de plusieurs serveurs vers un seul serveur selon la mise en miroir normale dans les versions inférieures?

Cela a été initialement demandé ici: /programming/10415225/mirroring-and-availability-groups-in-sql2012 Désolé, je ne pense pas que je puisse encore migrer les questions.

Tiré de ma réponse sur StackOverflow , uniquement pour empêcher les autres de consacrer des efforts au même type de réponse.

Personnellement, je pense que cela fonctionnera beaucoup mieux que la réplication transactionnelle, même si je n'ai fait aucune comparaison formelle des deux dans un véritable scénario de migration. Je sais qu'avec le nombre de problèmes que les gens ont avec la réplication transactionnelle, par rapport à la mise en miroir même standard (et c'est une mise à niveau de cela), vous êtes certainement lié à avoir moins de problèmes.

Le plus grand avantage est que le secondaire peut être marqué en lecture seule - vous pouvez donc exécuter tous les rapports que vous souhaitez, et cela n'affectera pas du tout la mise en miroir. Vous avez juste besoin de tempdb plus costaud (car il utilise essentiellement rcsi pour ce faire).

Bien sûr, vous devez être conscient que les deux côtés de l'AG doivent être entièrement sous licence afin d'utiliser la réplique pour des opérations en lecture seule. Et les deux parties doivent être exécutées sur des versions spécifiques de Windows (Enterprise ou mieux sur 2008 R2 et inférieur; Standard ou mieux sur 2012 et supérieur) car elles nécessitent un cluster de basculement - les instances SQL dans les AG n'ont pas besoin d'être clusterisées, mais ils doivent être assis au-dessus de cette infrastructure dans le système d'exploitation.

Avantages de la réplication transactionnelle sur les groupes de disponibilité pour la génération de rapports sur les charges de travail

Pour contrebalancer la réponse ci-dessus, voici quelques raisons pour lesquelles la réplication transactionnelle peut être une meilleure solution que les groupes de disponibilité pour signaler les charges de travail.

• Vous pouvez répliquer un sous-ensemble de tables dans la base de données. Les réplicas de groupe de disponibilité sont toujours la base de données entière. Si certaines tables contiennent des informations sensibles, l'audit d'accès est plus facile si tous les rapports sont effectués sur une base de données qui ne contient pas ces informations.
• Vous pouvez filtrer les lignes qui sont répliquées en fournissant un niveau de granularité fin. Par exemple, vous pouvez répliquer des informations spécifiques à un département sur une multitude de serveurs de reporting départementaux, chacun n'ayant accès qu'à ses informations.
• Vous pouvez avoir une stratégie d'indexation complètement différente entre l'éditeur et l'abonné. Avec les groupes de disponibilité, les index sont les mêmes et même si des statistiques seront créées sur la réplique et stockées dans tempdb, mais vous n'avez pas la possibilité de régler la réplication que vous donne.
• Problèmes de sécurité. En général, les utilisateurs de rapports se connectent directement à la base de données en utilisant SSMS, accèdent ou excellent et vous souhaitez restreindre leur accès à la base de données de rapports uniquement.

Si aucun de ces problèmes n'est important, les groupes de disponibilité peuvent être le meilleur choix.