Discussion :

[davidjo_20165]

bonjour a tous

je vient de mettre en place la solution alwayson in multi-sous-réseaux sous AWS

l’équipe Devops utilise AWS Backup & Disaster Recovery comme solution du backup

Hier j'ai tombé sur ce jolie Article https://blog.dbi-services.com/sql-se...out-parameter/ qui parle de l'impact du backup veeam sur l'alawyson

maintenant je pose la question Est ce qu'il est nécessaire de changer le paramètre session Timeout afin que j'aurai plus de problème de disconnection ?

comment je peut détecter ça dans l'errorlog ?

merci pour le partage de vos expériences ?

[mikedavem]

Etant l'auteur de cet article je peux y répondre

Je ne sais pas comment la solution AWS se comporte sur des infrastructures AlwaysOn. C'est à voir de ton côté ..

Augmenter les différents timeout concernant les infrastructures Alwayson (session Timeout compris) peut aider à rendre l'infrastructure AG moins sensible mais cela doit se faire avec modération. En effet si cela peut aider à "masquer" le problème il ne résoudra en rien la notion de disponibilité du point de vue plus globale. En effet, si augmenter les timeout peuvent aider à retarder les AGs à détecter qu'il y a un souci (et à envoyer des messages d'alertes si configuré), il n'en reste pas moins que les connexions applicatives risquent de se figer voir partir en timeout (TCP timeout = 20s), ce qui revient à une indisponibilité du système du point de vue utilisateur.

Concernant le Session Timeout, ce paramètre permet simplement de considérer un réplica secondaire comme déconnecté s'il ne répond pas en dessous de la valeur de seuil configurée (et de passer temporairement en asynchrone s'il était initialement en synchrone). Imagine maintenant que tu doubles cette valeur et qu'un réplica secondaire devient indisponible en réplication synchrone ... la / les transaction(s) vont se figer pendant 20s avant de rendre la main à l'application. Dans le pire des cas, tu peux même risquer d'aller au delà du timeout applicatif ..

++