Stratégies de sauvegarde et de restauration de la réplication de fusion
Pour la réplication de fusion, effectuez régulièrement des sauvegardes des bases de données suivantes :
La base de données de publication au niveau du serveur de publication
La base de données de distribution au niveau du serveur de distribution
La base de données d'abonnement sur chaque Abonné
Les bases de données système master et msdb au niveau du serveur de publication, du serveur de distribution et de tous les Abonnés. Il est recommandé de sauvegarder ces bases de données en même temps, ainsi que la base de données de réplication appropriée. Par exemple, sauvegardez les bases de données master et msdb au niveau du serveur de publication en même temps que la base de données de publication. Si la base de données de publication est restaurée, vérifiez que les bases de données master et msdb sont cohérentes avec la base de données de publication en termes de configuration de la réplication et de paramètres.
Si vous effectuez des sauvegardes régulières des journaux, toutes les modifications liées à la réplication doivent être capturées dans les sauvegardes des journaux. Si vous n'effectuez pas de sauvegardes des journaux, une sauvegarde doit être effectuée si un paramètre concernant la réplication est modifié. Pour plus d'informations, consultez Actions courantes nécessitant une sauvegarde mise à jour.
Choisissez une des approches détaillées ci-dessous pour la sauvegarde et la restauration de la base de données de publication, puis suivez les recommandations indiquées pour la base de données de distribution et les bases de données d'abonnement.
Sauvegarde et restauration de la base de données de publication
Il y a deux approches pour la restauration d'une base de données de publication de fusion. Après la restauration de la base de données de publication à partir d'une sauvegarde, il est recommandé d'effectuer l'une des deux actions suivantes :
Synchroniser la base de données de publication avec une base de données d'abonnement.
Réinitialiser tous les abonnements associés aux publications figurant dans la base de données de publication.
L'utilisation de l'une de ces deux méthodes garantit que, après une restauration, le serveur de publication et tous les Abonnés sont synchronisés.
[!REMARQUE]
Si des tables contiennent des colonnes d'identité, vous devez vérifier que les plages d'identité correctes sont attribuées après une restauration. Pour plus d'informations, consultez Réplication de colonnes d'identité.
Synchronisation de la base de données de publication
La synchronisation d'une base de données de publication avec une base de données d'abonnement vous permet de charger à partir d'une ou plusieurs bases de données d'abonnement les modifications précédemment effectuées dans la base de données de publication, mais qui ne sont pas représentées dans la sauvegarde restaurée. Les données qui peuvent être chargées dépendent de la façon dont une publication est filtrée :
Si la publication n'est pas filtrée, vous devriez pouvoir mettre à jour la base de données de publication en la synchronisant avec l'Abonné le plus à jour.
Si la publication est filtrée, il est possible que vous ne puissiez pas mettre à jour la base de données de publication. Supposons une table qui est partitionnée de façon telle que chaque abonnement reçoit des données client seulement pour une région : Nord, Est, Sud et Ouest. S'il y a au moins un Abonné pour chaque partition de données, la synchronisation avec un Abonné pour chaque partition doit permettre la mise à jour de la base de données de publication. Cependant, si par exemple des données de la partition Ouest n'ont été répliquées vers aucun des Abonnés, ces données ne peuvent pas être mises à jour au niveau du serveur de publication.
Important
La synchronisation d'une base de données de publication avec une base de données d'abonnement peut aboutir à des tables publiées restaurées à un point dans le temps plus récent que celui d'autres tables non publiées restaurées à partir de la sauvegarde.
Si vous effectuez une synchronisation avec un Abonné qui exécute une version de Microsoft SQL Server antérieure à Microsoft SQL Server 2005, l'abonnement ne peut pas être anonyme ; il doit être un abonnement client ou un abonnement serveur (qui s'appelaient « abonnement local » et « abonnement global » dans les versions antérieures).
Pour synchroniser un abonnement
Microsoft SQL Server Management Studio: Procédure : synchroniser un abonnement par envoi de données (SQL Server Management Studio)
SQL Server Management Studio: Procédure : synchroniser un abonnement par extraction de données (SQL Server Management Studio)
Programmation de la réplication Transact-SQL : Procédure : synchroniser un abonnement par envoi de données (push) (Programmation de la réplication)
Programmation de la réplication Transact-SQL : Procédure : synchroniser un abonnement par extraction de données (pull) (Programmation de la réplication)
Réinitialisation de tous les abonnements
La réinitialisation de tous les abonnements garantit que tous les Abonnés sont dans un état cohérent avec la base de données de publication restaurée. Cette approche doit être utilisée si vous voulez replacer une topologie entière à l'état précédent représenté par une sauvegarde donnée de la base de données d'abonnement. Par exemple, vous pouvez souhaiter réinitialiser tous les abonnements si vous effectuez la restauration d'une base de données de publication à un point antérieur dans le temps, dans le but de récupérer d'une opération de traitement effectuée incorrectement.
Si vous choisissez cette option, générez une nouvelle capture instantanée en vue de la communiquer aux Abonnés réinitialisés dès la fin de la restauration de la base de données de publication.
Pour réinitialiser un abonnement
SQL Server Management Studio: Procédure : réinitialiser un abonnement (SQL Server Management Studio)
Programmation Transact-SQL de la réplication : Procédure : réinitialiser un abonnement (programmation Transact-SQL de la réplication)
Pour créer et appliquer une capture instantanée
SQL Server Management Studio: Procédure : créer et appliquer la capture instantanée initiale (SQL Server Management Studio)
Programmation Transact-SQL de la réplication : Procédure : créer la capture instantanée initiale (programmation Transact-SQL de la réplication)
SQL Server Management Studio: Procédure : créer une capture instantanée pour une publication de fusion avec des filtres paramétrables (SQL Server Management Studio)
Programmation de la réplication Transact-SQL : Procédure : créer une capture instantanée pour une publication de fusion avec des filtres paramétrables (programmation Transact-SQL de la réplication)
Sauvegarde et restauration de la base de données de distribution
Avec la réplication de fusion, la base de données de distribution doit être sauvegardée régulièrement, et peut être restaurée sans considérations particulières aussi longtemps que la sauvegarde n'est pas plus ancienne que la période de rétention la plus courte de tous les abonnements qui utilisent le serveur de distribution. Par exemple, s'il y a trois publications avec des périodes de rétention de 10, 20 et 30 jours respectivement, la sauvegarde utilisée pour restaurer la base de données ne doit pas être vieille de plus de 10 jours. La base de données de distribution a un rôle limité dans la réplication de fusion : elle ne stocke aucune donnée utilisée dans le suivi des modifications et ne constitue pas un support de stockage temporaire pour les modifications de réplication de fusion destinées aux bases de données d'abonnement (comme elle le fait dans la réplication transactionnelle).
Sauvegarde et restauration d'une base de données d'abonnement
Pour garantir la récupération réussie d'une base de données d'abonnement, les Abonnés doivent se synchroniser avec le serveur de publication avant que la base de données d'abonnement soit sauvegardée ; ils doivent aussi se synchroniser après la restauration de la base de données d'abonnement :
La synchronisation avec le serveur de publication avant une sauvegarde de la base de données d'abonnement aide à garantir que si un Abonné est restauré à partir d'une sauvegarde, l'abonnement se trouve toujours dans la période de rétention d'abonnement. Supposons par exemple qu'une publication ait une période de conservation de 10 jours. La dernière synchronisation date de 8 jours et la sauvegarde est effectuée maintenant. Si elle est restaurée 4 jours plus tard, la dernière synchronisation datera de 12 jours, ce qui est supérieur à la période de rétention. Dans ce cas, vous devez réinitialiser l'Abonné. Si l'Abonné avait effectué la synchronisation juste avant la sauvegarde, la base de données d'abonnement se trouverait dans la période de rétention.
La sauvegarde ne doit pas être plus ancienne que la période de rétention la plus courte pour toutes les publications auxquelles l'Abonné souscrit. Par exemple, si un abonné adhère à trois publications avec des périodes de conservation de 10, 20 et 30 jours respectivement, la sauvegarde utilisée pour restaurer la base de données ne doit pas être âgée de plus de 10 jours.
La synchronisation de la base de données d'abonnement avec chacun de ses abonnements après une restauration garantit que l'Abonné est à jour avec toutes les modifications au niveau du serveur de publication.
Pour définir la période de rétention d'une publication
SQL Server Management Studio: Procédure : définir la période d'expiration des abonnements (SQL Server Management Studio)
Programmation Transact-SQL de la réplication : Procédure : définir la période d'expiration des abonnements (programmation Transact-SQL de la réplication)
Pour synchroniser un abonnement
SQL Server Management Studio: Procédure : synchroniser un abonnement par envoi de données (SQL Server Management Studio)
SQL Server Management Studio: Procédure : synchroniser un abonnement par extraction de données (SQL Server Management Studio)
Programmation de la réplication Transact-SQL : Procédure : synchroniser un abonnement par envoi de données (push) (Programmation de la réplication)
Programmation de la réplication Transact-SQL : Procédure : synchroniser un abonnement par extraction de données (pull) (Programmation de la réplication)
Sauvegarde et restauration d'une base de données de réédition
Une base de données de réédition désigne une base de données qui s'abonne à des données auprès d'un éditeur et qui, à son tour, diffuse ces données à d'autres bases de données d'abonnement. Lorsque vous restaurez une base de données de réédition, suivez les recommandations données dans les sections « Sauvegarde et restauration d'une base de données de publication » et « Sauvegarde et restauration d'une base de données d'abonnement » de cette rubrique.
Voir aussi