INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

UNIDAD CULHUACÁN.

SISTEMAS DISTRIBUIDOS.

UNIDAD V: CONTROL DE FALLOS

PROFESORA:
SALAS JIMENEZ VERÓNICA.

ALUMNO:
CRUZ HERNÁNDEZ JUAN CARLOS.

GRUPO:
8CM22.

FECHA DE ENTREGA: 02/Octubre/2022.

CIUDAD DE MÉXICO. 2022.

1
ÍNDICE
Tabla de ilustraciones ............................................................................................................................. 2
5.1 Casos de fallas ......................................................................................................................................... 4
5.1.1 Fallas locales .................................................................................................................................... 5
5.1.2 Fallos de sitios.................................................................................................................................. 6
5.1.3 Fallas de canal de comunicación ..................................................................................................... 6
5.2 Protocolos de recuperación .................................................................................................................... 7
5.2.1 UnDo/ ReDo ..................................................................................................................................... 8
5.2.2 No UnDo/ No ReDo ....................................................................................................................... 10
5.3 Protocolos de recuperación distribuidos .............................................................................................. 12
Referencias .................................................................................................................................................. 15

Tabla de ilustraciones

Ilustración 1 diagrama de comunicación entre servidores ................................................................. 5

Ilustración 2 descripción de UNDO/REDO ......................................................................................... 10
Ilustración 3 diagrama de funcionamiento de protocolos ................................................................ 12
Ilustración 4 representación de las fases de protocolo .................................................................... 13
2
Ilustración 5 funcionamiento de protocolos ..................................................................................... 14

3
5.1 Casos de fallas

Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados

para proveer un servicio específico. Un desperfecto de un sistema ocurre cuando el sistema no
desempeña estos servicios de manera especificada. Un estado erróneo en un sistema es un
estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal,
las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema
o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas
externos (como condiciones ambientales adversas, interferencia electromagnética, entradas
imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere
de los valores esperados.
Es necesario que el sistema sea capaz de recuperarse de las fallas, entonces necesitamos
deshacernos del estado de error del sistema.
Clasificación de las fallas
Falla de procesos
Aquí, la ejecución arroja un resultado incorrecto, los procesos provocan que el sistema se desvíe
de las especificaciones y el proceso puede suspender su progreso. Por ejemplo, interbloqueos,
tiempo expirado, violación de protección, error en la entrada provista por el usuario, violaciones
de consistencia.
Falla del sistema
Es cuando el procesador falla en la ejecución. Esto es causado por errores de software y
problemas de hardware, como por ejemplo errores de CPU, falla en la memoria principal, falla en
el bus, falla de energía, etc.
Además, una falla del sistema se puede clasificar como sigue:
Falla de amnesia: ocurre cuando se reinicia el sistema en un estado predefinido, y no depende
del estado del sistema antes de la falla. No se conoce el estado que tenía el sistema antes de la
falla.
Falla de amnesia parcial: ocurre cuando se reinicia el sistema y se conoce parte del estado que
presentaba antes de ocurrir la falla.
Falla de pausa: ocurre cuando el sistema se reinicia al mismo estado en que se encontraba antes
de la falla.
Falla de aborto (halting): ocurre cuando un sistema nunca se reinicializa.
Falla en medio de almacenamiento secundario: es cuando los datos almacenados no pueden ser
accedido. Normalmente es provocada por error de paridad, daño a las cabezas lectoras,
partículas de polvo depositadas en el medio. En caso de que ocurra esta falla, sus contenidos se
encuentran alterados y deberían ser reconstruidos desde una versión del archivo. Para tolerar
una falla del medio de almacenamiento secundario, el sistema puede ser configurado con un
sistema de discos espejos. Un sistema de disco espejo generalmente son dos discos físicamente

4
independientes que se comunican con la memoria y/o el CPU a través de controladores y buses
independientes. Esto hace que el almacenamiento de datos en un disco sea la imagen del otro.
Así, un sistema puede tolerar fallas de un disco de subsistema.

Ilustración 1 diagrama de comunicación entre servidores

Falla en los medios de comunicación: ocurre cuando un sitio no puede comunicarse con otro sitio
operacional en la red. Esto es ocasionado por la falla del nodo de conmutación y/o por los enlaces
de comunicación del sistema

5.1.1 Fallas locales

Aquí, la ejecución arroja un resultado incorrecto, los procesos provocan que el sistema se desvíe
de las especificaciones y el proceso puede suspender su progreso. Por ejemplo, interbloqueos,
tiempo expirado, violación de protección, error en la entrada provista por el usuario, violaciones
de consistencia.
Se dan durante un proceso: Se omiten pasos necesarios o deseables del procesamiento
Se realizan pasos innecesarios o indeseables en el procesamiento
Se omite arbitrariamente la respuesta a mensajes
En canales de comunicación
Corrupción de mensajes
5
Reparto de mensajes inexistentes
Duplicación del reparto de mensajes auténticos

5.1.2 Fallos de sitios

En un sistema distribuido crítico, con frecuencia nos interesa que el sistema pueda sobrevivir a
las fallas de los componentes (en particular del procesador), en vez de hacer que las fallas sean
poco probables: La confiabilidad de un sistema es en particular importante en un sistema
distribuido, debido a la gran cantidad de componentes presentes; de ahí la mayor posibilidad de
que falle uno de ellos. Esto es causado por errores de software y problemas de hardware, como
por ejemplo errores de CPU, falla en la memoria principal, falla en el bus, falla de energía, etc.

Además, una falla del sistema se puede clasificar como sigue:

• Falla de amnesia: ocurre cuando se reinicia el sistema en un estado predefinido, y no

depende del estado del sistema antes de la falla. No se conoce el estado que tenía el
sitema antes de la falla.
• Falla de amnesia parcial: ocurre cuando se reinicia el sistema y se conoce parte del estado
que presentaba ant es de ocurrir la falla.
• Falla de pausa: ocurre cuando el sistema se reinicia al mismo estado en que se
encontraba antes de la falla.
• Falla de aborto (halting): ocurre cuando un sistema nunca se reinicializa.
• Falla en medio de almacenamiento secundario: es cuando los datos almacenados no
pueden ser accedido. Normalmente es provocada por error de paridad, daño a las
cabezas lectoras, partículas de polvo depositadas en el medio. En caso de que ocurra
esta falla, sus contenidos se encuentran alterados y deberían ser reconstruidos desde una
versión del archivo. Para tolerar una falla del medio de almacenamiento secundario, el
sistema puede ser configurado con un sistema de discos espejos. Un sistema de disco
espejo generalmente son dos discos físicamente independientes que se comunican con
la memoria y/o el CPU a través de controladores y buses independientes. Esto hace que
el almacenamiento de datos en un disco sea la imagen del otro. Así, un sistema puede
tolerar fallas de un disco de subsistema.

5.1.3 Fallas de canal de comunicación

Una falla de un medio de comunicación, ocurre cuando un sitio no puede comunicarse con otro
sitio operacional de la red. Esto es ocasionado por la falla del nodo de conmutación y/o por los
enlaces de comunicación del sistema. La falla de un nodo de conmutación incluye la falla del
sistema y la falla de almacenamiento secundario, por otro lado, la falla de enlace incluye una
ruptura física y ruido en los canales de comunicación. Note que una falla en un medio de

6
comunicación (esto depende de la topología y la conectividad) puede no causar la pérdida total
de las facilidades de comunicación. Por ejemplo, una falla en el medio de comunicación puede
simplemente causar una pérdida del mensaje, la recepción de un mensaje con algunos errores,
o la partición de una red donde un segmento de sitios puede ser incomunicados con los sitios en
otro segmento, aunque los sitios dentro de un segmento pueden comunicarse entre sí.

• Fallos de parada: El elemento que falla, simplemente deja de funcionar y no interfiere con
el resto del sistema una vez falla.
• Fallos de omisión: El elemento que falla no hace cierta parte de su cometido ej.: un canal
de comunicación puede presentar fallos de omisión de envío o de respuesta.
• Fallos de temporización: El elemento que falla no lo hace en el tiempo previsto
• Fallos de respuesta: El elemento responde incorrectamente a las peticiones que se le
realizan
• Fallos arbitrarios: El componente que falla funciona de forma descontrolada.
El primer factor a tomar en cuenta es que el canal de comunicación esté libre de errores (canal
confiable). Para garantizar que el canal sea confiable se debe de realizar lo siguiente:
▪ Retransmisión de mensajes.
▪ Debe haber redundancia de canales
▪ La entrega de un paquete sea dentro de un tiempo límite especificado
En general, se considera que los canales de comunicación son fiables y que cuando falla la
comunicación es debido a la caída del proceso.

5.2 Protocolos de recuperación

Recordemos que un error es esa parte del estado del sistema que es distinto de los valores
esperados y que pueden conducir a la falla de un sistema, la recuperación de una falla es un
proceso que involucra la recuperación de estados erróneos a un estado libre de error. Hay dos
enfoques para la recuperación de un estado de error a un estado libre de error.
Un bloqueo es una información del tipo de acceso que se permite a un elemento. El SGBD impone
los bloqueos necesarios en cada momento. El gestor de acceso a los datos implementa las
restricciones de acceso. En algunos sistemas se permite que el usuario pueda indicar el bloqueo
más adecuado (locking hints).
Tipos de bloqueo con respecto a la operación:
read-locks: sólo permite lectura
write-locks: permite lectura y escritura
El gestor de bloqueos almacena los bloqueos en una tabla de bloqueos:
(<elemento>, <tipo de bloqueo>, <transacción>)=(E,B,T)
La transacción T tiene un tipo de bloqueo B sobre el elemento E.

7
Normalmente, E es clave, aunque no siempre, porque varias transacciones pueden bloquear el
mismo elemento de forma diferente.
Niveles de bloqueo
Especifica la granularidad del bloqueo
• Fila: Fila individual
• Clave: Fila de un índice
• Página: Páginas (8KB)
• Extent: Extensión (grupo de 8 páginas contiguas de datos o índices)
• Table: Tabla completa
• Database: Base de datos completa
Modos de bloqueo
Especifica el modo en que se bloquea un elemento
• Compartido: para operaciones sólo de lectura. Se permiten lecturas concurrentes, pero ninguna
actualización.
• Actualización: para operaciones que pueden escribir. Sólo se permite que una transacción
adquiera este bloqueo. Si la transacción modifica datos, se convierte en exclusivo, en caso
contrario en compartido.
• Exclusivo para operaciones que escriben datos. Sólo se permite que una transacción adquiera
este bloqueo.
• Intención: se usan para establecer una jerarquía de bloqueo. Por ejemplo, si una transacción
necesita bloqueo exclusivo y varias transacciones tienen bloqueo de intención, no se concede el
exclusivo.
• Intención compartida: Bloqueo compartido.
• Intención exclusiva: Bloqueo exclusivo.
• Compartido con intención exclusivo. Algunos bloqueos compartidos y otros exclusivos.
• Esquema para operaciones del DDL.
• Actualización masiva. En operaciones de actualización masiva

5.2.1 UnDo/ ReDo

El registro de la base de datos contiene información que es utilizada por el proceso de

recuperación para restablecer la base de datos a un estado consistente. Esta información puede
incluir entre otras cosas:
8
 • El identificador de la transacción,
• El tipo de operación realizada,
• Los datos accesados por la transacción para realizar la acción,
• El valor anterior del dato (imagen anterior), y
• El valor nuevo del dato (imagen nueva).

El DBMS inicia la ejecución en el tiempo 0 y en el tiempo t se presenta una falla del sistema.
Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado
su commit) pero T2 no pudo ser concluida.
La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de datos
estable. De forma similar, la propiedad de atomicidad requiere que la base de datos estable no
contenga alguno de los efectos de T2.
Operación REDO.
Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la base de
datos estable de algunas de las páginas de la base de datos volátil correspondientes a la
transacción T2.
Así, la información de recuperación debe incluir datos suficientes para permitir deshacer ciertas
actualizaciones en el nuevo estado de la base de datos y regresarla al estado anterior. A esta
operación se le conoce como UNDO. La operación UNDO restablece un dato a su imagen anterior
utilizando la información del registro de la base de datos.
Operación UNDO.
De forma similar a la base de datos volátil, el registro de la base de datos se mantiene en memoria
principal (llamada los buffers de registro) y se escribe al almacenamiento estable (llamado registro
estable).
Las páginas de registro se pueden escribir en el registro estable de dos formas: síncrona o
asíncrona.
En forma síncrona, también llamada un registro forzado, la adición de cada dato en el registro
requiere que la página del registro correspondiente se mueva al almacenamiento estable.
De manera asíncrona, las páginas del registro se mueven en forma periódica o cuando los buffers
se llenan.

9
 Ilustración 2 descripción de UNDO/REDO

5.2.2 No UnDo/ No ReDo

La idea detrás de la actualización diferida es diferir o posponer cualquier actualización real a la

base de datos en el disco hasta que la transacción complete su ejecución con éxito y llegue a su
punto de confirmación.
Durante la ejecución de la transacción, las actualizaciones se registran solo en el registro y en
los buffers de caché. Una vez que la transacción alcanza su punto de confirmación y el registro
se escribe en el disco, las actualizaciones se registran en la base de datos. Si una transacción
falla antes de llegar a su punto de confirmación, no es necesario deshacer ninguna operación
porque la transacción no ha afectado a la base de datos en el disco de ninguna manera. Por lo
tanto, solo se necesitan entradas de registro de tipo REDO en el registro, que incluyen el nuevo
valor (AFIM) del elemento escrito por una operación de escritura. Las entradas de registro de tipo
UNDO no son necesarios, ya que no será necesario deshacer las operaciones durante la
recuperación. Aunque esto puede simplificar el proceso de recuperación, no se puede utilizar en
la práctica a menos que las transacciones sean cortas y cada transacción cambie algunos
elementos. Para otros tipos de transacciones, existe la posibilidad de quedarse sin espacio en el
búfer porque los cambios de transacción deben mantenerse en los búferes de caché hasta el
punto de confirmación.
Podemos establecer un protocolo típico de actualización diferida de la siguiente manera:
1. Una transacción no puede cambiar la base de datos en el disco hasta que llegue a su
punto de confirmación.
2. Una transacción no alcanza su punto de confirmación hasta que todas sus entradas de
registro de tipo REDO se registran en el registro y el búfer de registro se escribe en el disco.
Tenga en cuenta que el paso 2 de este protocolo es una reexpresión del protocolo de registro de
escritura anticipada (WAL). Debido a que la base de datos nunca se actualiza en el disco hasta
después de que se confirme la transacción, nunca es necesario deshacer ninguna operación. Se
10
necesita REDO en caso de que el sistema falle después de que se confirme una transacción,
pero antes de que todos sus cambios se registren en la base de datos en el disco. En este caso,
las operaciones de transacción se rehacen desde las entradas de registro durante la
recuperación.
Para sistemas multiusuario con control de concurrencia, el control de concurrencia y los procesos
de recuperación están interrelacionados. Considere un sistema en el que el control de
concurrencia utiliza un estricto bloqueo de dos fases, por lo que los bloqueos en los elementos
permanecen en efecto hasta que la transacción alcance su punto de confirmación. Después de
eso, las cerraduras pueden ser liberadas. Esto asegura horarios estrictos y serializables.
Suponiendo que las entradas de [punto de control] están incluidas en el registro, a continuación,
se proporciona un posible algoritmo de recuperación para este caso, que llamamos RDU_M
(Recuperación usando actualización diferida en un entorno multiusuario).
Procedimiento RDU_M (NO-UNDO / REDO con puntos de control). Utilice dos listas de
transacciones mantenidas por el sistema: las transacciones confirmadas T desde el último punto
de control (lista de confirmación) y las transacciones activas T (lista activa). REDO todas las
operaciones de ESCRITURA de las transacciones confirmadas desde el registro, en el orden en
que fueron escritas en el registro. Las transacciones que están activas y no se confirmaron se
cancelan de manera efectiva y se deben volver a enviar.
El procedimiento REDO se define de la siguiente manera:
Procedimiento REDO (WRITE_OP). Rehacer una operación de escritura de artículo WRITE_OP
consiste en examinar su entrada de registro [write_item, T, X , new_value] y establecer el valor
del elemento X en la base de datos a new_value , que es la imagen posterior (AFIM). .
Podemos hacer que el algoritmo de recuperación NO-UNDO / REDO sea más eficiente si
observamos que, si un elemento de datos X se ha actualizado, como se indica en las entradas
del registro, más de una vez por transacciones confirmadas desde el último punto de control, solo
es necesario REDO la última actualización de X del registro durante la recuperación porque las
otras actualizaciones se sobrescribirían con este último REDO. En este caso, comenzamos desde
el final del registro; luego, cada vez que se rehace un elemento, se agrega a una lista de
elementos rehechos. Antes de aplicar REDO a un elemento, se comprueba la lista; Si el elemento
aparece en la lista, no se rehace nuevamente, ya que su último valor ya se ha recuperado.
Si una transacción se cancela por algún motivo (por ejemplo, por el método de detección de
interbloqueo), simplemente se vuelve a enviar, ya que no ha cambiado la base de datos en el
disco. Un inconveniente del método descrito aquí es que limita la ejecución simultánea de
transacciones porque todos los elementos de bloqueo de escritura permanecen bloqueados hasta
que la transacción alcanza su punto de confirmación. Además, puede requerir un espacio de búfer
excesivo para mantener todos los elementos actualizados hasta que se confirmen las
transacciones. El principal beneficio del método es que las operaciones de transacción nunca
deben deshacerse, por dos razones:
1. Una transacción no registra ningún cambio en la base de datos en el disco hasta que
alcanza su punto de confirmación, es decir, hasta que completa su ejecución con éxito. Por lo
tanto, una transacción nunca se retrotrae debido a un error durante la ejecución de la transacción.

11
 2. Una transacción nunca leerá el valor de un artículo que está escrito por una transacción
no confirmada, porque los artículos permanecen bloqueados hasta que una transacción llega a
su punto de confirmación. Por lo tanto, no se producirá ninguna reversión en cascada.

5.3 Protocolos de recuperación distribuidos

Protocolo 2PC de confiabilidad distribuida

El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol especial. Este es
llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados
participantes.

Ilustración 3 diagrama de funcionamiento de protocolos

El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente.

Cada participante corresponde a una sub-transacción la cual ha realizado alguna acción de
escritura en su base de datos local.
Se puede asumir que cada participante está en un sitio diferente.
Aun si un participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo
como si estuvieran en distintos sitios.
La idea básica del 2PC es determinar una decisión única para todos los participantes con respecto
a hacer commit o abort en todas las sub-transacciones locales.
El protocolo consiste en dos fases:
La primera fase tiene como objetivo alcanzar una decisión común,

12
La meta de la segunda fase es implementar esta decisión.

Ilustración 4 representación de las fases de protocolo

El protocolo procede como sigue:

Fase uno:
• El coordinador escribe “prepare” en la bitácora y envía un mensaje donde pregunta a todos los
participantes si preparan el commit (PREPARE).
• Cada participante escribe “ready” (y registra las sub-transacciones) en su propia bitácora si está
listo o “abort” de lo contrario.
• Cada participante responde con un mensaje READY o ABORT al coordinador.
• El coordinador decide el commit o abort en la transacción como un resultado de las respuestas
que ha recibido de los participantes. Si todos respondieron READY, decide hacer un commit. Si
alguno ha respondido ABORT o no ha respondido en un intervalo de tiempo determinado se
aborta la transacción.
Fase dos:
• El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe
“global_commit” o “global_abort” en la bitácora.
• El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución.
• Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje
recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de
asegurar que el efecto de la sub-transacción no será perdido).

13
Ilustración 5 funcionamiento de protocolos

14
Referencias

Colouris, G. Kindberg, T. T. Sistemas Distribuidos, Conceptos y Diseño, Tercera Edición,

Addison Wesley. Estados Unidos, 2001, 719pp

15