Vous êtes sur la page 1sur 6

Replica de base de datos.

La replicacin es un conjunto de tecnologas destinadas a la copia y distribucin de datos y objetos de base de datos desde una base de datos a otra, para luego sincronizar ambas bases de datos y mantener su coherencia. La replicacin permite distribuir datos entre diferentes ubicaciones y entre usuarios remotos o mviles mediante redes locales y de rea extensa, conexiones de acceso telefnico, conexiones inalmbricas e Internet. El principal objetivo del sistema de Rplicas de Datos es garantizar la credibilidad y disponibilidad del sistema en todas las sucursales, aunque algunas de ellas permanezcan horas, quizs das sin conectarse en Internet.

Eso se hace posible porque con el sistema de Rplica de Datos de la DB1 cada sucursal posee su propio banco de datos y todos los usuarios del sistema de gestin se conectan en ese banco de datos y no en el banco de datos central de la empresa, siempre que el banco de datos principal est sin transmisin, o an como banco de datos principal, para distribuir el procesamiento.

Las rplicas locales consisten en un duplicado de las bases de datos del servidor en el disco duro de su computadora, es decir, en el servidor local.

Estas bases de datos contienen adems de los documentos, un identificador que permitir posteriormente actualizar sus contenidos, tanto en el servidor como en las bases de datos locales. Esto constituye una ayuda especialmente til cuando se desea trabajar en una computadora que en ocasiones no estar conectada a la red donde se encuentra el servidor en el que reside el curso.

La rplica de una base de datos se realiza solamente una vez la primera- y posteriormente se procede a la "replicacin" de los documentos cada vez que se considere necesario. La forma de realizar este proceso se describe en los siguientes pasos:

Ventajas y desventajas de la replicacin

Con la replicacin se pueden llegar a obtener dos mejoras importantes:

1. Por un lado, se garantiza que el servicio ofrecido por la aplicacin, no se vea interrumpido en caso de que se d un fallo en alguna de las rplicas. Adems, el tiempo necesario para restablecer el servicio en la aplicacin podra llegar a ser grande en algunos tipos de fallo.

2. Por otra parte, la capacidad de servicio se ve incrementada cuando las peticiones efectuadas por los clientes nicamente implican consultas.

Sin embargo, estas ventajas tienen tambin un coste asociado. Cuando las peticiones atendidas impliquen una actualizacin en el estado de la aplicacin, dicha actualizacin debe realizarse en todas las rplicas, y esto debe hacerse de una manera ordenada para que todas ellas mantengan un estado consistente. Esto implica que las operaciones de actualizacin tendrn un tiempo de servicio mayor que en el caso no replicado, pues habr que proceder a la propagacin de las actualizaciones sobre todas las rplicas y para ello ser necesario emplear algn mecanismo de difusin.

Existen protocolos de replicacin que permiten controlar estas actualizaciones de una manera eficiente, por lo que la aplicacin replicada, podr tener un rendimiento muy similar al de una aplicacin no replicada en caso de peticiones de actualizacin y bastante superior, en caso de peticiones de consulta. Estos protocolos de replicacin deben complementarse con protocolos de recuperacin, para reintegrar una rplica previamente cada cuando sta vuelva a estar activa.

Protocolos de replicacin

Los protocolos de replicacin resultan necesarios para garantizar cierto grado de consistencia entre las rplicas de la aplicacin. La complejidad de un protocolo de replicacin depende de:

1. El modelo de replicacin utilizado. Existen dos modelos de replicacin bsicos: activo y pasivo. En el modelo activo el cliente difunde su peticin a todas las rplicas del servidor (bien

directamente, realizando el propio cliente la difusin, o a travs de una de las rplicas, que difundir su peticin antes de intentar servirla; siendo esta segunda opcin la ms sencilla de implantar al utilizar grupos cerrados). Estas rplicas servidoras procesan cada una de ellas la peticin de manera local, sin necesidad de ninguna coordinacin, y retornan su resultado al cliente. En el modelo pasivo el cliente slo interacta con una rplica primaria, que es la nica con capacidad para procesar activamente cada peticin. Posteriormente, esta rplica primaria difunde las actualizaciones al resto de rplicas y responde al cliente. A pesar de que estos dos modelos son los ms importantes y ms ampliamente implantados, para obtener un buen rendimiento se llegan a necesitar soluciones intermedias que precisan un protocolo de replicacin ms elaborado.

2. El modelo de fallos asumido. Existen dos modelos bsicos: cada no recuperable (fallo de parada) y cada recuperable. En el primero se asume que cuando un proceso falle, jams se recuperar. Esto es equivalente a asumir que cuando una rplica falle, perder por completo su estado y, cuando llegue a recuperarse, se presentar ante el resto como una rplica nueva, necesitando una transferencia completa del estado de la aplicacin. En el segundo modelo, la cada de un proceso no implica la prdida completa del estado. Se supone que parte de tal estado se mantiene de manera persistente. As, cuando vaya a reincorporarse al grupo, una rplica bajo este modelo slo necesita recuperar aquella parte de su estado (y las actualizaciones) que haya perdido.

3. El nmero de rplicas que puedan estar procesando distintas peticiones de manera simultnea. Esto depende del modelo de replicacin empleado.

Metodologa de replicacin de datos Es importante seguir una metodologa correcta de diseo de una BDD para poder obtener un esquema que sea escalable y adaptable a los cambios de tecnologa.

La forma de distribucin de informacin debe ser analizada cuidadosamente buscando una opcin que optimice y maximice la utilizacin todos los factores que se deban considerar para un problema particular.

El factor principal para la determinacin de la distribucin de datos va a estar dado, bsicamente, por los requerimientos de usuario. Cuestiones como por ejemplo la performance del sistema puede llevar a generar mayor replicacin en los datos, a fin de colocar la informacin "cerca" del usuario, evitando el costo de la transmisin de datos en la red. Obviamente esta apreciacin puede tornarse rpidamente en un inconveniente. Si la replicacin de la informacin aumenta los protocolos de cometido van a demorar ms en completar su ejecucin, o mantener las copias actualizadas "en lnea" resulta ms costoso.

Se puede obtener replicacin de datos considerando diferentes criterios. Uno de ellos, quiz el ms simple, consiste en clasificar la replicacin por el costo de latencia que existe para lograr la consistencia de los datos a lo largo de todas las rplicas. De esta manera se puede hablar de dos tipos de replicacin: sincrnica o asincrnica (eager o lazy).

La replicacin sincrnica provee un mecanismo que asegura que todas las rplicas se mantengan actualizadas en lnea. De esta forma, la latencia para lograr consistencia de datos se reduce a cero. La implementacin clsica del protocolo de cometido de 2 fases (2PC) garantiza este tipo de replicacin. Con este esquema de actualizacin de rplicas es

posible garantizar las propiedades ACID de una transaccin. Por el contrario, la replicacin asincrnica se limita a asentar las modificaciones en una copia o rplica, dejando para ms adelante la actualizacin del resto. De esta forma, un esquema con estas caractersticas debe aceptar inconsistencia temporaria de informacin.

Replicacin de Datos El proceso de Replicacin de una base de datos consiste en replicar las consultas de actualizacin en una base de datos maestra (master) sobre una o varias bases de datos esclavas (slave), de manera que tengamos una copia de las mismas a lo largo del tiempo. MySQL soporta replicacin unidireccional asncrona, es decir, las consultas de actualizacin ejecutadas en el maestro son replicadas en los servidores esclavos. Esta replicacin se realiza de forma transparente. Adems es instantnea si los servidores esclavos estn levantandos y en estado de Replicacin. Este servicio le permite al cliente con un Sistema Administrativo que use Base de Datos MySQL tener toda su informacin en Servidores Geogrficamente separados.

Conclusiones La replicacin es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reduccin de dependencia de un sistema de base de datos centralizado. Dada la diversidad de contextos donde se aplican mecanismos de replicacin, se puede disponer

de una gama de posibilidades, en vez de utilizar una nica forma de replicar datos. Cada uno de los tipos de replicacin se adapta en mayor o menor medida y pueden utilizarse en forma combinada para un caso especfico. Los tipos de replicacin disponibles permiten moverse desde contextos donde los sitios trabajan en forma completamente unos de otros, hasta contextos donde se requiere una alta consistencia transaccional.

Vous aimerez peut-être aussi