Partager via

Abonnés de réplication et groupes de disponibilité Always On (SQL Server)

  • Article

S'applique à : SQL Server

Quand un groupe de disponibilité Always On (AG) contenant une base de données est un abonné de réplication bascule, l’abonnement de réplication peut échouer. Pour les abonnés de réplication par émission transactionnelle, l’agent de distribution continue la réplication automatiquement après un basculement si l’abonnement a été créé avec le nom de l’écouteur de groupe de disponibilité. Pour les abonnés de réplication par réception transactionnelle, l’agent de distribution continue la réplication automatiquement après un basculement si l’abonnement a été créé avec le nom de l’écouteur de groupe de disponibilité et que le serveur de l’Abonné d’origine fonctionne. C’est parce que les travaux de l’agent de distribution sont uniquement créés sur l’Abonné d’origine (réplica principal du groupe de disponibilité). Pour les abonnés de fusion, un administrateur de réplication doit reconfigurer l'abonné manuellement, en recréant l'abonnement.

Ce qui est pris en charge

La réplication de SQL Server prend en charge le basculement automatique du serveur de publication et le basculement automatique des abonnés. Les abonnés de fusion peuvent faire partie d’un groupe de disponibilité ; toutefois, des actions manuelles sont requises pour configurer le nouvel abonné après un basculement. Les groupes de disponibilité ne peuvent pas être associés à des scénarios WebSync et SQL Server Compact.

Créer un abonnement transactionnel dans un groupe de disponibilité

Pour la réplication transactionnelle, utilisez la procédure suivante pour configurer et basculer un groupe de disponibilité d’abonné :

  1. Avant de créer l’abonnement, ajoutez la base de données de l’abonné au groupe de disponibilité AlwaysOn approprié.

  2. Ajoutez l’écouteur de groupe de disponibilité de l’abonné en tant que serveur lié à tous les nœuds du groupe de disponibilité. Cette étape garantit que tous les partenaires de basculement potentiels ont connaissance de l'écouteur et peuvent s'y connecter.

  3. À l’aide du script de la section Création d’un abonnement de réplication transactionnelle par émission de données, créez l’abonnement avec le nom de l’écouteur du groupe de disponibilité de l’abonné. Après un basculement, le nom de l'écouteur demeure valide, alors que le nom du serveur réel de l'abonné dépend du nœud réel qui est devenu le nouveau nœud principal.

    Notes

    L’abonnement doit être créé en utilisant un script Transact-SQL et ne peut pas être créé dans Management Studio.

  4. Pour créer un abonnement par extraction

    1. À l’aide de l’exemple de script de la section Création d’un abonnement de réplication transactionnelle par extraction ci-dessous, créez l’abonnement avec le nom de l’écouteur du groupe de disponibilité de l’abonné.

    2. Après un basculement, créez le travail de l’agent de distribution sur le nouveau réplica principal à l’aide de la procédure stockée sp_addpullsubscription_agent.

Quand vous créez un abonnement par extraction, avec la base de données d’abonnement dans un groupe de disponibilité, après chaque basculement il est recommandé de désactiver le travail de l’agent de distribution sur l’ancien réplica principal et d’activer le travail sur le nouveau réplica principal.

Création d’un abonnement de réplication transactionnelle par émission de données

-- commands to execute at the publisher, in the publisher database:
USE [<publisher database name>];
GO

EXEC sp_addsubscription @publication = N'<publication name>',
    @subscriber = N'<AG listener name>',
    @destination_db = N'<subscriber database name>',
    @subscription_type = N'Push',
    @sync_type = N'automatic',
    @article = N'all',
    @update_mode = N'read only',
    @subscriber_type = 0;
GO
  
EXEC sp_addpushsubscription_agent @publication = N'<publication name>',
    @subscriber = N'<AG listener name>',
    @subscriber_db = N'<subscriber database name>',
    @job_login = NULL,
    @job_password = NULL,
    @subscriber_security_mode = 1;
GO

Création d’un abonnement de réplication transactionnelle par extraction

-- commands to execute at the subscriber, in the subscriber database:
USE [<subscriber database name>];
GO

EXEC sp_addpullsubscription @publisher = N'<publisher name>',
    @publisher_db = N'<publisher database name>',
    @publication = N'<publication name>',
    @subscription_type = N'pull';
GO

EXEC sp_addpullsubscription_agent @publisher = N'<publisher name>',
    @subscriber = N'<AG listener name>',
    @distributor = N'<distributor AG listener name>', -- this parameter should only be used if the distribution database is part of an AG.
    @publisher_db = N'<publisher database name>',
    @publication = N'<publication name>',
    @job_login = NULL,
    @job_password = NULL,
    @subscriber_security_mode = 1;
GO

Notes

Lors de l’exécution de sp_addpullsubscription_agent pour un abonné qui fait partie d’un groupe de disponibilité, vous devez passer la valeur du paramètre @Subscriber à la procédure stockée en tant que nom d’écouteur du GA. Si vous exécutez SQL Server 2016 (13.x) et les versions antérieures ou SQL Server 2017 (14.x) avant CU 16, la procédure stockée ne fait pas référence au nom de l’écouteur du GA ; il sera créé avec le nom du serveur de l’abonné sur lequel la commande est exécutée. Pour corriger ce problème, mettez à jour manuellement le paramètre de l’@Subscriber sur le travail Agent de distribution avec la valeur du nom de l’écouteur du GA.

Récupérer les agents de fusion après le basculement du groupe de disponibilité de l’abonné

Pour une réplication de fusion, un administrateur de réplication doit reconfigurer l'abonné manuellement en procédant comme suit :

  1. Exécutez sp_subscription_cleanup pour supprimer l'ancien abonnement de l'abonné. Effectuez cette action sur le nouveau réplica principal (qui était auparavant le réplica secondaire).

  2. Recréez l'abonnement en en créant un nouveau, en commençant par un nouvel instantané.

Notes

Le processus actuel n’est pas pratique pour les abonnés de réplication de fusion, toutefois, le scénario principal de la réplication de fusion implique des utilisateurs déconnectés (bureaux, ordinateurs portables, appareils combinés téléphoniques) qui n’utilisent pas les groupes de disponibilité sur l’abonné.

Voir aussi