Назад | Перейти на главную страницу

Обновление MySQL 5.0 -> 5.1, обновление таблиц занимает очень много времени

У нас есть сервер базы данных, на котором был запущен MySQL 5.0 на Debian etch (!), И мы решили, что пора его обновить. Теперь он работает под управлением Debian squeeze 5.1.

Этот сервер базы данных имеет около 1,2 ТБ данных MyISAM в массиве SATA RAID и 2 ГБ оперативной памяти. Обычно скорость не является фактором для запросов, выполняемых этим сервером, это в основном фоновый материал.

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

Я попытался увеличить глобальный буфер key_buffer до 512 МБ, что, похоже, соответствует рекомендациям, но безрезультатно.

Проблема, похоже, в том, что он использует метод «Восстановить с помощью кэша ключей», который намного медленнее, чем метод сортировки:

mysql> show processlist;
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| Id  | User             | Host                             | db               | Command | Time  | State                | Info                                                                     |
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
|   5 | debian-sys-maint | localhost                        | xxxxxxxxxxxxxxxx | Query   | 45146 | Repair with keycache | REPAIR TABLE `xxxxxxxxxxxxxxxx`.`xxxxxxxxxxxxxxxxxxxx`     

Другие таблицы недоступны из-за необходимости обновления:

mysql> check table xxxxxxxxxxxxxxxxxxxx fast quick;
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| Table                                 | Op    | Msg_type | Msg_text                                                                                          |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | check | error    | Table upgrade required. Please do "REPAIR TABLE `xxxxxxxxxxxxxxxxxxxx`" or dump/reload to fix it! |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
1 row in set (1.09 sec)

Главный вопрос: как обновить эти таблицы и быстрее получить данные в сети?

Дополнительные вопросы:

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

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

Однажды мы 'set global myisam_max_sort_file_size=21474836480;' и перезапустил mysql, он начал использовать метод сортировки, который намного быстрее. Но затем на другом столе он вернулся к keycache, поэтому я увеличил его до 80G и снова перезапустил.

Все столы теперь обновлены.

Главный вопрос: как я могу обновить эти таблицы и быстрее получить данные в Интернете?

Простой ответ - запустить mysql_upgrade.

Использует ли myisamchk что-то вроде "myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename"обновить таблицу (т.е. не использовать метод кеширования ключей)?

Нет.

Могу ли я безопасно убить сценарий debian и обновить таблицы более эффективным методом?

Мне нужно узнать больше об этом скрипте.

Сервер изначально был запущен с key_buffer_size всего 16 млн. С тех пор я исправил это, установив глобальную переменную, но возможно ли, что сеанс сценария debian все еще использует какое-то меньшее значение? Если да, могу ли я это изменить?

Вы можете сделать это за сеанс:

mysql> SET SESSION key_buffer_size = ... ;