mysql> create table x (id int);
Query OK, 0 rows affected (0.06 sec)
mysql> LOCK TABLES x READ;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO x VALUES (1);
ERROR 1099 (HY000): Table 'x' was locked with a READ lock and can't be updated
|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Подскажите, пожалуйста, нужно обновлять данные по расписанию из xml. xml файлов получается очень много и данных очень много. Поэтому, чтобы не грузит сервер, и не допустить падения я загружаю данные постепенно. Скажем читаю через каждые 24 часа по 10 файлов за сессию, когда пользователь открывает страницу.
При этом есть база с колонками названий файлов и временем
table_file.file_name и table_file.date
Также есть таблица с самими данными в которой хранятся данные и также название файла
table2.file_name
Я делаю запрос на получение первых 10 файлов, которые еще не обновлялись
select * table_file from date='$date' limit10
затем в цикле удаляю все данные из table2.file_name равным table_file.file_name через delete и в том же цикле считываю файлы, и заношу обновленные данные через insert Into
Проблема в том, что если в одно и то же время страницу откроют несколько пользователей, то данные могут продублироваться. Как можно обойти эту проблему, т.е. как-то закрыть обновления и удаление данных, пока не закончится уже начатая операция delete и insert into
Неактивен
А что мешает все эти действия через крон сделать?
http://ru.wikipedia.org/wiki/Cron
Неактивен
Там обычный хостинг, без доступа даже к конфигурационным файлам Php, mysql
Неактивен
Задачи cron часто бывают доступны через панель хостинга
Неактивен
А на уровне mysql нельзя такое сделать? Задача еще в том, чтобы дать доступ к данным нескольким людям на уровне php-скрипта, т.е. закинул файл, создал базу, и оно обновляет время от времени
Отредактированно platedz (02.03.2013 15:28:04)
Неактивен
Чтобы избежать одновременного доступа используйте блокировки: http://webew.ru/articles/1383.webew
В MySQL, начиная с версии 5.1 есть EVENT SCHEDULER http://dev.mysql.com/doc/refman/5.1/en/events.html
Неактивен
Большое спасибо за ответ, сейчас буду разбираться. Будьте добры, подскажите еще, а как можно удалить дубли скажем по 2-3 полям
Неактивен
Почитал про блокировку, но, честно говоря не очень разобрался
Вот у меня запрос
Неактивен
Подскажите, правильно ли я понял.
команда
Read
разрешает для текущей сессии
запись, обновление, вставку, удаление
запрещает для других сессий
запись, обновление и удаление
разрешает для других сессий
чтение
write
разрешает для текущей сессии
запись, обновление, вставку удаление
и запрещает все это для других сессий.
Отредактированно platedz (03.03.2013 15:43:44)
Неактивен
read разрешает текущей сессии читать, а другим запрещает писать
write разрешает текущей сессии чиать и писать, а другим запрещает и чтение и запись
Неактивен
read разрешает читать текущей сессии
Так а писать то она разрешает или запрещает текущей сессии?
Неактивен
писать запрещает всем, в том числе и текущей сессии
http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html
Неактивен
С английским у меня не очень, но вот здесь написано
http://веб-информ.рф/mysql/LOCK_TABLES.html
Различие между READ LOCAL и READ состоит в том, что READ LOCAL позволяет выполнять неконфликтующие команды INSERT во время существования блокировки. Однако эту команду нельзя использовать для работы с файлами базы данных вне сервера MySQL во время данной блокировки.
Так какую же блокировку необходимо установить на таблицу, чтобы текущая сессия могла ее обновить, удалить, записать, а все остальные только прочитать?
Отредактированно platedz (03.03.2013 16:19:37)
Неактивен
Неактивен
Подскажите, а как можно из консоли windows открыть еще одну сессию с еще одним пользователем, чтобы потренироваться
Неактивен
запустить вторую консоль и в ней подключиться
Неактивен
Т.е. я так понял, что в целом выполнение скрипта, в этом случае просто встанет. Т.е. как бы получается что для моего случая нужно записать WRITE. При этом если скажем пользователь будет открывать страницу с данными, то будет происходить, своего рода принудительная задержка в выполнении php скрипта. Пока другой пользователь не закроет соединение.
Правильно ли я понимаю. Из консоли-то это кажется очевидным, а вот при работе сайта как-то не очень?
Неактивен
Точно. Все запросы будут ждать пока не освободится блокировка. Если истечет таймаут для скриптов php, то они прекратятся по таймауту недождавшись.
Неактивен
Большое спасибо за ответы. В целом думаю, что это не шибко страшно, т.ч. вполне можно и так реализовать.
Еще остался один вопрос, если не сложно.
Чем же все-таки отличается READ LOCAL от READ?
Неактивен
READ LOCAL работает только в MyISAM и позволяет дописывать в конец таблицы, если в ней нет щелей http://dev.mysql.com/doc/refman/5.0/en/ … serts.html
Неактивен
Спасибо за ответ. Сейчас попробую еще вариант с оптимизацией.
По поводу LOW_PRIORITY WRITE, еще не очень ясно
LOW_PRIORITY WRITE — блокирует таблицу для записи, но во время ожидания блокировки пропускает тех клиентов, которые стоят в очереди на получения блокировки типа READ. Во время ожидания блокировки, новые поступающие запросы на блокировку типа READ также пропускаются вперед, что может потенциально привести к тому, что запись не будет произведена никогда (если всегда есть клиенты в очереди на чтение).
Как понять, во время ожидания блокировки пропускает вперед тех клиентов, которые стоят в очереди на получение блокировки типа read?
Неактивен
И еще такой вопрос возник, если у меня скажем подряд несколько write стоит, как это будет в отношении других соединений?
Клиент открывает страницу, я делаю блок write, обновляю данные,
а в это время другой клиент также открывает файл, и соответственно он тоже должен запустить write и обновить данные. Что происходит в таком случае?
Получается вот несколько клиентов в очереди на ожидание.
write тоже ставится в очередь на ожидание?
И когда таких клиентов несколько, как получается, они по очереди друг за другом будут обновлять данные? Т.е. одна сессия заблокировала, отработала, разблокировала. Пошла вторая сессия, заблокировала, отработала, разблокировала и тд. ?
Отредактированно platedz (03.03.2013 23:08:25)
Неактивен
В общем-то видимо да. При попытке выполнить какие-либо действия в сторону заблокированной таблицы любые дальнейшие запросы уже невозможны получается.
Неактивен
