2010-01-08 7 views
6

Estoy trabajando en un sitio web con un patrón de uso de la web CRUD típico: similar a blogs o foros donde los usuarios crean/actualizan contenidos y otros usuarios leen el contenido.¿Es seguro establecer el aislamiento de MySQL en "Lectura no confirmada" (lecturas sucias) para el uso típico de la web? Incluso con la replicación?

parece que está bien para establecer el nivel de aislamiento de la base de datos de "de lectura no confirmada" (lecturas sucias) en este caso. Mi comprensión del inconveniente general de "Leer no comprometido" es que un lector puede leer datos no confirmados que luego se revertirán.

En un patrón de uso de blog/foro de CRUD, ¿habrá alguna reversión? E incluso si existe, ¿hay algún problema importante con la lectura de datos no confirmados?

En este momento no estoy utilizando ninguna replicación, pero en el futuro si deseo usar la replicación (basada en filas, no basada en enunciados) ¿me impedirá el nivel de aislamiento "Leer sin confirmar"?

¿Qué opinas? ¿Alguien ha intentado usar "Leer sin confirmar" en su RDBMS?

+4

¿Qué le está pidiendo que lea datos no confirmados? – cletus

+0

¿Estás experimentando bloqueo? –

+0

No tengo problemas de bloqueo. Le pedí esto para ayudarme a comprender los diversos niveles de aislamiento y su ramificación en el mundo real. También sería útil en el futuro si sé que un nivel de aislamiento relajante podría ayudar con la concurrencia. – Continuation

Respuesta

3

MySQL 5.1 es más estricto cuando se usa lectura no confirmada y borrado (necesario para la replicación), por lo que puede obtener errores en algunas declaraciones simples de actualización/eliminación que no obtendría en el nivel de aislamiento predeterminado REPEATABLE READ. He visto actualizaciones de PK simples como:

Actualizar foo set bar = 1 donde id = 1234;

Error con: mysql_real_query error 1598 mensaje: No es posible el registro binario . Mensaje: nivel de transacción 'READ-UNCOMMITTED' en InnoDB no es seguro para el modo binlog 'sentencia'

Por lo que debe estar preparado para hacer frente a esto cambiando de nuevo a repetible lee cuando se modifican los datos, o el uso de conexiones independientes para lecturas y escribe, con sus propios niveles de aislamiento. Este último puede ser útil cuando/si su proyecto escala y se necesita replicación, por lo que puede enviar seleccionar a un esclavo de solo lectura y escribir en el maestro.

OTOH, utilizando read-uncommitted para lecturas puede ser una ganancia real, si las lecturas consistentes no son estrictamente necesarias, ya que Innodb tiene menos bloqueos para tomar.

En cuanto a la pregunta sobre si son posibles las reversiones, creo que eres la mejor persona para contarnos sobre ella, ya que eres la que está codificando :).

2

Este nivel de aislamiento significa que puede leer datos inconsistentes. No hay garantía de que los datos que lea sean desde una vista consistente de la base de datos.

Cuando esto es un problema o no, no es una pregunta de MySQL, sino una pregunta de aplicación, que implica una evaluación del riesgo de usar/devolver datos inconsistentes.

En una aplicación de banca por Internet no necesitaría ir. En un juego, puede estar bien. Depende.

He usado "read uncommitted" y la replicación, y no he tenido problemas.

Cuestiones relacionadas