[SQL Server] Mini-FAQ sur le database mirroring

Ce billet offre une série de questions/réponses sur le database mirroring.

  • A partir de quelle version de SQL Server est supporté le database mirroring ?

    A partir de la version 2005.

  • Quelles sont les éditions supportant le database mirroring ?

Il s’agit des éditions Datacenter (à partir de SQL Server 2008 R2), Enterprise et Developer, ainsi qu’en mode haute-sécurité seulement pour les éditions StandardBusiness Intelligence (à partir de SQL Server 2012). L’édition Express et celle Web ne peuvent être utilisées qu’en tant que witness.

  • Peut-on créer une session miroir entre deux bases SQL Server de versions différentes ?

    Oui et non. Le database mirroring entre une base principale contenue dans une instance SQL Server 2008 (ou plus) et une base secondaire située sur une instance SQL Server 2005 est possible mais pas conseillé car en cas de failover, le database mirroring n’est plus possible car une base principale ne doit pas avoir une version inférieure à une base secondaire.

  • Qu’advient-il si l’on modifie le mode de récupération d’une base de données « miroir » de FULL à SIMPLE ?

    La session miroir est rompue, vu que le mode de récupération SIMPLE ne permet pas d’assurer la sauvegarde des journaux de transactions, nécessaires pour le database
    mirroring.

  • Peut-on tronquer la base principale ?

    Non.

  • Le shrink (réduction physique) d’une base principale ou de ses logs annule-t-il le database mirroring ?

    Non. Par contre, là où un shrink de logs n’est pas problématique (tant que ce n’est pas fréquent..), un shrink d’une base de données (i.e., de ses fichiers de données) est fortement à bannir (i.e., fragmentation des fichiers, fragmentation des indexes, augmentation de la charge de travail, surtout dans une session de database mirroring,…).

  • Peut-on configurer plusieurs bases de données pour une même base de données « miroir » ?

    Non, vu que la base de données « miroir » est une base de données « passive », car en état de restauration.

  • Peut-on sauvegarder la base « miroir » d’une session de database mirroring ?

    Non.

  • Peut-on faire des modifications dans la base « miroir » d’une session de database mirroring ?

    Non.

  • Peut-on effectuer une sauvegarde de la base principale impliquée dans une session de database mirroring ?

    Oui.

  • Peut-on faire intervenir une base dans plusieurs sessions de database mirroring ?

    Non.

  • Peut-on établir une session de database mirroring entre deux bases de versions différentes ?

    Non.

  • Peut-on placer le witness sur le même serveur que l’une des bases concernées par la session de database mirroring ?

    Oui, mais cela n’est pas recommandé. Il est en effet plus souhaitable de placer le witness sur un serveur autre que celui de la base principale et de celle secondaire. Et pour mieux comprendre cela, en voici quelques explications simples :

    • Lors de l’indisponibilité du witness, le failover automatique ne sera pas possible. La base principale va rester disponible, mais la session de database mirroring ne sera pas en cours de fonctionnement, à moins de rétablir le witness.
    • Lors de l’indisponibilité du witness et d’une base participant à la session de database mirroring :
      • S’il s’agit de la base principale, le failover automatique ne sera pas possible et donc, la base secondaire restera en mode de restauration. Autrement dit : ni la base principale, ni la base secondaire ne seront disponibles.
      • S’il s’agit de la base secondaire, pas de failover automatique possible, mais la base principale reste disponible.
  • Peut-on utiliser un même witness pour plusieurs sessions de database mirroring différentes ?

    Oui.

  • Peut-on combiner le database mirroring avec d’autres solutions de haute-disponibilité (log shipping, réplication, failover clustering,…) ?

    Oui.


Publicités

24 commentaires sur “[SQL Server] Mini-FAQ sur le database mirroring

  1. Thomas dit :

    Bonjour M. Cherif,
    je voudrais savoir ce qui se passe si j’ai deux bases en miroir et que l’instance de la base principale est arrête (arrêt du service SQL Server dans le configuration manager); est ce que le témoin bascule automatiquement (mode synchrone) sur la base mirroir? et que se passe t-il quand l’instance principale est redémarré? Est ce que la session de mirroring est automatiquement rétablie une fois que l’instance principale est redémarré ou il faudra faire une configuration manuelle?
    Meilleures salutations

    • Bonsoir Thomas,

      Si ta session est en mode synchrone, et que ta base principale est arrêtée, alors le témoin effectuera un failover automatique vers la base secondaire. Et quand l’instance principale est redémarrée, pas de failover, sauf si tu fais tout pour (arrêt ou redémarrage de la base secondaire devenue base principale, lancement d’une requête de failover via ALTER DATABASE,…).

      M.

      • Thomas dit :

        Bonjour M. Cherif,
        D’accord, j’ai fait le test; j’ai arrêté l’instance principale; le témoin a fait le basculement; ensuite j’ai redémarré l’instance principale; je suis allé sur l’instance secondaire (devenue principale) et je suis allé dans le menu miroir pour lancer le basculement vers la base principale originale; tout de suite il m’a mis un message d’erreur (du au temps de reconstruction des journaux); après quelques minutes, j’ai relancé et il a fait le basculement sur la base principale originale. Je suis satisfait; Merci beaucoup.
        Une dernière chose, j’ai vu qu’il y a une fonctionnalité Always On sur SQL Server 2012; j’ai pas encore testé; il parait que c’est une combinaison du failover Clustering et du database mirroring. Ferez-vous un article dessus?

      • Bonjour Thomas,

        Oui, un article (et même plusieurs) sur AlwaysOn est (sont) prévu(s), quand j’aurai un peu de temps.

        Concernant le database mirroring, si des logins SQL sont utilisés pour accéder à la base miroir, il faudra contrôler que le mapping se fasse correctement après chaque basculement (les SIDs pouvant différer d’une instance à l’autre). Plus de détails ici: https://mcherif.wordpress.com/2013/01/09/sql-server-quelques-operations-avancees-sur-le-database-mirroring.

        Bon courage,

        M.

  2. Thomas dit :

    Rebonjour M. Cherif,
    J’hésite entre le database mirroring et le failover clustering; dans quel cas faudrait il choisir un des modes de disponibilité; je crois que pour le database mirroring il faut en plus configurer la chaine de connexion pour l’application cliente qui doit prendre en compte le parternship alors que pour le failover clustering, c’est un seul nom qui est utilisé; en production, est ce qu’un failover clustering ne serait pas un meilleur choix?

    • Thomas,

      Tout dépend de tes besoins exacts, et surtout de ton niveau de tolérance à la perte de données.
      Pour mieux te situer: le failover clustering, c’est de la haute-disponibilité de type instance-level, là où le database mirroring est de type database-level.

      Pour info, le database mirroring est voué à disparaître à terme.

      Sinon, oui, ce que tu dis au sujet de la configuration du basculement au niveau applicatif est vrai: il est généralement plus facile de configurer un failover pour l’applicatif dans le cas du clustering (nom virtuel) que dans le cas du database mirroring (chaîne de connexion). Cela dit, le principal avantage du database mirroring par rapport au failover clustering, c’est la vitesse d’exécution du basculement, sans parler du fait qu’il n’est pas concerné par un quelconque SPOF (i.e., si ton témoin plante, ta session continue à quand même tourner).

      Une autre alternative (fort séduisante, d’ailleurs…) serait d’opter pour AlwaysOn (que j’aborderai dans une section du blog dédiée), si tu possèdes SQL Server 2012 (au moins), qui combine les avantages du mirroring (synchronisation de données) tout en étant basé sur une architecture en cluster.

      Bon courage,

      M.

  3. Thomas dit :

    Bonsoir M. Cherif,
    Merci pour la réponse; en réalité j’utilise une application client-serveur qui a besoin de deux bases SQL Server; une base de données système et une base de données métiers (découpée par exercice); je pense que dans mon cas, il est préférable d’opter pour un failover clustering pour ne pas s’embêter avec la chaîne de connexion. Je suis dans un environnement VmWare ESX 5.0 avec un cluster High Availability (2 hôtes); le SAN est un EMC. Y a t il des risques à configurer Microsoft Failover Clustering dans ce contexte?j’ai SQL Server 2005 Enterprise Edition x64 SP4.

  4. Thomas dit :

    Bonjour M. Cherif,
    Merci beaucoup; je vais m’y mettre

  5. Yves BOTTIN dit :

    Bonjour Mohamed,
    Tout d’abord, félicitations et merci pour ce beau travail.
    Mon problème : j’ai une base en miroir en mode synchrone sur deux serveurs. L’agent SQL est installé, et actif, sur chacun d’eux, avec les mêmes travaux, qui sont donc exécutés deux fois. Je peux le désactiver sur l’instance miroir, mais il faudrait qu’il soit actif en cas de basculement. Est-ce possible ? Ou, sinon, en laissant les deux actifs, y a t’il moyen de n’exécuter les travaux que depuis l’instance principale ?
    D’avance merci.

    • Bonsoir Yves,

      Est-ce que le fait de laisser tourner les jobs de l’instance au sein de laquelle se trouve la base secondaire est problématique pour toi (i.e., performances, etc…) ?

      En soi, laisser le SQL Server Agent actif sur l’instance de la base secondaire n’est pas une mauvaise pratique. Surtout qu’en cas de basculement, suivant la nature des travaux (réindexation, sauvegardes,…), la base secondaire devenue principale sera automatiquement prise en compte par les tâches du SQL Server Agent.

      Mais sinon, sur l’instance de la base secondaire, tu peux créer, pour chaque job du SQL Server Agent, une étape préliminaire qui vérifie le statut de ladite base. Ainsi, si la base est toujours en restauration (cas d’une base secondaire d’une session de database mirroring), alors le job ne fait rien, dans le cas échéant il se lance.

      Tu peux utiliser sys.databases (colonnes state et state_desc) ou, encore, sys.database_mirroring (mirroring_state_desc,…), notamment pour le requêtage.

      En guise d’information, quelques exemples de requêtes sont trouvables ici: https://mcherif.wordpress.com/2013/01/12/sql-server-elements-daudit-du-database-mirroring/.

      @+!

      M.

      • Yves BOTTIN dit :

        Bonjour Mohamed et merci pour ta réponse rapide,
        Non, ce n’est pas vraiment problématique, il s’agit d’une interrogation émanant de la MOA. Je peux lui exposer les deux solutions. Pourrais-tu s’il te plaît détailler un peu cette étape préliminaire ?

        D’avance merci

      • Bonjour Yves,

        Dans les propriétés de chaque job, section Steps (ou Etapes, si ton instance est en français), tu dois cliquer sur le bouton New (ou Nouveau). Puis dans la boîte modale qui s’ouvrira:
        1. Onglet General (Général):
        a. Changer le type de l’étape en T-SQL.
        b. Taper la requête suivante (supposons que la base en miroir s’appelle MaBase):
        IF NOT EXISTS(SELECT 1 FROM sys.databases WHERE state=0 and name=’MaBase’)
        RAISERROR(‘Base indisponible.’,16,1)
        GO

        2. Onglet Advanced (Avancé), choisir Quit the job reporting success pour l’option On failure action.

        Pour finir, après avoir validé la configuration de l’étape, il faut réordonner les étapes du job concerné de sorte que celle nouvellement créée soit exécutée en premier. Comme étape préliminaire, en somme.

        A titre informatif, la colonne state de la table système sys.databases indique l’état d’une base. La valeur 0 correspond à ONLINE. Tu peux également utiliser sys.database_mirroring et sa colonne mirroring_state_desc (SYNCHRONIZED,…) ou encore mirroring_role_desc (PRINCIPAL…) si tu veux être ultra-précis.

        Sinon, autre alternative (parmi tant d’autres, comme les DMOs), si tu es à l’aise avec les opérations ETL: SSIS. Ainsi, tu pourras créer une tâche d’exécution T-SQL (qui va lancer tes jobs (que tu pourras placer dans un container de séquence) suivant le résultat – encapsulé dans une variable réutilisée par un flux allant de ladite tâche vers ledit container – de ta requête de vérification du statut de ta base.

        @+!

        M.

      • Yves BOTTIN dit :

        Première solution parfaite.
        Merci Mohamed

      • Yves BOTTIN dit :

        Bonjour Mohamed,

        Si ce n’est pas abuser…

        Dans l’onglet « Avancé » de l’étape préliminaire, dans le cas de l’instance en miroir par exemple, donc qui ne doit pas exécuter le job, je mets quoi dans « Action en cas de succès », et tu me dis de mettre « Quitter le travail signalant la réussite » dans « Action en cas d’échec » ? Ce n’est pas limpide pour moi. Peux-tu m’éclairer ?

        Ensuite, pour ne plus te déranger, comment être averti par mail en cas de basculement ?
        Encore merci

      • Bonjour Yves,

        Dans Action en cas d’échec, tu dois indiquer la terminaison du job avec signalement de la réussite. En effet, le cas échéant, tu auras ton job constamment en échec tant que ta base miroir n’est pas disponible. Et voir le Job Monitor blindé d’événements d’erreurs, ce n’est pas très sexy.

        En revanche, dans le cas d’un succès (i.e., Action en cas de succès), il faut laisser le job passer à l’étape suivante. En effet, un succès indiquera que la base est disponible (donc, plus en miroir), et prête à être traitée par ledit job.

        Côté alerte en cas de basculement, tu peux utiliser le Database Mirroring Monitor pour créer tes alertes (comme ici:https://mcherif.wordpress.com/2013/01/12/sql-server-elements-daudit-du-database-mirroring/) ou simplement WMI (avec activation du Service Broker + création d’une alerte SQL Server Agent qui préviendra par mail un opérateur (toi, en l’occurrence) préalablement créé, en cas de failover, après exécution d’une requête WMI du style: SELECT * FROM DATABASE_MIRRORING_STATE_CHANGE WHERE State = 7 OR State = 8).

        Si cela reste trop complexe, je ferai un billet sur le sujet quand j’aurai du temps.

        @+!

        M.

      • Yves BOTTIN dit :

        Une fois de plus, MERCI MOHAMED

  6. Yves BOTTIN dit :

    Bonjour Mohamed, encore moi.
    En ce qui concerne l’alerte en cas de basculement, je ne reçois pas le mail. Elle est bien créée avec la requête WMI que tu m’as indiquée, avec « Notifier les opérateurs » coché, un opérateur avec une adresse type nom.prenom@sncf.fr (il ne faut pas SMTP: devant ?), option « Messagerie électronique » cochée.
    Je remarque que son historique est incrémenté chaque fois que j’effectue un basculement.
    Dans « Opérateurs » de « Agent SQL Server », j’ai créé un opérateur « Assistance A.S.T.I » avec « Nom de messagerie électronique » : nom.prenom@sncf.fr, tout coché en planification, « Alertes » sélectionné avec « Messagerie électronique » coché dans la partie « Notifications »
    J’ai au préalable configuré la « Messagerie de base de donnée » avec un profil et le compte SMTP « Assistance A.S.T.I » et son adresse mail.
    Je dois louper quelque chose…
    D’avance merci

  7. Yves BOTTIN dit :

    P.S.
    Dans les propriétés de « Agent SQL Server », « Système d’alerte », le bouton « Tester… » est grisé ?

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