MySQL恢復性能

我有什麼似乎是減緩MySQL恢復，並尋找一些調整建議（我是一個PostgreSQL和SQL Server的傢伙）。MySQL恢復性能

dev服務器有48GB內存，8個內核，運行Centos 6.2 64位和MySQL 5.1.61（與生產MySQL相同），以及軟件管理RAID-10/XFS中的4 x 7200 RPM SAS驅動器。唯一的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語句開始逐漸變慢。 mytop顯示的qps從3開始，並通過轉儲文件以60％下降到0。不確定在這種情況下mytop的準確度如何，因爲3個插入（帶有值）仍然看起來很慢。 htop顯示< MySQL使用的CPU的CPU利用率爲10％，使用的內存小於8GB。

不同的數據庫，但類似的恢復技術，使用PostgreSQL在同一臺服務器上運行速度快5-10倍。

想法？

[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

來源

2012-06-06 MattK

爲了增加神祕感，似乎一個MySQL 5.0轉儲恢復到5.1服務器是問題的一部分。將轉儲應用於5.0實例需要40分鐘，而5.1則需要3.75小時。 – MattK

聽起來像你的innodb指數會讓你放慢腳步。如果可以更改轉儲數據庫的方式，則可以刪除所有非主鍵索引來加載數據，然後重新添加它們。更好的是，還要命令數據由主鍵加載。這可能太多問了。

聽起來像是你已經知道這些提示：http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html

沖洗到磁盤的操作（innodb_flush_log_at_trx_commit = 2）可能會發生很多次。檢查您的innodb_log_file_size * innodb_log_files_in_group是否足以避免太頻繁地寫入磁盤。

（我以爲你正使用InnoDB從設置）

來源

2012-06-06 03:44:44 KCD

是的，InnoDB。我無法控制備份方法，但我可能會在轉儲中註釋掉索引創建。我猜標準轉儲不會在最後放置索引嗎？ – MattK

不，它不是，我記得innodb不能忽視它們。你可以對結構使用'mysqldump --no-data'，然後對數據使用'mysqldump --no-create-info'。有了這些，測試應該不會太難。祝你好運，希望它有幫助 – KCD

在這個數據庫中，其他主鍵（NIH）上沒有索引。我會從上面的建議中嘗試其他一些配置選項。 – MattK

回答

相關問題