Déposer des partitions historiques qui ne sont plus nécessaires pendant la réplication P2P

Question

La société que je travaille pour dispose d'un ensemble de bases de données (plus grandes juste en dessous de 1 ToB) sur différents serveurs - 2 aux États-Unis, 2 en Europe.

Nous exécutons une réplication pair-to-peer par base de données par base de données entre les 4 nœuds - afin qu'ils puissent tous prendre des transactions (insertion / mise à jour / supprimer) et tous ont les données que les autres nœuds ont été collectées (dans une latence variable - pire La connexion est en moyenne environ 30 à 40 secondes).

La plus grande base de données porte des données du début de 2008 à aujourd'hui. Toutes ces données sont encore répliquées aux nœuds de rapport qui contiennent toutes les données.

Je dois supprimer des données sur les nœuds transactionnels, jusqu'à 2013, pour supprimer le déficit de l'espace d'entraînement sur les nœuds transactionnels et que les données historiques ne seront disponibles que sur les nœuds de rapport.

Quelle est la meilleure façon de faire cela? Les données sont relativement gérables en ce sens qu'elle est bien partitionnée (mensuelle par partition, puis annuellement dans des fichiers / groupes de fichiers distincts). Cependant, il y a le problème de ne pas pouvoir abandonner les partitions lorsqu'ils sont impliqués dans la réplication et la lecture sur la commutation de partition - cela n'est pas autorisé avec cela non plus. ( Commutateurs Partitions Prérequis - Point 18 )

En tant qu'environnement de production complet, j'essaie d'éviter tout ce qui affectera la réplication - y compris la resynchronisation (beaucoup de données à la resynchronisation, sur de grandes distances).

Quelqu'un a-t-il de bonnes suggestions pour comment effectuer cette tâche?

Answer 1

Alors, pas de réponses d'ici, mais après une certaine discussion et une certaine pensée, je suis proposé un plan il y a quelques mois.

Je ferai cette réponse concise pour ce forum (vous ne pouvez pas accepter que j'ai!), Pour essayer d'aider toute personne à remplir une tâche similaire à l'avenir, n'hésitez pas à poser des questions si quelque chose manquait de quelque chose - Bien que la méthode soit simple.

Ainsi, la principale préoccupation est de supprimer les données sans impact significatif sur le trafic de production sur les nœuds que nous reproduisons vers / depuis. Le moyen le plus simple de le faire est de séparer un nœud que vous souhaitez travailler, en supprimant les données de ce nœud tout en laissant tous les autres non affectés (y compris les nœuds de rapport).

meilleure façon de le faire (rappelez-vous que vous ne pouvez pas laisser tomber les partitions et les opérations / la plupart des opérations sont répliquées et créent donc une grande quantité de trafic et une grande quantité de changements de ligne), est de créer une nouvelle SP et de configurer une publication. autour de celui-ci un sp. Il devrait donc être disponible sur tous les nœuds. Le bit important consiste à définir la réplication pour reproduire l'exécution du SP - pas le résultat (c'est-à-dire répliquer l'appel EXED SP_Delete et non la suppression de l'ID= 1, supprimez l'adresse ID= 2 - Niveau de ligne). Ceci est défini dans le bouton droit de la souris sur votre nouvelle publication (avant de configurer les autres nœuds de la topologie)> Propriétés> Articles> Cliquez sur le bouton SP_Delete Vous avez configuré> Bouton Propriétés de l'article> Définir les propriétés de la procédure stockée en surbrillance Article> Répliquer Line= Exécution du procédure stockée. Terminez votre topologie P2P.

Mais Mhsqldba, vous dites peut-être que cela va simplement supprimer séparément les lignes à chaque noeud via le sp. - C'est pourquoi vous définissez le SP pour uniquement faire les suppressions:

si @@ serveurName= 'Le serveur actuel que vous souhaitez affecter'

Suivez-la avec votre procédure de suppression.

Ainsi, lorsque cet appel EXEC est pris en charge sur le (s) serveur (s) que vous ne souhaitez pas exécuter les suppresses, il sera ignoré comme @@ ServerName ne sera pas égal au serveur que vous avez sélectionné.

Vous pouvez penser - pourquoi ne pas simplement créer un SP uniquement sur le serveur qui vous intéresse et exécutez-le? - En effet, si vous faites cela, la réplication décomposera les modifications dans la manière dont ils affectent les lignes d'article (tableau) et reproduisent les modifications réelles - vous devez reproduire le SP afin que vous puissiez spécifier que l'exécutif du SP soit reproduit plutôt que les changements résultants.

Ceci est l'ordre suggéré des événements à mon avis / Expérience:

1. Créez SP avec le code de suppression qui spécifie qu'il n'exécutera que le code de suppression si @@ ServerName= votre serveur souhaité
2. Configurez une nouvelle publication qui reproduit ce 1 sp avec le répliqué= exécution de la procédure stockée dans les propriétés de l'article
3. Exécutez le SP sur votre serveur souhaité et soyez heureux que vous n'aviez pas abattu tout le domaine avec des milliers de commandes de suppression répliquées

points de note:

1. C'est toujours une tâche laborieuse. En utilisant cette méthode, vous avez réduit votre effet sur tous les serveurs en dehors de celui que vous travaillez. Vous n'avez pas diminué de la charge de travail pour vous, en fait, vous l'avez fait pire - vous allez devoir exécuter ce même SP à chaque nœud (avec la ligne IF remplacée par le serveur que vous ciblez), augmentant efficacement le travail que vous avez à faire, par le nombre de serveurs, vous devez affecter. Il est extrêmement plus sûr, car vous aurez un effet minimal sur tous les autres nœuds (je suppose que vous avez échoué sur le trafic du nœud que vous travaillez bien sûr!)
2. En utilisant cette méthode, vous avez créé une incohérence entre vos nœuds - vous devez vraiment être sûr que les données que vous supprimez ne changent pas avant de pouvoir terminer la même opération sur tous les nœuds nécessitant un travail. Si une ligne que vous avez supprimée à 1 noeud est modifiée dans le reste de la succession, vous allez vous retrouver avec des erreurs de consistance.
3. Vous allez probablement mettre votre réplication normale que la SLA attendue derrière le temps qu'il faut pour effectuer les suppressions sur le nœud que vous travaillez (je vous recommande vivement de lire sur la suppression des suppressions) - donc vous avez besoin de Pour être conscient que, une fois l'opération terminée, vous ne recevrez pas le nœud en action jusqu'à ce que la réplication normale ait pris en arrière après que vos serrures de l'opération de suppression ont été publiées. Si vous répliquez sur des lignes de latence élevées, je vous suggère sérieusement de vérifier à l'aide d'agents de traction au lieu de pousser - cela fait une différence humoneuse.

Il existe probablement un meilleur moyen de déplacer les données de l'extérieur dans le SP qu'à utiliser Suppr - peut-être le déplacer vers une autre table qui n'est pas impliquée dans la réplication, puis de laisser tomber la "nouvelle" table - ou l'inverse, si les données que vous Voulez-vous conserver est inférieur à la quantité à supprimer, déplacez les données que vous souhaitez conserver dans une nouvelle table, laissez-la tomber l'ancienne puis renommez votre nouvelle table - il y a beaucoup d'avis de ces perspectives - je travaille dans un environnement où Il était plus facile de se battre pour la suppression que de promouvoir un concept que

Certains membres du personnel ne comprendront pas, alors je décris la manière douloureuse mais fondamentale.

Disclaimer: Tout ce qui précède est dangereux.Si cela est fait à la hâte sans prévoiement approprié, vous pouvez sérieusement gâcher une topologie de réplication, les données de votre entreprise et probablement votre emploi.Veuillez prendre la méthode ci-dessus et développer votre propre plan de bataille - Créez un environnement de test pour prouver le concept, le test de test et le test, ne prenez pas cette tâche légèrement.Avec suffisamment de mesures, vous réaliserez votre tâche - mais cela ne vaut pas la peine de faire le vendredi après-midi après quelques bières du midi.Faites-le bien, faites-le une fois (pour le test réel autant que vous le pouvez), faites-le correctement.

J'espère que cela aide quelqu'un d'autre.- J'ajoute ce bit comme c'est ce que j'aurais cherché si je voulais cette réponse:

Supprimer une grande quantité de données d'une topologie de réplication par pair à pair