Prise en charge des fonctionnalités de récupération d’urgence/haute disponibilité

Article
06/02/2023

Cette rubrique aborde la prise en charge par Pilotes Microsoft SQL Server pour PHP (ajoutée à la version 3.0) de la haute disponibilité et de la récupération d’urgence.

À compter de la version 3.0 des pilotes Microsoft pour PHP pour SQL Server, il est possible de spécifier l’écouteur d’un groupe de disponibilité de récupération d’urgence haute disponibilité ou d’une instance de cluster de basculement en tant que serveur dans la chaîne de connexion.

La propriété de connexion MultiSubnetFailover indique que l’application est déployée dans un groupe de disponibilité ou une instance de cluster de basculement et que le pilote tente de se connecter à la base de données sur l’instance SQL Server principale en essayant toutes les adresses IP. Spécifiez toujours MultiSubnetFailover=True lorsque vous vous connectez à un écouteur de groupe de disponibilité SQL Server ou à une instance de cluster de basculement SQL Server. Si l’application est connectée à une base de données Always On en basculement, la connexion d’origine sera interrompue. L’application devra établir une nouvelle connexion pour continuer de fonctionner après le basculement.

Pour plus d’informations sur groupes de disponibilité AlwaysOn, consultez la page Docs Haute disponibilité et récupération d’urgence.

Résolution d’adresses IP réseau transparente

La résolution d’adresses IP réseau transparente (TNIR) est une révision de la fonctionnalité MultiSubnetFailover existante. Elle affecte la séquence de connexion du pilote lorsque la première adresse IP résolue du nom d’hôte ne répond pas et qu’il existe plusieurs adresses IP associées au nom d’hôte. L’option de connexion correspondante est TransparentNetworkIPResolution. Avec MultiSubnetFailover, elle offre les quatre séquences de connexion suivantes :

TNIR activé et MultiSubnetFailover désactivé : une adresse IP est tentée, suivie de toutes les adresses IP en parallèle
TNIR activé et MultiSubnetFailover activé : toutes les adresses IP sont tentées en parallèle
TNIR désactivé et MultiSubnetFailover désactivé : toutes les adresses IP sont tentées l’une après l’autre
TNIR désactivé et MultiSubnetFailover activé : toutes les adresses IP sont tentées en parallèle

TNIR est activé par défaut et MultiSubnetFailover désactivé par défaut.

Voici un exemple d’activation de TNIR et de MultiSubnetFailover avec le pilote PDO_SQLSRV :

<?php
$serverName = "yourservername";
$username = "yourusername";
$password = "yourpassword";
$connectionString = "sqlsrv:Server=$serverName; TransparentNetworkIPResolution=Enabled; MultiSubnetFailover=yes";
try {
    $conn = new PDO($connectionString, $username, $password, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
    // your code 
    // more of your code
    // when done, close the connection
    unset($conn);
} catch(PDOException $e) {
    print_r($e->errorInfo);
}
?>

Mise à niveau pour utiliser des clusters de sous-réseaux multiples à partir de la mise en miroir de bases de données

Une erreur de connexion se produit si les mots clés de connexion MultiSubnetFailover et Failover_Partner sont présents dans la chaîne de connexion. Une erreur se produit également si MultiSubnetFailover est utilisé et que SQL Server retourne une réponse de partenaire de basculement indiquant qu’il fait partie d’une paire de mise en miroir de bases de données.

Si vous mettez à niveau une application PHP qui utilise actuellement la mise en miroir de bases de données vers un scénario de sous-réseaux multiples, supprimez la propriété de connexion Failover_Partner, remplacez-la par MultiSubnetFailover avec la valeur True et remplacez le nom du serveur dans la chaîne de connexion par un écouteur de groupe de disponibilité. Si une chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=true, le pilote génère une erreur. Toutefois, si une chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=false (ou ApplicationIntent=ReadWrite), l’application utilise la mise en miroir de bases de données.

Le pilote retournera une erreur si la mise en miroir de bases de données est utilisée sur la base de données principale au sein du groupe de disponibilité, et si MultiSubnetFailover=true est utilisé dans la chaîne de connexion qui établit une connexion à une base de données principale au lieu d’un écouteur de groupe de disponibilité.

Spécification de l’intention d’application

Vous pouvez spécifier le mot clé ApplicationIntent dans votre chaîne de connexion. Les valeurs assignables sont ReadWrite (par défaut) ou ReadOnly.

Lorsque vous définissez ApplicationIntent=ReadOnly, le client demande une charge de travail de lecture lors de la connexion. Le serveur applique l’intention au moment de la connexion et pendant une instruction de base de données USE.

Le mot clé ApplicationIntent ne fonctionne pas avec les bases de données en lecture seule héritées.

Cibles de ReadOnly

Lorsqu’une connexion choisit ReadOnly, elle est affectée à l’une des configurations spéciales suivantes qui peuvent exister pour la base de données :

Always On. Une base de données peut autoriser ou interdire les charges de travail en lecture sur la base de données ciblée du groupe de disponibilité. Ce choix est contrôlé à l’aide de la clause ALLOW_CONNECTIONS des instructions Transact-SQL PRIMARY_ROLE et SECONDARY_ROLE.
Géoréplication
Lecture du scale-out

Si aucune cible spéciale n’est disponible, la base de données normale est utilisée pour la lecture.

Le mot clé ApplicationIntent active le routage en lecture seule.

Routage en lecture seule

Le routage en lecture seule est une fonctionnalité qui permet de garantir la disponibilité d'un réplica de base de données en lecture seule. Pour activer le routage en lecture seule, tous les éléments suivants s’appliquent :

Vous devez vous connecter à un écouteur de groupe de disponibilité Always On.
Le mot clé de chaîne de connexion ApplicationIntent doit avoir la valeur ReadOnly.
L’administrateur de base de données doit configurer le groupe de disponibilité pour activer le routage en lecture seule.

Plusieurs connexions utilisant le routage en lecture seule ne sont pas nécessairement toutes établies avec le même réplica en lecture seule. Les modifications apportées à la synchronisation de base de données ou à la configuration du routage du serveur peuvent entraîner des connexions clientes à différents réplicas en lecture seule.

Vous pouvez vérifier que toutes les demandes en lecture seule se connectent au même réplica en lecture seule. Pour cela, ne transmettez pas d’écouteur de groupe de disponibilité au mot clé de chaîne de connexion Server. Au lieu de cela, spécifiez le nom de l'instance en lecture seule.

Le routage en lecture seule est susceptible de prendre plus de temps que la connexion à l’instance principale. En effet, il se connecte d’abord à l’instance principale, puis recherche le meilleur secondaire accessible en lecture disponible. En raison de ces multiples étapes, passez à un délai d’expiration login d’au moins 30 secondes.

Voir aussi

Connexion au serveur

Partager via