Partager via

Maintenance d’une base de données de publication AlwaysOn (SQL Server)

Cette rubrique traite des considérations spéciales relatives à la maintenance d’une base de données de publication lorsque vous utilisez des groupes de disponibilité AlwaysOn.

Gestion d'une base de données publiée dans un groupe de disponibilité

La gestion d’une base de données de publication AlwaysOn est essentiellement la même que la maintenance d’une base de données de publication standard, avec les considérations suivantes :

  • L'administration doit être effectuée au niveau de l'hôte de réplica principal. Dans SQL Server Management Studio, les publications apparaissent dans le dossier Publications locales pour l'hôte de réplica principal et également pour les réplicas secondaires lisibles. Après un basculement, il est possible que vous soyez contraint d'actualiser manuellement Management Studio pour que la modification soit prise en compte si le serveur secondaire qui est devenu le principal n'était pas lisible.

  • Le moniteur de réplication affiche toujours les informations de publication sous le serveur de publication d'origine. Toutefois, ces informations peuvent être consultées dans le moniteur de réplication à partir de tout réplica en ajoutant le serveur de publication d'origine comme serveur.

  • Si vous faites appel aux procédures stockées ou aux Replication Management Objects pour gérer la réplication sur le principal actuel, 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 (le serveur de publication d'origine). Pour déterminer le nom approprié, utilisez la PUBLISHINGSERVERNAME fonction. Lorsqu'une base de données de publication joint un groupe de disponibilité, les métadonnées de réplication stockées dans les réplicas de bases de données secondaires sont identiques à celles du principal. 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 serveur secondaire est celui du serveur principal, et non du serveur secondaire. Cela affecte la configuration et l'administration de la réplication si la base de données de publication bascule sur un serveur secondaire. Par exemple, si vous configurez la réplication avec des procédures stockées sur une base de données secondaire après le basculement et que vous souhaitez un abonnement par extraction à une base de données de publication activée sur un autre réplica, vous devez spécifier le nom de l’éditeur d’origine au lieu du serveur de publication actuel comme paramètre de @publisher ou sp_addpullsubscriptionsp_addmergepulllsubscription. Toutefois, si vous activez une base de données de publication après un basculement, le nom de l'instance du serveur de publication stocké dans les tables système est le nom de l'hôte principal actuel. Dans ce cas, vous devez utiliser le nom d'hôte du réplica principal actuel pour le paramètre @publisher .

    Remarque

    Pour certaines procédures, telles que sp_addpublication, le paramètre @publisher est pris en charge uniquement pour les éditeurs qui ne sont pas des instances de SQL Server ; dans ce cas, il n’est pas pertinent pour SQL Server AlwaysOn.

  • 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.

Suppression d'une base de données publiée d'un groupe de disponibilité

Considérez les points suivants lorsqu'une base de données publiée est supprimée d'un groupe de disponibilité, ou lorsqu'un groupe de disponibilité avec une base de données membre publiée est supprimé.

  • Si la base de données de publication chez l'éditeur d’origine est retirée d’un réplica principal du groupe de disponibilité, vous devez exécuter sp_redirect_publisher sans spécifier de valeur pour le paramètre @redirected_publisher afin d'annuler la redirection entre l'éditeur et la base de données.

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';

    La base de données restera à l'état de récupération dans le principal et devra être restaurée. Après cela, la réplication doit s'exécuter sans modification sur le serveur de publication d'origine.

  • Si la base de données de publication bascule du serveur de publication d'origine vers un réplica et que la base de données est supprimée du réplica principal du groupe de disponibilité, utilisez la procédure stockée sp_redirect_publisher pour rediriger explicitement le serveur de publication d'origine vers le nouveau serveur de publication. La base de données restera à l'état de récupération et devra être restaurée. Après cela, la réplication doit continuer à fonctionner de la même manière qu'avec le groupe de disponibilité.

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB',  
    @redirected_publisher = 'MyNewPublisher';

    Ne supprimez pas le serveur distant du serveur de publication d'origine du serveur de distribution, même si le serveur n'est plus accessible. Les métadonnées du serveur du serveur de publication d'origine sont requises sur le serveur de distribution pour satisfaire les requêtes de métadonnées de publication.

  • Si un groupe de disponibilité complet est supprimé, le comportement d’une base de données répliquée par un membre est le même que lorsqu’une base de données publiée est supprimée d’un groupe de disponibilité. La réplication peut être reprise à partir du dernier principal dès que la base de données a été restaurée et la redirection a été modifiée. Si la base de données est restaurée sur son serveur de publication d'origine, la redirection doit être supprimée. Si la base de données est restaurée sur un hôte différent, la redirection doit être explicitement dirigée vers le nouvel hôte.

    Remarque

    Lorsqu'un groupe de disponibilité comportant des bases de données membres publiées est supprimé, ou lorsqu'une base de données publiée est est supprimée d'un groupe de disponibilité, toutes les copies des bases de données publiées sont laissées à l'état de récupération. Si elles sont restaurées, chacune apparaîtra comme une base de données publiée. Une seule copie doit être conservée avec les métadonnées de publication. Pour désactiver la réplication d'une copie de base de données publiée, commencez par supprimer tous les abonnements et toutes les publications de la base de données.

    Exécutez sp_dropsubscription pour supprimer les abonnements de publication. Veillez à définir le paramètre @ignore_distributributor sur 1 pour conserver les métadonnées de la base de données de publication active sur le serveur de distribution.

    USE MyDBName;  
GO  

EXEC sys.sp_dropsubscription   
    @subscriber = 'MySubscriber',  
    @publication = 'MyPublication',  
    @article = 'all',  
    @ignore_distributor = 1;

    Exécutez sp_droppublication pour supprimer toutes les publications. De nouveau, affectez la valeur 1 au paramètre @ignore_distributor pour conserver les métadonnées de la base de données de publication active sur le serveur de distribution.

    EXEC sys.sp_droppublication   
    @publication = 'MyPublication',  
    @ignore_distributor = 1;

    Exécutez sp_replicationdboption pour désactiver la réplication pour la base de données.

    EXEC sys.sp_replicationdboption  
    @dbname = 'MyDBName',  
    @optname = 'publish',  
    @value = 'false';

    À ce stade, la copie de la base de données publiée peut être conservée ou supprimée.

Tâches associées

Voir aussi

Prérequis, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server)
Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server)
Groupes de disponibilité AlwaysOn : Interopérabilité (SQL Server)
Réplication de SQL Server

  • Last updated on