Асинхронное закрытие таблицы?

  • Автор темы Автор темы voituk
  • Дата начала Дата начала

voituk

прозревший
Асинхронное закрытие таблицы?

Производится анализ данных по такому алгоритму:
1. Из таблицы А (ОЧЕНЬ большой) с помощью "INSERT INTO ... SELECT" в таблицу B загружаются данные (порядка 200 тыс записей, всего порядка 40 млн записей)
2. Дальше из таблицы B формируется отчет и складывается в таблицу C (тоже с помощью "INSERT INTO ... SELECT")

Все это выполняется в shell-скрипте последовательными вызовами консольного MySQL:
п.1. mysql -u... -p... -e"INSERT INTO B ... SELECT ... FROM A" database
п.2. mysql -u... -p... -e"INSERT INTO C ... SELECT ... FROM B" database

В результате время от времени имеем ситуацию, при которой выполнениt п.1. уже завершилось, но при этом таблица "B" ещё в статусе нето "Closing table" нето "Repair with keycache" или что-то вроде этого (словить удалось только раз, но не придал значения и не запомнил точно). При попытке выполнить запрос к этой таблице - он успешно выполняется но возвращает пустой resultset.
Но при этом начинается выполнение п.2., который обрабатывает пустой resultset - в результате в таблицу C данные не поступают.

Если после п.1. дождаться закрытия таблицы "B" то п.2. выполняется отлично.

Попробовал поставить между п1. и п2. sleep 600, но IMHO это не выход.
Также пробовал делать все запросы в пределах одного подключения - та же "петрушка".

Все таблицы MyISAM
MySQL 4.1.15

show variables like '%concurrent%'; # Подозреваю что он тут при делах :)
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| concurrent_insert | ON |
+-------------------+-------+
1 row in set (0.01 sec)

Как избавиться от описанного асинхронного закрытия таблицы?
 
а что мешает сделать текстовый файл из двух запросов
INSERT INTO В SELECT ....
INSERT INTO С SELECT... FROM B

а далее выполнить его из консоли
mysql -u... -p... -gfilename
 
Попробуйте обновить mysql. У меня похожая проблема возникала на одной из версий.
 
.des.
Спасибо, но такой вариант исключен.

Есть другие предложения?
 
Есть такой прикол, что управление уже возвращается, хотя фактически запрос еще не завершился:
http://bugs.mysql.com/bug.php?id=29334

можно сделать FLUSH TABLES перед вторым запросом, но учтите, что при этом будут сбрасываться на диск _все_ таблицы. На нагруженом сервере с большим кол-вом таблиц это будет ужасно.
 
Апельсин
Спасибо за ссылку.

Буду пробовать выполнить FLUSH TABLES.

-~{}~ 02.10.07 11:15:

На текущем обьеме данных flush tables выполняется порядка 20 минут, но ошибка больше не возникает.
 
Сверху