attendez que la réplication transactionnelle dans ADO.NET ou TSQL

Question

Mon application Web utilise ADO.NET contre SQL Server 2008. Base de données écrit arrive contre une base de données primaire (éditeur), mais lit la charge est équilibrée à travers le primaire et une base de données secondaire (abonné). Nous utilisons intégré la réplication transactionnelle de SQL Server pour maintenir la mise à jour secondaire. La plupart du temps, le couple de secondes de latence est pas un problème.

Cependant, j'ai un cas où je voudrais bloquer jusqu'à ce que la transaction est validée sur le site secondaire. Le blocage pendant quelques secondes est OK, mais renvoie une page rassis à l'utilisateur n'est pas. Est-il possible dans ADO.NET ou TSQL préciser que je veux attendre la fin de la réplication? Ou puis-je, de l'éditeur, vérifiez l'état de réplication de la transaction sans se connecter manuellement au serveur secondaire.

[modifier] 99,9% du temps, les données de l'abonné est « assez frais ». Mais il y a une opération qui invalident elle. Je ne peux pas lire l'éditeur à chaque fois sur le hasard qu'il est devenu invalide. Si je ne peux pas résoudre ce problème dans la réplication transactionnelle, vous pouvez proposer une autre architecture?

Answer 1

Il n'y a pas cette solution pour SQL Server, mais voici comment je travaille autour d'elle dans d'autres environnements.

Utilisez trois chaînes de connexion séparées dans votre application, et choisir la bonne en fonction des besoins de votre requête:

• en temps réel - Points directement à l'un serveur maître. Toutes les écritures vont à cette chaîne de connexion, et ne lit les plus essentielles à la mission rendez-vous ici.
• temps quasi-réel - Points à une charge équilibrée des abonnés piscine. Aucun écrit vont ici, ne lit. Utilisé pour la grande majorité des lectures OLTP.
• Retard de déclaration - Dans votre environnement en ce moment, il va pointer vers le même pool de charge équilibrée des abonnés, mais sur la route, vous pouvez utiliser une technologie comme l'envoi de journaux d'avoir un pool de serveurs 8-24 heures derrière. Ces échelle vraiment bien, mais les données est loin derrière. Il est idéal pour les rapports, la recherche, l'histoire à long terme, et d'autres besoins non en temps réel.

Si vous concevez votre application pour utiliser ces 3 chaînes de connexion depuis le début, l'échelle est beaucoup plus facile, en particulier dans le cas que vous rencontrez.

Answer 2

Vous décrivez une situation de mise en miroir synchrone. La réplication ne peut pas, par définition, l'appui de votre exigence. La réplication doit attendre une transaction à avant de le lire dans le journal et à le livrer au distributeur et de là à l'abonné, ce qui signifie que la réplication par définition a une fenêtre d'opportunité pour que les données soient sur synchronisation.

Si vous avez un besoin d'une opération pour lire la copie authorithative des données, alors vous devriez faire que decission dans le client et assurez-vous lu de l'éditeur dans ce cas.

Alors que vous pouvez, en threory, valider une transaction donnée wether a été distribué à l'abonné ou non, vous ne devriez pas baser votre conception sur elle. La réplication transactionnelle ne fait aucune garantie de temps d'attente, par la conception, de sorte que vous ne pouvez pas compter sur un mode de fonctionnement « jour parfait ».