Discussion :

[erpWorld]

Bonjour,
Je suis entrain de lire des documentations autour des solutions de haute disponibilité disponibles sous SQL Server et je me sens perdu entre le failover et le groupe de disponibilité.
Pourrais vous m'expliquez le phénomène et la différence

Merci

[SQLpro]

La haute disponibilité est possible via 4 mécanismes :
1) le log shipping
2) le cluster système de basculement
3) le mirroring
4) AlwaysOn

Le mirroring est considéré comme "obolète" depuis la version 2012 de SQL Server, mais c'est le seul moyen de faire de la haute dispo synchrone pour les instance de version antérieures (2005, 2008, 2008 R2) ainsi que pour les édition standard des instances de version 2012 et 2014.

Le log shipping (to ship en anglais c'est "envoyer" dans le sens de "naviguer") consiste à transmettre à intervalle régulier les sauvegardes transactionnelles effectuées sur la base source pour reconstituer une base cible. Néanmoins la perte potentielle de données dans ce dispositif est assez importante car elle est induite par la fréquence des sauvegardes. Par exemple si vous sauvegardez le journal de transaction toutes les 5 minutes, alors vous perdrez en moyenne 2 minute 30 seconde de données.

Le cluster de basculement consiste à partager une même baise de disque pour stocker les bases, et avoir deux instances de SQL Server sur deux serveurs systèmes physiques, l'une en marche, l'autre a l'arrêt. En cas d'arrêt de celle en marche, la couche cluster de l'OS Windows décide de redémarrer la seconde instance qui prends le relais. Inconvénients : légère latence, mais surtout "SPOF" : la baie de disque partagée...

Le mirroring consiste à envoyer les données binaires du journal de transaction d'une base à l'autre qui l'intègre et la rejoue. Le mécanisme peut être synchrone (aucune perte de données) ou asynchrone. En mode synchrone, le système peut basculer automatiquement.

AlwaysOn combine le mirroring avec un cluster système :

• Le cluster FAILOVER est la partie système de AlwaysOn, assure le basculement.
• Le groupe de disponibilité est la partie logique de AlwaysOn et enrôle plusieurs bases devant basculer conjointement

De la même manière le mécanisme peut être synchrone (aucune perte de données) ou asynchrone. En mode synchrone, le système peut basculer automatiquement.

Plus d'informations dans notre livre :


A +

[erpWorld]

Sans commentaire, merci infiniment pour cette explication.
J'ai essayé de tester le logshipping cet après-midi, ça marché correctement, mais lorsque j'ai essayé de mettre la base inactive en read only je trouve toujours des erreurs lors de la restauration du trn.
je sais pas quelle bêtise j'ai fait.
autre question svp, est ce que le cluster de basculement et le alwaysOn exigent que les deux serveurs sont sous le même domaine ?
Est ce que AlwaysOn est disponible avec les versions developper ? Pour pouvoir les testés
Merci

[SQLpro]

autre question svp, est ce que le cluster de basculement et le alwaysOn exigent que les deux serveurs sont sous le même domaine ?

Cluster OUI, AlwaysOn non, mais c'est assez compliqué sans AD

Est ce que AlwaysOn est disponible avec les versions developper ? Pour pouvoir les testés

Version Developper = version Enterprise, donc oui. Mais vous ne pouvez pas utiliser la version Developper pour la production.

A +

[mikedavem]

autre question svp, est ce que le cluster de basculement et le alwaysOn exigent que les deux serveurs sont sous le même domaine ?

Un AlwaysOn multi domaine ou workgroup est possible depuis SQL 2016 + Windows Server 2016 mais au prix de certaines restrictions.

Est ce que AlwaysOn est disponible avec les versions developper ? Pour pouvoir les testés

Oui

PS: presque doublon avec SQLPro ... il a répondu plus vite

++