Posteado por: eurecadigital | febrero 9, 2009

Replicar Base de datos SQL Server 2000 en 2 Servidores distintos

Hay que tener 3 conceptos muy claros.
Publicador: Es aquel servidor que publica la información de su/us bases de Datos. (Es el origen de la Información)

Distribuidor: Es aquel servidor que se encarga de gestionar los cambios que hay en el Publicador para distribuirlos a las “BDD destino”

Suscriptor: Es aquel servidor que recibe los cambios de la BBDD origen y que contiene las BBDD destino replicadas.

 

Existen varias combinaciones entre quien asume el rol de P D o S. 

Lo normal es tener 2 Servidores uno publicador y otro Suscriptor y que uno de los dos asuma el rol de Distribuidor.

Mi experiencia me dice que la mejor combinación es que el Publicador sólo se encargue de publicar y el Suscriptor se encargue también de ser el Distribuidor. Ya que la tarea de Distribuir sobrecarga en exceso la máquina que desempeña esta tarea. (El caso Nº 2 que se muestra en la figura mas abajo)

En este enlace se detallan los Pasos a seguir para hacer una replicación transaccional.
  

Conceptos a tener en cuenta:

La replicación de datos consiste en el transporte de datos entre dos o más servidores, permitiendo que ciertos datos de la base de datos estén almacenados en más de un sitio, y así aumentar la disponibilidad de los datos y mejorar el rendimiento de las consultas globales. El modelo de replicación está formado por: publicador, distribuidor, suscriptor, publicación, artículo y suscripción; y varios agentes responsabilizados de copiar los datos entre el publicador y el suscriptor. A los tipos básicos de replicación (de instantáneas, transaccional y de mezcla), se le incorporan opciones para ajustarse aún más a los requerimientos del usuario.

 

 

La replicación de datos permite que ciertos datos de la base de datos sean almacenados en más de un sitio, y su principal utilidad es que permite aumentar la disponibilidad de los datos y mejora el funcionamiento de las consultas globales a la base de datos.  [Elm00]

La replicación en SQL Server consiste, en el transporte de datos entre dos o más instancias de servidores. Para ello SQL Server brinda un conjunto de soluciones que permite copiar, distribuir y posiblemente modificar datos de toda la organización. Se incluyen, además, varios métodos y opciones para el diseño, implementación, supervisión y administración de la replicación, que le ofrecen la funcionalidad y flexibilidad necesarias para distribuir datos y mantener su coherencia [Mic01].

En la replicación se utiliza una metáfora de la industria de la publicación para representar los componentes y procesos de una topología de replicación. De esta forma el modelo se compone, básicamente, de los siguientes elementos: publicador, distribuidor, suscriptores, publicaciones, artículos y suscripciones [Mic01].

 

 

Para representar los componentes y procesos de una topología de replicación se utilizan metáforas de la industria de la publicación. El modelo se compone de los siguientes objetos: el publicador, el distribuidor, el suscriptor, la publicación, el artículo y la suscripción; así como de varios agentes, que son  los procesos responsabilizados de copiar los datos entre el publicador y el suscriptor. Estos agentes son: agente de instantáneas, agente de distribución, agente del lector del registro, agente del lector de cola y agente de mezcla [Mic01].

La replicación de datos es un asunto exclusivamente entre servidores de datos, en nuestro caso hablamos de servidores SQL Server. Los servidores SQL Server pueden desempeñar uno o varios de los siguientes roles: publicador, distribuidor o suscriptor.

El publicador es un servidor que pone los datos a disposición de otros servidores para poder replicarlos. El distribuidor es un servidor que aloja la base de datos de distribución y almacena los datos históricos, transacciones y metadatos. Los suscriptores reciben los datos replicados.

es un conjunto de artículos (este concepto: “artículo de una publicación”, es diferente del concepto “artículo o registro de una base de datos”, como explicaremos más adelante) de una base de datos. Esta agrupación de varios artículos facilita especificar un conjunto de datos relacionados lógicamente y los objetos de bases de datos que desea replicar conjuntamente. Un artículo de una publicación puede ser una tabla de datos la cual puede contar con todas las filas o algunas (filtrado horizontal) y simultaneamente contar de todas las columnas o algunas (filtrado vertical), un procedimiento almacenado, una definición de vista, la ejecución de un procedimiento almacenado, una vista, una vista indizada o una función definida por el usuario.

Una suscripción es una petición de copia de datos o de objetos de base de datos para replicar. Una suscripción define qué publicación se recibirá, dónde y cuándo.  Las suscripciones pueden ser de inserción o de extracción; y una publicación puede admitir una combinación de suscripciones de inserción y extracción. El publicador (en las suscripciones de inserción) o el suscriptor (en las suscripciones de extracción) solicita la sincronización o distribución de datos de una suscripción.

El publicador puede disponer de una o más publicaciones, de las cuales los suscriptores se suscriben a las publicaciones que necesitan, nunca a artículos individuales de una publicación.  El publicador, además, detecta qué datos han cambiado durante la replicación transaccional y mantiene información acerca de todas las publicaciones del sitio. 

varía según la metodología de replicación implementada. En ocasiones se configura como distribuidor el mismo publicador y se le denomina distribuidor local. En el resto de los casos el distribuidor será remoto, pudiendo coincidir en algún caso con un suscriptor.

 Los suscriptores además de obtener sus suscripciones, en dependencia del tipo y opciones de replicación elegidas, puede devolver datos modificados al publicador. Además puede tener sus propias publicaciones [Mic01].

 

 

En una solución de replicación pudiera ser necesario utilizar varias publicaciones en una combinación de metodologías y opciones. En la replicación los datos o transacciones fluyen del publicador al suscriptor pasando por el distribuidor.

Por lo tanto en su configuración mínima una topología de replicación se compone de al menos dos o tres servidores SQL Server que desempeñan los tres roles mencionados.

 

Variando la ubicación del servidor distribuidor podríamos contar con las siguientes variantes:

1.       El rol de distribuidor desempeñado por el publicador (Fig. 1.1).

2.       El rol de distribuidor desempeñado por el suscriptor (Fig. 1.2)

3.       Un servidor de distribución, independiente del publicador y del suscriptor (Fig. 1.3)

sql             

Fig.1 Publicador-Distribuidor      Fig.2 Distribuidor-Suscriptor       Fig. 3 Distribuidor independiente

 

En la mayoría de las configuraciones, el peso fundamental de la replicación recae, sobre el servidor de distribución. Por tanto éste puede ser un criterio para determinar su ubicación, teniendo en cuenta las configuraciones (posibilidades físicas) de los servidores, así como otras responsabilidades que pueden estar desempeñando (servidor de dominio, servidor de páginas web entre otras) [Mic01].

3. Tipos de replicación

 

Los tipos básicos de replicación son:

·         replicación de instantáneas

·         replicación transaccional

·         replicación de mezcla

Para ajustarse aún más a los requerimientos de los usuarios se incorporan opciones como son la actualización inmediata en el suscriptor, la actualización en cola y la transformación de datos replicados [Mic01].

En la replicación de instantáneas los datos se copian tal y como aparecen exactamente en un momento determinado. Por consiguiente, no requiere un control continuo de los cambios. Las publicaciones de instantáneas se suelen replicar con menos frecuencia que otros tipos de publicaciones. Puede llevar más tiempo propagar las modificaciones de datos a los suscriptores. Se recomienda utilizar: cuando la mayoría de los datos no cambian con frecuencia; se replican pequeñas cantidades de datos; los sitios con frecuencia están desconectados y es aceptable un periodo de latencia largo (la cantidad de tiempo que transcurre entre la actualización de los datos en un sitio y en otro). En ocasiones se hace necesario utilizarla cuando están involucrados algunos tipos de datos (text, ntext, e image) cuyas modificaciones no se registran en el registro de transacciones y por tanto no se pueden replicar utilizando la metodología de replicación transaccional.

Los servidores OLAP son candidatos a la replicación de instantáneas. Las consultas ad-hoc que aplican los administradores de sistemas de información son generalmente de solo lectura y los datos con antigüedad de horas o días no afectan sus consultas. Por ejemplo un departamento desea hacer una investigación sobre demografía de los artículos vendidos hace dos meses. La información de la semana pasada no afectará sus consultas; además el departamento no está planeando hacer cambio en los datos, solo necesita el almacén de datos. Hay que destacar además que cuando están involucrados algunos tipos de datos (text, ntext, e image) cuyas modificaciones no se registran en el registro de transacciones [Mic01] y por lo tanto es necesario transportar estos datos del publicador al suscriptor para lo cual es necesario utilizar la replicación de instantáneas, al menos como una solución parcial.

Con la opción de actualización inmediata en el suscriptor se permite a los suscriptores actualizar datos solamente si el publicador los va a aceptar inmediatamente. Si el publicador los acepta, se propagan a otros suscriptores. El suscriptor debe estar conectado de forma estable y continua al publicador para poder realizar cambios en el suscriptor. Esta opción es útil en escenarios en los que tienen lugar unas cuantas modificaciones ocasionales en los servidores suscriptor.

En este caso se propaga una instantánea inicial de datos a los suscriptores, y después, cuando se efectúan las modificaciones en el publicador, las transacciones individuales se propagan a los suscriptores.  SQL Server 2000 almacena las transacciones que afectan a los objetos replicados y propaga esos cambios a los suscriptores de forma continua o a intervalos programados. Al finalizar la propagación de los cambios, todos los suscriptores tendrán los mismos valores que el publicador.  Suele utilizarse cuando: se desea que las modificaciones de datos se propaguen a los suscriptores, normalmente pocos segundos después de producirse; se necesita que las transacciones sean atómicas, que se apliquen todas o ninguna al suscriptor; los suscriptores se conectan en su mayoría al publicador; su aplicación no puede permitir un periodo de latencia largo para los suscriptores que reciban cambios.

Es útil en escenarios en los que los suscriptores pueden tratar a sus datos como de sólo lectura, pere necesitan cambios a los datos con una cantidad mínima de latencia. Ejemplo: un sistema para el procesamiento y distribución de pedidos. En este tipo de escenario, podría tener varios publicadores recibiendo pedidos de mercancías. Estos pedidos se replican entonces a un almacén central donde se despachan los pedidos. El almacén puede tratar los datos como de sólo lectura y requiere nueva información en forma periódica.

Con el uso de la opción de atualización inmediata en el suscriptor se pierde aún más la autonomía de sitio, pero se reduce el tiempo en el cual los sitios actualizan sus copias de los datos. Para hacer modificaciones en la base de datos del suscriptor éstas se realizan (o intentan) también en la base de datos publicador en una confirmación de dos fases (2PC) por lo que si su modificación se confirma indica que es válida y luego en cuestión de minutos, o según la planificación hecha, estos cambios son duplicados a las demás bases de datos suscriptoras.

3.3 Replicación de mezcla

Permite que varios sitios funcionen en línea o desconectados de manera autónoma, y mezclar más adelante las modificaciones de datos realizadas en un resultado único y uniforme. La instantánea inicial se aplica a los suscriptores; a continuación SQL Server 2000 hace un seguimiento de los cambios realizados en los datos publicados en el publicador y en los suscriptores. Los datos se sincronizan entre los servidores a una hora programada o a petición. Las actualizaciones se realizan de manera independiente, sin protocolo de confirmación, en más de un servidor, así el publicador o más de un suscriptor pueden haber actualizado los mismos datos. Por lo tanto, pueden producirse conflictos al mezclar las modificaciones de datos. Cuando se produce un conflicto, el Agente de mezcla invoca una resolución para determinar qué datos se aceptarán y se propagarán a otros sitios. Es útil cuando: varios suscriptores necesitan actualizar datos en diferentes ocasiones y propagar los cambios al publicador y a otros suscriptores; los suscriptores necesitan recibir datos, realizar cambios sin conexión y sincronizar más adelante los cambios con el publicador y otros suscriptores; el requisito de periodo de latencia de la aplicación es largo o corto; la autonomía del sitio es un factor crucial.

Es útil en ambientes en los que cada sitio hacen cambios solamente en sus datos pero que necesitan tener la información de los otros sitios. Por ejemplo podría crearse una base de datos que registre la historia delictiva de individuos. En cada municipio de Villa Clara, se puede tener una copia de la base de datos de toda la provincia y no se requiere estar conectado permanentemente a la base de datos de la instancia provincial.

 

 

En la elección de un método adecuado para la distribución de los datos en una organización influyen varios factores. Los cuales podemos agruparlos en dos grupos: factores relacionados con los requerimientos de la aplicación y factores relacionados con el entorno de red.

Dentro de los factores relacionados con los requerimientos de la aplicación, los fundamentales son  [Gar99]:

·         Autonomía

·         Consistencia transaccional

·         Latencia

La autonomía de un sitio da la medida de cuanto puede operar el sitio desconectado de la base de datos publicadora. La consistencia transaccional de un sitio viene dado por la necesidad de ejecutar o no inmediatamente todas las transacciones que se han ejecutado en el servidor, o si es suficiente con respetar el orden de las mismas. La latencia de un sitio se refiere al momento en que se deben de sincronizar las copias de los datos. ¿Necesitan los datos estar el 100% en sincronía? O si es admisible determinada latencia ¿de qué tamaño es aceptable el rezago? [Gar99].

Entre los factores relacionados con el entorno de red están la velocidad de transmisión de datos de la red, deben considerarse preguntas como ¿Cómo luce la red? ¿Es rápida? Debe analizarse además la confiabilidad de la red y responder preguntas como ¿Cuán confiable es la red? Por otra parte en el caso que los servidores SQL no permanezcan todo el día encendidos, como pudiera suceder en algunas organizaciones, deben considerarse los horarios de disponibilidad de cada servidor.

 

 

A pesar de que existen varias formas de implementar y supervisar la replicación, y el proceso de replicación es diferente según el tipo y las opciones elegidas, en general, la replicación se compone de las siguientes fases:

  • configuración de la replicación
  • generación y aplicación de la instantánea inicial
  • modificación de los datos replicados
  • sincronización y propagación de los datos.

 

finales

 

La replicación es muy útil para mejorar la disponibilidad de datos, lo cual pudiera llevarse al caso extremo, conocido como bases de datos distribuidas replicadas totalmente, en el cual consiste en la replicación de la base de datos completa en cada sitio en el sistema distribuido y garantiza notablemente la disponibilidad de datos, pues el sistema puede continuar operando cuando exista en servicio al menos uno de los servidores SQL Server. La desventaja es un alto costo para mantener la consistencia de las copias en cada sitio.

Aut: Daniel Eduardo Castro Morell

 

About these ads

Responses

  1. Un material exelente, me ayudo bastante con todos los incovenientes que tenia…..gracias

  2. me pareció bueísimo y bastante útil, me toca aplicar esto en un cliente y te comentaré como me fué y si tengo alguna duda espero me puedas ayudar a disiparla.

    saludos

    Mario Albuja
    Ecuador

  3. Buena esta la teoria pero como se aplica eso?
    Talvez podrias poner un ejemplo practico de replicacion de mezcla te lo agradeceria….

  4. Haz realizado una replicación entre un sql-2000 hacia un sql-2005 ???, es factible ó por diferencia de versión no es posible???, te agradeceria me aclaras esta duda para ver otra opción en vez de la replicación para actualizar un respaldo que saco del 2000 y lo subo en el 2005, muchas gracias.
    Federico Rossi

  5. Hola Federico.
    En principio no has de tener ningún problema en realizar una replicaión entre diferentes versiones.
    Sobre todo si el distribuidr es el SQL 2005.
    Para aclararte cualquier duda puedes consultar este enlace http://msdn.microsoft.com/es-es/library/ms143241(SQL.90).aspx

  6. Hola buenicimo, pero me puedes ayudar con oracle

  7. Hace unos años trabajé con Bases de Datos Oracle, pero sólo a nivel de programación y no de administración.

  8. Una pregunta: En un lugar fisico tengo una maquina (1) que funciona como publicador A, una maquina (2) como distribuidor A y en otra provincia una maquina (3) que es el suscriptor A. Luego intento crear en la maquina (3) una publicacion B sobre la misma base de datos, con una maquina (4) como distribuidor B y poner como suscriptor B a la maquina (1). el problema es que cuando actualizo un dato en 1 pasa lo mas bien a 3 pero quiere volver a 1 como si halla hubiese sido generado. Yo necesito que de 3 hacia 1 solo viajen los datos generados en 3 y no los actualizados desde 1. aclaro que la base es la misma y las tablas que se actualizan tambien. Desde ya muchas gracias

  9. Buenos días, ayuda !!!!
    Quiero hacer una replicación transaccional.
    Tengo 2 servidores con Windows 2003 Server SP 1 y SQL 2000 Service Pack 4 en ambos.
    Hago todo el proceso de la publicación y suscripción no marca ningún error, pero los procedimeintos de Inser, Delete y Update no se generan en el servidor de suscripción, en ambos servidores tengo los datos (misma base de datos) a la hora de marcar si quiero transferir los datos y esquema le digo que no.
    Si lo hago con datos y esquema si lo hace, pero no quiero hacer eso porque la base es muy grande.

    Me pueden ayudar por favor

  10. Hola David.
    Me podrias ayudar, tengo la siguiente situacion: tengo que realizar una replicacion entre dos puntos distintos que no se encuentran en la LAN, necesito que la repolicacion sea por la Internet, cada punto tiene una IP publica. No se como realizar una replicacion entre este dos puntos.
    Me podrias ayudar por favor.

  11. Nunca me ha tocado hacer algo así pero al parecer el único inconveniente es como ver desde cada punto el otro servidor.
    Para eso tendrás que abrir los puertos correspondientes en cada sede, en sus firewall o lo que tengas montado.
    Recuerda que a la hora de mapear el puerto que usa SQL es el 1433.
    Un saludo


Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Categorías

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: