Version imprimable
Bonjour a Tous
J'ai deux questions :
- Dans Quel cas l'always on bascule t il sur son noeud Secondaire ? A part l'arret du moteur SQL sur le primaire
- Comment mesurer l'impact des pertes données si le mode de disponibilité est en asynchrone ?
Merci a Tous et bonne journée
Dès que l'un des bases participant au groupe de disponibilité n'est plus en état de fonctionner. Par exemple erreur de fichier, disque plein, journal saturé...Citation:
Envoyé par olivtone
Il existe un outil de monitoring pour cela qui se base sur des DMV.Citation:
- Comment mesurer l'impact des pertes données si le mode de disponibilité est en asynchrone ?
A +Citation:
Merci a Tous et bonne journée
Peut être juste pour précision concernant les événements qui font basculer un groupe de disponibilité
Il en existe un certain nombre en fonction du niveau de basculement choisi. Il existe 5 niveaux avec le niveau 3 par défaut.
Cependant une la défaillance d'une base de données ne permet pas le basculement d'un groupe mais disons que ceci n'est valable que jusqu'en 2014. A partir de la version 2016, il y a effectivement nouvelle option DB_FAILOVER qui permet de faire basculer un groupe de disponibilités en fonction de l'état d'une DB. Cependant il faut encore préciser ici que seule la transaction d'une base de données de ONLINE à un état différent n'est prise en compte.
++
Un Merci tardif de ma part a vous deux :)
Quelle est il ? :DCitation:
Il existe un outil de monitoring pour cela qui se base sur des DMV.
- Continuant sur l'always on Je ne pige l’intérêt des préférences de sauvegarde alors que je fais déjà un backup sur le primaire, Si L'always ON fait des backup sur le secondaire ou les fait il ? (question peut être bête mais bon je la pose :mouarf:)
- Concernant les BEST PRATICSES sur les plans de maintenance, j'ai lu ici et la qu'il fallait mettre des backups Log sur le primaire et sur le secondaire, alors qu’après Test de mon coté, le backup Log sur mon primaire vide bien les logs aussi bien sur le primaire que sur le secondaire...
J'ai Juste mis les CHECKDB sur le noeud secondaire, et vous qu'avez vous mis en place de votre coté, je pense que les REBUILD INDEX et STATS ne sont pas necessaires ?
- Est ce que c'est la SP sp_server_diagnostics qui décide du basculement sur le noeud secondaire s'il n'y a pas de réponse de sa part? COmbien de fois est elle lancée par minute?
- Peut on donner une préférence de basculement d'un nœud par rapport a un autre, j'explique mon cas :
- J'ai 1 nœud principal et 1 nœud secondaire sur le même site et un 3eme nœud sur un site Distant
Est il possible de prédéfinir qu'en cas de crash du nœud 1 je préfère qu'il bascule sur le nœud 2 au lieu du Nœud 3 qui est sur le site Distant ?
merci a vous :mouarf:
Hello,
Je pense que SQLPro parlait du Dashboard des groupes de disponibilité (clic droit sur le groupe de disponibilité > Show Dashboard).Citation:
Il existe un outil de monitoring pour cela qui se base sur des DMV.
Quelle est il ?
Effectivement cet outil sur bases sur des DMV suivantes:
- sys.dm_hadr_cluster
- sys.dm_hadr_cluster_members
- sys.dm_hadr_availability_group_states
- sys.dm_hadr_availability_replica_states
- sys.dm_hadr_database_replica_states
L'intérêt de les faire sur les secondaires est de pouvoir décharger cette activité en terme de ressources sur les secondaires justement. Il effectuera les backups là où tu lui diras comme tu le ferais pour une sauvegarde normale.Citation:
- Continuant sur l'always on Je ne pige l’intérêt des préférences de sauvegarde alors que je fais déjà un backup sur le primaire, Si L'always ON fait des backup sur le secondaire ou les fait il ? (question peut être bête mais bon je la pose )
Il faut aligner des backups à ta politique de sauvegarde. Ce qui est important c'est de pouvoir s'assurer que ce que tu sauvegardes ne comporte pas de corruption.Citation:
J'ai Juste mis les CHECKDB sur le noeud secondaire, et vous qu'avez vous mis en place de votre coté, je pense que les REBUILD INDEX et STATS ne sont pas necessaires ?
Donc si tu sauvegardes sur le primaire, un dbcc checkdb sur le primaire est certainement suffisant. Si tu sauvegardes depuis un secondaire, effectuer un dbcc checkdb depuis un secondaire ET le primaire peuvent être envisagés.
Concernant les opérations de maintenance liés aux index et aux statistiques tu ne pourras de toute façon pas les faire depuis un secondaire.
Non ce n'est pas cette procédure qui décide du basculement d'un groupe de disponibilité. Elle fait juste partie intégrante du mécanisme de vérification de santé entre SQL Server et le cluster à basculement Windows. Cette procédure n'est exécutée que pour récupérer des informations de santé sur le réplica primaire et en fonction de ces informations + règle de basculement en vigueur (1 - 5). C'est le Resource Control Manager au niveau cluster qui décide de faire basculer les ressources liées au groupe de disponibilité.Citation:
- Est ce que c'est la SP sp_server_diagnostics qui décide du basculement sur le noeud secondaire s'il n'y a pas de réponse de sa part? COmbien de fois est elle lancée par minute?
Elle est exécutée toutes les 5 secondes par défaut (Healtcheck timeout / 4)
Si tu utilises une version de SQL Server < 2016 la réponse est non car tu ne peux utiliser qu'une seule paire de réplicas dans un processus de basculement automatique.Citation:
- J'ai 1 nœud principal et 1 nœud secondaire sur le même site et un 3eme nœud sur un site Distant
Est il possible de prédéfinir qu'en cas de crash du nœud 1 je préfère qu'il bascule sur le nœud 2 au lieu du Nœud 3 qui est sur le site Distant ?
Si tu utilises une version = 2016 il est possible maintenant d'utiliser 2 paires de réplicas pour effectuer un basculement automatique. Cependant il n'est pas encore possible à ma connaissance de configurer une liste de priorité depuis SQL Server.
++
merci mikedavem c'est vraiment top tes explications :) merci encore et bonne journée a toi :mouarf: