Похоже, что большие базы данных innodb с пиками нагрузки вызывают случайные сбои, когда в консоли «задача висит на 120 секунд». Во время этих сбоев журналы не записываются в систему. Столы innodb довольно большие, хранилище 20+ гигабайт.
Может ли фрагментация таблицы с большими нагрузками ввода-вывода в Ubuntu 10.04 с ядром 2.6.36 и 2.6.38-15 64 бит вызвать случайные сбои системы?
Мы изучаем проблемы со случайными сбоями системы при работе с большими таблицами innodb, размещенными на «выделенных» серверах, размещенных на виртуальных серверах.
Версия MySQL - 5.1.
Вот результаты: «SELECT data_length, index_length, (data_length + index_length) / power (1024,3) GB FROM information_schema.tables WHERE ENGINE = 'InnoDB' ORDER BY data_length + index_length DESC LIMIT 10;»:
+-------------+--------------+-------------------+
| data_length | index_length | GB |
+-------------+--------------+-------------------+
| 14758707200 | 17220501504 | 29.782958984375 |
| 9456762880 | 16465543168 | 24.1420288085938 |
| 16983785472 | 6954041344 | 22.2938385009766 |
| 5625610240 | 2997813248 | 8.03118896484375 |
| 3694133248 | 1730150400 | 5.0517578125 |
| 2031091712 | 35209216 | 1.92439270019531 |
| 1357905920 | 706740224 | 1.9228515625 |
| 1107312640 | 320356352 | 1.32962036132812 |
| 637534208 | 760889344 | 1.30238342285156 |
| 488636416 | 260620288 | 0.697799682617188 |
+-------------+--------------+-------------------+
Открытых файлов = 300.
тиа
Есть ли много клиентов, обращающихся к этой базе данных, или всего несколько одновременных подключений? Достаточно ли оперативной памяти или сервер меняет местами?
То, что вы описываете абсолютно жестяная банка произойдет, но это будет означать либо очень загруженную рабочую нагрузку, либо очень медленную / ненадежную подсистему ввода-вывода.
Вы пробовали какой спектакль bonnie++
, iozone
или какой-то другой инструмент для тестирования даст ваш сервер?
Похоже, у вас огромные столы
Если вы хотите дефрагментировать таблицу InnoDB mydb.mytable, просто выполните следующее:
ALTER TABLE mydb.mytable ENGINE=InnoDB;
Под ходдом он будет делать следующее:
CREATE TABLE mydb.mytablenew LIKE mydb.mytable;
INSERT INTO mydb.mytablenew SELECT * mydb.mytable;
ALTER TABLE mydb.mytable RENAME mydb.mytableold;
ALTER TABLE mydb.mytablenew RENAME mydb.mytable;
DROP TABLE mydb.mytableold;
Если вы хотите выполнить массовую дефрагментацию всех таблиц InnoDB, просто запустите это:
echo "SET SQL_LOG_BIN = 0;" > /root/DefragInnoDB.sql
MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
SQL="SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')"
SQL="${SQL} FROM information_schema.tables WHERE engine='InnoDB'"
mysql ${MYSQL_CONN} -ANe"${SQL}" >> /root/DefragInnoDB.sql
mysql ${MYSQL_CONN} -A < /root/DefragInnoDB.sql
Возможно, вам не нужно так часто дефрагментировать InnoDB. Ознакомьтесь с моим сообщением на DBA StackExchange, чтобы определить, нужно ли дефрагментировать какую-либо одну таблицу InnoDB..
Между прочим, некоторые таблицы выглядят так, будто индекс занимает больше места, чем данные. После выполнения дефрагментации этих таблиц вернитесь и просмотрите индексы в каждой таблице. Попробуй определить если есть неиспользуемые индексы и удалите их.
У вас 300 как innodb_open_files. Вы можете поднять его выше, но не сходите с ума, устанавливая его слишком высоко
См. Следующие сообщения в innodb_open_files
Я также хотел бы порекомендовать вам обновить MySQL 5.5, где вы можете поднять innodb_read_io_threads и innodb_write_io_threads для лучшего использования ЦП механизмом хранения InnoDB.