Replicacion en SQL 2008

Implementado Replicacion

Contenido

Lección 1: Visión general de la replicación

Lección 2: La replicación transaccional

Lección 3: La réplica de mezcla

Leccion 1

1. Los componentes de réplica
2. funciones de replicación
3. topologías de replicación
4. Agentes de replicación
5. perfiles de agente
6. Métodos de replicación
7. datos de conflictos
8. Prácticas

Ques es?

• La replicación está diseñado como un mecanismo de distribución de datos.
• El motor de replicación núcleo está diseñado para su aplicación muy flexible
• La arquitectura de la base se puede utilizar para proporcionar la disponibilidad de una base de datos ya que una copia redundante de los datos se mantienen en sincronización con una copia maestra

Componentes

artículos

• El bloque de construcción básico de la replicación
• Se puede definir en una tabla, vista, procedimiento almacenado o función

Publicaciones

• Las publicaciones son agrupaciones de artículos que definen el conjunto de replicación

Filtros

• Se puede aplicar uno o más filtros para cada artículo que restringir el conjunto de datos que se replican.
• Puedes filtrar los artículos por filas o por columnas.

Tipos de Filtros

estático

• Un ejemplo en el que Estado = 'TX'

dinámica

• Disponible sólo con la réplica de mezcla
• Durante el proceso de sincronización, el filtro se calcula ("WHERE UserName = suser_sname ()")

JOIN

• Disponible sólo en la réplica de mezcla
• Le permite filtrar una tabla basada en la relación con una tabla padre

Roles en la Replicacion

Publisher

• Mantiene la copia maestra de los datos dentro de una arquitectura de replicación

suscriptor

• Es la base de datos que está recibiendo cambios desde el motor de replicación definida por la publicación a la que se está suscribiendo

distribuidor

• Es el motor principal dentro de una arquitectura de replicación
• La base de datos de distribución se almacena en el ejemplo que está configurado como distribuidor (una instancia de SQL).

Topologias de Replicacion

Publicador Centralizado

Una topología editor central consta de un único editor que tiene uno o más abonados.

El editor central contiene la copia maestra de los datos y se utiliza para configurar la arquitectura de replicación. En esta topología, los cambios de datos generalmente se presentan en una única fuente,

el editor, y bajar hasta uno o más suscriptores 

Suscriptor Centralizado

Una topología de suscriptor central consta de un solo suscriptor que tiene más de un editor.

Los cambios se escriben en varias editoriales y luego consolidarse en un solo suscriptor. Una topología de suscriptor central se utiliza normalmente para la consolidación de múltiples bases de datos o como una base de datos central de informe.

Otro

Topología bidireccional. Dos editores centrales apilados juntos.

Otros dos "topologías" incluye un editor central con un distribuidor remoto y un suscriptor central con un distribuidor remoto.

Agentes de Replicacion

instantánea

Este agente es responsable de extraer el esquema y los datos que necesitan ser enviados del editor al suscriptor.

Lector de transacciones
Se utiliza para extraer las transacciones confirmadas desde el registro de transacciones en la editorial que deben ser replicados.

distribución

Tiene dos funciones: la aplicación de instantáneas y envío de transacciones

Merge

Se aplica la instantánea generada, cuando el abonado se inicializa

Las operaciones de cambio entre el editor y el suscriptor

De lectura de cola

Es responsable de la transferencia de la cola en el suscriptor al publicador.

• Snapshot.exe se utiliza en instantáneas, transaccional y la replicación de mezcla.
• El Agente de registro del LOG, logread.exe, sólo se utiliza en la replicación transaccional.
• El Agente de distribución, distrib.exe, se usa con réplica de instantáneas y transaccional.
• El Agente de Merge, replmerg.exe, se utiliza en la replicación de mezcla
• El Agente de lectura de cola, qrdrsvc.exe, se utiliza sólo cuando la opción de actualización en cola para la replicación transaccional o de instantáneas ha sido habilitada. se utiliza en la replicación de mezcla.

Perfiles del agente

Cada agente de replicación tiene numerosos parámetros de configuración que afectan su comportamiento. Las 12 opciones más comunes se combinan juntos en una unidad llamada un perfil de agente (Agente de Perfiles).

intervalo de sondeo

Controla la frecuencia con la que el agente comprueba si hay nuevas operaciones para replicar. El valor predeterminado es cinco segundos.

tiempo de espera de consulta

Controla el tiempo que el agente espera para una consulta en completarse. El valor predeterminado es de 1.800 segundos.

Login tiempo de espera

Controla el tiempo que el agente espera una conexión a ser creado. El valor predeterminado es 15 segundos.

Metodos de replicacion

Replicacion por instantanea
No se utiliza normalmente para la alta disponibilidad
1. Agente de instantáneas extrae el esquema y los datos BCPs

2. Agente de distribución recoge y aplica la instantánea a cada abonado (tablas se quita y se vuelve a crear, a continuación, los datos se copian utilizando BCP)

Sustitución completa de los datos

Replicacion Transaccional
Comienza con una instantánea inicial se aplica al abonado para asegurar que las dos bases de datos se sincronizan

Como las transacciones posteriores se emiten contra el editor, el motor de replicación de las aplica al suscriptor.

• Configurar la replicación transaccional (modos)
1. suscriptores de actualización inmediata
2. suscriptores de actualización en cola
• Dos arquitecturas alternativas
1. replicación transaccional bidireccional
2. peer-to-peer replicación transaccional

Replicacion de Merge
La replicación de mezcla está diseñada principalmente para móviles, procesamiento desconectado

Instantánea inicial, se aplica al abonado para asegurar que se sincronice y entonces cambios posteriores son enviados al abonado

La replicación de mezcla está diseñada para permitir cambios a realizar tanto en el publicador y el suscriptor de forma predeterminada.

El motor de mezcla entonces todos los cambios de los intercambios entre el editor y el suscriptor durante cada ciclo del agente.

CICLO DE UN AGENTE

La replicación puede ser configurado para ejecutarse tanto en un continuo o en un modo programado. En un modo programado, el agente de replicación se ejecuta sobre una base periódica. Cuando se configura en un modo continuo, el motor de replicación está funcionando constantemente. En cualquier caso, el motor de replicación siempre se ejecuta en un ciclo de determinar si existen cambios se repliquen, moviendo los cambios para el abonado, y entonces el acuse de recibo de los cambios. Este proceso es referido como un ciclo del agente de replicación. En un modo programado, el ciclo de un agente es más evidente debido a que el agente se inicia, efectúa un trabajo, y luego se apaga. El ciclo es menos evidente en el modo continuo, porque nunca el agente se apaga, pero en lugar de que comience otro ciclo tan pronto como el anterior se haya completado. El ciclo de un agente es un concepto muy importante para la comprensión de una variedad de escenarios que pueden ocurrir las más importantes de las cuales son los conflictos de datos.

Conflictos con los Datos

Conflictos de datos sólo se producen entre los ciclos del agente de replicación.

Conflictos de datos sólo se producen con:

• la réplica de mezcla
• transacción replicación con suscriptores de actualización en cola
• replicación transaccional bidireccional
• peer-to-peer replicación transaccional

Dado que los cambios pueden ser procesados ​​en el publicador y el suscriptor

 

Tipos de Conflictos

1. La inserción de una copia de la llave primaria, que ocurre cuando dos usuarios introducir la misma clave principal en el publicador y el suscriptor
2. Una actualización de conflicto, que se produce cuando dos usuarios modifican la misma fila en el publicador y el suscriptor
3. Una actualización de una fila inexistente, lo que ocurre cuando un usuario actualiza una fila en un lado de la arquitectura de replicación y otro usuario elimina la fila mismo en el otro lado.

Resolucion de Conflictos

El componente que realiza la resolución de conflictos que se conoce como una resolución de conflictos.

Los dos más comunes:

• El editor siempre gana
• El cambio en el editor anula el cambio en el suscriptor
• El suscriptor siempre gana
• El cambio que se realizó en el suscriptor anula el cambio introducido en el editor

• Conflictos de datos es una situación que debe ser detectada y resuelta por el motor de replicación para mantener una sola copia coherente de los datos a través de la arquitectura.
• Si la base de datos se coloca en el simple o Registro masivo modelo de recuperación y cualquiera de estas operaciones se ejecuta el motor de replicación no puede recoger los cambios porque la replicación transaccional se basa en transacciones en el registro de transacciones, y la réplica de mezcla depende de factores desencadenantes.

 Replicacion Transaccional

Seguimiento de los cambios

El Agente de registro del LOG se encarga de mover los cambios del registro de transacciones en el editor de la base de datos de distribución.

Agente de registro del lector

  Pasos durante cada ciclo

1. Se conecta a la base de datos de distribución y recupera la marca de agua de replicación, el número de secuencia registro anterior (LSN) durante el ciclo anterior, de la tabla MSlogreader_history.
2. Se conecta al registro de transacciones de la editorial y localiza el LSN pasado.
3. Se empieza a leer desde el LSN siguiente hacia adelante en el registro hasta que alcanza la transacción más antigua abierta.
4. Se escribe transacciones en la base de datos de distribución en los MSrepl_commands y mesa MSrepl_transactions, asegurando que todas las transacciones se secuenció en exactamente el mismo orden en que se hayan cometido en el editor.
5. Avanza la replicación de marca de agua en la mesa MSlogreader_history.
6. Se establece el indicador replicado en el registro de transacciones para cada transacción que se ha escrito correctamente en la distribución.
7. Se registra la información de error y la historia a la base de datos de distribución.

El Agente de distribución se encarga de mover los lotes de los cambios de la base de datos de distribución para cada suscriptor.

1. Recupera la última operación aplicada (base de datos de distribución)
2. Reúne todas las transacciones pendientes para un abonado
3. Paquetes de las transacciones en lotes
4. Se aplica cada lote de transacciones en suscriptor
5. Actualiza la entrada en el _Historia Msdistribution (LSN)
6. Registra la información de error y la historia a la base de datos de distribución

LIMPIEZA DE LA BASE DE DATOS DE DISTRIBUCIÓN

El Agente de distribución no se refiere directamente a limpiar las entradas de la base de datos de distribución que se han escrito correctamente a todos los suscriptores. Un trabajo independiente (conocido como el agente de limpieza) se ejecuta de forma periódica para eliminar las transacciones que han sido enviados a todos los suscriptores.

Impacto en la Base de Datos

Debido a que el motor de replicación garantiza que las transacciones escritas para el editor son recibidos por un abonado.

Si SQL Server permite la parte inactiva del registro que eliminar antes el Agente de registro del LOG podría escribir las transacciones a la base de datos de distribución, las transacciones podrían perderse.

Una segunda opción está habilitada dentro de un registro diario de las transacciones.

Una transacción no se elimina de la base de datos de distribución hasta que se ha grabado correctamente a cada abonado

Si su base de datos está en el modelo de recuperación simple, la parte inactiva del registro se elimina en cada punto de control.

Actualización inmediata Suscriptor Opción

1. La aplicación emite la transacción en el suscriptor
2. El gatillo se dispara
3. Los desencadenantes se alista el Coordinador de transacciones distribuidas de Microsoft (MS DTC) para conectar con el editor y volver a emitir la transacción
4. La transacción se confirma en el editor
5. El gatillo se compromete en el abonado.
6. La transacción se confirma en el suscriptor

Una columna de marca de tiempo se requiere en cada tabla que está participando en la replicación

La cuestión principal en arquitecturas de alta disponibilidad con suscriptores de actualización inmediata es que los cambios se deben aplicar a la editorial.

Si el editor no está disponible, la transacción distribuida falla, es una opción incompatible replicación para alta disponibilidad

En cola suscriptor Actualización Opción

1. La aplicación emite una transacción.
2. El gatillo se dispara.
3. El disparador registra la transacción en una cola (una tabla dentro de la base de datos).
4. El disparador comete.
5. La transacción se confirma.

El Agente de lectura de cola periódicamente transfiere la cola de nuevo a la editorial y todos los temas de las transacciones.

Esto requiere una columna de marca de tiempo sobre la mesa.

La ventaja de la opción de suscriptor de actualización en cola es que cuando el editor está de nuevo en línea, todos los cambios que se produjeron en el suscriptor durante el corte puede ser enviado a la editorial automáticamente.

Usted puede confi gurar una publicación transaccional con suscriptores de actualización inmediata tanto y actualización en cola opciones de suscriptor. La opción de suscriptor de actualización en cola puede ser usado como un mecanismo de conmutación por error cuando el editor no está disponible.

Arquitectura Transaccional

Punto a Punto

La arquitectura básica es permitir a re transaccional

La idea básica es que usted puede tomar un conjunto de tablas y replicarlos de Database1 a Database2 utilizando replicationplication transaccional para mover datos entre dos o más de sus compañeros

• Cada punto, debe tener su propia distribuidora
• La estructura de la tabla debe ser exactamente el mismo
• Actualización en cola y las opciones de actualización inmediatas no están disponibles
• Conflictos de datos puede ocurrir. 

Bidireccional

• Las estructuras de la tabla puede ser diferente
• Implementar mediante código
• Conflictos de datos no se manejan
• Usted no necesita un distribuidor independiente para cada editor

Monitoreo

Obtener estadísticas sobre el estado de funcionamiento de todas las publicaciones, suscripciones y agentes.

Ver error y la información del historial de estado.

Testigos de seguimiento también se introdujeron para proporcionar más detalles

Proporciona estadísticas de tiempo:

• Mueva el testigo a la base de datos de distribución
• La latencia de un editor para cada suscriptor

validación

Garantías de que las transacciones se mueven del editor al suscriptor en el mismo orden en que fueron cometidos originalmente

Un mecanismo para validar la sincronización:

• sp_publication_validation
• sp_article_validation (implícito)

El uso de dos métodos diferentes:

• Recuento de filas sólo
• Recuento de filas y suma de comprobación binaria

Replicacion Merge

Que es?
La replicación de mezcla es otra alternativa que se puede aplicar a sistemas de alta disponibilidad.
La replicación de mezcla fue diseñado principalmente para usuarios móviles, desconectados.
Por definición, los mecanismos ya están construidas en los cambios se produzcan en cualquier lugar y se sincronizan, así como para ser capaz de resistir fallos y continuar procesando

Proceso de Seguimiento

1. La aplicación emite una transacción.
2. El detonante detrás de la mesa se ​​dispara.
3. Una inserción o actualización se registra en MSmerge_contents, mientras que un delete se registra en MSmerge_tombstone.
4. El disparador comete.
5. La transacción se confirma.

Cada vez que el motor de mezcla se ejecuta, se hace una petición básica de la compañía editora y abonado (manda lo Que No Tenga mueve sólo los cambios que aún no existen).
Cuando se aplica un cambio, se elimina desde el motor de replicación.
Las tablas de metadatos de mezcla se encuentran en la misma base de datos como los artículos que se publican. Por lo tanto, cuando usted copia de seguridad de la base de datos, copia de seguridad de los metadatos de mezcla al mismo tiempo.
El motor de mezcla utiliza los metadatos para determinar los cambios que se deben aplicar. Debido a que tanto editor y el suscriptor mantener un historial completo de todos los cambios y los metadatos se almacenan en la misma base de datos que participan en la replicación, backup / restablecimiento de los procesos de mantener los metadatos sincronizados con los datos que se replican. Esto asegura que el motor de fusión se pueden recuperar, incluso de una operación de restauración y volver a sincronizar de forma incremental en sí.

validación

La validación se puede ejecutar en dos modos diferentes:

• Recuento de filas sólo
• recuento de filas, más una suma de comprobación.

Ejecutar sp_validatemergepublication para validar una publicación completa

sp_validatemergesubscription para validar un solo suscriptor

O añada la opción - Validar opción para el Agente de mezcla.