Replicación punto a punto en SQL Server 2005/08

Question

¿Alguien ha tenido alguna experiencia en la configuración de peer to peer replication utilizando SQL Server 2005 o 2008?

Específicamente, estoy interesado en si se consideraron otras opciones/alternativas y por qué finalmente se eligió la replicación P2P.

Si ha utilizado la replicación P2P:

¿Ha tenido algún problema durante la sincronización y era fácil de controlar?

¿Qué tan fácil/problemático es resolver los conflictos?

¿Tuvo que hacer cambios de esquema (es decir, reemplazar columnas de identidad, etc.)?

Alternativamente, si usted consideró la replicación P2P y fue con una opción diferente, ¿por qué lo descartó?

Answer 1

(Negación: Soy un desarrollador, no un DBA)

Tenemos la replicación del servidor 2005 de mezcla de SQL creada para replicar entre dos nodos activos/activos separados geográficamente para la resiliencia en un sistema heredado.

No sé si es fácil de monitorear; fuera de mi competencia

Crea desencadenantes en cada tabla para hacer el mecanismo de publicación/suscripción, cada uno de los cuales llama a su propio procedimiento almacenado.

En nuestro caso, se configuró para usar identidades 1-1bn en el nodo 0, 1bn-2bn en el nodo 1 para evitar colisiones de identidad (en lugar de usar una clave compuesta de NodeId + EntityId para cada tabla, o cambiar claves ser GUID, por ejemplo).

Creo que la latencia de replicación es de aproximadamente 15s (entre Londres y Nueva York por ancho de banda dedicado).

es un enorme dolor trabajar con:

• Tomó un contratista altamente pagado un año para configurarlo (de acuerdo, parte de esto era debido a la naturaleza legado del diseño de DB)
• carecemos de cualquier persona en la empresa con la experiencia necesaria para apoyarlo (el DBA en la casa que habíamos tomó ~ 6 meses para aprenderlo, y desde entonces ha seguido adelante)
• las actualizaciones del esquema son ahora dolorosa.Por lo que entiendo:
  • Ciertas actualizaciones deben realizarse en un solo nodo; la replicación se encarga entonces de averiguar qué hacer en el otro nodo (s)
  • Ciertos cambios deben realizarse en ambos nodos
  • actualizaciones de datos se debe realizar en un solo nodo (creo)
  • todas las actualizaciones ahora tomar mucho más tiempo para realizar: desde la fracción de segundo que lleva ejecutar un script de cambio DDL a ~ 30 minutos
• No lo sé con certeza, pero creo que el requisito de ancho de banda para la replicación es muy alto (en el rango de MBit/s)
• Introduce muchos objetos "noise" (3 sprocs por tabla, 3 desencadenadores por tabla) en el DB, lo que hace inconveniente encontrar en el explorador de objetos el elemento sobre el que se desea trabajar.
• Vamos a nunca configuramos un tercer nodo para este sistema, basado en gran medida en la dificultad percibida y el dolor añadido que introduciría en el momento del despliegue.
• También nos falta un entorno de preparación que refleje la producción, porque es demasiado doloroso de configurar.
• Anécdota: El DBA que hace la configuración con frecuencia maldeciría el hecho de que era una "MS v1" con la que se le obligaba a trabajar.
• Desafortunadamente recordado: El DBA necesitaba aumentar varias solicitudes de asistencia prioritarias para recibir ayuda de MS directamente.

Concedido: parte del dolor involucrado se debe a nuestro entorno específico y al no tener el talento interno para admitir esta configuración. Su experiencia puede ser diferente.