¿Cómo las confirmaciones de dos fases previenen el fallo del último segundo?

Question

Estoy estudiando cómo funciona la confirmación en dos fases en una transacción distribuida. Entiendo que en la última parte de la fase, el coordinador de transacciones pregunta a cada nodo si está listo para comprometerse. Si todos estuvieron de acuerdo, entonces les dice que sigan adelante y se comprometan.

¿Qué evita el siguiente error?

1. Todos los nodos responden que son listo para comprometerse
2. La transacción El coordinador les dice: "adelante". y cometer " pero uno de los nodos se bloquea antes de recibir esto mensaje
3. Todos los demás nodos se comprometen correctamente, pero ahora la transacción distribuida está dañada
4. Tengo entendido que cuando el nodo bloqueado regrese, su transacción habrá sido revertida (ya que nunca recibió el mensaje de confirmación)

Supongo que cada nodo está ejecutando una base de datos normal que no sabe nada acerca de las transacciones distribuidas. ¿Qué extrañé?

Answer 1

Resumiendo las respuestas de todos:

1. Uno no puede usar bases de datos normales con transacciones distribuidas. La base de datos debe admitir explícitamente a un coordinador de transacciones.

2. Los nodos no tienen instrucciones de retroceder porque algunos de los nodos ya se han confirmado. Lo que sucede es que cuando el nodo bloqueado regresa, el coordinador de transacciones le dice que finalice la confirmación.

Answer 2

No, no se les indica que retrocedan porque en el escenario del póster original, algunos de los nodos ya se han comprometido. Lo que sucede es que cuando el nodo bloqueado está disponible, el coordinador de transacciones le dice que se comprometa nuevamente.

Debido a que el nodo respondió positivamente en la sección " preparar " fase, se requiere para poder "confirmar", incluso cuando se trata de un bloqueo.

Answer 3

No. El punto 4 es incorrecto. Cada nodo registra en el almacenamiento estable que pudo cometer o revertir la transacción, de modo que podrá hacer lo que se le ordenó incluso a través de bloqueos. Cuando el nodo bloqueado vuelve a activarse, debe darse cuenta de que tiene una transacción en estado de confirmación previa, restablecer los bloqueos relevantes u otros controles, y luego intentar comunicarse con el sitio del coordinador para recopilar el estado de la transacción.

Los problemas solo ocurren si el nodo bloqueado nunca vuelve a funcionar (entonces todo lo demás piensa que la transacción estuvo bien, o lo será cuando regrese el nodo bloqueado).

Answer 4

La confirmación de dos fases no es infalible y solo está diseñada para funcionar en el 99% de los casos.

" El protocolo supone que hay un almacenamiento estable en cada nodo con un registro de escritura anticipada, que ningún nodo se bloquea para siempre, que los datos en el registro de escritura anticipada nunca se pierden o corrompen en una falla, y que cualquier dos nodos pueden comunicarse entre sí. "

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Answer 5

Hay muchas formas de atacar los problemas con la confirmación de dos fases. Casi todos terminan como una variante del algoritmo de confirmación de tres fases de Paxos. Mike Burrows, quien diseñó el servicio de bloqueo Chubby en Google que se basa en Paxos, dijo que hay dos tipos de algoritmos de confirmación distribuidos: "Paxos, y los incorrectos". - En una conferencia que vi.

Una cosa que el nodo bloqueado podría hacer, cuando se despierta, es decir "Nunca escuché sobre esta transacción, ¿debería haberse cometido?" al coordinador, que le dirá cuál fue el voto.

Tenga en cuenta que este es un ejemplo de un problema más general: el nodo bloqueado podría perder muchas transacciones antes de recuperarse. Por lo tanto, es muy importante que, al recuperarse, hable con el coordinador u otra réplica antes de ponerse a disposición. Si el nodo en sí no puede saber si se ha estrellado o no, entonces las cosas se involucran más pero aún son manejables.

Si utiliza un sistema de quórum para las lecturas de la base de datos, la inconsistencia se ocultará (y se dará a conocer a la propia base de datos).