Impossible de tronquer le journal des transactions, log_reuse_wait_desc - AVAILABILITY_REPLICA

Ce matin, j'ai été réveillé par une alerte complète du journal des transactions sur l'une de nos bases de données. Ce serveur est un cluster Alwayson et également un abonné à la réplication transactionnelle. J'ai vérifié log_reuse_wait_desc et cela a montré la reconnexion. Quelqu'un avait accidentellement désactivé les travaux de sauvegarde 4 jours plus tôt, j'ai réactivé le travail de sauvegarde du journal et le journal a été effacé. Comme il était 4 heures du matin, je pensais que j'irais au bureau plus tard dans la matinée et que je garderais le journal car il a atteint 400 Go.

10 h - Je suis au bureau et je vérifie l'utilisation du journal avant de rétrécir et c'était environ 16%. J'ai été surpris et j'ai vérifié le log_reuse_wait_desc, qui montrait une réplication. J'étais confus parce que c'était un abonné de réplication. Nous avons ensuite vu que la base de données était activée pour CDC et avons pensé que cela pourrait être la cause, donc désactivé CDC et maintenant le log_reuse_wait_desc affiche AVAILABILITY_REPLICA.

L'utilisation des grumes, quant à elle, continue de croître régulièrement et est maintenant de 17%. Je vérifie le tableau de bord alwayson et vérifie la file d'attente envoyée et refaite et les deux sont pratiquement nuls. Je ne sais pas pourquoi la réutilisation du journal s'affiche comme AVAILABILITY_REPLICA et je ne peux pas effacer le journal.

Une idée pourquoi cela se produit?

Si tu fais ça:

SELECT * FROM sys.databases

Et log_reuse_wait_desc affiche AVAILABILITY_REPLICA, ce qui signifie que SQL Server attend d'envoyer des données de journal à l'une de vos réplicas Always On Availability Group. L'une des répliques peut être à la traîne en raison d'un réseau lent ou peut être complètement en panne.

Si vous vérifiez le tableau de bord AG et qu'il n'affiche aucune file d'attente, vous avez peut-être été victime de l'épuisement des threads. C'est un problème connu que le tableau de bord AG cesse de mettre à jour après l'épuisement du thread de travail. Vous devrez vérifier l'état de chaque réplique directement plutôt que de vous fier au principal. La note de Nick dans cet élément Connect indique que vous pouvez simplement modifier les propriétés d'une réplique pour redémarrer la réplication, mais cela ne fonctionne pas toujours (surtout si vous avez des centaines de bases de données sur une réplique avec une grande quantité de données à envoyer, et le redémarrage de la réplication peut entraîner à nouveau l'épuisement du thread de travail.)

Si le dernier gars a configuré une réplique AG et qu'elle n'est plus censée exister, il est temps de supprimer cette AG et / ou réplique. Faites juste attention à ce que les applications ne pointent pas vers le nom de l'écouteur pour se connecter à votre serveur SQL.