У меня есть то, что похоже на замедление восстановления MySQL, и я ищу некоторые рекомендации по настройке (я являюсь парнем PostgreSQL и SQL Server).Ошибка восстановления MySQL
Сервер dev имеет 48 ГБ оперативной памяти, 8 ядер, работает 64-разрядный процессор Centos 6.2 и MySQL 5.1.61 (то же, что и в производстве MySQL), и 4 x 7200 RPM SAS-диски в программном обеспечении RAID-10/XFS. Единственным процессом клиента MySQL является восстановление. Дамп был взят с помощью простого mysqldump всех баз данных на рабочем сервере.
Я применил некоторые параметры от http://derwiki.tumblr.com/post/24490758395/loading-half-a-billion-rows-into-mysql, включая установку FOREIGN_KEY_CHECKS и UNIQUE_CHECKS на ноль. Я включил my.cnf ниже.
Мониторинг восстановления с помощью mytop и pv (pv backup.sql | mysql -u root -p), похоже, что инструкции INSERT INTO начинают постепенно замедляться. qps, показанный mytop, начинается с 3 и падает до 0 на 60% через файл дампа. Не уверен, насколько точным является mytop в этом случае, поскольку 3 вставки (со значениями) все еще кажутся медленными. htop показывает < 10% загрузки процессора на процессор, используемый MySQL, и используется менее 8 ГБ 48 ГБ ОЗУ.
Различные базы данных, но аналогичные методы восстановления, работают примерно на 5-10 раз быстрее на том же сервере, используя PostgreSQL.
Идеи?
[mysqld]
# my.cnf
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
slow-query-log
long_query_time = 60
log-slow-admin-statements
slow_query_log_file = /var/log/mysql_slow.log
innodb_buffer_pool_size = 2G
max_allowed_packet = 1G
key_buffer_size = 1G
concurrent_insert = 1
innodb_flush_log_at_trx_commit = 2
bulk_insert_buffer_size = 1G
innodb_flush_method = O_DIRECT
Чтобы добавить к тайне, представляется, что восстановление MySQL 5.0 дампа на сервер 5.1 является частью проблемы. Применение дампа к экземпляру 5.0 занимает 40 минут, по сравнению с 3,75 часа для 5.1. – MattK