Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsqu’un groupe de disponibilité AlwaysOn contenant une base de données utilisée comme instance 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.
Qu’est-ce qui est pris en charge
La réplication SQL Server prend en charge le basculement automatique de l'éditeur, le basculement automatique des abonnés transactionnels et le basculement manuel des abonnés de fusion. Le basculement d'un distributeur sur une base de données de disponibilité n'est pas pris en charge. AlwaysOn ne peut pas être combiné avec des scénarios Websync et SQL Server Compact.
Basculement d’un abonnement de collecte de fusion
Un abonnement par extraction échoue lors du basculement du groupe de disponibilité, car l'agent de tirage ne trouve pas les tâches stockées dans la base de données msdb de l'instance de serveur qui héberge le réplica principal, laquelle n’est pas disponible, car l’instance de serveur a subi une panne.
Basculement d’un abonnement Push de fusion
Un abonnement push échoue lors du basculement du groupe de disponibilité, car l’agent push ne peut plus se connecter à la base de données d'abonnement originale sur le serveur abonné d'origine.
Comment créer un abonnement transactionnel dans un environnement AlwaysOn
Pour la réplication transactionnelle, suivez ces étapes pour configurer et effectuer un basculement d'un groupe de disponibilité des abonnés :
Avant de créer l’abonnement, ajoutez la base de données de l’abonné au groupe de disponibilité AlwaysOn approprié.
Ajoutez l’écouteur du 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.
À l’aide du script dans la section Création d’un abonnement Push de réplication transactionnelle ci-dessous, créez l’abonnement en utilisant 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.
Remarque
L’abonnement doit être créé en utilisant un script Transact-SQL et ne peut pas être créé dans Management Studio.
Si vous créez un abonnement pull :
Dans Management Studio, sur le nœud de l'abonné principal, ouvrez l’arborescence SQL Server Agent.
Identifiez la tâche de l’Agent de distribution d’extraction et modifiez la tâche.
À l'étape Exécuter l'Agent, vérifiez les paramètres
-Publisheret-Distributor. Assurez-vous que ces paramètres contiennent les noms de serveur direct et d’instance appropriés du serveur de publication et du serveur de distribution.Remplacez le
-Subscriberparamètre par le nom de l’écouteur du groupe de disponibilité de l’abonné.
Lorsque vous créez votre abonnement en suivant ces étapes, vous n’aurez rien à faire après un basculement.
Création d’un abonnement Push de réplication transactionnelle
-- commands to execute at the publisher, in the publisher database:
use [<publisher database name>]
EXEC sp_addsubscription @publication = N'<publication name>',
@subscriber = N'<availability group 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'<availability group listener name>',
@subscriber_db = N'<subscriber database name>',
@job_login = null, @job_password = null, @subscriber_security_mode = 1;
GO
Pour reprendre 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 :
Exécutez
sp_subscription_cleanuppour supprimer l'ancien abonnement de l'abonné. Effectuez cette action sur le nouveau réplica principal (qui était auparavant le réplica secondaire).Recréez l'abonnement en en créant un nouveau, en commençant par un nouvel instantané.
Remarque
Le processus actuel est peu pratique pour les abonnés de la réplication de fusion ; cependant, le scénario principal de cette réplication concerne les utilisateurs déconnectés (ordinateurs de bureau, ordinateurs portables, appareils mobiles) qui n'utiliseront pas les groupes de disponibilité AlwaysOn du côté de l'abonné.