Log Shipping dans SQL Server 2000 (Partie II)

Le log shipping d’un serveur primaire à  un serveur secondaire permet d’utiliser le second à  la place du premier, si nécessaire. Si une défaillance ou un arrêt programmé (pour une mise à  niveau de matériel ou l’installation d’un pack de services, par exemple) sur le serveur primaire, vous amène à  mettre la base de données de production momentanément hors service, vous pouvez changer le rôle de la base de données du serveur secondaire, pour la mettre en production en remplacement du serveur primaire. SQL Server 2000 Books Online (BOL) appelle cette opération un log shipping role change (changement de rôle de log shipping). Pendant le log shipping, vous maintenez la base de données du serveur secondaire dans un état non récupéré afin de pouvoir restaurer les journaux de transactions du serveur primaire dans la base de données du serveur secondaire. (Dès lors que vous avez récupéré une base de données, vous ne pouvez plus y restaurer des journaux de transactions.) Le changement de rôles consiste à  récupérer la base de données du serveur secondaire et à  la désigner comme la nouvelle base de données du serveur primaire. Vous pouvez aussi préciser que l’ancienne base de données du serveur primaire deviendra la nouvelle base de données secondaire. Si l’ancienne base de données primaire n’a subi aucun dommage, vous pouvez rétablir le log shipping de la nouvelle base de données du serveur primaire sur l’ancien serveur primaire, qui devient alors la nouvelle base de données du serveur secondaire. Appelons cela une inversion de rôles.

Bien que SQL Server 2000 fournisse un utilitaire Enterprise Manager pour installer et superviser log shipping, il ne supporte que très peu les changements de rôles de log shipping, un travail que vous accomplissez en appliquant manuellement les procédures cataloguées système provenant de la base de données msdb. J’ai modifié ces directives pour obtenir un ensemble de six étapes de base : transférer et exporter les logins, dégrader le serveur primaire, promouvoir le serveur secondaire, informer le serveur moniteur du changement de rôles, résoudre les logins sur le serveur secondaire et subordonner l’accès aux bases de données à  certaines autorisations. Voyons maintenant chaque étape en détail.

Etape 1 : Transférer et exporter les logins. Tout d’abord, BOL recommande de construire un package SQL Server 2000 TDS (Data Transformation Services) pour transférer les logins du serveur primaire sur le serveur secondaire et pour résoudre les SID login sur des serveurs distincts. (La tâche DTS Transfer Logins, que l’on utilise pour transférer les logins, n’est disponible que dans SQL Server DTS.) Vous créez et sauvegardez le package DTS sur le serveur primaire puis établissez l’exécution du package en invoquant dtsrun.exe par l’intermédiaire d’un job SQL Server Agent sur le serveur primaire. L’exécution du package transfère les logins d’un serveur sur l’autre, mais elle ne résout pas leurs SID login. (La résolution des logins sera décrite dans une étape ultérieure.) Toutefois, pour pouvoir résoudre les ID login ultérieurement, il faut d’abord créer un fichier contenant un export de la table syslogins du serveur primaire.

Pour exporter les logins sur le serveur secondaire, l’article BOL recommande de créer un job SQL Server Agent en deux étapes : sortie et copie de bcp. Dans la première étape, vous exportez les logins dans un fichier en utilisant bcp en mode natif. Dans la seconde, vous copiez les logins dans un fichier sur le serveur secondaire que vous utiliserez ultérieurement pour résoudre les logins pendant le changement de rôles. A ce stade (étape 5), vous utilisez la procédure cataloguée sp_resolve_logins pour résoudre les SID login sur le serveur secondaire. Après avoir créé le job, vous pouvez l’exécuter à  intervalles réguliers (pendant la nuit, par exemple) pour garder un fichier exporté à  jour des logins sur le serveur secondaire, pour l’éventualité où il faudrait faire un changement de rôles de log shipping.

Etape 2 : Rétrograder le serveur primaire. Pour sortir le serveur primaire de son rôle comme source de log shipping, vous le rétrogradez à  une position inférieure. Vous pouvez rétrograder la base de données du serveur primaire d’un serveur de production à  un serveur secondaire potentiel et la supprimer du log shipping en exécutant la procédure cataloguée sp_change_primary_role sur le serveur primaire. Le listing 1 montre la procédure cataloguée qui modifie la base de données log shipping appelée Pubscopy, du mode lecture/écriture au mode standby lecture seule, prêt à  recevoir les sauvegardes de journaux de transactions. La procédure cataloguée enlève la base de données du serveur primaire du plan log shipping en plusieurs étapes. Les paramètres ordonnent à  la procédure cataloguée de faire une dernière sauvegarde du journal de transactions, de mettre fin à  tous les utilisateurs dans la base de données, puis de mettre la base de données dans un état final standby et à  un niveau d’accès multi-utilisateur. Le code de renvoi de la procédure cataloguée indique si l’instruction BACKUP LOG a réussi.

Etape 3 : Promouvoir le serveur secondaire. L’étape suivante consiste à  promouvoir la base de données du serveur secondaire courante en un état récupéré pour pouvoir l’utiliser en lieu et place de la base de données de production originale et pour qu’il puisse devenir une base de données log shipping primaire possible. Sur le serveur secondaire, après vous être assuré qu’aucun autre utilisateur n’accède à  la base de données, vous pouvez exécuter la procédure cataloguée sp_change_secondary_role présentée dans le listing 2.

Les paramètres font que la procédure cataloguée tente de copier tous les fichiers log restants de l’ancien serveur primaire et de charger tous les journaux de transactions copiés restants sur le serveur secondaire. Le passage du paramètre @do_load = 1 fait une dernière copie et charge tous les journaux de transactions restants et le passage du paramètre @force_load = 1 spécifie l’option Forceload non documentée sur sqlmaint.exe. Le paramètre @final_state = 1 met la nouvelle base de données primaire en mode de reprise (recovery mode) et le paramètre @access_level remet l’accès en mode multi-utilisateur. Le paramètre @terminate = 1 ordonne à  la procédure cataloguée de mettre fin à  tous les utilisateurs accédant à  la base de données, en émettant la commande ALTER DATABASE avec l’option ROLLBACK IMMEDIATE. Toutefois, si vous gardez votre propre connexion Enterprise Manager à  la base de données ouverte pendant l’exécution de la procédure cataloguée, l’action ALTER DATABASE échouera. Par conséquent, vous devrez peut-être vous assurer manuellement que vous avez supprimé toutes vos propres connexions à  la base de données. Enfin, si la base de données est une base de données de réplication de type publishing, le paramètre @keep_replication = 0 maintiendra les paramètres de réplication du serveur.

La procédure cataloguée sp_change_secondary_role demande l’utilisation exclusive de la base de données et échouera si elle ne l’a pas. J’ai vu cette procédure échouer et indiquer que la base de données est en cours d’utilisation alors même que je savais qu’aucun utilisateur n’accédait à  la base de données. Il a suffi de réexécuter la procédure cataloguée pour résoudre le problème.

Quand la procédure cataloguée se termine et met la base de données en ligne, elle envoie un message indiquant que la commande RESTORE DATABASE a réussi. Si vous avez décidé de faire du serveur secondaire un futur serveur primaire potentiel, le plan de maintenance de base de données créera un job de sauvegarde du journal de transactions sur le serveur secondaire. Après démarrage de ce job, les fichiers de sauvegarde du journal de transactions commenceront à  apparaître sur le nouveau serveur primaire. Vous aurez peut-être besoin de ces fichiers pour rétablir log shipping sur le nouveau serveur secondaire.

Etape 4 : Informer le serveur moniteur du changement de rôles. Log shipping de SQL Server 2000 installe un utilitaire de supervision sur un serveur moniteur, de préférence un serveur tiers. Pour indiquer au serveur moniteur le changement de rôles, il faut exécuter sur lui la procédure cataloguée sp_change_monitor_role, illustrée dans le listing 3. Malgré son nom, cette procédure cataloguée ne change pas le rôle du moniteur. Elle change les références aux file shares des serveurs secondaire et primaire. Autrement dit, elle supprime des lignes dans la table log_shipping_secondaries du serveur moniteur qui faisaient référence à  l’ancien serveur secondaire, puis remplace l’ancien nom du serveur primaire par le nouveau nom du serveur primaire dans la table log_shipping_primaries. La procédure cataloguée n’insère pas de lignes dans la table log_shipping_secondaries parce qu’il n’existe pas encore une paire de log shipping.

Etape 5 : Résoudre les logins sur le serveur secondaire. Résoudre les logins de l’ancien serveur primaire sur le nouveau serveur primaire permet aux utilisateurs d’accéder à  ce dernier. Vous pouvez résoudre les logins sur le nouveau serveur de production en utilisant le fichier logins exporté à  l’étape 1. La procédure cataloguée sp_resolve_logins lit le fichier logins exporté, puis résout les SID différents entre les serveurs. Par exemple, le listing 4 montre comment exécuter la procédure cataloguée sp_resolve_logins pour résoudre les logins sur la base de données Pubscopy nouvellement récupérée. L’article BOL dit qu’il faut exécuter cette procédure cataloguée dans la base de données cible. Mais, en réalité, sp_resolve_logins fait une référence non qualifiée à  la vue syslogins, et donc il faut exécuter la procédure cataloguée à  partir de la base de données maître.

Etape 6 : Subordonner l’accès aux bases de données à  certaines autorisations. L’article BOL termine sa discussion sur les changements de rôles à  l’étape 5, mais il omet une étape importante : coordonner l’accès à  la base de données avec les autorisations pour les logins transférés. Pour lier les logins transférés et résolus avec leurs utilisateurs et autorisations de bases de données correspondants, dans la base de données de production du nouveau serveur primaire, il faut exécuter la procédure cataloguée sp_change_users_login une fois pour chaque login :

USE pubscopy

GO

EXEC sp_change_users_login 'Update_One', 'UserName'

  'LoginName'

A ce stade, vous avez promu le serveur secondaire à  son nouveau rôle, et l'ancien serveur primaire est prêt à  devenir serveur secondaire. Mais vous n'avez pas encore établi une relation de log shipping. C'est un changement de rôles, pas une inversion de rôles.