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.