Introduction
Le mirroring (ou miroir) est une nouvelle fonctionnalité SQL Server 2005 qui maintient une base de données standby inactive à des fins de DR (Disaster/Recovery) et/ou de bascule automatique en cas d’échec (automatic failover).
Comme la réplication transactionnelle ou la stratégie 'Log Shipping', le
mirroring duplique les mouvements de données en utilisant les journaux de
transactions. Le miroir diffère des 2 autres méthodes citées dans sa façon de
dupliquer à la volée les blocs Tlog des journaux de transactions du serveur
primaire vers une base de données miroir définie en mode InRecovery
.
Il existe trois différentes manières de configurer le mirroring SQL Server 2005 :
- Mode
Safety ON
avec témoin (with witness
) : les transactions sont envoyées vers le miroir et le serveur primaire attend l’acquittement du miroir. Il s’agit d’un mécanisme de transfert synchrone sans latence entre les 2 parties. Un troisième serveur témoin (witness
) dans cette stratégie de miroir prend en charge la bascule automatique (automatic failover
). - Mode
Safety ON
sans témoin (without witness
) : le transfert est synchrone mais la bascule (failover
) est manuelle. - Mode
Safety OFF
: les transactions sont envoyées mais le serveur primaire n’attend pas l’acquittement du miroir. Le mécanisme est complètement asynchrone et la bascule (failover
) doit être forcée. Le miroir peut être désynchronisé par rapport au serveur primaire. Le mode asynchrone est donc la solution de miroir la plus performante mais elle implique l’acceptation de la perte de données.
La troisième stratégie est celle évoquée dans cet article (SAFETY OFF
sans
témoin).
Présentation technique générale
Prérequis
Les noms des bases de données doivent être identiques dans les 2 parties.
Les instances SQL Server 2005 communiquent entre elles, aussi le réseau, les comptes, etc. doivent être configurés proprement en conséquence.
La base de données primaire doit être impérativement dans le mode de
restauration "full recovery
", en effet les enregistrements dans les journaux
qui correspondent à des opérations massives réalisées en journalisation
minimale (mode "bulk-logged recovery
") ne peuvent pas être envoyés vers la base
de données miroir.
De l’espace disque suffisant doit être prévu pour les journaux de transactions pour éviter toute erreur faute d’espace.
La base de données miroir n’est pas accessible car celle-ci est en état de restauration.
Comment cela fonctionne ?
Les bases de données sont synchronisées en utilisant la stratégie
backup/restore with norecovery
. En fonction du temps nécessaire pour cette
étape backup/restore
, une étape supplémentaire backup tran/load tran with
norecovery
peut être réalisée.
Des points de terminaison (Endpoints
) doivent être définis dans chaque
instance. Un point de terminaison représente un tunnel de communication entre
un client et un serveur.
Guide pratique
Mise en œuvre rapide
Étape 1. | Serveur primaire : Création du point de terminaison (create endpoint).
|
Étape 2. | Serveur primaire : Préparation de la base primaire (mode recovery full)
|
Étape 3. | Serveur primaire : Sauvegarde de la base primaire
|
Étape 4. | Serveur miroir : Restauration de la base en mode NORECOVERY
|
Étape 5. | Serveur miroir : Création du point de terminaison (create endpoint)
|
Étape 6. | Serveur miroir : Association de la base de données miroir au point de
terminaison primaire (SET PARTNER)
|
Étape 7. | Serveur primaire : Association de la base de données primaire au
point de terminaison miroir (SET PARTNER)
|
Étape 8. | Serveur primaire : Configuration des options de miroir (safety et
timeout)
Dès la définition de l’option SAFETY (OFF | FULL), le miroir démarre
automatiquement et les serveurs principal et miroir se synchronisent. |
Vérifications des statuts d’un miroir (vues systèmes)
Voici quelques commandes utiles qui interrogent les vues systèmes et renvoient des informations sur le statut du miroir.
select db_name(database_id) 'DB',
mirroring_state_desc,
mirroring_role_desc,
mirroring_safety_level_desc,
mirroring_partner_instance,
mirroring_failover_lsn,
mirroring_connection_timeout,
mirroring_redo_queue,
mirroring_redo_queue_type
from sys.database_mirroring
where mirroring_guid is no t null
select * from sys.database_mirroring_endpoints
select * from sys.dm_db_mirroring_connections
select * from sys.tcp_endpoints
Commandes utiles
Bascule manuelle (manual failover) sur le miroir
Pour basculer manuellement sur la base miroir :
- Sur le serveur primaire
Le modeALTER DATABASE [databaseName] SET PARTNER SAFETY FULL ALTER DATABASE [databaseName] SET PARTNER FAILOVER
FAILOVER
ne peut être appliqué que si l’optionSAFETY
est àFULL
. - Sur le serveur miroir
ALTER DATABASE [databaseName] SET PARTNER SAFETY OFF
Suspension et reprise d’un miroir (resume/suspend)
Pour suspendre un miroir, se connecter dans chaque partenaire (primaire et
secondaire) et lancer la commande ALTER DATABASE
avec l’option SET PARTNER
SUSPEND
.
ALTER DATABASE [databaseName] SET PARTNER SUSPEND
Pour reprendre un miroir, se connecter dans chaque partenaire (primaire et
secondaire) et lancer la commande ALTER DATABASE
avec l’option SET PARTNER
RESUME
.
ALTER DATABASE [databaseName] SET PARTNER RESUME
Visualiser le contenu d’un miroir (SNAPSHOT)
Le contenu d’un miroir peut uniquement être consulté en utilisant la
nouvelle fonctionnalité de SNAPSHOT
(photo instantanée) de SQL Server 2005.
CREATE DATABASE [snap_databaseName] ON
( NAME = N'databaseName_data_file01 ', FILENAME = N'd:\snap_test_data.snap' )
AS SNAPSHOT OF [databaseName]
Le snapshot peut être supprimé avec la commande DROP DATABASE
.
DROP DATABASE snap_databaseName
Suppression d’un miroir
Pour supprimer un miroir, la commande ALTER DATABASE
avec l’option SET
PARTNER OFF
est exécutée sur les serveurs primaire et miroir
ALTER DATABASE [databaseName] SET PARTNER OFF