Serveur d'impression

Une migration monumentale vers SQL Server 2016 – Bien choisir son serveur d impression

Le 2 mai 2019 - 7 minutes de lecture

Il y a un peu plus d'un an, j'ai blogué à propos de mon expérience de migration d'une instance de test SQL Server d'une machine virtuelle vers une machine physique avec l'aide de mes amis. Cette migration s'est bien déroulée et l'instance fonctionne sans problème depuis. Mais ce sont de petites pommes de terre. Un exemple modeste, il ne représente que 5% environ de la taille de la production. Avec la fin de vie de EOL de SQL Server 2008R2, il était temps de migrer la production vers SQL Server 2016.

C’est une configuration plutôt musclée:

  • Instance en cluster avec basculement à 2 nœuds
  • 16 noyaux
  • 768 Go de RAM
  • 4 To de stockage
  • Plus de 8 000 bases de données

Le défi

Comment tu bouges huit mille bases de données dans un délai raisonnable? J'ai passé environ une heure et demie un matin à partager des idées avec des personnes de la chaîne dbatools Slack, ainsi que plusieurs conversations au bureau et avec notre fournisseur d'hébergement.

  • Start-DbaMigration? J'adore cette fonction, mais elle ne comporte qu'un seul thread et nous n'avons tout simplement pas le temps de sauvegarder et de restaurer autant de bases de données de cette façon.
  • Restauration de sauvegarde? Multi-threaded, nos sauvegardes complètes quotidiennes prennent plus de 3 heures. Doublez-le pour faire une sauvegarde et une restauration.
  • Détachez et rattachez? Nous aurons besoin de doubler l’espace de stockage et de perdre du temps en copiant les données, ou de prendre le temps nécessaire pour restaurer à partir d’une sauvegarde si nous devons revenir.
  • Envoi de journaux, mise en miroir, réplication? Encore une fois, doublez le stockage, et nous avons tant bases de données que ce n’est tout simplement pas faisable.
  • Mise à niveau sur place? N’est pas pris en charge par notre fournisseur d’hébergement et il n’ya pas beaucoup de filet de sécurité.

En fin de compte, l’équipe a opté pour une variante du détachement et du rattachement.

  1. Installez SQL Server 2016 sur de nouveaux serveurs physiques avec des lecteurs «factices» (afin que les chemins puissent être définis dans le processus d'installation)
  2. Arrêtez SQL Server 2008R2
  3. Prendre un instantané SAN
  4. Déplacer le LUN sur le nouveau serveur
  5. Joindre les bases de données

C’est le moyen le plus rapide pour nous de déplacer les données, et l’instantané fournit un moyen de revenir si nous devons revenir en arrière. Nous avons également des sauvegardes, mais il s’agit du parachute de réserve, l’instantané étant le principal.

Ce processus est plus simple si les chemins d'accès des fichiers de données et des fichiers journaux restent les mêmes. Mais cela n’est pas arrivé ici. Sur l'ancienne instance, les données et les journaux ont été vidés dans le même répertoire. La nouvelle instance possède des répertoires de données et de journal distincts. Et c’est une nouvelle lettre de lecteur à démarrer.

OK, alors comment allez-vous attacher huit mille bases de données et de déplacer leurs fichiers dans un délai raisonnable?

C’est un outil à la rescousse, avec Mount-DbaDatabase être la star du spectacle. Non seulement il attache des bases de données pour vous, mais vous pouvez également l'utiliser pour déplacer et renommer les fichiers. Mais c’est vraiment l’une des dernières étapes. Nous avons configuré pour faire en premier.

Préparation

Les bases

Une fois que les serveurs nous ont été livrés, les bases de l’administrateur de base de données ont dû être configurées. J'ai configuré quelques indicateurs de trace pour l'instance avec Set-DbaStartupParameter -Traceflags 3226,4199,7412,460.

Mise à jour 2019-01-16: J'ai reçu quelques questions sur l'utilisation de TF4199. Avec le option de base de données QUERY_OPTIMIZER_HOTFIXES il n’est pas absolument nécessaire d’obtenir des correctifs post-RTM pour l’optimiseur. Pedro Lopes (Blog|gazouillement) a recommandé dans son Sommet 2018 de l'activer à l'échelle mondiale, et il l'a confirmé lors d'un échange de courrier électronique avec Andy Galbraith (Blog|gazouillement) qu'Andy écrit sur son blog. Pam Lahoud (gazouillement) a écrit sur le sujet dans un post récent ainsi que.

J'ai utilisé Start-DbaMigration mais exclu Bases de données, connexions, AgentServer, ExtendedEvents (le dernier parce que nous n’utilisons de toute façon pas XE sur l’ancienne instance, ce qui évitait les avertissements ou les erreurs qui y étaient liées). L'exclusion de bases de données a du sens compte tenu de ce que j'ai écrit ci-dessus, mais pourquoi les connexions et les tâches d'agent? L'instance source a plusieurs années et a accumulé beaucoup de difficultés; cette migration était une bonne chance pour effacer cela. Toutes les connexions et les tâches désactivées ont été scriptées et enregistrées, et seuls les éléments actifs ont été migrés. Mais cela signifiait aussi que je ne pouvais pas utiliser Copy-DbaAgentServer car il ne filtre pas les travaux; quelques étapes supplémentaires étaient nécessaires.

Pour des raisons que je ne comprends pas, Start-DbaMigration copié fidèlement nos configurations de messagerie de base de données et de serveur lié, à une exception près: les mots de passe. Nous avons pu résoudre ce problème assez facilement, mais j’ai trouvé étrange que les mots de passe n’aient pas été copiés correctement. Surtout que j’ai réussi avec dbatools par le passé.

Déplacement de connexions

Bien que je ne souhaite que migrer les connexions actuellement actives, je souhaitais pouvoir recréer toutes les connexions désactivées au cas où, je devais donc extraire les scripts de création correspondants. J'ai réalisé ceci via Get-DbaLogin, Export-DbaLogin, et Copy-DbaLogin:

Emplois d'agent de déménagement

J'avais le même besoin de travail d'agent et je l'ai réalisé de la même manière. Cependant, parce que j'ai exclu le AgentServer de Start-DbaMigration, J’ai dû jeter un coup d’œil à cette fonction pour découvrir toutes les autres choses qu’elle copie avant de copier les travaux. Je souhaitais également laisser les tâches désactivées sur le nouveau serveur afin qu'elles ne soient pas exécutées avant que nous soyons prêts à les tester et les surveiller de manière plus contrôlée.

Maintenance et surveillance

Une fois cette opération terminée, nous avons mis à jour les outils de communauté installés dans les bases de données système.

Nous utilisons Minion CheckDB de MinionWare mais n’avons pas besoin d’effectuer une installation ou une migration séparée. À l'exception des travaux d'agent, tout est contenu dans une base de données unique. Les tâches de l'agent ont été copiées ci-dessus et la base de données a été ajoutée à toutes les autres.

Prêt à partir

Avec ce qui précède terminé, il ne restait plus grand-chose à faire, à part quelques tests à petite échelle du processus de pièce jointe à la base de données et la validation des opérations système (courrier de base de données, sauvegardes, CheckDB, etc.).

Mon prochain article couvrira le jour de la migration.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.