Partager via

Résoudre les problèmes de SQL Server Always On

  • Article

Cet article vous aide à résoudre le problème courant de configuration Always On sur SQL Server.

Remarque

Pour obtenir une présentation guidée de cet article, consultez Résolution des problèmes de SQL Server Always On.

Version d’origine du produit : SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Numéro de la base de connaissances d’origine : 10179

Remarques importantes

J’ai besoin de pointeurs sur la configuration et la configuration des groupes de disponibilité Always On

Si vous recherchez de la documentation sur la configuration de Always On configuration, consultez les documents suivants :

Prise en main avec Always On groupes de disponibilité (SQL Server) : le document fournit des réponses à de nombreuses questions que vous pouvez avoir sur les groupes de disponibilité et la configuration. Le fait de suivre toutes les étapes de cet article et de passer en revue les conditions préalables, les restrictions et les recommandations pour les groupes de disponibilité Always On (SQL Server) vous permettront d’éviter de nombreux problèmes que vous pouvez rencontrer lors de la configuration et de la maintenance des groupes de disponibilité dans votre environnement.

Ressources supplémentaires

Si ces informations ne sont pas utiles, consultez Plus d’informations sur Always On groupes de disponibilité.

Je rencontre des problèmes lors de la configuration des groupes de disponibilité Always On

Les problèmes de configuration classiques incluent Always On les groupes de disponibilité sont désactivés, les comptes sont mal configurés, le point de terminaison de mise en miroir de bases de données n’existe pas, le point de terminaison est inaccessible (SQL Server l’erreur 1418), l’accès réseau n’existe pas et une commande de jointure de base de données échoue (SQL Server Erreur 35250). Consultez le document suivant pour obtenir de l’aide sur la résolution de ces problèmes :

Résoudre les problèmes de configuration des groupes de disponibilité Always On (SQL Server)

Lien supplémentaire : Correction de l’erreur 41009 lorsque vous essayez de créer plusieurs groupes de disponibilité

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Je rencontre des problèmes avec la configuration de l’écouteur (19471, 19476 et autres erreurs)

L’un des problèmes de configuration les plus courants rencontrés par les clients est la création d’écouteurs de groupe de disponibilité. Les erreurs sont similaires aux suivantes :

  • Msg 19471, Niveau 16, État 0, Ligne 2Le cluster WSFC n’a pas pu mettre en ligne la ressource Nom réseau portant le nom DNS « ». Le nom DNS peut avoir été pris ou avoir un conflit avec des services de noms existants, ou le service de cluster WSFC peut ne pas être en cours d’exécution ou peut être inaccessible. Utilisez un autre nom DNS pour résoudre les conflits de noms ou case activée le journal du cluster WSFC pour plus d’informations.

  • Msg 19476, Niveau 16, État 4, Ligne 2La tentative de création du nom réseau et de l’adresse IP pour l’écouteur a échoué. Le service WSFC n’est peut-être pas en cours d’exécution ou est peut-être inaccessible dans son état actuel, ou les valeurs fournies pour le nom réseau et l’adresse IP peuvent être incorrectes. Vérifiez l’état du cluster WSFC et validez le nom réseau et l’adresse IP avec l’administrateur réseau.

La plupart du temps, l’échec de création de l’écouteur entraînant les messages précédents est dû à un manque d’autorisations pour l’objet CNO (Cluster Name Object) dans Active Directory pour créer et lire l’objet ordinateur de l’écouteur. Pour résoudre ce problème, consultez les articles suivants :

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Le basculement automatique ne fonctionne pas comme prévu

Si vous remarquez que le basculement automatique ne fonctionne pas comme prévu pendant le test ou en production, consultez : Résolution des problèmes de basculement automatique dans les environnements SQL Server Always On 2012.

Une configuration incorrecte du nombre maximal d’échecs dans la période spécifiée est l’une des principales causes du basculement du principal vers la base de données secondaire. La valeur par défaut de ce paramètre est N-1, où N est le nombre de réplicas. Pour plus d’informations, consultez Limite maximale des échecs du cluster de basculement (groupe).

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Je rencontre des problèmes de connexion à Always On groupes de disponibilité

Après avoir configuré l’écouteur de groupe de disponibilité pour un groupe de disponibilité Always On dans SQL Server 2012, vous ne pourrez peut-être pas effectuer un test ping sur l’écouteur ou vous y connecter à partir d’une application. Vous pouvez obtenir une erreur similaire à ce qui suit :

Sqlcmd : Erreur : Microsoft SQL Native Client : Le délai de connexion a expiré.

Pour résoudre ce problème et d’autres erreurs similaires, passez en revue les éléments suivants :

Liens d’informations supplémentaires :

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Je rencontre des problèmes lors de la configuration des groupes de disponibilité Always On dans ma machine virtuelle Azure (IaaS)

  1. De nombreux problèmes liés à Always On se produisent en raison d’une configuration incorrecte de l’écouteur. Si vous rencontrez des problèmes de connexion à l’écouteur,

    1. Veillez à lire toutes les limitations de l’écouteur ILB et à suivre toutes les étapes décrites dans l’article suivant, en accordant une attention particulière à la configuration des dépendances, à l’adresse IP et à divers autres paramètres dans le script PowerShell.

    2. En cas de doute, vous pouvez supprimer et recréer l’écouteur conformément au document ci-dessus.

  2. Si vous avez récemment déplacé votre machine virtuelle vers un autre service ou si les adresses IP ont changé, vous devez mettre à jour la valeur de la ressource d’adresse IP pour refléter la nouvelle adresse et recréer le point de terminaison à charge équilibrée pour votre groupe de disponibilité. Vous pouvez mettre à jour l’adresse IP à l’aide des Get commandes ou Set comme suit :

    Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"

Documents recommandés :

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Le basculement du principal vers le secondaire prend beaucoup de temps ou inversement

Après un basculement automatique ou un basculement manuel planifié sans perte de données sur un groupe de disponibilité, vous pouvez constater que le temps de basculement dépasse votre objectif de temps de récupération (RTO). Pour résoudre les problèmes liés aux causes et aux résolutions potentielles, consultez Résolution des problèmes : RTO dépassé par le groupe de disponibilité.

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Les modifications apportées au réplica principal ne sont pas répercutées ou sont lentes à répliquer sur le réplica secondaire

Vous remarquerez peut-être que les modifications apportées aux réplica primaires ne sont pas propagées à la base de données secondaire en temps voulu. Pour résoudre ces problèmes, procédez comme suit :

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Comment gérer la taille du journal des transactions pour mes bases de données de groupe de disponibilité

Vous pouvez réduire la taille du journal des transactions en configurant des sauvegardes régulières sur les serveurs principaux ou secondaires.

Pour plus d’informations, consultez les rubriques suivantes :

Si ces informations ne sont pas utiles, consultez Plus d’informations sur Always On groupes de disponibilité.

Serveurs principaux ou secondaires frappés dans l’état de résolution ou vous rencontrez des basculements inattendus

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Impossible de mettre des ressources en ligne

Vérifiez si la récupération des bases de données prend beaucoup de temps en examinant les messages dans le journal des erreurs SQL.

Si le problème persiste, consultez Plus d’informations sur Always On groupes de disponibilité.

Foire aux questions

  1. Est-il possible d’avoir deux écouteurs pour un groupe de disponibilité ?

    Oui, vous pouvez configurer plusieurs écouteurs pour le même groupe de disponibilité. Consultez Comment créer plusieurs écouteurs pour le même groupe de disponibilité (Goden Yao).

  2. Est-il possible d’avoir une carte réseau distincte carte pour le trafic always on et la connectivité client ?

    Oui, vous pouvez avoir des carte de cartes réseau dédiées pour le trafic Always On. Consultez Configurer un groupe de disponibilité pour communiquer sur un réseau dédié.

  3. Quelles éditions prennent en charge Always On instances de cluster de basculement ?

    Cette rubrique de la documentation en ligne de SQL Server contient plus d’informations : Éditions et fonctionnalités prises en charge pour SQL Server 2016.

  4. Comment récupérer en cas de défaillance sur tous les nœuds de votre cluster ?

    Consultez Récupération d’urgence WSFC par quorum forcé (SQL Server).

  5. Où puis-je trouver des informations sur la prise en charge des transactions distribuées dans les configurations du groupe de disponibilité ?

    Consultez Transactions : groupes de disponibilité et mise en miroir de bases de données.

  6. Comment mettre à jour les configurations Always On ?

    Consultez Mise à niveau Always On instances de réplica de groupe de disponibilité.

  7. Comment ajouter une base de données compatible TDE (Transparent Data Encryption) à la configuration du groupe de disponibilité ?

    Pour ajouter une base de données compatible TDE à un groupe de disponibilité, consultez Guide pratique pour configurer Always On pour une base de données TDE.

  8. Comment configurer des alertes pour vérifier si la base de données secondaire est en retard par rapport au serveur principal ?

    Vous pouvez utiliser le script suivant :

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

  9. Comment recevoir une alerte si l’état de la base de données n’est pas synchronisé ?

    Vous pouvez utiliser le script suivant :

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

    Vous pouvez également consulter les liens suivants pour obtenir des méthodes supplémentaires pour surveiller Always On groupes :

Plus d’informations sur les groupes de disponibilité Always On