Réplication transactionnelle SQL Server 2008R2 – Déplacer SubscriberDB – Abonnement Push

Réplication transactionnelle SQL Server 2008R2 – Déplacer SubscriberDB – Abonnement Push

J'ai besoin de déplacer une database d'abonné vers un nouveau server en dehors d'une panne de système, c'est-à-dire que je ne peux pas empêcher la nouvelle transaction de se charger dans la database de l'éditeur.

Jusqu'à présent, j'ai tenté d'arrêter l'agent de dissortingbution et de laisser toutes les commands non répliquées se répliquer dans la database des abonnés sur Server1. Ensuite, sauvegardez et restaurez la database des abonnés sur Server2. J'ai ensuite créé un nouvel abonnement de Server2 à la publication existante.

Cela fonctionne, mais seules les transactions créées à partir de ce point sont répliquées vers la database d'abonnés Server2. J'ai également besoin de toutes les anciennes transactions créées dans la database du dissortingbuteur destinées uniquement à Server1.

Existe-t-il une command de réplication disponible pour mettre à jour la destination des transactions existantes du dissortingbuteur vers le nouvel abonné subscriber_subscriber_DB?

Il y a 1 publication avec plusieurs articles. La publication n'est actuellement souscrite que par une database sur Server1.

Tu travailles trop dur. Créez un abonnement sur le nouveau server comme si vous n'aviez aucun abonnement existant. Il y a plusieurs façons de le faire. Choisissez votre favori. Je vois dans votre réponse à une autre réponse que les instantanés ne sont pas autorisés. J'ai eu beaucoup de succès en utilisant l'option "initialize from backup" (ici, "backup" fait reference à une sauvegarde de l'éditeur). Une fois l'abonné synchronisé après l'initialisation, vous avez terminé. Vous avez maintenant la possibilité de "migrer" vers le nouveau server.

Étant donné que l'agent de dissortingbution est spécifique à chaque server abonné, vous ne pouvez pas vraiment requestr à un nouvel abonné de prendre la relève d'un abonné existant. Le seul moyen de le faire est de sauvegarder / restaurer sur Serveur2, d'arrêter temporairement les transactions sur l'éditeur, de sauvegarder / restaurer le journal sur Serveur2, de créer des abonnements avec "support de réplication uniquement", puis de réactiver les transactions.

Ne pouvez-vous pas simplement append des abonnements à la même publication pour le nouvel abonné et lancer l'agent de capture instantanée? Cela synchronisera indépendamment Server2 tandis que Server1 continue à restr synchronisé. Vous devriez alors pouvoir passer à Server2 de façon transparente et supprimer les abonnements à Server1.

Une note d'avertissement cependant. Je vérifie la table sync_method dans syspublications (ou exécute sp_helppublications) de votre database de publication pour m'assurer que les snapshots ne verrouilleront pas les tables de votre éditeur (par défaut avec SQL Server 2005+, cela ne devrait pas poser de problème). Sinon, ce que je viens de suggérer va bloquer l'éditeur jusqu'à la fin de l'instantané.

En outre, il s'agit d'une bonne reference pour comprendre comment faire des instantanés un à la fois si vous configurez la réplication via l'interface graphique en utilisant les parameters par défaut. Cela sera utile pour répartir les instantanés sur une période plus longue afin de réduire la charge du server éditeur si vous avez beaucoup de données à répliquer (gigaoctets plutôt que mégaoctets). http://www.replicationanswers.com/TransactionalOptimisation.asp