Protocolo de replicaci´ on de Middle-R

La base de datos est´a dividida en clases de conflicto b´asicas. Las clases de conflicto b´asicas siempre son disjuntas y su granularidad puede ser una tabla u otro nivel de gra- nularidad m´as fino espec´ıfico de la aplicaci´on. Las clases de conflicto b´asicas se agrupan a su vez en clases de conflicto compuestas. Las clases de conflicto compuesta no tienen porque ser disjuntas, pero si diferentes. Cada clase de conflicto tiene una r´eplica maestra. Una transacci´on T puede acceder a cualquier clase de conflicto (CT) y Middle-R puede

identificar las clases de conflicto a las que accede la transacci´on, bien autom´aticamente, bien con informaci´on proporcionada por la aplicaci´on.

La selecci´on de la r´eplica maestra para las clases de conflicto con m´ultiples objetos se realiza utilizando una funci´on determinista (e.g. una funci´on hash como SHA-1) que se aplica a la clase de conflicto b´asica a los que accede la transacci´on, de esta forma cada transacci´on tiene una r´eplica maestra y s´olo es necesario asignar r´eplica maestra a las clases de conflicto b´asicas en lugar de tener que hacerlo a todas las posibles combinaciones de objetos. Los algoritmos que resuelven los conflictos y su correcci´on est´an descritos en [PMJPKA00].

Supongamos dos r´eplicas N1 y N2 y dos clases de conflicto b´asicas Cx y Cy. Sea N1 la

r´eplica maestra de la clase de conflicto {Cx} y N2 la r´eplica maestra de las clases de

conflicto {Cy} y {Cx, Cy}. Una transacci´on que actualice Cx es local en la r´eplica N1

y remota en la r´eplica N2. Y una transacci´on que actualice Cx y Cy, ser´a local en la

r´eplica N2 y remota en la r´eplica N1.

Para el control de concurrencia cada r´eplica tiene una cola CQx asociada a cada

clase de conflicto b´asica Cx. Cuando se entrega una transacci´on T que accede a una

clase de conflicto CT, cada r´eplica a˜nade T a las colas de las clases de conflicto b´asicas

contenidas en CT.

La ejecuci´on de la transacci´on T es de la siguiente forma, el cliente env´ıa la petici´on al sistema utilizando las primitivas de radiado. Cuando la transacci´on est´a la primera en todas las colas, la r´eplica maestra ejecuta la transacci´on: Env´ıa la transacci´on a la base de datos, ´esta la ejecuta y devuelve los “write sets” al middleware y compromete de forma local la transacci´on. El middleware env´ıa los “write sets” a las dem´as r´eplicas de Middle-R utilizando las primitivas de radiado para que ´estos apliquen los cambios. La r´eplica que recibi´o originariamente la petici´on env´ıa al cliente la confirmaci´on del compromiso una vez que haya recibido e instalado el “write set” o, si es la r´eplica maestra, haya realizado el compromiso localmente.

La figura 3.1 muestra la ejecuci´on de una transacci´on de actualizaci´on en Middle-R.

Réplica 1 Réplica 2 Réplica n

…

GetState SetState SetState

Transacción Propagación de actualizaciones Capa de middleware Capa de base de datos Middle-R Base de datos Middle-R Base de datos Middle-R Base de datos

Figura 3.1: Protocolo de replicaci´on de Middle-R

Para cada transacci´on de actualizaci´on se radian dos mensajes: un mensaje con la transacci´on y un mensaje de compromiso con las actualizaciones realizadas (los “write set”). Los mensajes de compromiso se radian de forma fiable y no es necesario garan- tizar el orden. El radiado utilizado para enviar la transacci´on a todas las r´eplicas debe realizarse con orden total ya que este orden se utiliza para determinar el orden de se- rializaci´on de las transacciones. Middle-R utiliza un sistema de entrega optimista con

radiado con orden total que se aprovecha del hecho de que en las redes de ´area local los mensajes est´an ordenados totalmente de forma espont´anea. Para realizar esto Middle-R proporciona el siguiente conjunto de primitivas:

TO-multicast(m) radia el mensaje m a todas las r´eplicas del sistema.

OPT-deliver(m) entrega el mensaje m de forma optimista.

TO-deliver(m) entrega el mensaje m de forma definitiva (en orden total)

Una secuencia de mensajes entregados de forma optimista (OPT-deliver) es un orden tentativo, mientras que una secuencia de mensajes entregados de forma definitiva (TO- deliver) representa el orden definitivo u orden total. Los mensajes pueden ser entregados de forma optimista en un orden diferente en cada r´eplica, pero el orden de entrega definitivo es el mismo en todas las r´eplicas. Adem´as ninguna r´eplica puede realizar la entrega definitiva de un mensaje antes de realizar la entrega optimista.

Realizando la entrega de los mensajes en dos pasos es posible superponer la ejecuci´on de la transacci´on con el tiempo necesario para determinar el orden total. Una petici´on es entregada de forma optimista tan pronto como es recibida y puede comenzar su ejecuci´on antes de que se haya establecido el orden definitivo.

El algoritmo 1 muestra el pseudo-c´odigo del protocolo de replicaci´on utilizado en Middle-R. El protocolo se describe a partir de los diferentes eventos que ocurren durante la vida de una transacci´on T : T es entregada de forma optimista (OPT-deliver), T es entregada de forma definitiva (TO-deliver), T completa la ejecuci´on y T compromete. Una transacci´on s´olo puede comprometer cuando ha sido ejecutada y entregada de forma definitiva.

Cuando una transacci´on es entregada de forma optimista, se encola en las colas de todas las clases de conflicto a las que accede en todas las r´eplicas. Cuando T es la primera transacci´on en todas las colas, la r´eplica maestra de T env´ıa la transacci´on a la base de datos para su ejecuci´on.

Cuando T completa su ejecuci´on en la r´eplica maestra, la entrega definitiva puede haberse realizado o no. Si ya se ha realizado la entrega definitiva, T puede comprometer ya que es la primera transacci´on en todas las colas de las clases de conflicto y no hay ninguna transacci´on conflictiva con T ni en el orden optimista, ni en el orden definitivo. El mensaje de compromiso (con el “write set”) es radiado a todas las r´eplicas. Si la transacci´on no ha sido entregada con orden definitivo, se marca como ejecutada y se espera a que se realice la entrega definitiva antes de realizar el compromiso, esto es necesario para evitar ´ordenes de serializaci´on conflictivos en diferentes r´eplicas.

Si cuando se realiza la entrega definitiva de T en la r´eplica maestra, T ya ha sido ejecutada porque era la primera en todas las colas, entonces no hay discordancia entre el orden optimista y el orden definitivo. T puede comprometer y el mensaje de compromiso (con el “write set”) es radiado a todas las r´eplicas. Si la transacci´on todav´ıa no ha sido ejecutada o no es local, el protocolo comprueba las discordancias entre el orden optimista y el orden definitivo que pudieran dar lugar a ejecuciones incorrectas. Si

Algoritmo 1 Algoritmo del protocolo de replicaci´on de Middle-R

Upon OPT-delivery of Ti

for each conflict class Cx ∈ CTi do

Append Ti to the queue CQx

end for

Once Ti is the first in all queues ∧Local(Ti)

Submit Ti for execution Upon TO-delivery of Ti

Mark Ti as committable

if Ti is executed then

Commit Ti

Remove Ti from all CTi

Broadcast commit(W STi)

else . Still active or not local

for each Cx ∈ CTi do

if F irst(CQx) = Tj∧ Local(Tj)∧ ¬Committable(Tj) then

Abort Tj

end if

Schedule Ti before the first not TO-delivered transaction in CQx

end for end if

Upon complete execution of Ti

if Ti is marked as committable then

Commit Ti

Remove Ti from all CTi

Broadcast commit(W STi)

else

Mark Ti as executed

end if

Upon receiving commit(W STi)

if ¬Local(Ti) then

Delay until Ti becomes committable∧Ti first in all the queues

Apply the updates of W STi

Commit Ti

Remove Ti from all CTi

alguna transacci´on conflictiva T0 fue entregada de forma optimista antes que T pero todav´ıa no ha sido entregada de forma definitiva (discordancia entre el orden optimista y el definitivo), T0 est´a ordenada de forma incorrecta antes que T en las colas comunes y hay que reordenarlas de forma que T est´e antes que T0. La reordenaci´on puede provocar el aborto de la transacci´on T0 si estaba ejecutando o ya se hab´ıa ejecutado y estaba esperando la entrega definitiva para comprometer. T0 s´olo tiene que abortar en la r´eplica local y no en todas las r´eplicas, en las r´eplicas remotas s´olo hay que cambiar el orden en las colas.

Una transacci´on local compromete enviando un compromiso a la base de datos. En las r´eplicas remotas, las actualizaciones (“write set”) recibidas en el mensaje de compromiso se aplican despu´es de que la transacci´on haya sido entregada con orden definitivo para garantizar que las actualizaciones se aplican con orden de serializaci´on total. Cuando las actualizaciones se han aplicado y los compromisos enviados a la base de datos, la transacci´on es eliminada de las colas.