Synchronisation de la base de données SQL Server


21

Définition du problème

Nos utilisateurs doivent pouvoir interroger une base de données pour la plupart à jour. Les données peuvent être périmées jusqu'à 24 heures, ce qui est acceptable. Quelle serait l'approche la moins coûteuse pour obtenir et maintenir à jour une deuxième base de données avec une copie de production? Y a-t-il une approche à laquelle je ne pense pas?

Charge de travail

Nous avons une application tierce que nous utilisons pour surveiller l'activité de négociation d'actions. Pendant la journée, beaucoup de petits changements se produisent dans le cadre de divers flux de travail (oui, ce métier était valide. Non, c'est suspect, etc.). La nuit, nous effectuons de grandes opérations basées sur des ensembles (charge les transactions de la veille).

La solution et le problème actuels

Nous utilisons des instantanés de base de données . À 22 h, nous déposons et recréons l'instantané. Le traitement ETL commence alors. Ceci est évidemment éprouvant pour notre disque mais permet à nos utilisateurs de pouvoir interroger la base de données sans verrouiller la base de données (ils utilisent un frontal d'accès). Ils l'utilisent tard dans la nuit et tôt le matin pour remarquer des temps d'arrêt.

Le problème avec cette approche est double. La première est que dans le cas où le traitement nocturne échoue, et ce n'est pas très rare, nous arrivons à restaurer la base de données, ce qui entraîne la suppression de l'instantané. L'autre problème est que nos délais de traitement dépassent notre SLA. Nous essayons de résoudre ce problème en travaillant avec le fournisseur après avoir identifié des requêtes mal écrites et un manque d'indexation. L'instantané de la base de données est également à l'origine de ce ralentissement, comme en témoigne la différence de vitesse lorsqu'elle est présente et non --- choquante, je sais.

Approches envisagées

Regroupement

Nous avions activé le clustering de bases de données, mais cela ne répondait pas aux besoins de mise à disposition des données et compliquait généralement la vie de l'administrateur. Il a depuis été désactivé.

Réplication SQL Server

Nous avons commencé à étudier la réplication la semaine dernière. Notre théorie est que nous pouvons obtenir un deuxième catalogue debout et synchronisé avec la base de données de production. Avant le début d'ETL, nous couperons la connexion et la réactiverons uniquement une fois le processus ETL terminé.

L'administrateur a commencé avec la réplication de cliché, mais il craint que cela prenne plusieurs jours d'utilisation élevée du processeur pour générer le cliché ainsi que la consommation de disque requise. Il indique qu'il semble écrire toutes les données dans des fichiers physiques avant de les envoyer à l'abonné, de sorte que notre base de données de 0,6 To coûtera 1,8 To en frais de stockage. De plus, si cela prend plusieurs jours pour générer un snap, il ne rentrera pas dans le SLA souhaité.

Après avoir lu le bon article, il semble que Snapshot pourrait être le moyen d'initialiser les abonnés, mais nous voudrions ensuite passer à la réplication transactionnelle pour le garder synchronisé après cela. Je suppose que l'activation / la désactivation de la réplication transactionnelle ne forcera pas une réinitialisation complète? Sinon, nous ferons sauter notre fenêtre temporelle

Mise en miroir de bases de données

Notre base de données est en mode de récupération complète, donc la mise en miroir de bases de données est une option, mais j'en sais encore moins à ce sujet que la réplication. J'ai trouvé la réponse SO qui indiquait que "la mise en miroir de bases de données empêche l'accès direct aux données, les données en miroir sont uniquement accessibles via un instantané de base de données."

Expédition des journaux

Il semble que l' envoi de journaux pourrait également être une option, mais c'est une autre de ces choses que je ne connais pas. Serait-ce une solution moins coûteuse (mise en œuvre et maintenance) qu'autre chose? Basé sur le commentaire de Remus "L'envoi de journaux permet un accès en lecture seule à la copie de réplique, mais déconnectera tous les utilisateurs lors de l'application du prochain journal de sauvegarde reçu (par exemple toutes les 15-30 minutes)." Je ne sais pas combien de temps ce temps d'arrêt se traduirait, ce qui pourrait inquiéter les utilisateurs.

MS Sync

Je n'ai entendu parler de l'utilisation de Sync que le week-end dernier et je ne l'ai pas encore étudié. Je détesterais introduire une nouvelle technologie pour quelque chose avec une grande visibilité comme ce problème, mais si c'est la meilleure approche, tant pis.

SSIS

Nous faisons beaucoup de SSIS ici, donc générer quelques centaines de packages SSIS pour garder le secondaire synchronisé est une option pour nous, bien que laide . Je ne suis pas fan de cela, car cela représente beaucoup de frais de maintenance, je préfère que mon équipe ne s'en charge pas.

Instantané "magique" du SAN

Dans le passé, j'ai entendu dire que nos administrateurs utilisaient une technologie SAN pour effectuer des sauvegardes instantanées de disques entiers. Peut-être y a-t-il une magie EMC qui pourrait être utilisée pour faire des copies uberquick du mdf / ldf et nous pouvons ensuite détacher / attacher la base de données cible.

Sauvegarde et restauration

Je pense que nous prenons des sauvegardes complètes une fois par semaine, des différentiels tous les soirs et des tlogs toutes les 15 minutes. Si les utilisateurs pouvaient vivre avec la panne de 3-4 heures pour la restauration complète, je suppose que cela pourrait être une approche.

Contraintes

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, stockage SAN EMC avec des lecteurs mappés sur des fichiers vmdk, commvault gérant les sauvegardes et 0,6 To de données dans le catalogue source. Il s'agit d'une application tierce que nous hébergeons en interne. La modification de leur structure est généralement mal vue. Les utilisateurs ne peuvent pas aller sans interroger la base de données et refuser d'être contraints en identifiant de manière proactive les tables qu'ils contrôlent pour faire leur travail.

Nos DBA sont pour le moment purement contractuels. Les chronométreurs sont partis et nous ne les avons pas encore remplacés. Les administrateurs d'application ne connaissent pas bien les questions de SQL Server et nous avons une équipe d'administrateurs de stockage / VM qui pourraient aider / entraver cet effort. Les équipes de développement ne sont pas actuellement impliquées mais peuvent être enrôlées en fonction de l'approche. Une solution plus simple à mettre en œuvre et à maintenir serait donc préférable.

Moi, je suis du côté du développement de l'hosue donc je ne peux que proposer des approches et je n'ai pas eu à m'occuper du côté administratif des choses. Donc, sans temps en selle d'administrateur, j'hésite à dire qu'une approche serait supérieure à une autre - tout semble parfait selon les documents. Je suis tout à fait disposé à suivre toutes les directions que vous suggérez, car selon moi, cela ne fera que me rendre plus précieux en tant que professionnel DB. J'ai une brouette mais aucune cape d'holocauste disponible .

Questions connexes

Modifications

Pour répondre aux questions de @ onpnt

Acceptation de la latence des données

Les utilisateurs affichent actuellement des données qui ont jusqu'à 24 heures de retard. Les données ne sont à jour qu'en 2200

La quantité de données change dans une minute, une heure et un jour donnés Je ne sais pas comment quantifier cela. Heures d'ouverture, peut-être des centaines de changements par heure. Traitement nocturne, millions de lignes par jour ouvrable

Connectivité au secondaire

Réseau interne, hôte virtuel séparé et stockage dédié

Lire les exigences sur l'instance secondaire

Le groupe Windows aura un accès en lecture au secondaire, toutes les tables

Mise à jour de l'instance secondaire

Il n'y a pas de définition précise d'une exigence de disponibilité. Les utilisateurs veulent qu'il soit toujours disponible, mais sont-ils prêts à payer pour cela, probablement pas autant. En réalité, je dirais que 23 heures de la journée suffiraient.

Modifications du schéma existant et de tous les objets

Modifications peu fréquentes, peut-être une fois par trimestre pour les objets de table. Peut-être une fois par mois pour les objets de code.

Sécurité

Aucun besoin de sécurité particulier. Les autorisations de production correspondraient aux autorisations de la copie. Bien que j'y pense, nous pourrions révoquer l'accès en lecture des utilisateurs à prod et ne leur permettre que de lire la copie ... Pas une exigence cependant.

@darin strait

Revenir à l'instantané pourrait être une option, mais je pense qu'il y avait une raison pour laquelle ils ne l'ont pas poursuivi. Je vérifierai avec l'administrateur

@cfradenburg

Mon hypothèse était que nous n'utiliserions qu'une seule de ces approches mais c'est un bon point que les restaurations briseraient les "autres" technologies de synchronisation. Ils étudient la possibilité d'utiliser la magie des instantanés EMC. Comme l'administrateur l'a décrit, ils prendraient un instantané à 1900 et migreraient l'image vers la zone du secondaire. Cela devrait se terminer d'ici 2200, puis ils effectueraient un détachement et un rattachement de la base de données secondaire.

Emballer

2012-10-29 Nous avons évalué la magie des instantanés EMC et certaines autres options de réplication, mais les administrateurs de bases de données ont décidé qu'ils pouvaient mieux comprendre la mise en miroir. A voté les réponses parce qu'elles ont toutes aidé et m'ont donné beaucoup d'options ainsi que des «devoirs» à enquêter.


Est-il possible pour vous de restaurer l'instantané de la base de données en cas de problème? Cela devrait vous ramener à l'endroit où se trouvait la base de données lorsque l'instantané a été pris. Vous pouvez ensuite prendre un nouvel instantané, résoudre votre problème de traitement et continuer. W / R / T expédition de journaux, vous n'avez pas nécessairement à restaurer les sauvegardes de journaux sur votre copie toute la journée, au même moment où vous les prenez. Vous pouvez les laisser s'accumuler, puis les restaurer en groupe. Cela minimise l'interruption de l'utilisateur sur la copie, car vous pouvez choisir un temps lent pour le faire, et cela signifie que la copie ne changera pas toute la journée.
détroit de Darin

Si vous devez restaurer la base de données périodiquement, toute méthode rapide devra être réinitialisée. Si vous restaurez des sauvegardes DIFF ou LOG, une restauration complète devra être effectuée pour synchroniser à nouveau les bases de données. Même chose avec la mise en miroir et je ne suis pas sûr de la réplication. Votre meilleur pari est peut-être de voir ce que EMC peut faire pour vous. Je sais que lorsque j'ai parlé à NetApp, ils ont une solution qui ferait ce que vous recherchez, mais c'est un outil complémentaire.
cfradenburg

Réponses:


6

La modification de leur structure est généralement mal vue

La réplication est plus que probable et je voudrais jeter Sync avant cela. (à partir de tests transacitonaux réels dans Sync Framework)

Si 3-4 heures sont votre exception de latence des données, l'envoi de journaux sera probablement votre meilleur pari ici sur une copie en lecture seule. Mais combien de changements se produisent dans le journal? découvrez cela en le surveillant pour voir à quelle vitesse et combien vous devez pousser.

Si vous ne pouvez pas accéder à la mise en miroir ou à la mise à niveau vers 2012 Enterprise, cela ne sera pas le cas, mais ce serait une bonne stratégie si vous pouvez passer à Enterprise sinon.

SSIS n'est pas censé simplement vider des données, mais il peut le faire. Vous regardez beaucoup trop en termes de transformations de recherche et la tâche serait coûteuse en temps et en ressources. Bien que, comme je l'ai dit, cela puisse le faire.

Vraiment, il y aura un rétrécissement distinct des choix basés sur la réponse à quelques questions

  • Acceptation de la latence des données
  • Quantité de données modifiées dans une minute, une heure et un jour donnés Connectivité au secondaire
  • Lire les exigences sur l'instance secondaire
  • Mise à jour de l'instance secondaire
  • Modifications du schéma existant et de tous les objets
  • Sécurité

4

Cela va être l'une de ces choses que vous devez essayer par vous-même pour trouver ce qui fonctionne le mieux. La réplication peut être délicate, alors qu'il peut ne pas y avoir de coût monétaire direct, il y aura des frais généraux administratifs pour le maintenir.

Pour développer l'envoi de journaux, vous n'avez pas besoin de restaurer les journaux toutes les 15 à 30 minutes. Si vous le souhaitez, vous pouvez le faire toutes les quatre heures ou une fois par jour. Une solution similaire à celle que j'ai mise en œuvre consiste à effectuer une sauvegarde et une restauration complètes hebdomadaires dans une base de données de rapports (ce qui peut prendre un certain temps et se produire le week-end). Au cours de la semaine, des sauvegardes différentielles sont effectuées et celles-ci sont restaurées tous les soirs dans la base de données de rapports. Les utilisateurs doivent être démarrés avant la restauration, mais comme la base de données de génération de rapports est une application des heures ouvrables, cela ne pose aucun problème. Les données datent d'un jour, ce qui ne devrait pas être un problème en fonction de vos besoins.

Pour utiliser la mise en miroir de bases de données à cet effet, vous devez acheter Enterprise pour pouvoir utiliser des instantanés si vous n'exécutez pas déjà Enterprise. Il ne permettrait pas non plus de garder les données à 100% à jour car l'instantané doit être supprimé (ce qui signifie que tous les utilisateurs doivent être exclus), puis recréé pour obtenir les nouvelles données. Cependant, cela prendrait moins de temps que les restaurations de journaux ou la méthode que j'ai expliquée ci-dessus.

Si la mise à niveau vers SQL 2012 est une option, il est possible de configurer un secondaire en lecture seule qui sera mis à jour avec la base de données principale. Je ne mentionne cela que parce que c'est probablement la solution la plus fluide.


4

Autant que les gens se moquent de la réplication transactionnelle, cela ressemble à un bon ajustement pour votre situation. Quelques notes:

  1. Vous n'avez pas à initialiser l'abonné avec un instantané. Vous pouvez prendre une sauvegarde de l'éditeur et l'initialiser avec cela.
  2. Vous pouvez suspendre la livraison des commandes à l'abonné en arrêtant simplement le travail de distribution (il s'agit simplement d'un travail d'agent SQL normal chez le distributeur ou l'abonné selon que vous l'avez configuré en tant qu'abonnement push ou pull, respectivement). Gardez simplement à l'esprit votre rétention chez le distributeur de telle sorte que vous gardez suffisamment d'histoire autour de laquelle vous pouvez rattraper votre retard.
  3. Vous pouvez modifier l'indexation chez l'abonné pour prendre en charge les charges de travail qui y seront effectuées (vraisemblablement de type de rapport) au lieu d'avoir à accepter l'indexation de votre éditeur (probablement de type OLTP) si vous le souhaitez.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.