Entendiendo la replicación

3 comentarios

Cuando trabajamos con bases de datos todo el contenido de ellas es extremadamente importante para la organización que nos contrató y no podemos permitir que por nuestra culpa, por no prever las contingencias, se pierdan datos.

Las armas que tenemos para evitar que algo desastroso ocurra son:

  • Copias de seguridad, también llamadas backups o copias de respaldo
  • Copias shadow, también llamadas copias espejo
  • Replicación

La importancia de hacer backups supongo que todo el mundo la conoce y no es necesario explayarse sobre ese tema. El problema con los backups es que generalmente cuando se los restaura lo que se obtiene es algo viejo. Dependiendo de cuando se hizo el último backup lo que restauremos tendrá minutos, horas, días, semanas o meses de antigüedad. Y todo lo que se registró desde el momento en que se inició el backup hasta el momento actual será trabajo perdido. En una organización pequeña eso puede ser aceptado, pero en una organización grande con varias sucursales y decenas o cientos de usuarios concurrentes será totalmente inaceptable. Simplemente no les puedes decir a tus usuarios que todo el trabajo que hicieron desde el último backup se perdió y deben registrarlo nuevamente.

Las copias shadow tienen la ventaja de que todo lo que se registró en la Base de Datos original también se registró en la copia shadow, hasta el último detalle. Todas las inserciones, borrados y actualizaciones realizados en la Base de Datos original están fielmente reflejados en la copia shadow. El problema con la copia shadow es que debe encontrarse en la misma computadora que la Base de Datos original y si esa computadora se incendió, fue robada, destruida por una inundación, por un terremoto, por un ataque terrorista o algo así, todo lo registrado en la Base de Datos original y en la copia shadow puede estar irremediablemente perdido.

La replicación tiene la ventaja de que podemos tener una copia de seguridad, un backup, en otra computadora, quizás alejada del Servidor por decenas, centenas o miles de kilómetros.

¿Qué significa replicación?

Copiar el contenido de una Base de Datos en otra Base de Datos, las cuales pueden (y deberían) estar en computadoras distintas

¿La replicación necesariamente requiere copiar todo el contenido de una Base de Datos?

No, se puede copiar solamente una parte o sea solamente algunas tablas

¿Cómo funciona la replicación?

  1. En una computadora llamada “Servidor de Replicación” o “Administrador” se encuentra la Base de Datos cuyo contenido será copiado en otra Base de Datos que se encuentra en una computadora cuyo nombre es “Cliente de Replicación”. Ambas computadoras pueden encontrarse a miles de kilómetros de distancia.
  2. En el “Servidor de Replicación” se eligen las tablas cuyos contenidos  serán copiados en el “Cliente de Replicación”. Pueden ser todas las tablas o solamente algunas tablas.
  3. No es obligatorio copiar todas las filas de las tablas elegidas, pueden copiarse solamente algunas filas si se desea.
  4. Cuando el proceso se inicia, el contenido de las tablas que tienen el mismo nombre se trata de igualar. Por ejemplo, si se decidió replicar la tabla PRODUCTOS entonces los datos de cada producto que está en el “Servidor de Replicación” se trata de copiar en la tabla PRODUCTOS que se encuentra en el “Cliente de Replicación”
  5. Si un producto existe en el “Servidor de Replicación” y no existe en el “Cliente de Replicación” entonces no hay problema, se lo inserta en la tabla de PRODUCTOS y listo. Pero si ya existe y además fue actualizado en ambas bases de datos después de la última replicación hay un conflicto ¿cuál de las dos versiones se debe mantener, la que se encontraba en el “Servidor de Replicación” o la que se encontraba en el “Cliente de Replicación”? Esto es algo que debe resolverse manualmente, o sea que una persona debe decidir.
  6. El “Servidor de Replicación” no tiene por que coincidir con el Servidor del Firebird. Cualquier computadora puede actuar como “Servidor de Replicación” y cualquier computadora puede actuar como “Cliente de Replicación”, inclusive la computadora que en un instante actuó como “Servidor de Replicación” en otro instante puede actuar como “Cliente de Replicación”.
  7. Del punto 6. se deduce que la replicación puede ser bidireccional, eso ocurre cuando ambas bases de datos son actualizadas.

Ejemplos en los cuales se necesitaría hacer replicación

Ejemplo 1:

Un vendedor viajante registra en su notebook (también llamada laptop) los datos de las ventas que va realizando. Él no necesita conocer los precios de compra de los productos, ni las compras realizadas, ni los pagos efectuados, ni los sueldos de los empleados, ni un montón de otras cosas. Solamente debe tener en su notebook los códigos de los productos, los nombres de los productos, la cantidad en stock de los productos, los precios de venta de los productos. Adicionalmente, los códigos, nombres, direcciones, teléfonos y quizás algunos otros datos de sus propios clientes. No debería tener los datos de los clientes de los otros vendedores, solamente de sus propios clientes.

En este caso la replicación es parcial, solamente algunas tablas son replicadas en la computadora notebook del vendedor e inclusive solamente algunas filas de dichas tablas, ni siquiera se replican las tablas completas, solamente se replican las filas que el vendedor puede necesitar.

Cuando el vendedor copia en su notebook los datos de los productos y de los clientes que se encuentran en la Base de Datos principal su computadora notebook actúa como “Cliente de Replicación” porque es la computadora que recibe los datos. Sin embargo, ¿qué sucede si más tarde se corta la conexión con Internet? el vendedor sigue registrando las ventas en su notebook y cuando la conexión se restablece actualiza a la Base de Datos remota, la que se encuentra en las oficinas de la empresa. En este caso su computadora notebook actuó como “Servidor de Replicación” porque fue la que envió los datos.

Ejemplo 2:

La Casa Central o Casa Matriz de la empresa se encuentra en Londres y las sucursales se encuentran en Berlín, Madrid, París y Roma. Cada una de estas sucursales tiene su propia Base de Datos en la cual se registran todas las operaciones que le conciernen. En la Base de Datos que se encuentra en la sucursal de Berlín solamente se tienen los datos que corresponden a la sucursal de Berlín. En la Base de Datos que se encuentra en la sucursal de Madrid solamente se tienen los datos que corresponden a la sucursal de Madrid. Y así sucesivamente. Pero en la Base de Datos que se encuentra en Londres se tienen los datos de Londres y también los de Berlín, Madrid, París y Roma. O sea, allí está todo.

Cada noche, al final de la jornada laboral, se replican los datos de las sucursales en la Casa Central. La computadora que se encuentra en Londres actúa como “Cliente de Replicación” porque es la computadora que recibe los datos y las computadoras que se encuentran en Berlín, Madrid, París y Roma actúan como “Servidores de Replicación” porque son las que envían los datos.

Pero un poco más tarde los papeles se invierten. Las computadoras que se encuentran en Berlín, Madrid, París y Roma necesitan ser actualizadas con los nuevos precios de costo de algunos productos y entonces la computadora de Londres actúa como “Servidor de Replicación” porque es la que envía los datos y las otras computadoras actúan como “Clientes de Replicación” porque son las que reciben los datos.

Ejemplo 3:

El propietario de la empresa no quiere tener problemas por causa de una Base de Datos dañada porque ya tuvo una mala experiencia con eso en el pasado, por lo tanto cada vez que llega a su casa replica en su computadora personal toda la Base de Datos que está en su oficina. Cuando el proceso de replicación finaliza el está seguro de que ambas bases de datos son exactamente iguales y así puede dormir tranquilo.

Conclusión:

La replicación es extremadamente importante cuando las computadoras no se encuentran en una red local o cuando se desea tener un backup en una computadora que está lejos. La computadora que envía los datos se llama “Servidor de Replicación” y la computadora que recibe los datos se llama “Cliente de Replicación”. Cuando se hace la replicación puede ocurrir un conflicto si una fila fue actualizada en ambas bases de datos después de la última replicación y en esos casos generalmente se requiere de intervención humana para solucionar el conflicto. Si se corta la conexión con Internet no hay problema, se puede continuar trabajando normalmente con ambas bases de datos y cuando la conexión se restablece se realiza la replicación.

Artículos relacionados:

Creando una copia shadow

Anuncios

Creando una copia SHADOW

4 comentarios

Firebird posee una característica que en ciertas circunstancias puede ser muy útil: crear una Base de Datos “shadow”.

Aunque la palabra “shadow” significa “sombra”, en Informática se la traduce como “espejo”.

Una Base de Datos shadow es una Base de Datos que es idéntica a la original y que es actualizada en el mismo momento en el cual la original es actualizada.

¿Para qué sirve?

Para poder recuperar al instante una Base de Datos que se dañó por un problema físico del disco duro, un problema en la red o porque fue borrada.

¿Cómo funciona?

En un disco duro distinto al disco duro de la Base de Datos original se tiene una versión idéntica a la cual se la conoce como copia “shadow”, todo lo que se inserte, borre o modifique en la Base de Datos original automáticamente también será insertado, borrado o modificado en la Base de Datos shadow.

¿Por qué el disco duro debe ser distinto?

En realidad ambas bases de datos podrían estar en el mismo disco duro pero eso no tendría mucho sentido ya que la principal utilidad de la copia shadow es servir de respaldo cuando ocurre un problema de daño físico en la Base de Datos original. Y en ese caso lo más probable es que todo el disco duro se haya tornado inaccesible, no solamente una parte de él.

Por lo tanto, lo normal es que ambas bases de datos se encuentren en discos duros distintos.

¿Si alguien borró o modificó una fila por error, la copia shadow  servirá de respaldo para recuperar esa fila a su estado anterior?

No, porque la copia shadow es exactamente igual a la Base de Datos original. Cualquier inserción, borrado o modificación en la Base de Datos original se refleja al instante en la copia shadow. La copia shadow solamente es útil cuando ocurre un daño físico en el disco duro original, o la red no funciona o se borró la Base de Datos original. Por lo tanto, si alguien borró por error o por intención una fila en la Base de Datos original, esa fila también estará borrada en la copia shadow.

¿Cuál es el beneficio de tener una copia shadow?

Que si ocurre un desastre en el hardware que dañó, borró o volvió inaccesible a la Base de Datos original, se puede recuperar rápidamente la copia shadow la cual estará exactamente igual a como estaba la Base de Datos original antes de que el desastre ocurriera. El mismo beneficio se tendrá si la Base de Datos fue borrada o fue dañada por un virus o algún otro programa o usuario malicioso.

¿Qué se debe de tener en cuenta cuándo se utiliza una copia shadow?

  1. La copia shadow es una copia exacta de la Base de Datos original. Todo lo que se inserta, borra o modifica en ésta instantáneamente se refleja en aquella
  2. Su utilidad es servir de respaldo en el caso de daño físico del disco duro, de problema grave en la red, o si la Base de Datos original fue borrada o dañada
  3. Cuando se activa una copia shadow, ésta empieza a funcionar en ese mismo instante
  4. Funciona en forma invisible, los programadores nada deben hacer para que funcione
  5. No se requiere acceso exclusivo a la Base de Datos para crearla
  6. Pueden tenerse varias copias shadow a la vez
  7. No es una protección contra corrupción de datos causada por problemas de software
  8. Es un método de todo o nada. Cuando se activa una copia shadow, toda la Base de Datos es activada, no se puede activar solamente algunas tablas o algunos stored procedures, o algunos triggers, etc. Cuando se la activa, se la activa totalmente.
  9. Debe estar en un disco duro fijo, no puede estar en un disco duro removible, ni en un pen-drive, ni en un disco mapeado de la red
  10. No es un sustituto para backups. No creas que por tener shadows puedes dejar de hacer backups periódicamente.
  11. Como cualquier otro archivo de la computadora, puede ser dañado o borrado.
  12. No te puedes conectar a una copia shadow. Nunca trates de conectarte a una copia shadow ni de moverla a otra carpeta, ni de borrarla. Cuando sea necesario conectarse a ella el Firebird sabe muy bien como hacerlo

¿Cuál es la sintaxis para crear una copia shadow?

CREATE SHADOW NúmeroCopia [AUTO | MANUAL] [CONDITIONAL] “NombreArchivo”

Ejemplo:

SHADOW1

(haciendo click en la imagen la verás más grande)

  • Debes estar conectado a la Base de Datos en la cual crearás la copia shadow
  • El modo por defecto es AUTO. Eso significa que cuando la Base de Datos original se torne inaccesible automáticamente  se usará la copia shadow
  • El NúmeroCopia puede ser cualquier número entero, no necesariamente 1
  • El NombreArchivo no debe existir
  • No es obligatorio que el nombre del archivo sea ‘MiShadow1’, puede ser cualquier nombre
  • No es obligatorio que la extensión del archivo sea .shd, puede ser cualquiera o inclusive no tener extensión

¿Cómo se puede saber si la copia shadow existe?

Con el comando SHOW DATABASE;

SHADOW2

(haciendo click en la imagen la verás más grande)

En este caso, como el modo es AUTO la copia shadow se activará automáticamente cuando la Base de Datos original no pueda ser accedida.

¿Cómo se activa una copia shadow cuyo modo es MANUAL?

Mediante el programa GFIX.EXE y la opción -activate, como se puede ver en esta imagen:

SHADOW3

(haciendo click en la imagen la verás más grande)

¿Para qué sirve la cláusula CONDITIONAL?

Cuando el modo es AUTO y la Base de Datos se volvió inaccesible la copia shadow automáticamente toma su lugar y desde ese momento ya no hay una copia shadow (porque la copia que era shadow ahora es la Base de Datos en uso)

Cuando el modo es MANUAL la copia shadow no puede ser usada hasta que sea activada mediante GFIX -activate y desde que es activada ya no existe una copia shadow (porque la que era la copia shadow ahora es la Base de Datos en uso). Generalmente se elige MANUAL cuando se quiere que las conexiones a la Base de Datos se mantengan bloqueadas hasta que manualmente se habilite una nueva copia shadow.

En el caso de AUTO ya no hay una copia shadow. En el caso de MANUAL puede haberla si fue creada manualmente, en otro caso no.

Cuando el modo es AUTO la copia shadow toma rápidamente el lugar de la Base de Datos original y hasta que el administrador cree una nueva copia shadow  la nueva Base de Datos estará funcionando sin un shadow. Esta es una situación que en muchas situaciones podría ser inaceptable, porque si ocurre un nuevo desastre antes de crearse una nueva copia shadow todas las transacciones que ocurrieron se perderán para siempre.

Al usar la palabra clave CONDITIONAL se le dice al Firebird que cuando la copia shadow se convierta en la Base de Datos activa automáticamente cree una nueva copia shadow. De esta manera siempre se tendrá una copia shadow. En general, esta es la opción preferible de usar.

¿Qué más se debe hacer para que la copia shadow reemplace a la Base de Datos original?

Debes renombrarla para que pueda ser utilizada por los programas. Por ejemplo:

La Base de Datos original se llamaba: CONTA.FDB

La copia shadow se llamaba: SHADOWCONTA1.SHD

Después que la copia shadow se convirtió en la Base de Datos activa debes renombrarla como: CONTA.FDB para que todos los programas puedan conectarse a ella

¿Cómo se borra una copia shadow?

Si por alguna razón ya no quieres tener una copia shadow puedes escribir:

DROP SHADOW NúmeroCopia;

y la Base de Datos ya no tendrá la copia shadow NúmeroCopia. Por ejemplo:

DROP SHADOW 1

Harías esto cuando la copia shadow existe, es accesible, pero ya no la quieres usar por alguna razón.

¿Cómo se elimina la referencia a una copia shadow?

Si una copia shadow es borrada del disco duro o es renombrada o por alguna otra razón se vuelve inaccesible, será imposible conectarse a su Base de Datos original, todos los intentos serán rechazados:

SHADOW4

(haciendo click en la imagen la verás más grande)

 En realidad, este problema generalmente ocurre cuando el modo es MANUAL, cuando el modo es AUTO la Base de Datos automáticamente elimina la referencia a la copia shadow y la conexión puede realizarse exitosamente.

El programa GFIX.EXE tiene una opción -kill que sirve para eliminar las referencias a las copias shadows inaccesibles.

SHADOW5

(haciendo click en la imagen la verás más grande)

 A partir de este momento ya se podrá acceder a la Base de Datos, pero ésta se encontrará sin ninguna copia shadow. Si se desea que tenga una copia shadow habrá que crearla como se explicó más arriba.

CONCLUSIÓN:

Una buena característica del Firebird es que nos permite tener copias shadows muy fácilmente y gracias a ello si ocurre un desastre en el hardware no se perderán los datos, podrán ser recuperados al 100%.

Pero lo anterior no significa que deben dejarse de lado los backups periódicos, ya que las copias shadows y los backups sirven para cosas distintas: las copias shadows para tener copias que pueden ser utilizadas muy rápidamente en caso de fallas en el hardware o borrado físico de la Base de Datos; los backups para recuperar los datos que se tenían horas o días atrás y para resguardarse en caso de un incendio, robo de la computadora y situaciones similares.