Implementación de replicas instantáneas, de combinación y transaccionales en SQL Server 2005 Volumen II

Mis queridos amiguitos amarillos, ha llegado el momento de la verdad, el momento en el que vais a tener que trabajar como chinos, en virtud de ese cliente pelmazo que no para de dar el cacorrio con que sus datos son lo mas importante del mundo mundial. Algo habrá que hacer para que deje de dar la murga y por fin ha llegado el momento de la verdad, lo que los gungans llamaban “la hora del dolor”.

Pero no todo tiene que ser necesariamente malo en las oscuras tierras de Microsoft, donde se extienden las sombras -"Atrás!! llama de Udûn!!!"-, de modo que para traer un poco de claridad al proceloso mundo de las réplicas en SQL Server vamos a elegir un disco de Chill Out que sonará a un volumen moderadamente moderado en vuestros altavoces, al tiempo que le dais a la tecla con alegría y desparpajo. Nunca antes existió cirujano escuchando chill mientras extirpaba un tumor, pero vosotros si que podéis escuchar algo bueno mientras tecleáis; es por ello que vosotros no os coméis los mocos con vuestro suelducho de mileurista mientras que ellos se ponen morados a bogavante, que coge por detrás, te coge por delante.

Bien, el disco va a ser "Café del Mar – Dreams Vol 2", se indica como requisito para poder llevar a buen puerto esta instalación. Si algo falla es q no estáis escuchando el disco correcto.

Para empezar con buen pinrrelillo vamos a partir de una instalación límpida, que consistirá en:

• 2 máquinas Windows 2003 R2 SP2 32 bits que llamaremos diligentemente “Nodo1” y “Nodo2”.
• Nodo1 será el DC principal del dominio y Nodo2 el DC secundario. No trataré aquí cómo montar un dominio porque no es el objetivo, y además hoy en día es insultantemente facil montar lo que otrora era un PDC y un BDC (ahhh que tiempos los del NT 3.5 mas… horrorosos!!) .
• Comprobar que está instalado IIS en ambas máquinas al completo.
• Iniciar ambas máquinas con la cuenta de administrador de dominio e instalar SQL Server 2005 al completo. Las opciones por defecto serán mas que válidas por el momento.

No es necesario que las máquinas sean iguales en lo tocante a hardware ya que en este tipo de entorno todo se resuelve por soft (a diferencia del modo Cluster) si bien yo os recomendaría que para hacer esta prueba os montarais un par de VMwares antes que usar dos máquinas físicas, por comodidad mas que nada (a los efectos da exactamente igual). Apunto aquí una nota mental para un posterior articulo sobre hypervisors, que la cosa esta que hecha chispas en este sector.

Una vez llegados a en este punto no faltarán los que se empiecen a revolver en su silla: “porque un dominio?”, “porque instalaciones completas?” etc. Bueno, yo diría que porque sí y te jodes, pero la verdad es que la cosa no funciona si todas las máquinas que van a participar en la réplica no están metidas en el mismo dominio. Domino eh? no grupo de trabajo, dominio. Las instalaciones completas se hacen para minimizar errores, luego vosotros ya lo iréis puliendo una vez q lo tengáis en marcha. Al hilo de todo esto, solo se va a usar la cuenta de administrador para configurar las credenciales de los procesos necesarios, cosa que es un poco fea como todos sabemos. Un nivel mayor de control se deja al feliz informático que quiera hacer las cosas bien, que de esos hay pocos y se esconden; aqui solo se muestra la base del asunto de forma muy elemental.

Finalmente para quitarnos problemas con las políticas de seguridad del 2003 os recomiendo que configures una contraseña de 8 caracteres con números y mayúsculas para la cuenta de administrador, por si acaso.

 

Presentaciones

Llegados a este punto vamos a establecer como montaremos este primera escenario:

Nodo1

Sera el Publicador y el que tenga la base de datos a replicar, que llamaremos “origen”. La Publicación va a ser de tipo transaccional en un solo sentido (del Publicador al Suscriptor) aunque en el arranque le vamos a enchufar al Suscriptor una instantánea o snapshot fresca y completita.

Nodo2

Será el Suscriptor, va a aplicar la Publicación en la base de datos llamada “destino”. El porqué llamamos a las bases de datos de forma distinta es un poco por claridad pero en el fondo es tontería: imaginar que tenéis una aplicación que dispara contra la base de datos “origen”. Lo suyo seria que si el sistema se cae podre seguir atacando a “origen” pero en el esclavo, de modo que lo suyo seria llamar a las dos bases de datos igual aunque aqui como digo no se hará asi por claridad.

Además, el tercer rol, el del Distribuidor lo podremos colocar donde nos plazca pero nosotros lo haremos en el Suscriptor, para dejar mas libre al Publicador ya que se supone que es la máquina contra la que tiran los clientes normalmente. En este caso, si el Distribuidor está en el Suscriptor vamos a operar por el método “pull” o “polling” que como bien sabemos consiste en preguntar cada 2×3 al Publicador si hay cambios pendientes de aplicar. Poner el Distribuidor en el Publicador implica un esquema de tipo “push” en el que el Publicador “empuja” los datos al Suscriptor, algo en principio más óptimo a nivel general pero particularmente para el publicador mas costoso ya que tiene que ejecutar un proceso adicional, que es el del Distribuidor. Sobre pull vs push se podría hablar un poco más y en próximas entregas quizá se haga si os portáis bien y no dejáis nada en el plato.

Finalmente comentar que toda la configuración del percal se realiza a través del Microsoft SQL Server Management Studio, la herramientilla grafica basada en MMC que trae el SQL Server, y mas concretamente en la rama de “replicación”.

Hechas las presentaciones comienza el baile:

 

Prolegómenos

• Creamos una base de datos de prueba llamada Origen en Nodo1.
• Creamos una tabla de nombre “miTabla” con 2 campos de tipo nchar(10) que llamaremos Clave y Datos.
• El campo Clave será la clave primaria.

 

OJO: TODAS LAS TABLAS TIENEN QUE TENER CLAVE PRIMARIA!. Si la base de datos que queréis replicar no tuviera una clave primaria en TODAS las tablas se la añadís a manubrio. Si no lo hacéis el proceso de réplica casca y os iréis a casa taciturnos y cejijuntos, os lo digo ahora, luego no me vengáis con lloros y malas caras.

• Creamos la base de datos Destino vacía en Nodo2.

Ahora tenemos todo lo necesario para poder configurar la réplica. Hay que adelantar que el proceso puede resultar un poco confuso porque a pesar de que se nota que el interface gráfico tiene unas cuantas vueltas no es lo suficientemente claro. Por ejemplo no queda representado de forma gráfica el rol del Distribuidor y además la secuencia de pasos que hay q seguir no es del todo lógica (lo lógico seria configurar primero el Publicador y luego el resto pero hay que empezar por el Distribuidor, el rol mas “gris” de los 3).

 

Nodo2

Como nuestro Distribuidor va a estar en Nodo2 lo configuramos allí:

 

• Ahora tendremos que seguir el Wizard (que de Wizard no tiene mucho la verdad) rellenando los datos necesarios:

 

• Se nos pregunta donde va a ir el Distribuidor, por defecto se ilumina Nodo2 y asi que lo dejamos. Como hemos dicho antes el Distribuidor podría ponerse en otra máquina, que no será el caso.

 

• Aqui se nos pregunta el path donde reside el snapshot inicial. Ojo al dato que nos lo rellena con un path local tal y como viene en la figura, cosa que en este caso no aplica. Y porque no aplica? porque hemos quedado que en Nodo1 está el Publicador y en Nodo2 el Distribuidor asi que tenemos que decirle al Distribuidor que el snapshot no está en un path local sino remoto. Como se hace esto? facil: ponemos “\\nodo1\recurso_compartido”. No dejarse llevar por el pánico por el hecho de que todavía no hayamos creado el recurso compartido (ni sepamos a donde hay que apuntarlo) en Nodo1. Todo llegará a su debido tiempo mis pezqueñines.

 

• Ahora damos nombre a la base de datos de Distribución. Esta base de datos es de tipo System y nosotros no la tocaremos para nada. Yo la llamo “miDistribucion”.

 

• En esta pantalla se nos esta preguntando por los Publicadores (que todavía no tenemos) que usarán este Distribuidor. Por defecto viene Nodo2 pero eso no es correcto porque el Publicador hemos dicho que lo tenemos en Nodo1 asi que con el botón add lo añadimos y desactivamos nodo2, que de hecho no va a llevar Publicador.
• En la pantalla siguiente se nos pide una password que usara el Publicador cuando quiera realizar labores de administración sobre el Distribuidor. No se por qué no se usa una cuenta del dominio simplemente, cosas de Windows supongo. La cosa: poner la password y recordarla porque la tendréis que introducir en el Publicador cuando lo configuremos más adelante.
• Finalmente se nos ofrece la posibilidad de crear el Distribuidor o en su defecto solo generar la secuencia de comandos para poder nosotros lanzarlos a mano con posterioridad. Elegimos crear el Distribuidor ahora y finalizamos con lo que se nos presentará una pantalla resumen de las sabias elecciones tomadas en el proceso y luego una pantalla de progreso que deberá culminar en iconos verdes con un OK bien grande.

Llegados a este punto nada parece haber cambiado a simple vista en la MMC ya que no hay icono asociado al Distribuidor como decía, si bien se ha creado una base de datos de sistema llamada “miDistribucion” con lo que la cosa se supone va por su camino.

 

Nodo1

Pasamos al Nodo1.

 

• Creamos una nueva Publicación

 

• Se nos pregunta donde esta el Distribuidor, asi que le decimos que lo tenemos en Nodo2
• Rellenamos la password que introdujimos en Nodo2
• Elegimos la base de datos a replicar (“Origen”)

 

• Aqui elegimos el tipo de réplica que queremos: snapshots, transaccional, combinación etc. Elegimos una publicación transaccional, que nos permitirá además enviar un snapshot inicial como veremos a continuación.

• Elegimos los artículos a incluir en la Publicación: no nos liaremos en absoluto, añadimos la tabla completa de la base de datos Origen.
• Podemos filtrar los datos a Publicar: en el apartado anterior podíamos elegir columnas y tablas, aqui se nos deja construir una SELECT para cribar datos. Sin mas pasamos del tema.

• Ahora se nos interpela por el agente de snapshots: si queremos que genere un snaphost ahora mismo, y si queremos que los genere vía scheduler a horas determinadas (lo cual esta muy fresco porque como ya decíamos “ayer” al hacer un snapshot se bloquea para escritura y selectivamente la tabla que se está copiando, ergo es una opción guapa hacer snapshots a las 3 de la mañana, cuando solo curran los pelotas o los desesperados (o los jartos de coca, que también los hay). Nosotros como no somos ni lo juno ni lo jotro vamos a poner que genere un snapshot ahora mismo y listo.

• Ya para ir terminando se nos pregunta por las credenciales del Publicador para el agente de logs y de snapshots. Para ambos dos le vamos a dar la cuenta de admin del dominio, para que no falte de nada y estén contentos. Esto vuelve a ser una cagada y como tal hay que decirlo pero aqui lo vamos a dejar asi.
• Y como ya es costumbre se nos pregunta si queremos generar el Publicador ahora o mas tarde con unas secuencias de comandos (lo generamos ahora), presentándonos un bonito resumen de las elecciones tomadas, pidiéndonos nombre para la Publicación(yo he puesto “miPublicacion”) y unas alegres barritas de progreso iguales que las del Distribuidor, que también tiene que terminar el verde, color de la esperanza.

En este caso si que hay un cambio evidente en la MMC:

Chulo eh? bueno, que ya queda menos. Mejor dicho, ya no queda nada porque ahora terminamos con el Suscriptor, asi que volvemos a Nodo2

chsst! un momento ahí ! pensabas que se me iba a olvidar eh?? noooo!!: hay que hacer el recurso compartido! –ein? cual recurso?- Despierta hombre! si, el recurso compartido donde reside el snapshot claaaaaro que genera el Publicador y que recoge el Publicador. Bueno pues sencillamente se trata de compartir la carpeta donde reside el susodicho, que es:

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData\

Le dais un nombre coincidente con el que le disteis mas arriba en el Distribuidor y tira millas. Dar permisos de lectura y escritura a granel por cierto.

Nodo2 revisited

 

• Creamos la Suscripción

 

• Elegimos la Publicación ya creada en Nodo1

 

• Elegimos donde queremos ejecutar el Suscriptor, en el equipo que ejecuta el Distribuidor (Nodo2) o en el equipo que ejecuta el Publicador (Nodo1). Esta es la diferencia que mencionábamos antes: push vs pull. Lo dejamos en Nodo2.

 

• Elegimos base de datos de Suscripción. Esto es, el Publicador nos manda los datos y el Suscriptor los deja en una base de datos que nosotros hemos llamado Destino y es el efectivamente la base de datos replicada.

 

• El Suscriptor se tiene q conectar con el Distribuidor así que le enchufamos credenciales frescas de administrador.

 

• Igual que antes se nos pregunta por la periodicidad con la que el Suscriptor busca cambios. Nosotros le vamos a poner que constantemente. Esto se podría rebajar si no fuera necesario estar sincronizados al segundo y asi aligerar la carga de CPU y red primando el tamaño de las transferencias por encima del numero de ellas.
• Se nos pregunta si inicializamos ya mismo la Suscripción con un snapshot o lo vamos a hacer en la primera sincronización. Como hemos dejado el snapshot al crear el Publicador ya preparado le damos candela y le ponemos que ya mismo.
• Y lo de siempre: barras, verdes y parabienes, congratulations you are the best, gracias por confiar en Microsoft y toda la fanfarria y boato necesarios por haber seguido un wizard diligentemente. Estos se deben de creer que somos gilipollas o algo.

Y aqui termina la configuración porque ya es muy tarde y no da tiempo ni para recoger. La replica ahora tendria que funcionar a plena satisfacción, cosa que podeis comprobar si en Nodo1 metéis filas y veis en Nodo2 como se van añadiendo como por arte de birli birloque.

En la(s) próxima(s) entrega(s) vamos a configurar el Distribuidor en el Publicador, a montar una replica en las dos direcciones para el caso de que hagamos inserciones en el nodo2 (y evitar los errores que se dan si ahora mismo hacemos ahora inserciones en Nodo2), a hacernos un poco con la configuración modificándola y retorciéndola y a monitorizar el estado de la replica, reiniciándola y tal. Finalmente nos pondremos la pegata de “replicante” en el pecho al tiempo que disfrutamos con un par de tomas falsas o descartes.

Implementación de réplicas instantáneas, de combinación y transaccionales para SQL Server 2005 Volumen I

Un cliente coñón, con una empresa de 3 y el del tambor, que no puede vivir sin su preciada base de datos SQL Server pero que no quiere gastarse un puto duro ni en licencias ni en una solución decente (lo normal, lo de siempre, todo es importantisisisimo hasta que llega la factura), me ha obligado a empaparme un poco de la historia q voy a intentar relatar en una serie de articulillos, no mas de 3 espero, y mas de 1 (también lo espero).

El caso: tenemos una base de datos en SQL Server 2005 y queremos sincronizarla / replicarla para tener una copia de respaldo actualizada al momento por si un día peta por los aires poder trabajar sobre el backup hasta que sea remendada. Para ello necesitamos, a saber:

• Windows 2003 Server.
• SQL Server 2005.
• 2 equipos de corte servidor.
• Un buen par de huevos para entender todo este mondongo.

Aclaro que esto esta basado en un pseudo-libro llamado “SQL Server 2005 Manual del administrador” de Mc Graw Hill, obra y gracia del señor William R. Stanek al que no quito ningún merito ni crédito por no tener yo acceso a su obra original (como en la guerra, el valor se le supone). En su defecto tengo la edición española a cargo de un “traductor profesional” llamado Eloy Pineda Rojas que me gustaría tener presente para usar sus testículos como balón de futbol en toda regla y dejárselos como el apellido. Es un caso generalizado comprar libros en castellano pensando que los entenderás mejor que en su idioma origen, y es caso generalizado que el traductor, que no tiene ni puta idea de informática ni quiere tenerla, estropee totalmente lo que otrora fue un hermoso y bonito libro.

Hechas las presentaciones vamos a explicar la teoría, que no es mucha pero que el funesto libro dedica casi 20 hojas de paja, y que para que no os resulte lo mismo de indigesta que me resultó a mi leyendo la castaña ésta, la voy a intentar simplificar con un ejemplo/paralelismo usando a la industria editorial por fascículos, al mas puro estilo Planeta Agostini y a la sazón.

Roles

En el esquema general de un SQL Server replicado tenemos 3 roles principales, para que no falte de nada:

• Publicador.
• Distribuidor.
• Suscriptor.

De esta guisa tenemos que:

• Publicador: el que genera las copias del contenido. Es una empresa que se encarga de “fotocopiar” un original que ha escrito un señor anónimo, y lo hace miles miles miles de veces, para que el Distribuidor lo distribuya allende los mares. En este caso el Publicador es lo que se conoce como una Editorial: la empresa que determina qué es interesante fotocopiar y qué no lo es, es el que determina qué bases de datos van a ser replicadas, que objetos dentro de ellas etc y nos lo va a dejar preparadito para poder desperdigarlo a los 4 vientos. El Publicador puede ejecutarse en la misma máquina que lleva la base de datos de la que el cliente tira normalmente o en otra máquina aparte. Hay que decir que el proceso de publicación no es moco de pavo y carga la máquina notablemente. Por simplificar y dado que tenemos solo 2 equipos en el ejemplo practico que luego desarrollaré, irá en el que lleva la base de datos principal. Pero ojo amiguitos! no confundir el Publicador con el motor de base de datos ni con la base de datos en si misma!! no no y no! una cosa es la base de datos que usa nuestro querido cliente para sus cositas, con su motor de base de datos y tal, otra es el Publicador, que coge partes de esa base de datos para generar otra, igual o menor, que será la Publicación, y que se replicará en el Suscriptor. Nunca confundir, una Publicación es una base de datos subconjunto de la base de datos original, y la genera el Publicador. Coño.
• Distribuidor: el camionero que lleva la publicación al kiosco o a casa directamente. Un proceso que recoge las Publicaciones y las lleva a los Suscriptores.
• Suscriptor: el lector, que rellenó un panfleto en su día pensando que la colección iba a ser 20 fascículos y resulta que son 2 mil. En nuestro caso el Suscriptor es la base de datos donde vamos a replicar los datos que vienen del Publicador y nos son entregados por el Distribuidor.

Resumiendo un poco, el origen de los datos será el Publicador, el destino el Suscriptor y el agente que pasa datos de uno a otro es el Distribuidor. Haciendo una correspondencia con la terminología mas estándar de MySQL el Publicador vendría a ser mas o menos el Maestro y el Suscriptor el Esclavo. Es evidente que SQL Server parte de un modelo mas complejo que MySQL y por tanto mas flexible y potente, como iremos viendo poco a poco. Y es que ésta es la magia de las medias verdades: ambos motores soportan réplica pero es como comparar un 600 con un Ferrari.

Está claro que en este esquema puede haber muchos Publicadores, muchos Distribuidores y muchos Suscriptores pero por simplificar solo tendremos 1 de cada.

Mas cosas: La unidad mínima para la replica es el “articulo“. Es el fascículo en nuestra analogía editorial. Puede ser una tabla completa o partes de ella (filas, columnas, vistas, procedimientos almacenados). Un grupo de Artículos es una Publicación; por si no lo habías adivinado una base de datos completa a replicar podría ser  una Publicación (muchos artículos empaquetados).

Un esquema básico dividido en roles puede ser el siguiente:

 

 

Aquí tenemos una base de datos que actúa como maestro y 3 réplicas. Los roles son desperdigables en máquinas distintas para mejorar el rendimiento; de hecho el publicador por ejemplo es el mas indicado para separarlo del motor de base de datos ya que al poder generar publicaciones bastante configurables (no solo se limita a preparar bases de datos completas sino que puede operar solo con parte de ellas) puede demandar muchos recursos de CPU.

 

Réplicas

Pero que tipos de réplica hay? solo 3  a fe mía, 3 tipos que detallo a continuación:

• Replica de instantáneas: todo el churro completo. Todos los fascículos a cañón. Sale un fascículo nuevo y te los envían todos incluyendo el nuevo. Que no falte de nada. El Amazonas moribundo, y tu nadando en papel como nadaba el tío Gilito en su piscina de monedas amarillas. Es un volcado de la publicación completa: el Suscriptor cuando la recibe hace un Drop de lo que tiene e incorpora lo que le envían.
• Replica transaccional: un fascículo cada vez, un cambio en la base de datos genera una transacción de replica. Puede que queramos apelotonar varias transacciones en una, algo asi como que no nos envíen todos los días el fascículo de la colección que estoy ya muy mayor para bajar todos los días al buzón, mándame todas de golpe una vez por semana.
• Replica de combinación. Este tipo no vamos a tratarlo mucho, por no decir nada. Los datos que se reciben se modifican, se transforman. No es tan común.

Lo normal es un proceso de réplica es comenzar por una instantánea para poner al día al Suscriptor y luego se le van enchufando replicas de transacción, una por cada cambio. Esto en MySQL se suele hacer parando el Maestro o lockeando a mano todas las tablas, copiando la base de datos con “scp” o haciendo un dump y luego montándola en el esclavo. En SQL Server también podemos hacer esto mismo haciendo un backup del Maestro y un restore en el Esclavo aunque la réplica de instantáneas es menos “cutre” y no necesita tanta “mano de obra” ni parar la base de datos aunque cuando se está´generando la réplica el motor de base de datos hará un lock de escritura de la tabla que este replicando en ese momento de modo que los clientes no podrán escribir en esa tabla. Además las réplicas instantáneas permiten ser empaquetadas en un fichero .CAB para minimizar los tiempos de transferencia por red y espacio en disco necesario.

Por otro lado el asunto de las replicas transaccionales da bastante juego ya que en SQL Server la dirección de réplica puede ser en ambos sentidos sin necesidad de bailar roles como sucede en MySQL, así que toca hablar un poco de esto.

Lo normal es que la dirección de la replica sea única: la base de datos genera una Publicación que el Publicador entrega al Distribuidor que aplica en el Suscriptor (el maestro desperdiga los datos en los esclavos) pero esto tiene matices, como se vera a continuación:

En la replica de instantáneas no hay mucha ostia: se envia todo del Publicador al Suscriptor y el Suscriptor se lo come íntegro. Es como si tiraras todo lo que tienes y te quedaras con todo lo que te envían cada vez. El consumo de red puede ser galopante, un chorreo constante de gigas y gigas. Sin embargo en la réplica transaccional el Suscriptor puede modificar y enviar datos al Publicador de 2 maneras (tanto del Publicador al Suscriptor como a la inversa):

• Actualización inmediata: “chist, me has puesto ‘havia’ con ‘v’!!” el Suscriptor envía de inmediato el cambio al Publicador, que lo acepta de buen grado como un acto de fe. Si hubiera otros Suscriptores recibirían ese cambio desde el Publicador al momento.
• Actualización en cola: “oye pues voy cambiando cosillas y ya te las envío si eso”. Puede ser que haya huelga en correos asi que cuando el link este arriba enviamos todos los cambios de golpe. Si resulta que correos funciona bien (ejem) pues los vas enviando según los vas encontrando.

Pero que sucede si un Suscriptor envía un cambio y el Publicador ha cambiado datos justo en ese articulo? como era de esperar el Publicador gana (estaría gordo) de modo que la transacción emitida por el Suscriptor se rechaza y no solo eso, el Suscriptor se come una transacción con el cambio del Publicador. Luego si quiere podrá generar una nueva transacción con el cambio pero sobre los datos ya cambiados por el Publicador.

 

Procesos

Te lo estás pasando en grande, yo lo sé. Solo puedes haber llegado hasta aqui porque estas de mierda hasta arriba, pero yo te comprendo amigo: las fechas aprietan y necesitas esa base de datos en réplica cuanto antes. Todavía te queda un rato pero no desesperes, que vamos andando el camino. Bájate a la máquina expendedora y sácate unas patatas fritas, date una vuelta a la manzana, fúmate un cigarrillo si eres fumador, ves pasar a las chatis durante un rato, y vuelves con las pilas cargadas.

Hasta aqui todo claro espero. Si no esta claro releer, preguntar y repreguntar porque si no se entiende bien la cosa y no se manejan los 4 conceptos con soltura se cae el chiringuito.

Ahora vamos a describir los procesos que se involucran en todo este meollo repartidos por roles:

En el distribuidor

• Agente de instantáneas (snapshot.exe). Se conecta al Publicador y recaba los datos publicados para hacer la instantánea.
• Agente de registro de log (logread.exe). Es el que pasa los fascículos (los cambios de la base de datos) al Distribuidor para que los distribuya.

De esto se viene a deducir que ambos procesos son lo mismo y hacen lo mismo pero uno relativo a réplicas transaccionales y otro a las de instantáneas: se conectan al Publicador y se traen los datos al Distribuidor.

En el distribuidor y en el suscriptor

• Agente de distribución (distrib.exe) es el que aplica las instantáneas o las transacciones producto de la réplica en el Suscriptor. Es el cartero que te inunda de fascículos o te los trae de uno en uno. En el Distribuidor incluye las Suscripciones, en el Suscriptor las extrae para su posterior aplicación.

En el publicador o en el suscriptor

• Agente de combinación (replmerg.exe). Imagina que la Publicación es la segunda vez que se publica y el Suscriptor no pudo acabarla la primera vez con lo que se da de alta otra vez pero ya tiene algunos fascículos de antes. Recibe fascículos pero como ya tiene algunos de antes el pobre hombre se hace un lio porque empieza a tener algunos repetidos (conflictos). No pasa nada, el agente de combinación resuelve estos conflictos. Se puede ejecutar en el Publicador o en el Suscriptor, lo que seria algo asi como suscribirse a una publicación indicando en el panfleto que me manden todo menos los números 3 y 7 que ya los tengo o que me manden todo que ya tiro yo (el Suscriptor) lo que me sobre a fin de tener a la parienta contenta con el numero mínimo de papeles rondando por allí.

Este agente no trataremos porque solo se usa en replicas de combinación. En MySQL no existe esta figura que yo sepa: sin hay conflictos el proceso de replica sale con error.

En el suscriptor

• Agente de lectura de cola (qrdrsvc.exe). Com hemos dicho antes las modificaciones fluyen en ambas direcciones y el Agente de lectura de cola se encarga de eso: cuando el Publicador y Suscriptor están desconectados por lo que sea y se producen cambios en el Suscriptor estos cambios se van acumulando y los envía el Agente de lectura de cola cuando el link se restablece.

Modelos de réplica

Parece que ya vamos quedándonos con la terminología y por ende con la copla. Pero no cantemos victoria tan pronto mis pezqueñines, que esto tiene cuerda para rato, a fin de cuentas es Microsoft el que ha pergeñado todo este invento de locos.

Ahora que tenemos mas o menos todas las piezas vamos a ver que topología de réplica podemos aplicar. Esto en MySQL es talmente igual:

• Modelo de igual a igual: peer to peer: todos pueden hacer de todo. Una bacanal. Un libertinaje. Un “que viva la fiesta”. En un momento dado hay un Publicador y un Suscriptor pero podemos bailar los roles si por ejemplo el Publicador peta o tiene un gatillazo . El Suscriptor pasaría a ser Publicador y cuando el antiguo Publicador se despierte le enchufamos una replica de instantánea para que se vaya calentando y se ponga al día, al tiempo que le volvemos a nombrar Publicador en funciones, por listo.
• Modelo Publicador central: como el Napster: tenemos un Publicador central y n Suscriptores. El caso típico de la editorial que reparte a muchos Suscriptores.
• Modelo de Publicador central con distribuidor remoto: ya habíamos dicho que el distribuidor podía estar en un servidor separado o en el publicador. No se porque lo repite la mierda de libro esta. Sera por fardar?
• Modelo de suscriptor central. Imagina un jubileta que se aburre mazo porque la parienta monopoliza todo el Home Cinema que en sus momento le permitió comprar con programas del corte de Ana Rosa Quintana y similares. El hombre comprensiblemente tiene fobia a este tipo de ponzoña de modo que se suscribe a 200 publicaciones para estar bien entretenido. Después los de Greenpeace lo requerirán para darle unas de yoyas por encargo.Se trata de una base de datos que recibe datos a cascoporro de varios Publicadores.
• Modelo de publicación del suscriptor: aqui las neuronas no me llegan para entender lo que pone este hombre en el libro. Yo creo q ha pasado el parrafo por el traductor de Google y ha quedado de aquella manera. Entiendo que se refiere a un modelo mixto. Es como esas personas (jubiladas también, esto parece el Inserso) que ves por las mañanas cuando vas a currar con muchas muchas barras de pan y piensas “A donde cojones ira este con tanta barra? y lo que es mas raro… a donde va TAN PRONTO?”.  Pues a repartir chavalines, a repartir. Y tu lo dejas marchar porque acabas de desayunar, que sino le pillabas un currusco eh?. El Publicador envía al Suscriptor los datos y este a su vez publica a otros Suscriptores. Según leo es para el caso en q el Publicador y los Suscriptores están muy lejos (enlace Wan) pero los Suscriptores están todos cerca de si (enlace LAN): el Publicador actualiza 1 solo Suscriptor y este reparte el bacalao  entre el resto de Suscriptores. Como te decía: el jubileta que va a la panadería, se carga de barras y reparte para toda la escalera (y fijo que se queda con el cambio, sino no se entiendo tamaño empeño y altruismo).

Y hasta aqui hemos llegado amiguitos, en esta “amena” introducción. En la próxima le daremos candela al asunto pero ya al teclado, como los hombrrrrres.

Pero candela de buena.