none
Scénarios de reprise - réplication transac égal à égal SQL2005 RRS feed

  • Question

  • Bonjour,

     

    Je souhaiterai installer deux serveurs SQL2005 (A et B) en réplication transactionnelle d’égal à égal.

    L’objectif étant d’avoir deux machines redondantes, qui en cas de panne, assureront la disponibilité des données de production.

    (Le basculement en cas d’indisponibilité d’un des deux serveurs est géré par les applications clientes).

     

    Mes interrogations s’orientent autour des scénarios de reprise en cas de panne :

     

    Supposons que le fonctionnement nominal soit atteint (tout est configuré, la réplication se fait entre A et B, et B et A), et que le serveur B devienne indisponible (coupure réseau, problème matériel…) :

     

    Cas d’une coupure réseau :

    -          Le serveur A est-il capable de détecter le retour de B, et de le remettre à niveau (en archivant les transactions pour les rejouer lorsque la liaison est rétablie, évitant l’intervention de l’administrateur) ?

    -          Y’a-t-il une durée d’interruption maximale pour que la remise à niveau soit possible (tenant compte des temps de latence occasionnés) ?

    -          Le serveur A reste t-il disponible pour ses applications clientes pendant cette remise à niveau ?

     

    Cas d’une panne ou défaillance matérielle :

    -                     Le serveur A peut-il évaluer les conséquences de la panne (ex : pertes de données sur l'acquis avant panne) ?

    -                     Jusqu’à quel point le système peut-être autonome pour se remettre en fonctionnement nominal ?

    -                     Le serveur A peut-il alerter l’administrateur qu’une remise à niveau est impossible (procédure de restauration manuelle) ?

     

    Merci par avance pour votre aide.

     

    Frédéric

    mercredi 4 mars 2009 14:51

Toutes les réponses

  • Bonjour,

    Pour avoir 2 machines redondantes la réplication n'est pas la bonne solution il est nécessaire de mettre en place le miroir de base de données. Cette fonctionnalité est disponible depuis le service pack 1 de SQL Server.

    Pour permettre la basculement automatique d'un serveur à l'autre, le processus à besoin d'un témoin (une instance SQL Server).

    Enfin l'url de connexion des programmes clients doit être légerement modifié afin d'inclure les 2 instances du miroir.
    jeudi 5 mars 2009 20:26
  • Bonjour,

    Le choix de ce type de transaction a été choisi car une des applications clientes a une fonctionnalité de persistances des données (relevés de mesures d'automates en tps réel) qui l'a rend incompatible avec le mirroring.

    Cette solution étant déja actée, je cherche à savoir quels sont les modes de rétablissement en cas de panne.

    Merci :)


    vendredi 6 mars 2009 08:21