Réplication d'égal à égal dans SQL Server 2005/08

Question

Quelqu'un at-il déjà participé à la configuration de la réplication entre homologues ? utiliser SQL Server 2005 ou 2008?

Plus précisément, je voudrais savoir si d’autres options / alternatives ont été envisagées et pourquoi la réplication de poste à poste a été finalement retenue.

Si vous avez utilisé la réplication P2P:

Avez-vous rencontré des problèmes lors de la synchronisation et était-il facile à surveiller?

Dans quelle mesure était-il / est-il facile de résoudre les conflits?

Avez-vous dû modifier le schéma (remplacer les colonnes d'identité, etc.)?

Sinon, si vous envisagiez la réplication P2P et optiez pour une option différente, pourquoi l'avez-vous exclu?

Answer 1

(Avertissement: je suis un développeur, pas un administrateur de base de données)

La réplication de fusion SQL Server 2005 est configurée pour être répliquée entre deux nœuds actifs / actifs géographiquement séparés afin de garantir la résilience dans un système hérité.

Je ne sais pas s'il est facile à surveiller. en dehors de mes attributions.

Il crée des déclencheurs sur chaque table pour exécuter le mécanisme de publication / abonnement, chacun appelant sa propre procédure stockée.

Dans notre cas, il a été configuré pour utiliser les identités 1 à 1 milliard dans le nœud 0, 1 à 2 milliards dans le nœud 1 pour éviter les conflits d'identité (plutôt que d'utiliser une clé composite NodeId + EntityId pour chaque table, ou remplacer les clés par être des GUID, par exemple).

Je pense que la latence de la réplication est d'environ 15 secondes (entre Londres et New York sur une bande passante dédiée).

Travailler avec :

• Il a fallu un an à un entrepreneur très bien payé pour le mettre en place (cela était en partie dû à la nature héritée de la conception de la base de données)
• Il manque toute personne interne possédant l'expertise nécessaire pour le prendre en charge (notre administrateur de base de connaissances interne a pris environ 6 mois pour l'apprendre et a depuis évolué)
• Les mises à jour de schéma sont maintenant douloureuses . D'après ce que j'ai compris:
  • Certaines mises à jour doivent être effectuées sur un seul noeud. la réplication se charge ensuite de déterminer quoi faire sur le ou les autres nœuds
  • Certaines mises à jour doivent être effectuées sur les deux nœuds
  • Les mises à jour des données doivent être effectuées sur un seul noeud (je pense)
  • Toutes les mises à jour prennent désormais beaucoup plus de temps - de la fraction de seconde nécessaire à l'exécution d'un script de modification DDL à environ 30 minutes
• Je ne sais pas avec certitude, mais je pense que la bande passante requise pour la réplication est très élevée (dans la plage de mbit / s)
• Il introduit de nombreux " bruits " objets (3 sprocs par table, 3 déclencheurs par table) dans la base de données, il est donc difficile de trouver dans l’explorateur d’objets l’élément sur lequel on veut travailler.
• Nous ne mettrons en place un troisième nœud pour ce système, basé en grande partie sur la difficulté perçue et la douleur supplémentaire qu'il introduirait au moment du déploiement.
• Nous manquons également d'un environnement de transfert qui reflète la production, car il est trop pénible à mettre en place.
• Anecdote: l'administrateur de base de données chargé de la configuration maudissait souvent le fait qu'il s'agissait d'un "MS v1". il était forcé de travailler avec.
• Rappelez-vous faiblement: l'administrateur de base de données devait générer plusieurs tickets d'assistance prioritaires pour obtenir directement de l'aide de MS.

Certes, une partie de la douleur est due à notre environnement spécifique et au manque de talent interne pour prendre en charge cette configuration. Votre kilométrage peut varier.