Choix du type de réplication approprié
MicrosoftSQL Server offre trois types de réplication. Chaque type de réplication correspond à des besoins différents des applications. Selon les besoins de votre application, vous pouvez utiliser un ou plusieurs types de réplication dans une topologie :
Réplication de capture instantanée
Réplication transactionnelle
Réplication de fusion
Pour vous aider à choisir le type approprié de réplication, cette rubrique donne des informations sur les éléments suivants :
Scénarios de réplication
Cette section décrit brièvement plusieurs cas d'utilisation courants de la réplication, avec des liens vers des descriptions plus détaillées.
Types de réplication
Cette section décrit les besoins des applications auxquels peut répondre chaque type de réplication.
Mise à jour de données sur des Abonnés
Cette section décrit les options disponibles pour les applications qui nécessitent des mises à jour des données sur l'Abonné.
Nous recommandons de lire d'abord les descriptions des scénarios pour trouver le scénario qui correspond le mieux aux besoins de votre application, puis de cliquer sur le lien pour obtenir davantage d'informations. Si vous ne pouvez pas trouver une correspondance proche des besoins de votre entreprise ou si vous voulez des informations supplémentaires sur les types de réplication, lisez « Types de réplication ». Si votre application nécessite des mises à jour sur un ou plusieurs Abonnés, lisez « Mise à jour de données sur des Abonnés » pour déterminer la technologie appropriée à utiliser.
Scénarios de réplication
Les scénarios de réplication peuvent être divisés en deux grandes catégories : la réplication de données dans un environnement de serveur à serveur et la réplication de données entre un serveur et des clients. Les scénarios de serveur à serveur sont mis en œuvre à l'aide de la réplication transactionnelle (et parfois de la réplication de capture instantanée) ; les scénarios de serveur à client sont mis en œuvre à l'aide de la réplication de fusion.
Scénarios de serveur à serveur
Les données sont généralement répliquées entre des serveurs pour prendre en charge les applications et les besoins suivants :
Scénario |
Description |
|---|---|
Amélioration de l'adaptabilité et de la disponibilité |
La gestion de copies des données mises à jour en permanence permet aux activités de lecture d'évoluer vers plusieurs serveurs. La redondance résultant de la gestion de plusieurs copies des mêmes données est cruciale pour la maintenance planifiée et non planifiée du système. Pour plus d'informations, consultez Amélioration de l'adaptabilité et de la disponibilité. |
Entrepôt de données et création de rapports |
Les serveurs d'entrepôt de données et de création de rapports utilisent souvent des données provenant de serveurs de traitement transactionnel en ligne (OLTP). Utilisez la réplication pour déplacer des données entre des serveurs OLTP et des système de création de rapports et d'aide à la prise de décision. Pour plus d'informations, consultez Entreposage de données et rapports. |
Intégration de données provenant de plusieurs sites |
Les données sont souvent « remontées » de sites distants et consolidées sur un site central. De la même façon, les données peuvent être répliquées vers des sites distants. Pour plus d'informations, consultez Intégration de données provenant de plusieurs sites (Serveur). |
Intégration de données hétérogènes |
Certaines applications dépendent de données envoyées vers ou depuis des bases de données autres que MicrosoftSQL Server. Utilisez la réplication pour intégrer des données provenant de bases de données non-SQL Server. Pour plus d'informations, consultez Intégration de données hétérogènes. |
Déchargement du traitement par lots |
Les opérations de traitement consomment souvent trop de ressources pour s'exécuter sur un serveur OLTP. Utilisez la réplication pour décharger le traitement sur un serveur dédié au traitement par lots. Pour plus d'informations, consultez Déchargement de traitement par lots. |
Scénarios serveur et client
Les données sont généralement répliquées entre des serveurs et des clients (des stations de travail, des ordinateurs portables, des tablettes et des périphériques) pour prendre en charge les applications suivantes :
Scénario |
Description |
|---|---|
Échange de données avec des utilisateurs mobiles |
De nombreuses applications nécessitent que les données soient disponibles pour les utilisateurs distants, tels que les commerciaux, les livreurs, etc. Ces applications couvrent les domaines de la gestion de la relation clientèle (CRM, Customer Relationship Management), de l'automatisation des forces de vente (SFA, Sales Force Automation) et de l'automatisation des groupes opérationnels (FFA, Field Force Automation). Pour plus d'informations, consultez Échange de données avec des utilisateurs mobiles. |
Applications de point de vente au consommateur (POS, Consumer Point of Sale) |
Les applications POS, telles que les terminaux de retrait et les machines DAB, nécessitent que les données soient répliquées depuis des sites distants vers un site central. Pour plus d'informations, consultez Applications POS. |
Intégration de données provenant de plusieurs sites |
Les applications intègrent souvent des données provenant de plusieurs sites. Par exemple, une application qui prend en charge des bureaux régionaux nécessite que les données transitent dans un ou deux sens, entre les bureaux régionaux et un bureau central. Pour plus d'informations, consultez Intégration de données à partir de plusieurs sites (client). |
Types de réplication
Réplication de capture instantanée
Le processus de capture instantanée est souvent utilisé pour fournir le jeu initial de données et d'objets de base de données pour des publications transactionnelles et de fusion, mais la réplication de capture instantanée peut aussi être utilisée pour elle-même. L'utilisation de la réplication de capture instantanée pour elle-même est la plus appropriée quand une ou plusieurs des conditions suivantes sont remplies :
Les données changent peu fréquemment.
Il est acceptable que des copies des données ne soient pas à jour relativement au serveur de publication pendant un certain temps.
de faibles volumes de données sont répliqués ;
Un gros volume de modifications surviennent au cours d'une brève période de temps.
La réplication de capture instantanée est plus appropriée quand les modifications de données sont substantielles mais peu fréquentes. Par exemple, si une entreprise commerciale gère des tarifs de produits, et que ces tarifs sont tous mis à jour en même temps, une à deux fois par an, il est recommandé de procéder à une réplication de l'intégralité de la capture instantanée des données modifiées.
Réplication transactionnelle
La réplication transactionnelle est généralement utilisée dans des environnements de serveur à serveur et elle est appropriée dans chacun des cas suivants :
Vous souhaitez propager les modifications incrémentielles vers les abonnés, au fur et à mesure qu'elles s'exécutent.
L'application requiert une latence faible entre le moment où des modifications sont effectuées sur le serveur de publication et celui où les modifications arrivent sur l'Abonné.
L'application requiert l'accès aux états intermédiaires des données. Par exemple, si une ligne change cinq fois, la réplication transactionnelle permet à une application de répondre à chaque modification (par exemple activer un déclencheur), et pas simplement au résultat final des modifications de la ligne.
Le serveur de publication a un volume très élevé d'activités d'insertion, de mise à jour et de suppression.
Le serveur de publication ou l'Abonné est une base de données non-SQL Server, par exemple Oracle.
Par défaut, les Abonnés à une publication transactionnelle doivent être traités en lecture seule, car les modifications ne sont pas propagées en sens inverse au serveur de publication. Cependant, la réplication transactionnelle n'offre pas d'options qui permettent des mises à jour sur l'Abonné. Pour plus d'informations, consultez la section « Mise à jour de données sur des Abonnés » dans cette rubrique.
Réplication de fusion
La réplication de fusion est généralement utilisée dans des environnements de serveur à client. La réplication de fusion est appropriée dans les situations suivantes :
Plusieurs abonnés peuvent mettre à jour les mêmes données à différents moments et propager ces modifications au serveur de publication et à d'autres Abonnés.
des abonnés doivent recevoir des données, apporter des modifications hors connexion et synchroniser ultérieurement ces modifications avec l'éditeur et d'autres abonnés ;
Chaque Abonné requiert une partition de données différente.
Des conflits peuvent se produire et, le cas échéant, vous devez pouvoir les détecter et les résoudre.
L'application requiert le résultat des modifications des données au lieu de devoir accéder aux états intermédiaires des données. Par exemple, si une ligne change cinq fois sur un Abonné avant qu'il se synchronise avec un serveur de publication, la ligne ne change qu'une seule fois sur le serveur de publication pour refléter le résultat final des modifications (c'est-à-dire la cinquième valeur).
La réplication de fusion permet à plusieurs sites de fonctionner de manière autonome, pour fusionner ensuite leurs mises à jour en un résultat unique et uniforme. Étant donné que les mises à jour sont effectuées sur plusieurs nœuds, les mêmes données ont pu être mises à jour par le serveur de publication et par plusieurs Abonnés. Par conséquent, des conflits peuvent se produire quand des mises à jour sont fusionnées ; la réplication de fusion fournit plusieurs moyens de gérer ces conflits.
Mise à jour de données sur des Abonnés
Les types de réplication suivantes et leurs options vous permettent d'effectuer des modifications sur un Abonné et de faire en sorte que ces modifications soient transmises au serveur de publication :
Type de réplication |
Cas d'utilisation |
|---|---|
Réplication de fusion |
Pour plus d'informations, consultez Présentation de la réplication de fusion et Fonctionnement de la réplication de fusion. |
Réplication de fusion d'égal à égal |
Pour plus d'informations, consultez Réplication transactionnelle d'égal à égal. |
Réplication transactionnelle avec des abonnements mis à jour |
Pour plus d'informations, consultez Abonnements pouvant être mis à jour pour la réplication transactionnelle. |
Voir aussi