• Article

Microsoft.com au jour le jourDémarrage de la mise en miroir de base de données

Saleem Hakani

Si votre base de données se retrouve hors ligne, vous êtes probablement dans le pétrin, non ? Cependant, si vous utilisez SQL Server 2005 avec SP1, la fonctionnalité de mise en miroir de la base de données peut empêcher le désastre. Cette nouvelle technologie de haute disponibilité vous permet de maintenir une veille de votre base de données pour utilisation lorsque votre serveur de base de données de production devient

indisponible, quelle qu’en soit la raison. La fonctionnalité de mise en miroir de la base de données transfère les journaux de transactions d’une base de données du serveur primaire au serveur secondaire, qui sert de veille. Avec la mise en miroir de base de données, les modifications de données sont enregistrées dans le journal des transactions avant que les modifications ne soient apportées aux véritables pages de données, comme les mises à jour SQL Server™ fonctionnent toujours. Les journaux sont tout d’abord placés dans le tampon de journal de la base de données principale en mémoire, puis copiés sur disque. Ces journaux des transactions sont copiés sur la base de données du serveur miroir et rejoués dessus. Ceci provoque la duplication des modifications de la base de données principale sur la base de données miroir. Attention, seule la base de données principale est accessible aux connexions client. Lorsque la base de données principale reçoit des modifications demandées par les clients, le serveur principal envoie ces modifications actives au serveur miroir ; le miroir ne prend pas ces décisions. Lorsque la mise en mémoire de base de données est activée et que la base de données principale échoue, la base de données mise en miroir devient disponible.

Mécanique de la mise en mémoire de base de données

La mise en miroir de base de données fonctionne avec tout le matériel standard prenant en charge SQL Server 2005 et garantit qu’il n’y aura pas de perte de données en cas de défaillance de la base de données. La base de données miroir sera systématiquement mise à jour avec la transaction en cours de traitement sur le serveur de base de données primaire. La figure 1 illustre le flux de données.

Si votre serveur principal tombe en panne, vous pouvez être sûr que le serveur miroir dispose d’une copie exacte de la base de données principale au moment de la dernière transaction validée. Ainsi, le miroir est toujours prêt à prendre le rôle du serveur principal.

Figure 1 Réplication des données sur le miroir

Figure 1** Réplication des données sur le miroir **(Cliquer sur l'image pour l'agrandir)

Dans la topologie de mise en mémoire de base de données, vous aurez besoin d’un troisième serveur appelé témoin si vous voulez activer le basculement automatique du serveur principal au serveur miroir et inversement. N’importe quel ordinateur prenant en charge SQL Server 2005 peut être serveur témoin.

Modes d’opération

La topologie de mise en miroir de base de données dépendra de la sécurité des transactions et des modes d’opération que vous avez choisis. Les modes d’opération pris en charge par la mise en miroir de base de données incluent la sécurité élevée (avec ou sans basculement automatique) et les performances élevées.

Sécurité élevée (avec basculement automatique) Ce mode prend en charge une disponibilité de base de données maximale avec transfert de données synchrone et basculement automatique vers la base de données miroir. Ce mode d’opération est idéal lorsque vous avez des communications rapides et très fiables entre le serveur principal et le serveur miroir, et que vous avez besoin d’un basculement automatique pour une seule base de données. Dans ce schéma, la base de données principale attend de valider une transaction jusqu’à ce qu’elle reçoive un message du serveur miroir indiquant que celui-ci a copié le journal des transactions sur le disque.

Sécurité élevée (sans basculement automatique) Ce mode prend en charge une disponibilité de base de données maximale avec transfert de données synchrone mais sans basculement automatique vers la base de données miroir. Dans ce mode, si l’instance de serveur miroir devient indisponible, l’instance de serveur principale continue à fonctionner mais ne pourra pas mettre en miroir les données. Si le serveur principal tombe en panne, la mise en miroir de base de données est interrompue, mais vous pouvez forcer manuellement le service à basculer.

Performances élevées Dans ce mode d’opération, le transfert de données est asynchrone. Le serveur principal n’attend pas d’indication du miroir comme dans les deux modes ci-dessus. Le serveur miroir fait de son mieux pour suivre le principal, mais il n’est pas garanti que toutes les transactions les plus récentes du serveur principal seront systématiquement copiées dans le journal des transactions du serveur miroir. Si le serveur principal tombe en panne, la mise en miroir de base de données est interrompue, mais vous pouvez forcer manuellement le service à basculer.

Poser les bases

La configuration d’une mise en miroir de base de données est un processus simple si vous établissez des bases solides en vous servant des meilleures pratiques :

Server Edition Revérifiez que les serveurs principal et miroir s’exécutent sur la même édition de SQL Server 2005 ; vous pouvez utiliser l’édition que vous souhaitez (Standard ou Enterprise).

Disponibilité du serveur témoin Si vous avez l’intention d’utiliser une sécurité élevée avec basculement automatique, assurez-vous que le serveur témoin est disponible et que SQL Server 2005 (n’importe quelle édition) est installé. Le serveur témoin peut s’exécuter sur n’importe quel système informatique fiable prenant en charge SQL Server 2005.

Image miroir Vérifiez que l’instance de serveur miroir et l’instance de serveur principale ont les mêmes tâches, logins, packages SQL Server Integration Service (SSIS), partitions de disque, emplacements de fichiers et configurations de serveur. Si vous configurez le serveur miroir exactement comme le serveur principal, le serveur miroir pourra fonctionner de la même façon que le principal.

Récupération complète Il est important que toutes les bases de données participant à la mise en miroir de base de données soient configurées sur le modèle de récupération FULL (complète).

Master et TempDB Vérifiez que toutes les instances de serveurs dans une topologie de mise en miroir utilisent le même classement Master et TempDB et la même page de code. Si ce n’est pas le cas, cela pourrait provoquer des problèmes lors de la configuration de mise en miroir de la base de données.

Sauvegarde Si la base de données à mettre en miroir a une taille importante, vous devez tout d’abord réaliser une sauvegarde complète de la base de données, puis la restaurer sur l’instance de serveur miroir à l’aide de l’option NORECOVERY.

Planification à l’avance Déterminez tous les noms de serveurs, numéros de ports, comptes de sécurité et emplacements où pourraient se trouver les bases de données et documentez-les. Voir la barre latérale Meilleures pratiques pour la mise en miroir de base de données qui contient une liste de vérification.

Une fois que vous vous êtes occupé des bases, vous êtes prêt à vous lancer dans la configuration de la mise en miroir de base de données dans votre environnement.

Meilleures pratiques pour la mise en miroir de base de données

  1. Utilisez des serveurs partenaires ayant une UC, une mémoire, une capacité de stockage et une capacité réseau identiques.
  2. Assurez-vous que les deux partenaires ont les mêmes éditions de SQL Server et du système d’exploitation, des service packs et des mises à jour.
  3. Installez SQL Server sur un répertoire et une structure de disque identiques sur les deux instances.
  4. Si les performances sont basses, vous pouvez envisager d’utiliser une carte d’interface dédiée pour diviser la charge.
  5. Comme pour les partenaires, vérifiez que les deux instances sont identiques en termes d’UC, de mémoire, de stockage et de capacité réseau. Si vous faites en sorte que les deux serveurs aient la même structure de répertoires, le même schéma de division des disques et la même configuration SQL Server, vous n’aurez pas à les modifier pendant ou après le basculement vers le partenaire miroir.
  6. Vérifiez que toutes vos applications peuvent se connecter et exécuter les actions nécessaires, et que tous les logins SQL Server actifs (et leurs autorisations) sur l’instance de serveur principale sont également présent sur l’instance de serveur miroir. Vous pouvez utiliser la tâche Transfer Logins de SQL Server 2005 Integration Services pour accomplir cela.
  7. Copiez les tâches d’agents SQL Server, les alertes, les packages SSIS, les bases de données d’assistance, les définitions de serveurs liés, les dispositifs de sauvegarde, les plans de maintenance, les profils de messagerie etc. du serveur principal au serveur miroir.
  8. Établissez une procédure de façon à ce que chaque fois que vous apportez des modifications au serveur principal (matériel, logiciel, paramètres SQL Server ou n’importe quel objet de base de données), ces modifications seront automatiquement répétées ou copiées et transférées sur l’instance de serveur miroir.
  9. Exécutez plusieurs basculements tests avant de commencer.

Configuration

Configurons la mise en miroir de base de données en utilisant le mode d’opération à sécurité élevée avec basculement automatique. (Comme indiqué, cela signifie qu’une instance de serveur témoin est nécessaire). Pour mon exemple j’utiliserai les noms de serveur et de base de données affichés à la figure 2, qui spécifie également le rôle de chaque serveur.

N’oubliez pas qu’étant donné que la configuration peut influer sur les performances lorsque le journal des transactions est copié du serveur principal au serveur miroir, il vaut sans doute mieux réaliser la configuration initiale en période creuse.

La configuration du miroir comporte trois étapes : la création de points finaux sur les serveurs qui participent, la sauvegarde et la restauration de votre base de données principale et l’activation de sessions miroir sur tous les serveurs participants.

Avant d’établir une session de mise en miroir de base de données, vous devez configurer le mécanisme de communication entre tous les serveurs participant à la mise en miroir de base de données. Pour ce faire, créez des points finaux sur tous les serveurs en exécutant cette instruction à la fois sur le serveur A et le serveur B :

Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);

Pour le serveur C (qui servira de témoin), modifiez (Role=Partner) en (Role=Witness) et exécutez l’instruction. Ceci contrôle le port TCP sur lequel écoute chaque instance.

Pour l’étape suivante, exécutez une sauvegarde complète de la base de données, suivie d’une sauvegarde de la base de données DBM_Demo sur le serveur principal puis restaurez-la sur l’instance de serveur miroir à l’aide de l’option NORECOVERY. (Le fait d’utiliser NORECOVERY permet de garantir que la base de données miroir sera dans l’état de restauration afin que les journaux des transactions puissent être appliqués).

Voici l’instruction T-SQL permettant de réaliser une sauvegarde de base de données complète de DBM_Demo à partir du serveur A (instance de serveur principale) :

Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';

Si des modifications sont apportées à la base de données une fois que vous avez réalisé la sauvegarde complète, vous devrez peut-être exécuter une sauvegarde de journaux de la base de données ; sinon, cela ne sera peut-être pas nécessaire.

Si nécessaire, vous pouvez utiliser l’instruction T-SQL suivante pour exécuter une sauvegarde de journaux de la base de données DBM_Demo à partir du serveur A :

Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';

Une fois toutes les sauvegardes exécutées, déplacez les fichiers de sauvegarde sur le serveur B ou un emplacement partagé de façon à ce que vous puissiez restaurer ces sauvegardes sur le serveur B. Une fois que c’est fait, restaurez les sauvegardes de journaux de transactions réalisées depuis la dernière sauvegarde de base de données complète à partir du serveur A, le cas échéant.

Vous pouvez utiliser l’instruction T-SQL suivante pour restaurer les sauvegardes complète et de journaux sur le serveur B à l’aide de l’option NORECOVERY :

--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;

Enfin, utilisez l’instruction T-SQL suivante pour restaurer la sauvegarde de journaux sur le serveur miroir en utilisant l’option NORECOVERY :

Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;

Une fois que vous avez fini de restaurer toutes les sauvegardes, vous êtes prêt à exécuter la dernière étape, c’est-à-dire l’action de votre session de mise en miroir de base de données sur tous les serveurs participants.

La configuration d’une session de mise en miroir de base de données nécessite une adresse réseau de serveur pour chacune des instances de serveurs. Cette adresse doit identifier l’instance en fournissant une adresse système et le numéro de port sur lequel l’instance écoute. La syntaxe pour une adresse réseau de serveur ressemble à ce qui suit :

TCP://<System-address>:<port>

<Adresse système> : est un nom de domaine pleinement qualifié ou une adresse IP ; vous pouvez obtenir ces informations en exécutant IPCONFIG sur l’ordinateur local à partir d’une invite de commande.

Vous avez établi le <Port> lorsque vous avez créé les points finaux.

Vous pouvez démarrer la session de mise en miroir de base de données sur le serveur B :

Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';

Ensuite, exécutez l’instruction T-SQL suivante pour démarrer la session sur le serveur A :

Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';

Ensuite, activez la session de mise en miroir sur le serveur C (serveur témoin) :

Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';

La mise en miroir de base de données est à présent prête à fonctionner dans votre environnement. Tous les objets de base de données ayant été ajoutés ou modifiés sur la base de données DBM_Demo seront transférés sur la copie du serveur B. Cependant, si la base de données du serveur A devient indisponible, un basculement peut survenir, modifiant ainsi le rôle de la base de données mise en miroir qui devient la base de données principale.

Maintenant que vous avez un miroir de base de données en état de fonctionnement, vous disposerez toujours d’une veille si votre base de données de production tombe en panne.

Saleem Hakani est un ingénieur de base de données sénior chez Microsoft, ayant plus de 14 années d’expérience avec les systèmes de base de données. Il a fondé la communauté Microsoft SQL, qu’il dirige, et est responsable des normes et de l’automatisation de SQL Server dans toute l’organisation Windows Live. Saleem détient des certifications MCTS, MCDBA et MCSA. Vous pouvez le contacter à l’adresse Saleem@sqlcommunity.net.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.