database - ¿Cómo las confirmaciones de dos fases previenen la falla de último segundo?
distributed-transactions (5)
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 le pregunta a cada nodo si está listo para comprometerse. Si todos estuvieron de acuerdo, les dice que sigan adelante y se comprometan.
¿Qué previene la siguiente falla?
- Todos los nodos responden que están listos para comprometer
- El coordinador de transacciones les dice que "continúen y se comprometan", pero uno de los nodos falla antes de recibir este mensaje
- Todos los otros nodos se comprometen correctamente, pero ahora la transacción distribuida está corrupta
- Tengo entendido que cuando el nodo bloqueado regrese, su transacción se habrá retrotraído (ya que nunca recibió el mensaje de confirmación)
Supongo que cada nodo ejecuta una base de datos normal que no sabe nada sobre las transacciones distribuidas. ¿Qué me perdí?
El compromiso en dos fases no es infalible y está diseñado para funcionar en el 99% de los casos.
"El protocolo asume que hay un almacenamiento estable en cada nodo con un registro de escritura anticipada, que ningún nodo falla para siempre, que los datos en el registro de escritura anticipada nunca se pierden o corrompen en un bloqueo, y que dos nodos pueden comunicarse juntos."
Hay muchas maneras de atacar los problemas con la confirmación en dos fases. Casi todos terminan como una variante del algoritmo de compromiso trifásico de Paxos. Mike Burrows, quien diseñó el servicio de bloqueo Chubby en Google, que está basado en Paxos, dijo que hay dos tipos de algoritmos de compromiso distribuidos: "Paxos e incorrectos" en una conferencia que vi.
Una cosa que el nodo accidentado podría hacer, cuando reactiva, es decir: "Nunca escuché acerca de 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 que se recupere. Por lo tanto, es terriblemente importante que, después de la recuperación, deba hablar con el coordinador u otra réplica antes de estar disponible. Si el nodo en sí no puede decir si se ha bloqueado o no, entonces las cosas se vuelven más complicadas pero aún tratables.
Si usa un sistema de quórum para las lecturas de la base de datos, la incoherencia quedará enmascarada (y se dará a conocer a la base de datos misma).
No, no se les ordena retroceder 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 vuelva a comprometerse.
Debido a que el nodo respondió positivamente en la fase de "preparación", se requiere poder "comprometer", incluso cuando se recupera de un bloqueo.
No. El punto 4 es incorrecto. Cada nodo registra en un almacenamiento estable que pudo confirmar o deshacer la transacción, de modo que podrá hacer lo que se le indique, incluso en caso de fallas. Cuando el nodo bloqueado vuelve a subir, debe darse cuenta de que tiene una transacción en estado de precomisión, restablecer los bloqueos relevantes u otros controles, y luego intentar ponerse en contacto con el sitio del coordinador para recopilar el estado de la transacción.
Los problemas solo ocurren si el nodo bloqueado nunca vuelve a aparecer (entonces todo lo demás piensa que la transacción fue correcta, o lo será cuando el nodo fallado vuelva a aparecer).
Resumiendo las respuestas de todos:
No se pueden usar bases de datos normales con transacciones distribuidas. La base de datos debe admitir explícitamente un coordinador de transacciones.
Los nodos no reciben instrucciones de retroceder porque algunos de los nodos ya se han confirmado. Lo que sucede es que cuando el nodo bloqueado vuelve, el coordinador de transacciones le dice que se vuelva a comprometer.