[SQL Server] Quelques opérations avancées sur le database mirroring

Ce billet présente quelques opérations avancées sur le database mirroring. Si vous souhaitez comprendre comment mettre-en-place le database mirroring allez ici ou .

Failover d’une base en session de database mirroring

Techniques de failover

Avec la mise-en-place faite du database
mirroring en mode synchrone avec basculement automatique, aucune configuration spécifique n’est nécessaire en cas d’indisponibilité de la base principale. Cependant, il serait intéressant de savoir comment s’y prendre manuellement en cas de besoin exceptionnel.

Côté basculement, si vous êtes emmené à devoir effectuer un basculement manuel, le script suivant peut être exécuté au sein du serveur principal :

USE master
GO
ALTER DATABASE IFC_SUITE SET PARTNER FAILOVER
GO

Si la base de données principale est indisponible, le script suivant peut être exécuté pour forcer le basculement vers la base secondaire (perte de données possible) :

USE master
GO
ALTER DATABASE IFC_SUITE SET PARTNER FAILOVER FORCE_SERVICE_ALLOW_DATA_LOSS
GO

Le script ci-dessus doit être exécuté sur le serveur miroir, à condition que le witness (s’il est utilisé) soit désactivé ou connecté au serveur miroir. La perte de données concerne les transactions (et mises-à-jour correspondantes) non-envoyées à la base secondaire avant le crash de la session.

Notons que :

  • Si vous avez créé et activé un witness mais que vous souhaitez le désactiver, il suffira simplement de faire un ALTER DATABASE IFC_SUITE SET WITNESS OFF sur l’instance de la base principale.
  • En mode asynchrone ou synchrone sans witness tout failover (automatique ou manuel) n’est pas possible. De ce fait, si jamais la base principale devient inaccessible (suite à un crash, par exemple) et que :
    • L’on souhaite simplement annuler la session de miroir et récupérer la base secondaire à un état ONLINE,
      il suffira simplement d’effectuer une restauration de celle-ci : RESTORE IFC_SUITE WITH RECOVERY.
    • L’on souhaite garder la session miroir, mais rendre la base secondaire disponible en tant que base principale, il suffira d’utiliser l’option FORCE_SERVICE_ALLOW_DATA_LOSS à lancer sur l’instance secondaire. Et une fois la base principale opérationnelle, elle assumera automatiquement le rôle de base miroir, la base secondaire devenant donc la base principale. Par contre, juste après le changement de rôles, la session miroir restera à SUSPENDED ce qui fait qu’il sera nécessaire de lancer un RESUME pour la rétablir complètement (voir section 2.4.2).
  • Le basculement automatique d’une base en miroir ne conduit pas nécessairement au pointage automatique de l’application vers la nouvelle base principale. Toutefois, au niveau applicatif, il est possible que cela puisse faire automatiquement. Référez-vous au lien suivant : http://msdn.microsoft.com/en-us/library/cc917713.aspx#ECAA.

Mapping automatique des utilisateurs après failover

Il faut savoir qu’après le basculement d’une base principale vers une base secondaire, les logins SQL présents à la fois sur le serveur principal et le serveur secondaire, et mappés à la base principale, ne sont pas automatiquement mappés à la base secondaire. Et ce, même si avant la mise-en-miroir, lesdits logins ont été manuellement mappés à la base secondaire.

En effet, MSSQL effectue le mapping non pas en fonction des noms de login, mais en fonction de leurs identifiants sécurité (appelés SID). Ainsi, si un login SQL est présent à la fois sur le serveur principal et sur le serveur secondaire, mais que son SID n’est pas identique sur les 2 serveurs, le mapping automatique échouera après chaque basculement d’une base à l’autre.

Pour remédier à ce problème, la solution est simple : affecter le même SID pour le login sur les 2 serveurs en suivant le modus operandi suivant (on suppose qu’on veuille copier le SID du login SQL usr_suite_ifc sur le serveur SRV-SQL01 vers le login SQL usr_suite_ifc sur le serveur SRV-SQL02):

  • Sur SRV-SQL01 :
    • Affichage des SIDs des logins :

      Le lancement de la requête SQL ci-dessous…

USE master
GO
SELECT l.name,
     l.sid
FROM sys.sql_logins l
GO

… donnera le résultat suivant :

  • Copie du SID de usr_suite_ifc (voir caractères hexadécimaux encadrés en rouge sur la figure ci-dessus).
  • Sur SRV-SQL02 :
    • Affichage du SID du login SQL secondaire (il suffit de relancer la même requête SQL que celle sur l’affichage des SID sur SRV-SQL01 vue précédemment)a, sur le serveur secondaire) :

    Remarquons d’ailleurs la différence de SID entre usr_suite_ifc sur le serveur principal et usr_suite_ifc sur le serveur secondaire.

    • Recréation du login SQL secondaire avec affectation du SID copié :

      Exécutez la requête SQL suivante :

/*** Suppression du login SQL, s'il existe ***/
IF EXISTS (SELECT * FROM sys.server_principals WHERE name =N'usr_suite_ifc')
DROP LOGIN usr_suite_ifc
GO
/*** (Re)création du login SQL avec le bon SID ***/
CREATE LOGIN usr_suite_ifc
WITH PASSWORD=N'password',
SID=0xFC92190567AB3E448685C9425FFD3340, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

Il n’est pas nécessaire de spécifier les autres options telles que la base de données par défaut, la langue,… Le mapping automatique post-basculement se chargera de le faire. Par contre, l’utilisation de l’option CHECK_EXPIRY est recommandée si l’on ne souhaite pas voir le mot-de-passe de son login expirer. De même, la désactivation du CHECK_POLICY permet de spécifier un mot-de-passe non soumis à une quelconque contrainte de nommage, de numérotation…

  • Vérification de la bonne prise en compte du nouveau SID copié :

Le SID étant désormais identique à celui sur SRV-SQL01, le basculement de la base principale vers la base secondaire sera donc suivi d’un mapping automatique du login SQL à la base secondaire devenue miroir.

A noter que ces différentes opérations ne s’appliquent pas aux logins Windows vu qu’ils ne sont pas concernés par ce problème de mapping automatique post-basculement. En effet, le SID de ces logins sont créés en se basant sur le SID du domaine.

Notez également qu’il n’est pas possible de modifier directement le SID d’un login. La seule solution est donc de recréer le login en spécifiant le SID souhaité.

Reprise après arrêt ou sinistre

Si la session miroir a été temporairement suspendue, et que vous souhaitez la reprendre:

USE master
GO
ALTER DATABASE IFC_SUITE SET PARTNER RESUME
GO
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s