Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Приветствую, Господа!
Подскажите плиз, кто имеет представление, ситуация следующая:
Имеется сервер, на котором стоит freebsd
FreeBSD 7.0-STABLE-200807 FreeBSD 7.0-STABLE-200807
на нем mysql
mysql --version
mysql Ver 14.12 Distrib 5.0.67, for portbld-freebsd7.0 (amd64) using 5.2
На сервере несколько баз, в них таблицы, в которых внутри (увы, увы) миллионы записей.
у таблиц тип myisam имеют внешний вид 2009_01_01_00,2009_01_01_01,2009_01_01_02,...,2009_01_01_23
на каждую такого рода группу таблиц имеется одна таблица mrg_myisam, которая "объединяет" эти 24 таблички, чтобы можно было работать с суточными данными через одну таблицу.
Нужно мне перенести эти таблицы на другой сервер (суммарно всех данных за 100 гигабайт, поэтому перетаскиваю по ssh с помощью fish, а не запросами и не с помощью mysqldump).
На другом сервере стоит centos 5.1
Linux 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
mysql --version
mysql Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (x86_64) using readline 5.0
Создал базу, скопировал туда с фрюшного сервера все данные.
Проблема в следующем: при попытке работы с суточной mrg-табличкой вылезает ошибка
A MySQL error was encountered. The message is:
Cannot fetch table information.
The following error occured: Unable to open underlying table which is differently defined or of non-MyISAM type or doesn't exist (1168).
Пробовал убивать mrg-табличку и создавать новую - при запросе создания mrg-таблицы ошибки не вылетает, но тем не менее ни один запрос сделать не могу.
Единственное, как у меня получилось сделать - это еще в одной специальной базе создать все эти таблицы, потом сделать
insert into `new_base`.`2009_02_04_02` select * from `temp_base`.`2009_02_04_02`;
на все таблицы - после этого mrg-таблица нормально работает.
но это решение не прельщает - долго очень, оставлю на крайний случай.
У всех перенесенных таблиц владелец - mysql, права 660.
Вот, собственно, кто знает в чем тут может быть дело - подскажите плиз.
Неактивен
При копировании таблички лочите? Они приезжают не побитые?
Попробуйте сделать CHECK TABLE над ними — что говорит?
Вообще, MERGE очень скрупулезно относится к формату нижележащих табличек; кажется, что
между 45 и 67 формат файликов не менялся, но, может, что-то ему не нравится. Я бы попробовал
сделать REPAIR двум и собрал бы MERGE над ними — вдруг в этом дело.
А вообще глобально уменьшать версию сервера плохо — могут возникать странные глюки. Может,
поднять версию сервера на Linux?
Неактивен
paulus написал:
При копировании таблички лочите? Они приезжают не побитые?
Попробуйте сделать CHECK TABLE над ними — что говорит?
Вообще, MERGE очень скрупулезно относится к формату нижележащих табличек; кажется, что
между 45 и 67 формат файликов не менялся, но, может, что-то ему не нравится. Я бы попробовал
сделать REPAIR двум и собрал бы MERGE над ними — вдруг в этом дело.
А вообще глобально уменьшать версию сервера плохо — могут возникать странные глюки. Может,
поднять версию сервера на Linux?
Check Table говорит, что все в порядке.
Repair выругался, что таблицы read-only, хотя владелец там mysql и с правами на файлы все в порядке.
Что касается подъема версии на linux - то это сложно, там centos стоит и более свеженькой версии mysql в репозитории нету. Решил воспользоваться mysqldump в итоге, так все в порядке. Спасибо за ответ.
Неактивен
Страниц: 1