Pourquoi un VPN rapide ralentit encore une validation SQL synchrone

Ouvrez une session de requête sur le primaire et observez ce qu'attend une simple écriture. Si la base de données appartient à un groupe de disponibilité à validation synchrone et que le secondaire est connecté, une partie de cette attente quitte le bâtiment : les enregistrements du journal voyagent vers le réplica, y sont durcis, et la nouvelle de ce durcissement revient avant que la validation ne se termine. La bande passante ne raccourcit pas cet aller-retour. Le parcours ci-dessous suit l'accusé de réception de l'écran au disque distant et retour.

Commencez par le type d'attente sur le primaire

Une écriture qui attend sur le réplica distant apparaît comme une attente liée au journal plutôt qu'une attente de processeur ou de verrou, et la durée de la transaction suit l'aller-retour au lieu du nombre de lignes. Beaucoup de petites validations le rendent évident, car chacune paie le trajet séparément. Une seule opération groupée cache le même coût dans un accusé plus long.

Triez votre charge de travail par fréquence de validation avant de conclure quoi que ce soit sur la liaison.

Lisez l'état du réplica avant de lire le réseau. Les compteurs qui comptent sont la file d'envoi, la file de redo et l'état de synchronisation, et ensemble ils montrent si le secondaire suit le rythme ou prend du retard. Une file d'envoi qui grossit pointe vers le transport, tandis qu'une file de redo qui grossit pointe vers le travail ou le stockage du secondaire lui-même. Ce sont des réparations différentes, et aucune ne s'améliore en ajoutant de la bande passante.

Suivez l'accusé jusqu'au secondaire

En validation synchrone, le primaire attend la confirmation que le journal concerné a été durci sur le secondaire avant de déclarer la validation terminée. Durci signifie durable dans le journal, pas rejoué dans les pages de données. C'est exactement cette distinction qui explique qu'un secondaire synchrone puisse être en retard sur le redo tout en confirmant encore le durcissement.

Parcourez le chemin dans l'ordre et mesurez chaque étape plutôt que l'ensemble. Les enregistrements du journal passent par le transport, le secondaire les écrit et les vide, et l'accusé revient par le même chemin. Le délai de transport, l'ordonnancement du secondaire et la latence du disque de journal du secondaire entrent tous dans le total, et seul le premier appartient au responsable du réseau. Un secondaire dont le volume de journal est saturé par autre chose peut étirer chaque validation pendant que la liaison reste inactive.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Prenez cet instantané avant et après une écriture représentative plutôt qu'une fois un après-midi calme. La différence est ce qui vous dit quelle file a bougé pendant que la validation attendait.

Mesurez le chemin, pas la liaison

Un test de débit mesure la capacité entre deux points qui ne sont pas vos réplicas, sous une charge qui n'est pas votre travail. Demandez au responsable du réseau le délai et la perte le long du chemin réel du réplica pendant que le trafic réel circule, dans les deux sens. La perte compte plus que la capacité ici, car un segment perdu coûte une retransmission et chaque validation attend un accusé. Une liaison qui paraît excellente dans un test de téléchargement peut encore convenir mal à un schéma de validation bavard.

Gardez intactes la sécurité du transport de la base de données et les contrôles d'accès pendant la mesure. Mesurer un chemin n'est jamais une raison de les contourner.

Corrélez les temps avec les compteurs plutôt qu'avec l'intuition. Si la file d'envoi reste vide et que la validation attend toujours, le délai est dans l'accusé ou dans le vidage du secondaire. Si la file d'envoi croît régulièrement, le transport ou la capacité est la contrainte. Notez quelle observation a soutenu la conclusion pour que la personne suivante puisse répéter la mesure plutôt que la discussion.

Ce que le mode asynchrone change vraiment

La validation asynchrone supprime l'attente de l'accusé de durcissement du secondaire, ce qui accélère les écritures et ce qui change votre position de durabilité. Le primaire confirme la transaction sans cet accusé distant. Le secondaire est alors autorisé à prendre du retard, et ce retard est l'exposition.

Si le primaire est perdu avant que le journal n'atteigne une cible de basculement utilisable, forcer le service sur ce réplica jette des transactions que l'application avait déjà été informée comme validées.

C'est une décision de point de restauration et elle appartient au responsable de la base de données, pas à une revue de performance. Fixez d'abord la fenêtre de perte de données tolérée, choisissez le mode qui la satisfait, puis optimisez à l'intérieur de cette limite. Les options qui conservent la protection synchrone incluent la suppression des allers-retours de validation évitables là où l'application le permet, la correction d'un goulot d'étranglement mesuré de transport ou de stockage, et le déplacement du réplica pour que l'accusé parcoure moins de distance. Pesez-les contre l'exigence de durabilité avec laquelle vous avez commencé, qui n'a pas changé.