この質問は、DBA @ SEで既に行われている質問に似ています。
現在の構成では、サーバー(4 GBのRAMを備えたLinuxクアッドコアボックス)があり、データベースとアプリケーションサーバーの両方がこのサーバーでホストされています。 2つのMySqlデータベース-ProdおよびStagingが同じサーバー上にあります。一部のテーブルはMyIasmエンジンにあり、一部はInnoDBにあります。
root 10119 1 0 1233 1012 3 Mar03 ? 00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe ...
mysql 10233 10119 9 238047 108896 0 Mar03 ? 12:11:11 /usr/local/mysql/libexec/mysqld ...
Prod dbのダンプが毎日取得され、Staging dbに復元されます。合計サイズは1 GBに近く、いくつかのテーブルには100万行を超える行があります。
MySqlDumpによるダンプの取得は高速で、1分もかかりません(完全なダンプ-バイナリログからのデルタだけではありません)。 auto_commit、foreign_key_checksなどをオフにするなどの最適化がダンプに追加されました。
数日後、復元部分(Staging DBへ)は、約1時間かかり、アプリケーションが麻痺するため、非常にひどくなりました。(私の開発ボックスでの同じ復元には4分もかかりません-構成が異なり、誰もアクセスしていません)
根本的な原因を解明して軽減できるようにしています。サーバーへのアクセスが制限されているため、考えられる質問を収集して、それらをホスティングプロバイダーに持っていくようにしています。見ておくべき指針を教えていただけませんか。
この間のCPU使用率とI/Oピーク。
ありがとうございました。
[[Edit]-innodb_buffer_pool_sizeを増やした後、復元時間がある程度短縮されました。
This is the sample dump, that gets generated:
SET FOREIGN_KEY_CHECKS=0;
SET unique_checks=0;
SET AUTOCOMMIT=0;
// The scripts go here:
DROP TABLE IF EXISTS `access_tokens`;
CREATE TABLE `access_tokens` ( ... );
LOCK TABLES `access_tokens` WRITE;
INSERT INTO `access_tokens` VALUES (...) // All of the data is in a single insert
UNLOCK TABLES;
...
// Script for other tables
SET FOREIGN_KEY_CHECKS=1;
SET unique_checks=1;
COMMIT;
SET AUTOCOMMIT=1;
サーバー構成が含まれていないため、考えられるすべてを記述しています。
すでにinnodb_buffer_pool_sizeがあるため、スキップします。
ステージングサーバーで次を使用する
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 256M
Mysqldumpでは次のオプションを使用します
--disable-keys
--extended-insert
--add-locks
ログサイズの変更 this way を使用する必要があります。
これは完全にずれているかもしれませんが、ディスクシステムが最適に動作していることを確認しましたか?それは起こったばかりのように思え、あなたのデータベースは短期間にそれほど大きく成長しなかったと思います。
故障したRAIDディスク、または故障した標準ドライブは、あらゆる種類の書き込みエラー/待ち時間の原因となる可能性があります。
実際にはDBAの回答ではありませんが、確認する価値があります。