Déplacement de bases de données vers de nouveaux centres de données

Mon entreprise transfère notre infrastructure vers un nouveau centre de données et j'essaie de trouver la meilleure façon de synchroniser la base de données sur le nouveau serveur avec la base de données de production actuelle jusqu'à ce que les nouveaux environnements soient prêts à être mis en service. N'étant pas un DBA à temps plein, j'ai fait quelques recherches et d'après ce que j'ai lu, il semble qu'une configuration de réplication transnationale répondrait le mieux à nos besoins.

Quelques détails: la base de données de production fait environ 90 Go et en utilisant Robocopy, il a fallu environ 9 heures pour en déplacer une copie sur l'un des nouveaux serveurs. La base de données de production actuelle devra rester en ligne et accessible tout au long du processus de migration. Il s'agit d'une récupération simple, donc la mise en miroir de bases de données n'est pas disponible.

Une réplication transactionnelle est-elle la meilleure méthode pour garder les bases de données synchronisées?

Mon plan:

1. (Terminé) Transférez la base de données actuelle et connectez-vous au nouveau serveur et attachez-la à la nouvelle instance de SQL Server
2. Configurer un distributeur sur notre machine de base de données de développement et y publier à partir de la base de données de production
3. Créez un abonné sur la nouvelle machine de base de données qui acceptera les mises à jour qui sont expulsées du distributeur, une fois par nuit

Il y a deux choses dans mon esprit. La réplication transactionnelle nécessite que chaque table publiée ait une clé primaire et que la plupart des tables de la base de données de production n'aient pas de clé primaire définie. Je ne pense pas que ce sera un problème trop important car ma principale préoccupation est simplement de synchroniser les bases de données. Nous testerons les différentes applications qui utilisent la base de données dans des données ultérieures, mais je voudrais m'assurer que ce n'est pas un problème sérieux. Deuxièmement, dois-je également déplacer les bases de données système associées de l'instance d'origine, telles que le maître? Nous passons à une configuration Active Directory dans le nouvel environnement, donc je ne me soucie pas des utilisateurs et autres, mais je ne suis pas sûr de la nécessité des bases de données système.

Et juste en général, est-ce que je saisis correctement ces concepts?

Votre situation actuelle:

• Base de données de 90 Go que vous souhaitez déplacer vers un nouveau centre de données.
• La base de données est en récupération simple.
• Vous envisagez d'utiliser T-Rep pour synchroniser les données.
• Il existe de nombreuses tables dans la base de données qui n'ont pas de clé primaire - c'est une condition pour que toutes les tables soient publiées.
• Vous avez déjà une copie de sauvegarde dans le centre de données de destination.

Je vois de nombreux inconvénients dans votre approche:

• T-Rep n'est pas facile à installer par rapport à d'autres technologies. S'il y a des modifications de schéma, cela nécessite un nouvel instantané.
• Si vous optez pour T-REP, vous devez apporter des modifications au schéma - ajoutez la clé primaire aux tables qui n'en ont pas.
• En apportant des modifications à votre base de données existante, votre application doit être entièrement testée pour éviter tout comportement inattendu.
• Si votre base de données comporte un grand nombre de transactions et en fonction de la bande passante réseau entre les 2 centres de données, il y aura également une latence de réplication.

D'après mon expérience, voici ma recommandation:

• Changez votre base de données en récupération complète. Ce n'est pas un impact majeur par rapport à la création de PK.
• Expédiez la sauvegarde complète de la base de données source - effectuez une sauvegarde avec compression et activez l'initialisation instantanée des fichiers. Cela vous aidera à réduire le temps de restauration sur le centre de données de destination.
• Restaurez la base de données sur le serveur de destination WITH NORECOVERY.
• Implémentez Logshipping et initialisez-le à partir de la sauvegarde.
• Faites expédier les journaux toutes les 1 min.
• Le jour du basculement, effectuez une dernière sauvegarde du journal de queue sur la source et restaurez-la sur la destination à l'aide WITH RECOVERY. Cela mettra la base de données de destination en ligne.
• Une fois la base de données de destination en ligne, vous devez synchroniser les utilisateurs .
• Vous devez modifier votre web.config pour le pointer vers le nouveau serveur.

Vous ne devez déplacer aucune base de données système. Assurez-vous de faire tout le travail de préparation avant de remettre manuellement les connexions, les travaux, les packages ssis, etc. et créez-les sur le serveur de destination.

Reportez-vous à cette réponse pour les étapes de post-restauration et les autres meilleures pratiques .

Remarque: Vous pouvez également implémenter la mise en miroir de bases de données (SYNC ou ASYNC selon l'édition du serveur SQL que vous utilisez), mais l'envoi de journaux est simplement simple à implémenter et si vous le testez, il ne vous décevra pas. J'ai réussi à déplacer la base de données téraoctets d'un centre de données à un autre en utilisant la technique ci-dessus et cela fonctionne parfaitement bien.

La base de données de production actuelle devra rester en ligne et accessible tout au long du processus de migration.

Il y aura toujours un temps d'arrêt et vous devrez le planifier. Même si vous investissez en payant des sommes importantes dans des solutions telles que le clustering, lorsque vous basculez, il y aura des temps d'arrêt. Vous devez équilibrer combien votre entreprise peut investir pour avoir un temps d'arrêt proche de zéro par rapport à ce qui est disponible avec un temps d'arrêt acceptable.

Je n'ai pas eu l'occasion de l'utiliser moi-même et je pense que c'est toujours en avant-première, mais SQL Data Sync sur la plateforme Azure pourrait être une option potentielle:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Il fonctionne avec les bases de données locales et Azure SQL et semble être un outil utile pour garder les bases de données synchronisées.