Amélioration de la disponibilité
La réplication peut être utilisée pour répliquer des données vers un serveur de secours, ce qui accroît la disponibilité en cas d'interruptions du système, planifiées ou non. Il convient d'utiliser la réplication pour disposer d'un serveur de secours à chaud si les données requises sur ce serveur sont un sous-ensemble des données requises sur le serveur primaire. Prenez également en considération les points suivants :
Si votre application a besoin de données sur plusieurs sites pour améliorer son évolutivité et sa disponibilité, consultez Amélioration de la disponibilité et de l'évolutivité.
Si votre application nécessite qu'une base de données entière soit disponible sur un serveur de secours, utilisez la mise en miroir de bases de données plutôt que la réplication. La mise en miroir de bases de données est plus efficace si l'ensemble de la base de données doit être synchronisé, et il n'est pas nécessaire d'utiliser le serveur secondaire pour les requêtes. Pour plus d'informations, consultez Administration de la mise en miroir de bases de données.
Le diagramme ci-dessous montre un serveur primaire et un serveur de secours unique, ainsi qu'un sous-ensemble des données du serveur primaire disponible sur le serveur secondaire.
.gif "Réplication de données vers un serveur de secours")
[!REMARQUE]
La réplication ne fournit pas de mécanisme pour basculer d'un serveur sur un autre serveur de secours. Toutes les applications qui ont accès à un serveur déterminé doivent être programmées pour utiliser un autre serveur pour le cas où le premier ne serait pas disponible.
Exemple Adventure Works Cycles
Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples de bases de données AdventureWorks.
Adventure Works Cycles possède un certain nombre de serveurs dans ses ateliers de fabrication, qui collectent les données relatives aux incidents sur les chaînes de production. Ils utilisent la réplication pour assurer la disponibilité de ces serveurs. Un code à été écrit pour rediriger les requêtes vers un serveur de secours à chaud durant les interruptions, planifiées ou non.
Conditions communes pour ce scénario
Les applications qui utilisent la réplication ont en général les exigences suivantes, auxquelles doit répondre une solution de réplication appropriée :
Le système doit assurer la cohérence des transactions.
Le système doit avoir une faible latence : les mises à jour effectuées sur un serveur doivent atteindre rapidement les autres serveurs.
Le système doit avoir un débit élevé : il doit assurer la réplication d'un grand nombre de transactions.
Le traitement des réplications ne doit nécessiter qu'une charge minimale.
Les données requises sur un serveur secondaire peuvent être un sous-ensemble des données disponibles sur le serveur primaire (voir ci-dessus le premier diagramme).
Type de réplication à utiliser pour ce scénario
MicrosoftSQL Server utilise une métaphore du secteur de l'édition pour décrire les composants du système de réplication. Ces composants sont le serveur de publication, les Abonnés, les publications et articles et les abonnements.
Dans le diagramme ci-dessus, le serveur primaire est le serveur de publication. Tout ou partie des données du serveur primaire sont incluses dans la publication, chaque table de données étant un article (les articles peuvent aussi être d'autres objets de bases de données, tels que des procédures stockées). Le serveur de secours est un Abonné à la publication, et reçoit comme abonnement des schémas et des données. Pour plus d'informations sur les composants de ce système, consultez Présentation du modèle de publication de réplication.
SQL Server offre différents types de réplication pour différents besoins des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La plus adaptée à ce scénario est la réplication transactionnelle, qui convient bien pour prendre en compte les conditions exposées dans la section qui précède. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.
De par sa conception, la réplication transactionnelle satisfait les principales conditions de ce scénario :
Homogénéité des transactions
Faible latence
Débit élevé
Charge minimale
La première option à envisager pour ce scénario est le filtrage. La réplication transactionnelle vous permet de filtrer les lignes et les colonnes, de façon que les tables au niveau des Abonnés ne contiennent que les données nécessaires à votre application. Pour plus d'informations, consultez Filtrage des données publiées.
Procédure de mise en œuvre de ce scénario
Pour mettre en œuvre ce scénario, vous devez tout d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur chaque étape :
Après initialisation d'un abonnement, lorsque les données circulent entre le serveur de publication et les Abonnés, peut-être aurez-vous besoin de consulter les rubriques qui suivent pour vous informer sur les tâches d'administration et de surveillance courantes :