Réplication et mise en miroir des bases de données
La mise en miroir des bases de données peut avoir lieu en parallèle à la réplication afin d'assurer la disponibilité de la base de données de publication. La mise en miroir des bases de données consiste à avoir deux exemplaires d'une même base de données qui résident généralement sur des ordinateurs différents. À un moment donné précis, les clients ne peuvent accéder qu'à un seul exemplaire de la base de données. Cet exemplaire s'appelle la base de données primaire. Les mises à jour apportées par les clients sur la base de données primaire sont appliquées à l'autre exemplaire de la base de données, appelé base de données miroir. La mise en miroir consiste à répercuter dans la base de données miroir chaque insertion, mise à jour ou suppression apportée à la base de données primaire.
Le basculement de la réplication vers un miroir n'est assuré que pour les bases de données de publication ; il ne l'est pas pour les bases de données de distribution et d'abonnement. Pour plus d'informations sur la façon de récupérer une base de données de distribution ou d'abonnement sans avoir à reconfigurer la réplication, consultez Sauvegarde et restauration de bases de données répliquées.
[!REMARQUE]
Après un basculement, le miroir devient la base de données primaire. Dans cette rubrique, les termes « primaire » et « miroir » renvoient toujours aux bases de données primaire et miroir d'origine.
Conditions requises et éléments à prendre en compte pour procéder à une réplication avec mise en miroir des bases de données
Tenez compte des exigences et des points suivants lors d'une réplication avec mise en miroir des bases de données :
Les bases de données primaire et miroir doivent partager un serveur de distribution. Nous vous conseillons de choisir un serveur de distribution à distance qui offre une plus grande tolérance de panne en cas de basculement inopiné du serveur de publication.
Les serveurs de publication et de distribution doivent être MicrosoftSQL Server 2005 ou version ultérieure. Les Abonnés peuvent exécuter n'importe quelle version, mais les abonnements de réplication de fusion par extraction de données antérieurs à SQL Server 2005 ne prennent pas en charge le basculement. Dans ce cas, l'agent s'exécute au niveau de l'Abonné et les versions antérieures de l'agent ne tiennent pas compte des miroirs. La réplication vers des Abonnés de ce type reprend en cas de restauration automatique de la base de données miroir vers la base de données primaire.
La réplication prend en charge la mise en miroir des bases de données de publication pour les réplications de fusion et les réplications transactionnelles mettant en jeu des Abonnés en lecture seule ou des Abonnés avec mise à jour en file d'attente. Les Abonnés avec mise à jour immédiate, les serveurs de publication Oracle et les serveurs de publication d'une topologie d'égal à égal ne sont pas pris en charge.
Les métadonnées et les objets qui existent en dehors de la base de données, c'est-à-dire connexions, travaux, serveurs liés, etc. ne sont pas copiés vers le miroir. Si vous voulez faire figurer les métadonnées et les objets dans le miroir, vous devez les copier manuellement. Pour plus d'informations, consultez Gestion des connexions et des travaux après un basculement de rôle.
Configuration de la réplication avec mise en miroir des bases de données
La configuration de la réplication et de la mise en miroir des bases de données se fait en cinq étapes. Chaque étape est décrite plus en détail dans les sections qui suivent.
Configurez le serveur de publication.
Configurez la mise en miroir des bases de données.
Configurez la base de données miroir de façon à ce qu'elle utilise le même serveur de distribution que la base de données primaire.
Configurez les agents de réplication pour le basculement.
Ajoutez les bases de données primaire et miroir dans le Moniteur de réplication.
Les étapes 1 et 2 peuvent être inversées.
Pour configurer la mise en miroir d'une base de données de publication
Configurez le serveur de publication :
Nous vous conseillons d'utiliser un serveur de distribution distant. Pour plus d'informations sur la configuration de la distribution, consultez Configuration de la distribution.
Vous pouvez activer une base de données en vue de publications de captures instantanées, de publications transactionnelles et/ou de publications de fusion. Pour les bases de données mises en miroir contenant plusieurs types de publications, vous devez activer la base de données pour les différents types au niveau du même nœud à l'aide de sp_replicationdboption. Vous pourriez, par exemple, appeler la procédure stockée suivante sur le serveur principal :
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=truePour plus d'informations sur la création des publications, consultez Publication de données et d'objets de base de données.
Configurez la mise en miroir des bases de données. Pour plus d'informations, consultez Procédure : configurer une session de mise en miroir de bases de données (SQL Server Management Studio) et Configuration de la mise en miroir d'une base de données.
Configurez la distribution pour le miroir. Spécifiez le nom du miroir comme serveur de publication, puis spécifiez le serveur de publication et le dossier de captures instantanées que le serveur principal utilise. Par exemple, si vous configurez la réplication par le biais de procédures stockées, exécutez sp_adddistpublisher sur le serveur de distribution, puis sp_adddistributor sur le miroir. Pour sp_adddistpublisher :
Donnez au paramètre @publisher le nom de réseau du miroir.
Donnez au paramètre @working_directory le nom du dossier de captures instantanées utilisé par le serveur principal.
Spécifiez le nom du miroir comme paramètre d'agent –PublisherFailoverPartner. Agent Ce paramètre est obligatoire ; il permet aux agents suivants d'identifier le miroir après le basculement :
Agent de capture instantanée (pour toutes les publications)
Agent de lecture du journal (pour toutes les publications transactionnelles)
Agent de lecture de la file d'attente (pour les publications transactionnelles prenant en charge les abonnements avec 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 via la synchronisation Web)
Contrôle ActiveX SQL Merge (pour les abonnements de fusion synchronisés à l'aide du contrôle)
L'agent de distribution et le contrôle ActiveX SQL Distribution n'ont pas ce paramètre puisqu'ils ne se connectent pas au serveur de publication.
Les modifications apportées au paramètre Agent prennent effet au prochain démarrage de l'agent. Si l'agent s'exécute en permanence, vous devez l'arrêter puis le redémarrer. Les paramètres peuvent être définis dans les profils d'agent et à l'invite de commandes. Pour plus d'informations, consultez :
Nous vous recommandons d'ajouter le paramètre –PublisherFailoverPartner à un profil d'agent, puis de spécifier le nom du miroir dans le profil. Par exemple, si vous configurez la réplication à l'aide de 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 les bases de données primaire et miroir dans le Moniteur de réplication. Pour plus d'informations, consultez Procédure : ajouter et supprimer des serveurs de publication à partir du moniteur de réplication (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 reste quasiment identique qu'elle soit mise en miroir ou non, mais quelques précautions sont toutefois à prendre :
L'administration et la surveillance doivent se faire au niveau du serveur actif. Dans SQL Server Management Studio, les publications apparaissent sous le dossier Publications locales uniquement pour le serveur actif. En cas de basculement sur le miroir, par exemple, les publications s'affichent sur le miroir et plus sur le serveur principal. Si la base de données bascule sur le miroir, vous aurez à actualiser manuellement Management Studio et le moniteur de réplication pour répercuter les modifications.
Le moniteur de réplication affiche les nœuds de serveur de publication dans l'arborescence des objets de la base de données primaire et de la base de données miroir. Si la base de données primaire est le serveur actif, les informations de publication sont affichées uniquement sous le nœud de base de données primaire dans le moniteur de réplication.
Si la base de données miroir est le serveur actif :
Si un agent possède une erreur, celle-ci est indiquée sur le nœud de base de données primaire, pas sur le nœud de base de données miroir.
Si la base de données primaire n'est pas disponible, les nœuds de base de données primaire et miroir affichent des listes identiques de publications. La surveillance doit être réalisée sur les publications sous le nœud de base de données miroir.
Si vous faites appel aux procédures stockées ou aux objets d'administration de la réplication (RMO) pour gérer la réplication sur le miroir, vous devez spécifier comme serveur de publication le nom de l'instance où la base de données est activée pour la réplication. Pour déterminer le nom approprié, utilisez la fonction publishingservername.
En cas de mise en miroir d'une base de données de publication, les métadonnées de réplication stockées dans la base de données miroir sont identiques à celles de la base de données primaire. Par conséquent, en cas de bases de données de publication activées pour la réplication sur le serveur principal, le nom d'instance du serveur de publication stocké dans les tables système du miroir est celui du serveur principal, et non du miroir. Cela affecte la configuration et l'administration de la réplication si la base de données de publication bascule sur le miroir. Supposons, par exemple, que vous configuriez la réplication à l'aide de procédures stockées sur le miroir, une fois le basculement réalisé, et que vous vouliez ajouter un abonnement par extraction de données à une base de données de publication activée au niveau du serveur principal, vous devez alors utiliser le nom principal et non le nom miroir dans le paramètre @publisher de sp_addpullsubscription ou sp_addmergepullsubscription.
Si vous activez une base de données de publication au niveau du miroir, une fois le basculement vers le miroir réalisé, le nom d'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 dans le paramètre @publisher.
[!REMARQUE]
Dans certains cas, comme sp_addpublication, le paramètre @publisher n'est pris en charge que pour les serveurs de publication non-SQL Server ; il ne sert alors à rien en cas de mise en miroir des bases de données SQL Server.
Pour synchroniser un abonnement dans Management Studio après un basculement : synchronisez les abonnements par extraction à partir de l'Abonné, puis synchronisez les abonnements par émission de données à partir du serveur de publication actif.
Comportement de la réplication en cas de suppression de la mise en miroir
Gardez les points suivants à l'esprit si la mise en miroir des bases de données est retirée d'une base de données publiée :
Si la base de données de publication du serveur principal n'est plus mise en miroir, la réplication se poursuit comme si de rien n'était vis-à-vis de la base de données primaire d'origine.
Si la base de données de publication bascule du serveur 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 pourront pas travailler avec le miroir. Si la base de données primaire est définitivement perdue, désactivez, puis reconfigurez la réplication avec le miroir choisi comme serveur de publication.
Si la mise en miroir des bases de données est totalement supprimée, la base de données miroir passe en é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 à l'égard de la réplication varie selon que l'option KEEP_REPLICATION est ou non activée. Cette option oblige 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 elle a été créée. N'utilisez l'option KEEP_REPLICATION que si 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 intacte et en cours de réplication. Pour plus d'informations sur KEEP_REPLICATION, consultez Arguments RESTORE (Transact-SQL).
Comportement de l'Agent de lecture du journal
Le tableau suivant décrit la façon dont se comporte l'Agent de lecture du journal dans les différents modes d'opération de la mise en miroir des bases de données. Pour plus d'informations sur les modes d'opération, consultez Paramètres Transact-SQL et modes d'opération de mise en miroir de bases de données.
Mode d'opération |
Comportement de l'Agent de lecture du journal en cas d'indisponibilité du miroir |
|---|---|
Mode haute sécurité avec basculement automatique |
Si le miroir n'est pas disponible, l'Agent de lecture du journal propage les commandes vers la base de données de distribution. Le serveur principal ne peut pas basculer sur le miroir tant que ce dernier n'est pas connecté et que toutes les transactions du serveur principal n'y figurent pas. |
Mode hautes performances |
Si le miroir n'est pas disponible, la base de données primaire s'exécute sans filet (elle n'est pas mise en miroir). Toutefois, l'Agent de lecture du journal réplique les transactions renforcées sur le miroir. Si le service est forcé et que le serveur miroir joue le rôle de serveur principal, l'Agent de lecture du journal travaille en fonction du miroir et commence à collecter les nouvelles transactions. Pour plus d'informations, consultez Service forcé (avec possibilité de perte de données). Sachez que la durée de latence de la réplication augmente si le miroir se trouve derrière le serveur principal. |
Mode haute sécurité sans basculement automatique |
Toutes les transactions validées sont renforcées sur le disque dur du miroir. L'Agent de lecture du journal ne réplique que les transactions renforcées du miroir. Si le miroir n'est pas disponible, le serveur principal empêche toute autre activité dans la base de données. L'Agent de lecture du journal n'a plus aucune transaction à répliquer. |
Voir aussi