Las transacciones se pueden realizar de manera efectiva utilizando el procesamiento de transacciones distribuidas. Sin embargo, hay casos en los que una transacción puede fallar por una variedad de causas. La falla del sistema, la falla del hardware, el error de la red, los datos inexactos o no válidos, los problemas de la aplicación son causas probables. Las fallas en las transacciones son imposibles de evitar. Estas fallas deben ser manejadas por el sistema de transacciones distribuidas. Cuando surgen errores, uno debe ser capaz de identificarlos y corregirlos. Transaction Recovery es el nombre de este procedimiento. En bases de datos distribuidas, el procedimiento más difícil es la recuperación. Es extremadamente difícil recuperar un sistema de red de comunicación que ha fallado.
Consideremos el siguiente escenario para analizar cómo puede ocurrir una falla en la transacción. Supongamos que tenemos dos personas X e Y. X envía un mensaje a Y y espera una respuesta, pero Y no puede recibirlo.
Los siguientes son algunos de los problemas con esta circunstancia:
- El mensaje no se envió debido a un problema de red.
- La comunicación enviada por la ubicación B no se entregó al lugar A.
- La ubicación B fue destruida.
- Como resultado, localizar el origen de un problema en una gran red de comunicación es un gran desafío.
La confirmación distribuida en la red es otro problema importante que puede causar estragos en la recuperación de una base de datos distribuida.
Uno de los métodos más famosos de recuperación de transacciones es el » Protocolo de confirmación de dos fases». El coordinador y el subordinado son los dos tipos de Nodes que utiliza el Protocolo de confirmación de dos fases para llevar a cabo sus procedimientos. El proceso del coordinador está vinculado a la aplicación del usuario y se forman canales de comunicación entre los subordinados y el coordinador.
El protocolo de compromiso de dos fases contiene dos etapas, como su nombre lo indica. El primer paso es la fase de PREPARACIÓN, en la que el coordinador de la transacción entrega un mensaje de PREPARACIÓN. El segundo paso es la fase de toma de decisiones, en la que el coordinador envía un mensaje COMMIT si todos los Nodes pueden completar la transacción, o un mensaje de cancelación si al menos un Node subordinado no puede. 2PC centralizado, 2PC lineal y 2PC distribuido son todas formas que se pueden usar para realizar el 2PC.
- 2PC Centralizado : El contacto en el 2PC Centralizado se limita al proceso del coordinador y no se permite la comunicación entre subordinados. El coordinador es el encargado de enviar el mensaje PREPARE a los subordinados, y una vez recibidos y analizados todos los votos de los subordinados, el coordinador elige si abortar o comprometer. Hay dos etapas en este método:
- La Primera Fase: Cuando un usuario desea COMMITIR una transacción durante esta fase, el coordinador envía un mensaje de PREPARACIÓN a todos los subordinados. Cuando un subordinado recibe el mensaje PREPARE, registra un registro PREPARE y envía un VOTO SÍ y entra en el estado PREPARADO si el subordinado está dispuesto a COMPROMETERSE; o crea un registro de cancelación y envía un VOTO NO si el subordinado no está dispuesto a COMPROMETERSE. Debido a que sabe que el coordinador emitirá un aborto, un subordinado que transmite un VOTO SIN VOTO no necesita ingresar al estado PREPARADO. En esta situación, el VOTO NO funciona como un veto ya que solo se requiere un VOTO NO para cancelar la transacción.
- Segunda Fase: Después de que el coordinador haya tomado una decisión, debe comunicar esa decisión a los subordinados. Si se elige COMMIT, el coordinador ingresa al estado de compromiso y envía un mensaje COMMIT a todos los subordinados notificándoles la elección. Cuando los subordinados reciben el mensaje COMMIT, pasan al estado de compromiso y envían al coordinador un mensaje de reconocimiento (ACK). La transacción se completa cuando el coordinador recibe los mensajes ACK. Si el coordinador, por otro lado, toma una decisión ABORT, envía un mensaje ABORT a todos los subordinados. En este caso, el coordinador no necesita enviar un mensaje ABORT a los subordinados NO VOTE.
- Lineal 2PC: Los subordinados en el linear 2PC pueden comunicarse entre sí. Los sitios están numerados del 1 al N, siendo el sitio 1 el coordinador. Como resultado, el mensaje PREPARE se propaga de forma secuencial. Como resultado, la transacción tarda más en completarse que los enfoques centralizados o dispersos. Finalmente, es el Node N el que envía el COMMIT global.
- Distributed 2PC: Todos los Nodes de un 2PC distribuido interactúan entre sí. A diferencia de otras técnicas 2PC, este procedimiento no requiere la segunda fase. Además, para saber que cada Node ha emitido su voto, cada Node debe tener una lista de todos los Nodes participantes. Cuando el coordinador entrega un mensaje PREPARAR a todos los Nodes participantes, se inicia el 2PC distribuido. Cuando un participante recibe el mensaje PREPARE, transmite su voto a todos los demás participantes. Como resultado, cada Node realiza un seguimiento de los participantes de cada transacción.