Sistema Bayou

De Wikipedia, la enciclopedia libre

Es un sistema de alta disponibilidad, propuesto por Terry et al. en 1995 y Petersen et al. en 1997., que se usa en replicación (informática).

Actualizaciones tentativas y consumadas sistema bayou

Al igual que ocurre con la Arquitectura Cotilla, este sistema proporciona menos garantías que la consistencia secuencial con el objetivo de priorizar la disponibilidad. La garantía en este caso será que cada gestor recibe el mismo conjunto de actualizaciones y, con el tiempo, las aplica de modo que las bases de datos de todas las réplicas sean idénticas. Es posible que ocurra que el flujo de actualizaciones sea continuo, en cuyo caso cabría la posibilidad de que las bases de datos nunca llegasen a ser idénticas; no obstante, en el momento que las actualizaciones se detuvieran, se cumpliría esta condición.

Funcionamiento[editar]

Cuando se reciben las actualizaciones, éstas se marcan como tentativas y con el tiempo serán ordenadas canónicamente y marcadas como consumadas (committed). Mientras que dichas actualizaciones están en un estado tentativo, es posible deshacerlas y reaplicarlas para llegar a un estado consistente. Sin embargo, una vez que estén consumadas, se mantienen aplicadas en el orden asignado.

Para conseguir el orden de consumación, se puede designar un gestor de réplicas como primario, de modo que éste reciba las actualizaciones tentativas y propague la información de ordenación al resto de réplicas. Algunos ejemplos de máquinas adecuadas para este rol podrían ser una que normalmente esté disponible y proporcione respuestas rápidas o simplemente aquella con más prioridad en el proyecto.

En lo que al estado de las bases de datos se refiere, se puede ver como una secuencia de actualizaciones consumadas seguida por otra secuencia de actualizaciones tentativas, pudiendo ambas estar vacías. En el caso de que llegue una nueva actualización consumada, o de que alguna de las actualizaciones tentativas pase a estar consumada, entonces será necesario hacer una reordenación de estas secuencias. La ilustración de este artículo es un claro ejemplo de esto, en el cual la actualización tentativa ti pasa a estar consumada. Todas las actualizaciones tentativas que vienen detrás de la consumada Cn tienen que deshacerse para que ti pueda ser aplicada después de ésta, y a continuación reaplicarse detrás de ti.

Es posible que una determinada actualización entre en conflicto con alguna otra operación que ya se hubiese aplicado, para lo cual Bayou cuenta con un procedimiento de fusión y una comprobación de dependencias, específicos del dominio. Un gestor de réplicas utilizará este comprobador antes de aplicar una operación para verificar si se produciría algún conflicto en el caso de que se aplicase la actualización. En el supuesto de que hubiese algún conflicto, entonces se invocaría el ya mencionado procedimiento de fusión, mediante el cual se intentará alterar la operación aplicada para conseguir un efecto similar al buscado pero evitando el conflicto. Si durante este proceso es imposible encontrar ninguna operación adecuada, entonces el sistema indicará el error.

Análisis[editar]

Debido al funcionamiento descrito previamente, este sistema no proporciona una replicación (informática) transparente al cliente. Esto puede acarrear una serie de desventajas, ya que se complica el trabajo de los programadores al obligarles a proporcionar métodos para comprobar las dependencias, así como procedimientos de fusión. Otra desventaja podría ser la complejidad de cara al usuario, ya que se les proporciona acceso a información que puede ser leída cuando aún está en un estado tentativo. Además, puede ocurrir que las operaciones que se lleven a cabo al final resulten haber sido alteradas por otros usuarios. Es por esto que es importante mostrar a los usuarios qué información es tentativa y cuál está consumada. Por tanto, este tipo de sistemas funcionan mejor en aplicaciones donde haya pocos conflictos y los usuarios sean capaces de manejar información tentativa.

Referencias[editar]