Base de Datos Distribuidas -...

1

Bases de Datos Distribuidas

Integrantes: Maria A. Ascanio. MJosé A. González R.Héctor. E. Cruz F.

Agenda


ANTECEDENTES

Las bases de datos distribuidas ofrecen diversas ventajas a los diseñadores y usuarios de bases de datos.

Entre las más importantes se encuentra la transparencia en el acceso y localización de información.

Sin embargo, el diseño y administración de bases de datos distribuidas constituye un gran desafío que incorpora problemas no encontrados en bases de datos centralizadas.

ANTECEDENTESINTRODUCCIÓNBASES DE DATOS DISTRIBUIDAS

TIPOS DE TRANSACCIONESDESVENTAJAS DE LAS BASES DE

DATOS DISTRIBUÍDASCONDICIONES DESEABLES EN

UNA BASE DE DATOS TIPOS DE BASES DE DATOS

DISTRIBUÍDASARQUITECTURAS DISTRIBUÍDAS

DEL DBMS Arquitectura Cliente-Servidor Arquitectura de Servidores

CooperantesDe una Vía Centralizada

ALMACENAR DATOS EN UN DBMS DISTRIBUIDO

Fragmentación Replicación

MANEJO DEL CATÁLOGO DISTRIBUIDO

Nombramiento de objetos

2

Agenda


INTRODUCCION

Un área en la cual las soluciones están integrando tecnología con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de información.

Ellos se refieren al manejo de datos almacenados en facilidades de cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones. Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de datos distribuidas.












Agenda


BASES DE DATOS DISTRIBUIDAS

Los datos en un sistema de la base de datos distribuida se almacenan a través de varios sitios, y cada sitio es manejado típicamente por un DBMS que pueda funcionar independiente de los otros sitios.

La vista clásica de un sistema de la base de datos distribuida debe mostrar los datos distribuidos de forma transparente, dar la impresión de que los datos son locales












3

Agenda


BASES DE DATOS DISTRIBUIDAS

Lo que motiva a la distribución de la data es:

Incrementa la Disponibilidad

Acceso Distribuido a los Datos

Análisis de los Datos Distribuidos

Autonomía












Agenda


TIPOS DE TRANSACCIONES

Hay dos tipos de transacciones:

Locales: Es aquella que accede a los datos del único sitio donde se inició la transacción.

Globales: Es aquella que accede a los datos situados en uno o mas sitios diferentes de aquel en que se inició la transacción












4

Agenda


DESVENTAJAS DE LAS BDs DISTRIBUIDAS

Coste de Desarrollo del Software

Mayor Probabilidad de Errores

Mayor Sobrecarga del Procesamiento












Agenda


CONDICIONES DESEABLES EN UNA BD

Particularmente, las características siguientes se consideran deseables.

Independencia de datos distribuidaLos usuarios deberían ser capaces de

solicitar queries sin especificar donde están situadas las relaciones, ya sean sus copias o fragmentos, a las que hizo referencia.

Atomicidad de una Transacción distribuida:

Los usuarios deberían ser capaces de escribir transacciones que accedan y actualicen datos en muchos sitios, las mismas tienen que seguir siendo atómicas, sino llevarían a la BDdistribuida a un estado inconsistente




UNA BASE DE DATOSTIPOS DE BASES DE DATOS








5

Agenda


ARQUITECTURAS DISTRIBUIDAS DEL DBMS

Arquitectura Cliente-Servidor

Posee uno o más procesos clientes y uno o más procesos servidores, un proceso cliente puede mandar un query a alguno de los procesos servidores. Los clientes son responsables de los aspectos relacionados con la interface de usuario, mientras que los servidores manejan los datos y ejecutan las transacciones.






DEL DBMSArquitectura Cliente-Servidor Arquitectura de Servidores






Agenda



Arquitectura de Servidores Cooperantes

Podemos tener una colección de servidores de bases de datos, cada uno capaz de correr transacciones sobre los datos locales, y cooperativamente sobre datos residentes en otro servidor.












6

Agenda



De una Vía Centralizada:

La idea es que necesitamos solo un servidor de bases de datos capaz de manejar queries y transacciones provenientes de múltiples servidores.

Podemos pensar en este servidor especial como una capa del software que coordina la ejecución de queries y transacciones a través de uno o más servidores de bases de datos independientes, es usualmente llamado Middleware.












Agenda



Fragmentación

Consiste en partir la relación en pequeñas relaciones o fragmentos y almacenar los fragmentos, posiblemente, en diferentes sitios.

Estos fragmentos contienen suficiente información como para permitir la reconstrucción de la relación original.

Hay dos esquemas diferentes de fragmentación de las relaciones:.

Fragmentación Horizontal

Fragmentación Vertical









FragmentaciónReplicación



7

Agenda



11MaracayManuel53831

12MaracayTeresa53832

19ValenciaCarlos53650

18ValenciaJuan53688

18Caracas José53666

EdadCiudadNombreEID

Fragmentación VerticalFragmentación Horizontal

T5

T4

T3

T2

T1

TID

Fragmentación Horizontal y VerticalANTECEDENTESINTRODUCCIÓNBASES DE DATOS DISTRIBUIDAS








FragmentaciónReplicación



Agenda



ReplicaciónSignifica que almacenamos muchas

copias de una relación o de los fragmentos de la misma. Una relación entera puede estar replicada en uno o mas sitios, y similarmente, uno o más fragmentos de una relación.

Ventajas: Evaluación más rápida de los queriesIncrementa la disponibilidad de los datosMinimiza el movimiento de los datos entre

los sitios

DesventajasSobrecarga incrementada durante laactualización












8

Agenda














Nombrando Objetos Si una relación es fragmentada y replicada, se

debe tener un identificador único por cada réplica de cada fragmento.

La solución a esto es usar nombres con varios campos: El 1er. campo sería el nombre local (asignado localmente en el sitio donde fue creada la relación), y El 2do. Campo el sitio de origen (identifica al sitio donde la relación fue creada)

Estos 2 campos identifican únicamente a la relación y llamamos al conjunto nombre global de la relación.

Para identificar una réplica o un fragmento de una relación, usamos el nombre global de la relación y le añadimos el id réplica (identificador de la réplica). Se le llama nombre global de la réplica.

Agenda



Estructura Del Catálogo Independencia De

Datos Distribuida PROCESAMIENTO EN QUERY

DISTRIBUIDOQUERIES NONJOIN EN UN DBMS

DISTRIBUIDOJOINS EN UNA DBMS DISTRIBUIDA

Leer lo Necesario

Envió a un sitioSEMIJOINS Y BLOOMJOINS

Semijoins

BloomjoinsOPTIMIZACIÓN BASADA EN

COSTOSACTUALIZACIÓN DE LA DATA

DISTRIBUIDAReplicación sincrónica

Replicación Asincrónica


Estructura del Catálogo (describe toda la data de cada sitio):

Un sistema de catálogo centralizado puede ser vulnerable a fallas ocurridas en el sitio que lo contiene. Una alternativa es mantener una copia del mismo en cada sitio, aunque esto compromete la autonomía del sitio, ya que cada cambio realizado a dicho catálogo debe ser propagado a todos los otros sitios.

Otra solución, que preserva la autonomía local y no es vulnerable a fallas en un solo sitio, es que cada sitio mantenga un catálogo local que describa todas las copias de la data almacenada en el sitio.

9

Agenda



Independencia de la Data Distribuida

Significa que el usuario debería ser capaz de escribir un query sin importarle como la relación esta fragmentada o replicada, es decir, esto debe ser “transparente” al usuario.

En realidad es responsabilidad del DBMSprocesar la relación como se necesite, (localizando copias convenientes de fragmentos, ensamblando los fragmentos verticales, y tomando la unión de fragmentos horizontales)



Datos DistribuidaPROCESAMIENTO EN QUERY



Leer lo Necesario


Semijoins





Agenda


Procesamiento en Query Distribuido

Consideremos las siguientes relaciones: Marinero (mid, mnombre, promedio, edad)Reservación: (mid, bid, día, rnombre)

Usaremos lo anterior, para estimar el costo de una estrategia de evaluación, mas el numero de I/O’s de página, también debemos contar el número de páginas mandadas de un sitio a otro, ya que la comunicación implica un costo significativo del costo total en un sistema de BD distribuida. Añadiremos el costo de trasladar las tuplas resultantes del sitio donde se realizó el Query al sitio donde se ensamblará el resultado total.






Leer lo Necesario


Semijoins





10

Agenda


Procesamiento en Query Distribuido

Se asumirá la siguiente notación: Td: Tiempo que toma leer una página del disco.Ts: Tiempo que toma trasladar una pagina.






Leer lo Necesario


Semijoins





Agenda


Queries Nonjoin en un DBMS Distribuido

Incluso simples operaciones como búsqueda, selección, y proyección en una relación, son afectadas por la fragmentación y duplicación.

Consideremos el siguiente Query:

SELECT S.edadFROM Marinero SWHERE S.promedio > 3 and S.promedio < 7

Suponiendo que la relación marinero esta fragmentada horizontalmente, con todas las tuplas < 5 en Shangai, y todas las tuplas >= 5 en Tokio.






Leer lo Necesario


Semijoins





11

Agenda


Queries Nonjoin en un DBMS Distribuido

El DBMS debe responder este Query evaluando en ambos sitios y tomando la unión de las respuestas. Si la clausula SELECT contuvo el AVG (S.edad), la combinación, de las respuestas no puede hacerse con un simple join. El DBMS debe calcular la cuenta y suma de los valores de las edades en los dos sitios y usar esta información para calcular la edad promedio de todos los marineros.

Por otra parte, si la cláusula WHERE contenía solo la condición S.promedio > 6, por la otra parte, el DBMS debe reconocer que este Query puede ser respondido ejecutándolo solamente en Tokio.






Leer lo Necesario


Semijoins





Agenda


Joins en una DBMS Distribuida

Los Joins de Relaciones almacenadas en diferentes sitios pueden ser muy costosos. Ahora supondremos que la relación Marinero fue almacenada en Londres y Reservación en Paris.

Consideraremos varias maneras para resolver:

Marinero Reservación






Leer lo Necesario


Semijoins





12

Agenda


Leer lo Necesario

La idea principal, es traer las páginas necesarias y almacenarlas en la cache, para terminar de procesarlas. Podemos hacer un Page-orientednested loops join en Londres con marinero como la más externa, y por cada página de marinero, y leer todas las páginas de Reservación de Paris. Si almacenamos las páginas leídas de Reservación en Londres hasta que el join este completo, estas son leídas una sola vez.

Ahora, supondremos que las páginas de Reservación no pueden ser almacenadas en un cache:

El costo es 500td para scan Marinero + (por cada página de Marinero) el costo del canning y envio de todas las de Reservación, el cual es de 1000 (td+ ts). Por lo tanto el costo total sería: 500td + 500.000(td +ts).






Leer lo Necesario


Semijoins





Agenda


Leer lo Necesario

Además, si el query no fue hecho desde el sitio en Londres, debemos añadir el costo del envío del resultado al sitio donde se realizó la consulta, lo que depende del tamaño del resultado. Debido a que mid es una clave para Marinero, el número de tuplas en el resultado es 100.000 (# tuplas n Reservación) y cada tupla tiene una longitud de 40 + 50 = 90 bytes, entonces hay 4000/90 = 44 tuplas por página en el resultado, el tamaño total de éste es de 100.000/44 = 2273 páginas.

El costo de enviar la respuesta a otro sitio es de 2273ts. En el caso anterior (el sitio del

query no es ni Londres ni Paris), sería más barato si trasladáramos ambas relaciones al sitio del query y ejecutáramos el join allí.






Leer lo Necesario


Semijoins





13

Agenda


Envió a un sitio

Consiste en enviar, completamente, una de las 2 relaciones al sitio donde se encuentra la otra y luego ejecutar allí el query. Podríamos trasladar la relación Marinero de Londres a Paris y ejecutar luego el joinallá, o en lugar de mover Marinero, trasladar Reservación a Londres y realizar el join en Londres; otra opción sería trasladar ambas (Marinero y Reservación) al sitio donde se realizó el query y procesar el join en él.

El costo del scanning, el envío de Marinero, guardando la relación Marinero en Paris y asumiendo un sort-merge join, y la ejecución del joinen Paris es de: 500(2td + ts).






Leer lo Necesario


Semijoins





Agenda


SEMIJOINS Y BLOOMJOINS

Suponiendo que se envío Reservación a Londres y se ejecutó el join allí. Algunas tuplas de Reservación no harían join con ninguna tupla de Marinero. Si de alguna manera identificamos las tuplas de Reservación que seguramente no van a hacer join con ninguna de Marinero, entonces podríamos evitar enviarlas. Estas dos técnicas proponen reducir el número de tuplas a ser trasladadas






Leer lo Necesario


Semijoins





14

Agenda


Semijoins

La idea es seguir los siguientes tres pasos: 1) En Londres, computar la proyección de Marinero en el join por columnas (en este caso solo el campo mid) y trasladarla a Paris.

2) En Paris, realizar el join natural de la proyección recibida desde el primer sitio con la relación Reservación. El resultado de este join es llamado la reducción de Reservación con respecto a Marinero.

Solo aquella tuplas en la reducción harán join con las tuplas en la relación Marinero. Trasladar la reducción de Reservación a Londres es preferible antes que la relación completa.

3) En Londres, calcular el join de la reducción de Reservación con Marinero.

El semijoin es especialmente útil en conjunción con una selección aplicada a una de las relaciones.






Leer lo Necesario


Semijoins





Agenda


Bloomjoins

Es muy similar a la técnica de Semijoin, solo que usa un vector de bits conjuntamente con hash. En el 1er. paso no se envía la proyección de Marinero sino un vector de bits. Un vector de bits de tamaño k es procesado aplicando hashing a cada tupla de Marinero en un rango de 0 a (k - 1), colocando el bit ia 1 algunas tupla hashes con i, y 0 de lo contrario. En el 2do. paso, la reducción de Reservación es procesada mediante el hashing de cada tupla de Reservación (usando el campo mid) en un rango de 0 – (k-1) usando la misma función de hash empleada para construir el vector de bits y desechando las tuplas cuyo valor de i corresponda a un bit 0. El costo de aplicar esta técnica aplicada a Reservación es menor que el correspondiente a la de Semijoins; por otra parte, el tamaño de la reducción de Reservación tiende a ser más grande y el costo del envío de la reducción y de hacer el join con Marinero es mayor.






Leer lo Necesario


Semijoins





15

Agenda


Optimización Basada en Costos

Hemos visto como la distribución de datos pueden afectar la implementación de operaciones individuales, como una selección, adición, etc. En general, un query involucra severas operaciones, y la optimización de esta en una BD distribuida nos trae los siguientes retos:

*El costo de la comunicación debe ser considerado. Si tenemos muchas copias de una relación, debemos decidir cual copia usar.

*Si cada sitio corre individualmente bajo el control de diferentes DBMS, la autonomía de cada sitio debe ser respetada cuando se hacen planes de queries globales.

La optimización de queries se hace básicamente como en las BD Centralizadas, claro que hay nuevos métodos para las operaciones (por ejemplo: joins distribuidos).






Leer lo Necesario


Semijoins





Agenda


ACTUALIZACIÓN DE LA DATA DISTRIBUIDA

En relación a las actualizaciones, igualmente las transacciones deben continuar siendo atómicas, sin importar que la data este fragmentada o replicada. Hay dos maneras de actualizar las copias de una relación modificada:

- Replicación sincrónica. - Replicación asincrónica.






Leer lo Necesario


Semijoins





16

Agenda


Replicación sincrónica

Es cuando todas las copias de la relación modificada son actualizadas antes que la transacción que las modificó haga commit. Aquí se aplican 2 técnicas:

- Voting (votando): Una transacción debe escribir la mayoría de las copias para modificar un objeto y leer al menos suficientes copias para asegurarse que esa copia está presente.

Esta técnica no es muy recomendada ya que en la mayoría de los casos leer un objeto

requiere leer múltiples copias, y en muchas aplicaciones, los objetos son leídos con más

frecuencia que actualizados, es así la eficiencia en cuanto a lectura muy importante.






Leer lo Necesario


Semijoins





Agenda


Replicación sincrónica

- Read-any write-all (Leer cualquiera, escribir todas): Para leer un objeto, una transacción puede leer cualquier copia, pero para escribir un objeto, ésta debe escribir todas las copias. Las lecturas son rápidas, especialmente si tenemos una copia local, pero escribir se vuelve muy lento, en relación con la técnica Voting.

Esta técnica (read-any write-all) recomendada cuando las lecturas son más frecuentes que las escrituras, y es la más usada a la hora de implementar la replicación síncrona.






Leer lo Necesario


Semijoins





17

Agenda



Es la más ampliamente usada a nivel comercial en los DBMSs. Aquí las copias de una relación modificada son actualizadas solo periódicamente y una transacción que lea diferentes copias de la misma relación puede leer diferentes valores. Este tipo de replicación compromete la independencia de la data distribuida.

La replicación asíncrona trae consigo un costo significativo. Antes que una transacción de actualización pueda hacer commit, esta debe obtener los locks sobre todas las copias –asumiendo el uso de la técnica read-any write-all -de la data modificada. La transacción puede haber mandado solicitudes de lock a sitios remotos y esperar por los locks, pero durante este periodo ella mantiene sus otros locks.






Leer lo Necesario


Semijoins





Agenda



Si el sitio o el enlace de comunicación fallan, la transacción no puede hacer commit hasta que todos los sitios a los cuales les ha modificado la data se recuperen. Por todo esto, la replicación asíncrona no es deseable e inclusive inalcanzable en muchas situaciones. El hecho de mantener copias con distintitos valores de una misma relación ocasiona la inconsistencia de los datos.

Este tipo de replicación tiene dos formas:

- De Sitio Primario: Una copia de la relación es designada como copia maestra o primaria. Las réplicas o los fragmentos de la relación completa pueden ser creados en otros sitios; estas serían copias secundarias, y a diferencia de la copia primaria; pueden no ser actualizadas.






Leer lo Necesario


Semijoins





18

Agenda



Un mecanismo común para establecer las copias primaria y secundaria es que los usuarios primero registran la relación en el sitio primario y subsecuentemente suscriben

Un fragmento de la relación registrada en otro (secundario) sitio.

- Par a Par: Más de una copia (aunque no todas) puede ser designada como actualizables, esta es una copia maestra. Además para propagar los cambios,

Una resolución de conflicto puede ser usada para lidiar con el hecho de hacer el cambio en los diferentes sitios. Esta es la más utilizada.






Leer lo Necesario


Semijoins





Agenda


TRANSACCIÓN DISTRIBUIDA

Las transacciones realizadas en bases de datos distribuidas puede acceder a otros sitios, los cuales se les llama subtransacciones.

Cuando una transacción es remitida de un lugar, el manejador de transacciones de ese lugar divide la transacción en colecciones de subtransacciones para ejecutar en diferentes lugares, que se ejecutara en sus respectivos manejadores de transacciones.

TRANSACCIÓN DISTRIBUIDACONTROL DE CONCURRENCIA

DISTRIBUIDACentralizadoCopia PrimariaTotalmente DistribuidoInterbloqueos Distribuidos

RECUPERACIÓN DISTRIBUIDAEjecución Normal y Protocolos

Comprometidos (Commit)Protocolo de Dos FasesReinicio luego de una fallaProtocolo de Tres Fases

19

Agenda


CONTROL DE CONCURRENCIA DISTRIBUIDA

El protocolo de control de concurrencia es el encargado de determinar que objeto almacenado utilizara un lock.

Para un ambiente distribuido existen varias técnicas para escoger dicho objeto y la elección de una de estas técnicas determinara la forma de administrar los locks.

Las técnicas a tratar son:

•Centralizado•Copia Primaria•Totalmente Distribuido





Agenda



Centralizado:

Cada sitio esta encargado de manejar los locks para todos los objetos que lo soliciten.





20

Agenda



Copia Primaria:

Una copia de cada objeto es designada como copia primaria. Todas las peticiones de locks y unlocks sobre una copia de este objeto son procesadas por el manejador de lock en el sitio donde la copia primaria está almacenada, sin importar donde la copia particular solicitada esté guardada.





Agenda



Totalmente Distribuido

Las peticiones de locks y unlocks sobre una copia de un objeto almacenado en un sitio son manejadas por el manejador de lock del mismo.





21

Agenda



Interbloqueos Distribuidos

Uno de los aspectos que requieren atención es la detección de interbloqueos al usar lockingen copia primaria y totalmente distribuido.

A diferencia de la técnica centralizada, la copia primaria y el totalmente distribuido no necesariamente se puede detectar un interbloqueo con el grafo de espera local, hay que revisar los grafos de espera global.





Agenda



Por ejemplo supóngase que 2 sitios, A y B, ambos contienen copias de los objetos O1 y O2, y que la técnica usada es read-any write-all. Tenemos las transacciones: T1 en A (quiere leer O1 y escribir O2) y T2 en B (quiere leer O2 y escribir O1):

T1: T2:Begin BeginS-lock O1 at sitio A S-lock O2 at sitio BX-lock O2 at sitio A X-lock O1 at sitio BX-lock O2 at sitio B X-lock O1 at sitio A





T1 T2T1 T2T1 T2

En el lugar A

T1 T2T1 T2T1 T2

En el lugar B

T1 T2T1 T2T1 T2

Espera global

22

Agenda



Para detectar este caso, existen tres algoritmos para detección de interbloqueos distribuidos:

• Centralizado: envía periódicamente todos los grafos de espera locales de cada sitio a un lugar designado para la detección de interbloqueos, y allí el algoritmo realiza una unión de todos los grafos locales recibidos formando un grafo de espera global en el que detecta interbloqueos.





Agenda



• Jerárquico: este algoritmo es orientado a BDD a nivel de países, en el que los sitios se forman en grupos por estados, y luego por país y finalmente por un grupo que tenga todos los grupos. Cada nodo realiza un grafo que revela los interbloqueos locales, y cada uno de estos envían periódicamente dichos grafos al lugar encargado de hacer el grafo estadal y así ver los interbloqueos estadales. Luego estos envían periódicamente ese grafo al lugar donde se encarga de hacer los grafos por país que a su vez hacen un grafo y lo envían al sitio que finalmente realiza el grafo de espera global.





23

Agenda


CONTROL DE CONCURRENCIA DISTRIBUIDATRANSACCIÓN DISTRIBUIDA


CentralizadoCopia PrimariaTotalmente DistribuidoInterbloqueos Distribuidos



Y el último algoritmo es el más simple: aborta toda transacción que su tiempo de ejecución sobrepase un tiempo estipulado llamado time-out. Este tiene el problema que si se escoge mal el time-out ocurrirán muchos reinicios innecesarios.

Agenda


RECUPERACIÓN DISTRIBUIDATRANSACCIÓN DISTRIBUIDACONTROL DE CONCURRENCIA




La recuperación de fallas en un DDBMS es mas complicado que las de un DBMS por:

• Aparecen nuevas clases de fallas: una falla de comunicación y la falla de algún sitio que se encontraba ejecutando una subtransacción.• O todas las transacciones llegan al commito no lo hacen, sin importar fallas de comunicación o de la localización de un sitio.

Esto es garantizado al usar un protocolo de commit.

24

Agenda






Ejecución Normal y Protocolos de Commit:

Durante la ejecución normal cada sitio mantiene su log, y las acciones de las subtransacciones son logged en el sitio donde son ejecutadas. El manejador de transacciones en el sitio donde ésta se originó es llamado el coordinador para la transacción, los manejadores de transacciones en los sitios donde las subtransacciones se ejecutan son llamados subordinados (con respecto al coordinador de esa transacción).

Agenda






Protocolo de Dos Fases: Cuando el usuario decide hacer commit en una transacción, el comando de commit es mandado al coordinador para la transacción. Los pasos son los siguientes:

1. El coordinador manda un mensaje prepárense a cada subordinado.

2. Cuando el subordinado recibe el mensaje prepárense, decide si abortar o hacer commiten su subtransacción. Él fuerza la escritura de un abort o preparado en el log, y luego manda un mensaje de si o no al coordinador.

25

Agenda






3. Si el coordinador recibe un mensaje de si de todos los subordinados, fuerza la escritura del commit en los registros del log y luego manda un mensaje de commit a todos los subordinados. Caso contrario o algunos de los subordinados no responde en intervalo de tiempo específico, fuerza la escritura de aborten el log, y manda un mensaje de aborten a los subordinados.

Agenda






4. Cuando un subordinado abort este fuerza la escritura de abort en el log, y manda un mensaje de ack al coordinador, y aborta la subtransacción. Cuando un subordinado commit fuerza la escritura de commit al log, y manda un mensaje de ack al coordinador, luego hace commit con su transacción.

5. Finalmente el coordinador recibe todos los ack de sus subordinados y escribe en el log end para la transacción.

26

Agenda






Reinicio luego de una falla: Al momento de hacer una recuperación se aplican los siguientes pasos:

*Si tenemos un commit o un abort de la transacción T, limpiamos la transacción, aplicamos REDO o UNDO (según el caso).Si este sitio es el coordinador, el cual puede determinar los commits y los aborts a partir del log, debemos periódicamente reenviar un commit o un abort a cada subordinado hasta que recibamos un ack. Después de recibidos los acks de todos los subordinados, se escribe un end en el log para T.

Agenda






*Si nos preparamos para escribir en log para la transacción T, pero esta no a enviado ni commit ni un abort; entonces este sitio es subordinado, y el coordinador puede estar determinado para preparado para grabar en el log. Debemos repetidamente contactar al coordinador del sitio y determinar el estatus de T. Una vez que el coordinador responda con cualquiera de las dos commit o abort, escribimos el correspondiente registro log, aplicamos REDO o UNDO (según sea el caso) y escribimos end de la transacción en el log.

27

Agenda






*Si no nos preparamos, escribimos un commit o un abort en el registro del log para la transacción T; seguramente T no había hecho commit antes de la falla, entonces podemos abortar unilateralmente y deshacemos (UNDO) T y escribir un end en el registro log. En este caso no tenemos manera de determinar si el presente sitio es coordinador o subordinado para T. Sin embargo, si el sitio coordinador para una transacción T falla, los subordinados que votaron si no pueden decidir si hacen commit o abort a T hasta que el coordinador se recupere; decimos entonces que T estábloqueada.

Agenda






Es una mejora al protocolo de 2 fases. La idea básica es que, cuando el coordinador mande el mensaje prepárense y reciba el mensaje de si de todos los subordinados, manda a todos los sitios un mensaje de precommit. Cuando un número suficiente de acks han sido recibidos, se hace commit en el registro log y manda un mensaje de commit a todos los subordinados. Este protocolo impone un costo adicional durante la ejecución normal y requiere que las fallas en los enlaces de comunicación no conlleven a la partición de la red, para asegurar estar libre de bloqueos. Por esta razón no se usa en la práctica.

Date post:	01-Oct-2018
Category:	Documents
Upload:	vanthuan
View:	221 times
Download:	1 times

Base de Datos Distribuidas -...

Documents