MS-SQL Server 2005: Inicializando una suscripción de fusión con una ubicación de instantánea alternativa

sql server replication options

Question

Comenzamos una replicación de fusión en el extranjero hace 1 año y todo va bien hasta ahora. Mi problema es que ahora tenemos tantos datos en nuestro sistema que cualquier falla en uno de los servidores del suscriptor será un desastre: reiniciar una suscripción de la manera estándar llevará días (¡nuestras conexiones son definitivamente lentas, pero ya son muy caras)! Entre las ideas que he estado siguiendo están las siguientes:

1. hacer una copia de la base de datos original, congelarla, enviar los archivos por avión al suscriptor e iniciar la replicación sin instantánea: esto es algo que se hizo tradicionalmente con versiones anteriores de SQL, pero me suena un poco desordenado: Tendría que poner los datos de mi editor en modo de solo lectura y detener todas las replicaciones hasta que se complete la operación.
2. haga una instantánea de los datos, envíe los archivos de instantáneas al exterior, instálelos en el suscriptor e indique la nueva ubicación de instantáneas como una ubicación alternativa en las propiedades de replicación. Esto me parece justo (no es necesario suspender las replicaciones en curso, no hay congelación de datos), pero, en este punto, la ayuda de Microsoft no ... ayuda.

Estoy seguro de que algunos de ustedes ya han experimentado tal situación. ¿Cuál fue tu elección?

EDITAR: por supuesto, uno podría decir "¿por qué no pruebas tus ideas?", Pero llevará horas (varias instancias de servidores sql, máquinas virtuales y todo eso ...), y yo Estaba pensando que el tipo que lo hizo necesitará solo 2 minutos para explicar su idea. Y sería el hombre más feliz si alguien acepta perder 2 minutos de su tiempo para ahorrarme horas de trabajo duro ...

Answer 1

Acabamos de pasar por algo como esto, y no es bonito. A pesar de que todos los servidores involucrados eran locales, aún tomó mucho tiempo.

Para dificultar las cosas, al menos con SQL 2000, la instantánea fallará si la cabina comprimida supera los 4 gigas.

El mejor consejo que podría ofrecer es asegurarse de que cada sitio tenga buenas copias de seguridad disponibles. Con eso, al menos los datos no tendrían que ser llevados a mano al suscriptor.

Answer 2

Tenía que hacer algo similar a esto al replicar datos de Los Ángeles, California a China. El chasquido habría tardado 44 días en cargarse con los métodos normales.

Lo que hice fue configurar la Replicación SQL para usar una ruta local a la instantánea. Luego deshabilité el trabajo transaccional (en su caso, el trabajo de fusión). Luego ejecuté el complemento. Comprimé el complemento y transferí los archivos desde California a China. Cuando llegaron a China, los descomprimí y los puse en la misma carpeta que utilicé en California.

Luego ejecuté el distrib.exe desde la línea de comando en el servidor en China. Esto cargó los datos en la tabla en china. Una vez que se cargó el complemento, apagué el distribuidor en el servidor en China y comencé el distribuidor normal en el servidor en California.

Este método solo tomó aproximadamente 28 horas en lugar de más de un mes.

Si sus datos tardarán más de un par de días en llegar a su destino, deberá editar la publicación e incrementar la cantidad de datos que pueden ponerse en cola o se agotarán los tiempos de espera del suscriptor, por lo que será necesario incluir una nueva instantánea. tomado.