одновременный update и select из разных потоков.

[Renny]

одновременный update и select из разных потоков.

Всем привет.
Есть база данных tbl_stat, к ней одновременно подключаются 2 потока, один пытается update несколько строк, а другой эти строки хочет прочитать, и получаются битые данные. Как с этим бороться?
Подозреваю что надо лочить таблицу или лочить строки.

 

[varan]

использовать транзакции?

 

[Renny]

НЕ получится, так как тип таблиц MyIsam

 

[varan]

изменить тип таблиц?

 

[Renny]

тогда меняю условия задачи:

Есть таблица tbl_stat, по крону раз в 5 минут, в ней происходит update строк, с данными за текущие сутки.

И по крону, с других серверов происходит select данных, на те же самые строки.

Оставив на тестирование на ночь я с удивлением обнаружил множество битых данных. Как этого избежать?

 

[varan]

или лочить всю таблицу (в myisam лочится или всё или ничего) или менять тип таблиц на innodb и выполнять несколько апдейтов в рамках одной транзации.

 

[Renny]

ТОгда следующий вопрос, есть 2 варианта:
1 - лочим таблицу и делаем select на строки, и в тот же момент приходит запрос update на эти строки. Что произойдет? Строка после разблокировки таблицы проапдейтится или нет?
2 - лочим таблицу и делаем update на строки, и в тот же момент приходит запрос select на эти строки. Что произойдет? Тот кто просил select уйдет с ответом, таблицы нетути, или просто подожет разблокировки таблицы и прочтет свои строки?

 

[varan]

http://www.mysql.ru/docs/man/LOCK_TABLES.html

 

[damngood]

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

 

[Viktor_Rez]

Re: одновременный update и select из разных потоков.

Автор оригинала: Renny
Всем привет.
Есть база данных tbl_stat, к ней одновременно подключаются 2 потока, один пытается update несколько строк, а другой эти строки хочет прочитать, и получаются битые данные. Как с этим бороться?
Подозреваю что надо лочить таблицу или лочить строки.

"Битые" данные не получатся ну ни как! Это противоречит логике СУБД. Советую покурить мануал по MySQL, в частности очередь блокировок.

 

[varan]

"Битые" данные не получатся ну ни как! Это противоречит логике СУБД. Советую покурить мануал по MySQL, в частности очередь блокировок.

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

 

[Viktor_Rez]

varan в MySQL приорететная очередь запросов (update и insert) это WRITE (если не указан параметр LOW_PRIORITY).

Так что между двумя выборками не может быть противоречий.

-~{}~ 25.11.09 23:45:

varan
Получается что часть данных в таблице новая, часть старая, а как я понял, должно апдейтиться всё скопом.

Да, согласен. Бывают такие казусы. Но как их решать... У мну есть товарная база на 20 000 товаров. Примерное время выполнения update 0.7 мс.

Хотя есть идеи как ещё скостить примерно 0.1 мс. =)

 

[varan]

Кстати, есть еще вариант, со второй таблицей. Обновляющий скрипт пишет в таблицу типа tmp_table, а потом делает
RENAME TABLE real_table TO backup_table, tmp_table TO real_table;
Насколько я понимаю, эта операция атомарна.

Хотя если селектов из другого процесса несколько, то придется всё-таки лочить всю таблицу.

 

[Alexandre]

использовать транзакции

+1

 

[Renny]

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

 

[varan]

тьфу ты блин, что ж ты раньше не сказал, транзакции и блокировки точно не причем

 

[dr-sm]

в такой ситуации использовать myisam, это ололо

 

[Viktor_Rez]

Автор оригинала: Renny
По поводу битых данных я сам пока не разобрался, суть там в следующем.
В мускуль кидается массив обработанный json_encode, и вот в этой то строке и теряется концовочка, примерно 10-20 символов куда-то пропадают, размер поля не превышен, с кодировкой тоже все ок, вот и пытаюсь разобраться.

Как так!? Т.е. твой пост не про update и insert?

Ты хоть понимаешь смысл строк, которые ты пишешь!? примерно 10-20 символов куда-то пропадают - а если у меня строка в 6 символов...