web-dev-qa-db-ja.com

mySqlの復元が非常に遅い

この質問は、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分もかかりません-構成が異なり、誰もアクセスしていません）

    • key_buffer_sizeは512Mb [合計RAMの約12.5％]です。 table_cache = 256は最適とは言えません（ただし、その間にリクエストが多すぎることはありません）。 read_buffer_size = 1M。 sort_buffer_size = 64M
    • 復元スクリプトでは、データを挿入する前に各テーブルがロックされ、データが挿入されてからテーブルがロック解除されます。
    • スロークエリログが有効になっている（およびダンプからのほとんどのクエリがそこに場所を見つける）-高いI/Oがパフォーマンスに影響を与えている可能性がありますか？

根本的な原因を解明して軽減できるようにしています。サーバーへのアクセスが制限されているため、考えられる質問を収集して、それらをホスティングプロバイダーに持っていくようにしています。見ておくべき指針を教えていただけませんか。

この間の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;
mysqlmysqldumprestoreperformanceslow-log
2
TJ-

サーバー構成が含まれていないため、考えられるすべてを記述しています。

すでに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 を使用する必要があります。

1
Jai

これは完全にずれているかもしれませんが、ディスクシステムが最適に動作していることを確認しましたか？それは起こったばかりのように思え、あなたのデータベースは短期間にそれほど大きく成長しなかったと思います。

故障したRAIDディスク、または故障した標準ドライブは、あらゆる種類の書き込みエラー/待ち時間の原因となる可能性があります。

実際にはDBAの回答ではありませんが、確認する価値があります。

0
Mike