database - Compromiso de dos fases

distributed-transactions (3)

Creo que la mayoría de la gente sabe qué es 2PC (protocolo de confirmación en dos fases) y cómo usarlo en Java o en la mayoría de los idiomas modernos. Básicamente, se usa para garantizar que las transacciones estén sincronizadas cuando tienes 2 o más DB.

Supongamos que tengo dos DB (A y B) usando 2PC en dos ubicaciones diferentes. Antes de que A y B estén listos para comprometer una transacción, ambos DB informarán al gerente de transacciones diciendo que están listos para comprometerse. Entonces, cuando se acuse de recibo al administrador de transacciones, enviará una señal a A y B indicándoles que continúen.

Aquí está mi pregunta: digamos que A recibió la señal y cometió la transacción. Una vez que todo está completo, B está a punto de hacer lo mismo, pero alguien desenchufa el cable de alimentación, lo que hace que se cierre todo el servidor. Cuando B vuelve a estar en línea, ¿qué hará B? ¿Y cómo lo hace B?

Recuerde, A está comprometido pero B no, y estamos usando 2PC (entonces, el diseño de 2PC deja de funcionar, ¿no?)

Creo que el compromiso de tres fases es un enfoque mucho mejor. Lamentablemente, no he encontrado a nadie implementando tal tecnología.

http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/

Aquí están las partes esenciales del artículo anterior:

La dificultad fundamental con 2PC es que, una vez que el coordinador ha tomado la decisión de comprometerse y se la comunica a algunas réplicas, las réplicas siguen adelante y actúan sobre la declaración de compromiso sin verificar si cada otra réplica recibió el mensaje. Luego, si una réplica que cometió fallas junto con el coordinador, el sistema no tiene forma de decir cuál fue el resultado de la transacción (ya que solo el coordinador y la réplica que obtuvo el mensaje lo saben con certeza). Dado que la transacción podría haberse comprometido en la réplica bloqueada, el protocolo no puede abortar de forma pesimista, ya que la transacción podría tener efectos colaterales que son imposibles de deshacer. De manera similar, el protocolo no puede obligar de manera optimista a la transacción a comprometerse, ya que el voto original podría haber sido abortar.

Este problema es, en su mayoría, eludido por la adición de una fase extra a 2PC, como era de esperar, nos dio un protocolo de confirmación de tres fases. La idea es muy simple. Rompemos la segunda fase de 2PC - ''commit'' - en dos subfases. El primero es la fase "prepararse para comprometerse". El coordinador envía este mensaje a todas las réplicas cuando ha recibido votos unánimes "sí" en la primera fase. Al recibir estos mensajes, las réplicas llegan a un estado en el que pueden comprometer la transacción (al tomar bloqueos necesarios, etc.) pero, fundamentalmente, no realizan ningún trabajo que luego no puedan deshacer. Luego responden al coordinador diciéndole que se recibió el mensaje "prepararse para comprometerse".

El propósito de esta fase es comunicar el resultado del voto a cada réplica para que el estado del protocolo se pueda recuperar sin importar qué réplica fallezca.

La última fase del protocolo hace casi exactamente lo mismo que la fase original ''commit or abort'' en 2PC. Si el coordinador recibe confirmación de la entrega del mensaje "preparar para comprometerse" de todas las réplicas, entonces es seguro continuar con la transacción. Sin embargo, si no se confirma la entrega, el coordinador no puede garantizar que el estado del protocolo se recupere en caso de que se bloquee (si tolera un número fijo de fallas, el coordinador puede continuar una vez que haya recibido f + 1). confirmaciones). En este caso, el coordinador abortará la transacción.

Si el coordinador se cuelga en cualquier punto, un nodo de recuperación puede hacerse cargo de la transacción y consultar el estado desde cualquier réplica restante. Si una réplica que ha comprometido la transacción se ha bloqueado, sabemos que cada otra réplica ha recibido un mensaje de "preparación para la confirmación" (de lo contrario, el coordinador no se habría movido a la fase de confirmación) y, por lo tanto, el nodo de recuperación será capaz de determinar que la transacción pudo ser comprometida, y guiar de manera segura el protocolo hasta su conclusión. Si alguna réplica informa al nodo de recuperación que no ha recibido ''prepare para confirmar'', el nodo de recuperación sabrá que la transacción no se ha confirmado en ninguna réplica y, por lo tanto, podrá abortar o volver a ejecutar de manera pesimista el protocolo desde el principio.

Entonces, ¿3PC soluciona todos nuestros problemas? No del todo, pero se acerca. En el caso de una partición de red, las ruedas se desprenden, imagine que todas las réplicas que recibieron ''prepararse para comprometer'' están en un lado de la partición, y las que no lo estaban en la otra. Entonces ambas particiones continuarán con nodos de recuperación que respectivamente comprometerán o abortarán la transacción, y cuando la red se fusione, el sistema tendrá un estado incoherente. Entonces, 3PC tiene ejecuciones potencialmente inseguras, al igual que 2PC, pero siempre progresará y, por lo tanto, satisface sus propiedades de vida. El hecho de que 3PC no bloquee las fallas de un solo nodo lo hace mucho más atractivo para los servicios donde la alta disponibilidad es más importante que las bajas latencias.

Su escenario no es el único donde las cosas pueden ir mal a pesar de todo el esfuerzo. Supongamos que A y B han informado que están "listos para comprometerse" con TM, y luego alguien desenchufa la línea entre TM y, por ejemplo, B. B está esperando el avance (o no-go) de TM, pero ciertamente ganó Siga esperando por siempre hasta que TM se vuelva a conectar (sus propios recursos involucrados en la transacción deben permanecer bloqueados / inaccesibles durante todo el tiempo de espera por razones obvias). Entonces, cuando B se mantiene esperando demasiado tiempo para su propio gusto, tomará lo que se llama "decisiones heurísticas". Es decir, decidirá comprometerse o deshacerse independientemente de TM, basado en, bueno, realmente no sé qué, pero eso en realidad no importa. Debería ser obvio que cualquiera de tales decisiones heurísticas puede desviarse de la decisión de cometer real tomada por TM.

En compromiso de dos fases

El compromiso en dos fases no garantiza que una transacción distribuida no pueda fallar, pero garantiza que no puede fallar silenciosamente sin que la TM lo conozca.

Para que B informe que la transacción está lista para comprometerse, B debe tener la transacción en un almacenamiento persistente (es decir, B debe poder garantizar que la transacción puede comprometerse en cualquier circunstancia). En esta situación, B ha persistido en la transacción, pero el administrador de transacciones aún no ha recibido un mensaje de B confirmando que B ha completado la confirmación.

El gerente de transacciones volverá a sondear a B cuando B vuelva a estar en línea y le pedirá que confirme la transacción. Si B ya ha comprometido la transacción, informará la transacción como comprometida. Si B aún no ha comprometido la transacción, se comprometerá porque ya la ha mantenido y, por lo tanto, aún puede comprometer la transacción.

Para que B falle en esta situación, tendría que sufrir una falla catastrófica que perdiera datos o entradas de registro. El administrador de transacciones aún sabría que B no informó una confirmación exitosa. ¹

En la práctica, si B ya no puede comprometer la transacción, implicaría que el desastre que eliminó B causó la pérdida de datos, y B informaría un error cuando la TM le pidiera que cometiera un TxID del que no tenía conocimiento o No pensé que estaba en un estado commitable.

Por lo tanto, la confirmación de dos fases no evita que ocurra una falla catastrófica, pero evita que la falla pase desapercibida. En este escenario, el administrador de transacciones informará un error a la aplicación si B no puede comprometerse.

La aplicación aún debe poder recuperarse del error, pero la transacción no puede fallar silenciosamente sin que la aplicación tenga conocimiento del estado incoherente.

Semántica

Si un administrador de recursos o una red desciende en la fase 1, el administrador de transacciones detectará un error fatal (no se puede conectar al administrador de recursos) y marcará la subtransacción como fallida. Cuando la red vuelva a funcionar, cancelará la transacción en todos los administradores de recursos participantes.
Si un administrador de recursos o una red deja de funcionar en la fase 2, el administrador de transacciones continuará sondeando al administrador de recursos hasta que vuelva a funcionar. Cuando se vuelva a conectar con el administrador de recursos, le indicará al RM que confirme la transacción. Si el RM devuelve un error en la línea de ''TxID desconocido'', la TM sabrá que hay un problema de pérdida de datos en el RM.
Si la TM cae en la fase 1, el cliente bloqueará hasta que la TM vuelva a subir, a menos que se agote el tiempo o reciba un error debido a una conexión de red interrumpida. En este caso, el cliente conoce el error y puede volver a intentarlo o iniciar el mismo.
Si la TM cae en la fase 2, bloqueará al cliente hasta que la TM vuelva a subir. Ya ha informado que la transacción es comisionable y no se debe presentar ningún error fatal al cliente, aunque puede bloquearse hasta que la TM vuelva a funcionar. La TM seguirá teniendo la transacción en un estado no comprometido y encuestará a los RM para que se comprometan cuando vuelva a aparecer.

Los eventos de pérdida de datos posteriores a la confirmación en los administradores de recursos no son manejados por el administrador de transacciones y son una función de la capacidad de recuperación de los RM.

El compromiso en dos fases no garantiza la tolerancia a fallas (consulte Paxos para ver un ejemplo de un protocolo que trata la tolerancia a fallas), pero garantiza que la falla parcial de una transacción distribuida no puede pasar inadvertida.

Tenga en cuenta que este tipo de falla también podría perder datos de transacciones previamente comprometidas. La confirmación en dos fases no garantiza que los administradores de recursos no puedan perder o dañar datos o que los procedimientos de DR no se dañen.