Réplication et mise en miroir des bases de données
La mise en miroir de bases de données peut être utilisée pour améliorer la disponibilité de certaines bases de données de réplication. La prise en charge de l'utilisation conjointe de la réplication transactionnelle et de la mise en miroir de bases de données dépend des bases de données de réplication que vous souhaitez utiliser. L'utilisation conjointe de la réplication d'égal à égal et de la mise en miroir de bases de données n'est pas prise en charge. Pour plus d'informations sur la mise en miroir de bases de données, consultez Administration de la mise en miroir de bases de données.
Le tableau suivant répertorie les bases de données de réplication et le niveau de prise en charge correspondant pour la mise en miroir.
Base de données de réplication |
Utilisation conjointe à la mise en miroir de bases de données prise en charge |
|---|---|
Publication |
Oui. Prise en charge de l'utilisation conjointe de la fusion et de la réplication transactionnelle, et du basculement automatique. Les agents de réplication qui se connectent à la base de données de publication peuvent basculer automatiquement vers la base de données de publication en miroir. En cas d'échec, les agents qui se connectent à la base de données de publication se reconnecteront automatiquement à la nouvelle base de données principale. |
Distribution |
Non. La mise en miroir de la base de données de distribution n'est pas prise en charge. La base de données de distribution est celle où la configuration de la réplication est stockée. Les métadonnées de configuration y sont fortement couplées au nom du serveur où la base de données du serveur de distribution est configurée. Le nom du serveur changera pendant le basculement vers la base de données mise en miroir, mais les données de configuration stockées dans la base de données de distribution pointeront vers l'ancien serveur de base de données de distribution. |
Abonnement |
Oui. À compter de SQL Server 2008, prise en charge de la réplication transactionnelle avec le basculement et la configuration manuels. Les agents de réplication qui se connectent à la base de données d'abonnement ne prennent pas en charge la mise en miroir. En cas d'échec de la base de données d'abonnement principale, le basculement vers la base de données secondaire nécessite de votre part plusieurs opérations manuelles afin de restaurer le flux de données de réplication. Pour plus d'informations, consultez Réplication SQL Server : fournir une haute disponibilité grâce à la mise en miroir de base de données (article technique sur SQL Server). |
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.
Notes
Après un basculement, le miroir devient la base de données principale. Dans cette rubrique, les termes « principale » et « miroir » renvoient toujours aux bases de données principale 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 principale 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 Microsoft SQL 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 principale.
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 bases de données des abonnés pouvant être mises à jour immédiatement, les serveurs de publication Oracle, la topologie d'égal à égal sur les serveurs de publication et les serveurs de republication 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 principale.
Configurez les agents de réplication pour le basculement.
Ajoutez les bases de données principale 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 d'instantanés, 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 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 d'instantanés que le 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 d'instantanés utilisé par le principal.
Spécifiez le nom du miroir pour le 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 d'instantané (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 :
Il est recommandé 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 principale 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 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 principale et de la base de données miroir. Si la base de données principale est le serveur actif, les informations de publication sont affichées uniquement sous le nœud de base de données principale 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 principale, pas sur le nœud de base de données miroir.
Si la base de données principale n'est pas disponible, les nœuds de base de données principale 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 principale. Par conséquent, en cas de bases de données de publication activées pour la réplication sur le principal, le nom d'instance du serveur de publication stocké dans les tables système du miroir est celui du 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 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.
Notes
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 principal n'est plus mise en miroir, la réplication se poursuit comme si de rien n'était vis-à-vis du 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 pourront pas travailler avec le miroir. Si la base de données principale 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 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 principal ne peut pas basculer sur le miroir tant que ce dernier n'est pas connecté et que toutes les transactions du principal n'y figurent pas. |
Mode hautes performances |
Si le miroir n'est pas disponible, la base de données principale 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 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 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 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