Безопасно ли устанавливать изоляцию MySQL для "чтения незафиксированных" (грязных чтений) для типичного веб-использования? Даже с репликацией?

Я работаю на веб-сайте с типичным шаблоном веб-использования CRUD: подобно блогам или форумам, где пользователи создают/обновляют содержимое, а другие пользователи читают содержимое.

кажется, что это нормально, чтобы установить уровень изоляции базы данных "Читать Uncommitted" ("грязное" чтение) в данном случае. Я понимаю общий недостаток "чтения без обязательств" в том, что читатель может прочитать незаполненные данные, которые позже будут откатаны.

в блоге CRUD / использование форума паттерн, будет ли когда-нибудь откат? И даже если есть, есть ли какие-либо серьезные проблемы с чтением незафиксированных данных?

прямо сейчас я не использую репликацию, но в будущем, если я хочу использовать репликацию (на основе строк, а не на основе операторов), будет ли уровень изоляции "чтение незафиксированных" препятствовать мне в этом?

Что вы думаете? Кто-нибудь пробовал использовать "Read Uncommitted" в своих СУБД?

6
database mysql postgresql replication transactions

2 ответов

MySQL 5.1 строже при использовании Read-uncommitted и binlogging (необходим для репликации) - поэтому вы можете получить ошибки на некоторых простых инструкциях update/delete, которые вы не получили бы в уровне изоляции по умолчанию, повторяемом чтении. Я видел простые обновления PK, такие как:

обновить Foo set bar=1, где id=1234;

ошибка с: mysql_real_query ошибка 1598 сообщение: двоичный ведение журнала невозможно. Сообщение: уровень транзакции "READ-UNCOMMITTED" в InnoDB не безопасно для binlog mode 'STATEMENT'

поэтому вы должны быть готовы справиться с этим, переключившись на повторяемые чтения при изменении данных или используя отдельные соединения для чтения и записи со своими уровнями изоляции. Последний может пригодиться, когда / если требуется масштабирование и репликация проекта, поэтому вы можете отправить select только для чтения и записи на ведущем устройстве.

OTOH, использование read-uncommitted для чтения может быть реальным выигрышем, если последовательные чтения строго не нужны, поскольку Innodb имеет меньше замков.

Что касается вопроса о том, возможны ли откаты, я думаю, что вы лучший человек, чтобы рассказать нам об этом, так как вы его кодируете :).

3

этот уровень изоляции означает, что вы можете прочитать противоречивые данные. Нет никакой гарантии, что данные, которые Вы читаете, являются согласованным представлением базы данных.

Whethere это проблема или нет, это не вопрос MySQL, а вопрос приложения, который включает в себя оценку риска использования/возврата непоследовательных данных.

в приложении интернет-банкинга это не будет не-идти. На игре это может быть нормально. Это зависит от.

Я использовал оба " read uncommitted" и репликация, и не было никаких проблем.

2