Recuperación de fallas en Two Phase Commit Protocol (Distributed Transaction)

Protocolo de confirmación de dos fases
En el protocolo de confirmación de dos fases, los sitios que contribuyen a una transacción distribuida y el coordinador que administra toda la transacción globalmente pueden fallar o colapsar, y esto podría conducir a la falla de toda la transacción. Dado que se requiere unanimidad para comprometer una transacción distribuida con éxito si alguno de los sitios falla, toda la transacción se cancelará.

Se pueden encontrar los siguientes tipos de fallas en el protocolo de compromiso de 2 fases:
Falla del sitio contribuyente : si el coordinador (C) detecta que un sitio se bloqueó, entonces el coordinador toma las siguientes acciones:

Si el sitio (Si) ha fallado antes de responder con un mensaje <T listo> al Coordinador (C), el coordinador asume que el sitio ha respondido con un mensaje <T abortar> .
Si el sitio ha fallado después de enviar el mensaje <ready T> a C, el coordinador ignorará la falla del sitio y ejecutará el resto del protocolo de compromiso de la manera habitual.
Cuando el sitio fallido (Si) se recupere de la falla, el sitio examinará su registro para conocer el destino de la transacción T . si ha fallado o no-

• Si el registro contiene un registro <Commit T> , en este caso, el sitio ejecutará <redo T>.
• Si el registro contiene un registro <abort T> , en este caso, el sitio ejecuta <undo T>.
• Un caso muy importante, si el registro de registro contiene la <T lista>, en este caso, el sitio debe comunicarse con el Coordinador (C). Pero, si el C ha fallado, entonces en este caso el Sitio (Si) debe consultar los sitios vecinos y verificar su estado de registro si la transacción (T) se ha ejecutado o abortado en su ausencia.
• Si todos los sitios no pueden dar una respuesta adecuada, en este caso el sitio (Si) debe esperar a que el coordinador se recupere o la respuesta adecuada de los sitios vecinos.
• Por lo tanto, Si debe consultar periódicamente sobre el destino de la transacción mediante el envío de mensajes de consulta a otros sitios.

Si el registro no contiene ningún registro (abortar, confirmar, listo) sobre la transacción T , entonces sabemos que Si ha fallado antes de responder al mensaje <preparar T> de Ci. Por lo tanto, Ci debe abortar y ejecutar <deshacer T>.

Falla del coordinador (Ci): si el coordinador falla en medio de la ejecución de la transacción T en el protocolo de compromiso de 2 fases, los sitios participantes deben decidir el destino de la transacción T. En ciertos casos, los sitios participantes no pueden decidir si confirmar o abortar la transacción T y, por lo tanto, estos sitios deben esperar a que se recupere el coordinador fallido.

• Si todos los sitios contienen un registro <commit T> en su registro, entonces T debe ser commit.
• Si todo el sitio contiene un registro <abortar T> en su registro, entonces T debe ser abortado.
• Si algunos sitios no contienen el registro <T listo> en su registro, entonces el coordinador fallido (C) no puede decidir confirmar/abortar, por lo que el sitio no puede responder al mensaje <preparar T> del coordinador. por lo tanto, será mejor abortar la transacción en lugar de esperar.
• Si ninguno de los casos anteriores se cumple, entonces todo el sitio activo tiene un registro <T listo> en su registro, pero no se encontrará ningún otro registro ya que el coordinador falló. Es imposible determinar si se tomó una decisión de compromiso/abortar a menos que el coordinador (C) se recupera. Entonces, todos los sitios tienen que esperar la recuperación del coordinador. Esta situación se llama Problema de Bloqueo.  

                                  La solución al problema de bloqueo es el protocolo de compromiso trifásico.

Particionamiento de la red : no es más que un tipo de falla en la que la conectividad de la red se divide entre las particiones o los Nodes debido a una falla. Cuando ocurre el particionamiento de la red, pueden ocurrir los siguientes dos casos:

• El coordinador y todos los sitios participantes permanecen en una partición de red, luego las fallas de red tienen un impacto en el protocolo de confirmación.
• Si todos los sitios participantes y el coordinador pertenecen a dos o más particiones diferentes, desde el punto de vista del sitio, los sitios cuya partición no tiene el coordinador han fallado y comienzan el protocolo de recuperación mientras que los otros sitios simplemente se ejecutan cuya partición contiene el coordinador y siga el protocolo habitual de 2PC.

henry_korth