Meilleure stratégie de réplication de serveur de sauvegarde chaud/chaud (SQL Server 2005)

Question

J'ai deux serveurs identiques avec SQL Server 2005 et mon application.

exigences dures:

1. je dois être en mesure de mettre à jour les données à chaque serveur.
2. Je dois être en mesure de débrancher l'un ou l'autre des serveurs sans avoir à reconfigurer quoi que ce soit dans la base de données.
3. Lorsqu'un serveur est rebranché, il doit automatiquement se synchroniser avec l'autre serveur.

Notes:

1. Je préfère les options qui ne seraient pas ajouter des charges importantes au serveur principal si possible.
2. Les deux serveurs ont un réseau privé pour la réplication, donc la bande passante n'est pas un problème.
3. Il est possible que les données soient périmées sur l'un ou l'autre des serveurs.

D'après ce que j'ai lu mes options sont:

• réplication transactionnelle avec actualisables Abonnements (de mise à jour en attente)
• fusion de réplication

Quelle configuration convient le mieux à mes besoins?

Answer 1

Aucune des options actuelles n'autorise l'écriture des deux serveurs. À peu près votre seule option va être la réplication de fusion car cela permet des mises à jour pour les deux serveurs. Toutefois, la réplication de fusion est la plus difficile à configurer et à exécuter. Vous devrez vous assurer que le distributeur dispose de suffisamment d'espace disque pour que le distributeur ne manque pas d'espace pendant tout le temps où l'un des serveurs est hors service.

L'envoi de journaux et la mise en miroir n'autorisent pas la mise à jour du serveur secondaire.

Answer 2

Avez-vous considéré Log Shipping?

Je ne pense pas que cela puisse facilement être configuré de sorte que la veille à chaud puisse prendre automatiquement le relais, donc un effort manuel a été nécessaire pour en faire le primaire.

Et ce sera seulement aussi bon que le dernier journal reçu - mais vous pourriez configurer pour expédier des notations toutes les minutes ou ainsi.

Si vous devez avoir 100% de mise à jour en veille, vous avez besoin d'une solution qui synchronise chaque transaction - qui sera un engagement distribué. Mais si vous expédiez le service de secours par FedEx et que vous pouvez forcer un processus (c'est-à-dire expédier le journal "final") avant sa mise hors tension, cela devrait fonctionner; ou si c'est juste déconnecté, FedEx'd, puis revient "en ligne" le Log Shipping devrait reprendre là où il s'était arrêté; alors quand vous en faites le primaire, il sera aussi "frais" que le journal le plus récent qu'il a reçu.