Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La mise en miroir de bases de données peut être utilisée conjointement avec la réplication pour améliorer la disponibilité de la base de données de publication. La mise en miroir de bases de données implique deux copies d’une base de données unique qui réside généralement sur différents ordinateurs. À un moment donné précis, les clients ne peuvent accéder qu'à un seul exemplaire de la base de données. Cette copie est appelée base de données principale. Les mises à jour apportées par les clients à la base de données principale sont appliquées sur l’autre copie de la base de données, appelée base de données miroir. La mise en miroir implique l’application du journal des transactions à partir de chaque insertion, mise à jour ou suppression effectuée sur la base de données principale sur la base de données miroir.
Le basculement de réplication vers un miroir est entièrement pris en charge pour les bases de données de publication, avec un soutien limité pour les bases de données d’abonnement. La mise en miroir de bases de données n’est pas prise en charge pour la base de données de distribution. Pour plus d’informations sur la récupération d’une base de données de distribution ou d’une base de données d’abonnement sans avoir à reconfigurer la réplication, consultez Sauvegarde et restauration des bases de données répliquées. Pour plus d’informations sur la mise en miroir de la base de données des abonnés, consultez la page
Remarque
Après un basculement, le miroir devient le principal. Dans cette rubrique, « principal » et « miroir » font toujours référence au principal et au miroir d’origine.
Exigences et considérations relatives à l’utilisation de la réplication avec la mise en miroir de bases de données
Tenez compte des exigences et considérations suivantes lors de l’utilisation de la réplication avec la mise en miroir de bases de données :
Le principal et le miroir doivent partager un serveur de distribution. Nous recommandons qu'il s'agisse d'un distributeur distant, qui offre une meilleure tolérance aux pannes si l'éditeur rencontre un basculement imprévu.
La réplication prend en charge la mise en miroir de la base de données de publication, que ce soit pour la réplication de fusion ou pour la réplication transactionnelle avec des abonnés en lecture seule ou des abonnés mettant à jour en file d'attente. La mise à jour immédiate des Abonnés, des Éditeurs Oracle, des Éditeurs dans une topologie d'égal à égal et la republication ne sont pas prises en charge.
Les métadonnées et les objets qui existent en dehors de la base de données ne sont pas copiés dans le miroir, notamment les connexions, les travaux, les serveurs liés, et ainsi de suite. Si vous avez besoin des métadonnées et des objets sur le miroir, vous devez les copier manuellement. Pour plus d’informations, consultez Gestion des connexions et des travaux après le basculement de rôle (SQL Server).
Configuration de la réplication avec la mise en miroir de bases de données
La configuration de la réplication et de la mise en miroir de bases de données implique cinq étapes. Chaque étape est décrite plus en détail dans la section suivante.
Configurez le serveur de publication.
Configurez la mise en miroir de bases de données.
Configurez le miroir pour utiliser le même serveur de distribution que le principal.
Configurez les agents de réplication pour le basculement.
Ajoutez le principal et le miroir au moniteur de réplication.
Les étapes 1 et 2 peuvent également être effectuées dans l’ordre opposé.
Pour configurer la mise en miroir de bases de données pour une base de données de publication
Configurez le serveur de publication :
Nous vous recommandons d’utiliser un serveur de distribution distant. Pour plus d’informations sur la configuration de la distribution, consultez Configurer la distribution.
Vous pouvez activer une base de données pour les publications d’instantanés et transactionnelles et/ou les publications de fusion. Pour les bases de données mises en miroir qui contiennent plusieurs types de publication, vous devez activer la base de données pour les deux types au même nœud à l’aide de sp_replicationdboption. Par exemple, vous pouvez exécuter les appels de procédure stockée suivants sur le serveur principal :
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true; exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true;Pour plus d’informations sur la création de publications, consultez Publier des données et des objets de base de données.
Configurez la mise en miroir de bases de données. Pour plus d’informations, consultez Établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (SQL Server Management Studio) et configurer la mise en miroir de bases de données (SQL Server).
Configurez la distribution pour le miroir. Spécifiez le nom du miroir en tant qu'Éditeur, et spécifiez le même Distributeur et dossier d'instantané que celui utilisé par le principal. Par exemple, si vous configurez la réplication avec des procédures stockées, exécutez sp_adddistpublisher sur le serveur de distribution ; puis exécutez sp_adddistributor sur le miroir. Pour sp_adddistpublisher :
Définissez la valeur du paramètre @publisher sur le nom réseau du miroir.
Définissez la valeur du paramètre @working_directory sur le dossier d’instantanés utilisé par le principal.
Spécifiez le nom du miroir pour le paramètre de l’agent -PublisherFailoverPartner . Agent Ce paramètre est requis pour que les agents suivants identifient le miroir après le basculement :
Agent d’instantané (pour toutes les publications)
Agent de lecture de journaux (pour toutes les publications transactionnelles)
Agent de lecture de file d’attente (pour les publications transactionnelles qui prennent en charge les abonnements de mise à jour en file d’attente)
Agent de fusion (pour les abonnements de fusion)
Écouteur de réplication SQL Server (replisapi.dll: pour les abonnements de fusion synchronisés à l’aide de la synchronisation web)
SQL Merge ActiveX Control (pour les abonnements de fusion synchronisés via le contrôle)
L'Agent de distribution et le contrôle de distribution ActiveX n'ont pas ce paramètre, car ils ne se connectent pas à l'Éditeur.
Les modifications apportées aux paramètres prennent effet au prochain démarrage de l'Agent. Si l'Agent fonctionne en continu, vous devez l'arrêter, puis le redémarrer. Les paramètres peuvent être spécifiés dans les profils d’agent et à partir de l’invite de commandes. Pour plus d’informations, consultez :
Nous vous recommandons d’ajouter -PublisherFailoverPartner à un profil d’agent, puis de spécifier le nom du miroir dans le profil. Par exemple, si vous configurez la réplication avec des procédures stockées :
-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles. -- Select the profile id of the profile that needs to be updated from the result set. -- In the agent_type column returned by sp_help_agent_profile: -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent. exec sp_help_agent_profile; -- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'; -- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';Ajoutez le principal et le miroir au Moniteur de réplication. Pour plus d'informations, consultez Ajouter et supprimer des éditeurs du Moniteur de réplication.
Gestion d’une base de données de publication mise en miroir
La gestion d’une base de données de publication mise en miroir est essentiellement la même que la maintenance d’une base de données non mise en miroir, avec les considérations suivantes :
L’administration et la surveillance doivent se produire sur le serveur actif. Dans SQL Server Management Studio, les publications apparaissent sous le dossier Publications locales uniquement pour le serveur actif. Par exemple, si vous basculez vers le miroir, les publications y sont affichées et ne le sont plus chez le principal. Si la base de données bascule vers le miroir, vous devrez peut-être actualiser manuellement Management Studio et le Moniteur de réplication pour que la modification soit reflétée.
Le Moniteur de réplication affiche les nœuds publisher dans l’arborescence d’objets pour le principal et le miroir. Si le principal est le serveur actif, les informations de publication s’affichent uniquement sous le nœud principal du Moniteur de réplication.
Si le miroir est le serveur actif :
Si un agent a une erreur, l’erreur est indiquée uniquement sur le nœud principal, et non sur le nœud miroir.
Si le principal n’est pas disponible, le principal et les nœuds miroir affichent des listes de publications identiques. La surveillance doit être effectuée sur les publications sous le nœud miroir.
Lorsque vous utilisez des procédures stockées ou des objets RMO (Replication Management Objects) pour administrer la réplication sur le miroir, pour les cas où vous spécifiez le nom du serveur de publication, vous devez spécifier le nom de l’instance sur laquelle la base de données a été activée pour la réplication. Pour déterminer le nom approprié, utilisez la fonction publishingservername.
Lorsqu’une base de données de publication est mise en miroir, les métadonnées de réplication stockées dans la base de données mise en miroir sont identiques aux métadonnées stockées dans la base de données principale. Par conséquent, pour les bases de données de publications activées pour la réplication par le principal, le nom de l’instance du serveur de publication stocké dans les tables système du miroir est celui du principal, et non celui du miroir. Cela affecte la configuration et la maintenance de la réplication si la base de données de publication bascule vers le miroir. Par exemple, si vous configurez la réplication avec des procédures stockées sur le miroir après un basculement et que vous souhaitez ajouter un abonnement par extraction à une base de données de publication activée sur le principal, vous devez spécifier le nom du principal plutôt que le nom du miroir pour le paramètre @publisher de sp_addpullsubscription ou sp_addmergepullsubscription.
Si vous activez une base de données de publication sur le miroir après le basculement vers le miroir, le nom de l’instance du serveur de publication stocké dans les tables système est le nom du miroir. Dans ce cas, vous devez utiliser le nom du miroir pour le paramètre @publisher.
Remarque
Dans certains cas, comme sp_addpublication, le paramètre @publisher est pris en charge uniquement pour les serveurs de publication non-SQL Server ; dans ces cas, il n’est pas pertinent pour la mise en miroir de bases de données SQL Server.
Pour synchroniser un abonnement dans Management Studio après un basculement : synchroniser les abonnements par extraction à partir de l’Abonné ; et synchronisez les abonnements Push à partir du serveur de publication actif.
Comportement de réplication si la mise en miroir est supprimée
Gardez à l’esprit les problèmes suivants si la mise en miroir de bases de données est supprimée d’une base de données publiée :
Si la base de données de publication du principal n’est plus mise en miroir, la réplication continue de fonctionner sans modification pour le principal d'origine.
Si la base de données de publication bascule du principal vers le miroir et que la relation de mise en miroir est par la suite désactivée ou supprimée, les agents de réplication ne fonctionnent pas sur le miroir. Si le principal est définitivement perdu, désactivez la réplication puis configurez à nouveau le miroir spécifié en tant que serveur de publication.
Si la mise en miroir de bases de données est supprimée complètement, la base de données miroir est dans un état de récupération et doit être restaurée pour devenir fonctionnelle. Le comportement de la base de données récupérée par rapport à la réplication dépend de la spécification de l’option KEEP_REPLICATION. Cette option force l’opération de restauration à conserver les paramètres de réplication lors de la restauration d’une base de données publiée sur un serveur autre que celui sur lequel la sauvegarde a été créée. Utilisez l’option KEEP_REPLICATION uniquement lorsque l’autre base de données de publication n’est pas disponible. L’option n’est pas prise en charge si l’autre base de données de publication est toujours intacte et réplicable. Pour plus d’informations sur KEEP_REPLICATION, consultez RESTORE (Transact-SQL).
Comportement de l’agent de lecture du journal
Le tableau suivant décrit le comportement de l’agent de lecteur de journal pour les différents modes d’exploitation de la mise en miroir de bases de données.
| Mode d’exploitation | Comportement de l’Agent de lecture du journal si le miroir n’est pas disponible |
|---|---|
| Mode de sécurité élevée avec basculement automatique | Si le miroir n’est pas disponible, l’Agent de lecture du journal de log transmet les commandes à la base de données de distribution. Le principal ne peut pas basculer vers le miroir tant que le miroir n’est pas à nouveau en ligne et qu’il dispose de toutes les transactions provenant du principal. |
| Mode hautes performances | Si le miroir n’est pas disponible, la base de données principale fonctionne de manière exposée (autrement dit, non mirroring). Toutefois, l’Agent de lecture du journal réplique uniquement les transactions qui sont confirmées sur le miroir. Si le service est forcé et que le serveur miroir assume le rôle du principal, l’Agent de lecture du journal fonctionne sur le miroir et commence à récupérer les nouvelles transactions. N’oubliez pas que la latence de réplication augmente si le miroir se trouve derrière le principal. |
| Mode haute sécurité sans basculement automatique | Toutes les transactions archivées sont garanties d'être écrites sur le disque du miroir. L'Agent de lecture du journal ne réplique que les transactions qui sont stabilisées sur le miroir. Si le miroir n’est pas disponible, le principal interdit toute activité supplémentaire dans la base de données ; par conséquent, l’Agent de lecture du journal n’a pas de transactions à répliquer. |
Voir aussi
Réplication de SQL Server
Copie des journaux de transaction et réplication (SQL Server)