Un petit billet, rapide, concernant la mise en place des groupes de disponibilité sous SQL Server.
Extrêmement simple à mettre en place (une installation classique de SQL Server, l’ajout de la fonctionnalité Windows Server failover Cluster, une case à cocher pour activer AlwaysOn Availability Group) et permettant de disposer à la fois d’une solution de haute disponibilité, de disaster recovery, voire de load balancing pour de la lecture massive sur une ferme de serveur secondaires (depuis SQL Server 2016 et 2017 nativement).
Simple à mettre en place, donc, mais il ne faut pas négliger les prérequis Active Directory et disque. En effet, même si le système est conçu pour fonctionner sur un stockage asymétrique (on n’est pas liée à une baie de disque ou à des disques en attachement local, on pout tout à fait panacher) il convient de respecter quelques règles.
La première assez évidente, bien qu’il soit possible de la transgresser, consiste à utiliser les mêmes lettres de volumes ou points de montage, les mêmes répertoires pour stocker les fichiers de Data et Log.
La seconde est de disposer de disques de … même génération ! En effet, depuis quelques temps, des disques dit 4K remplacent les « vieux » disques 512 octets. Attention, je ne parle pas du formatage au sens Allocation Unit Size NTFS, mais bien du pan physique du nombre d’octets par secteurs.
Imaginez donc mette en place un AG sur 2 réplicas, chacun sur une baie de disque spécifique. Tout fonctionne parfaitement, jusqu’au jour où on ajoute un tiroir dans une des baies et que l’on déplace un volume (opération extrêmement simple dans le cadre de la virtualisation) sur une LUN hébergées sur ce nouveau tiroir.
Et puis, le journal de transaction sur le serveur principal commence à grossir, et malgré les backup log, ne se vide pas …
Et le journal de transaction commence à présenter des messages mentionnant des IO mal alignés … Et un serveur secondaire qui n’est plus synchrone …
Hum hum …
Sur le serveur principal on dispose de disques 512 octets
![clip_image002[5]](https://conseilit.wordpress.com/wp-content/uploads/2017/12/clip_image0025.jpg "clip_image002[5]")
Alors que le serveur secondaire dispose lui de disques 4K.
Deux possibilités pour résoudre le problème :
- Stopper l’instance sur le serveur secondaire, présenter un nouveau volume sur une LUN 512 octets, utiliser une commande du style ROBOCOPY /SEC pour recopier le contenu du volume de log et ensuite intervertir les lettre de volumes et relancer le service SQL.
- La seconde possibilité consiste à utiliser le Trace Flag 1800 qui permet d’éliminer le problème. Une fois le service SQL redémarré, les erreurs disparaissent.
Well done.
Happy troubleshooting
Christophe LAPORTE - Consultant 
Exactement les mêmes erreurs entre 2 générations de serveurs mais avec du mirroring au lieu d’un AG et pas de problème de log file qui ne se vide pas.
Pour info, tu vais quoi en log_reuse_wait_desc ?
select name
,log_reuse_wait_desc
from sys.databases
Salut Greg
J’ai cherché mais je n’ai pas retrouvé de capture d’écran pour ajouter au post. Le wait était ‘AVAILABILITY_REPLICA’, en toute logique.
Par contre, j’ai eu un soucis chez un client, où, 1 à 2 fois par an le log ne se vide pas sur le primaire. Rien en send Queue, rien en redo queue. SAns trouver quoi que ce soit, on a tenté quelques workaroud, et dans ce cas là, un restart du service sur le secondaire résoud le probème. OK, pas spécialement de rapport, mais les faits sont là. J’enrage de ne pas avoir la root cause et l’explication, mais je pense que à un moment le secondaire n’envoie pas un ACK au primaire, je ne vois que cela.
++
Christophe
Dans ce cas, à part ouvrir un case au support, difficile de fixer le problème. Merci pour ta réponse 🙂