mysqldumpが進行中の場合、ユーザーはシステムの実行速度が遅いと不平を言う

MYSQLデータベース（ibdata1）のサイズは73 GBで、Windows 2008 O / SでINNODBテーブルの専用データベースサーバーとして実行するように構成されています。mysqldumpを使用してバックアップを実行していますmysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert- set-charset-圧縮--log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

バックアップファイルProddb0635.sqlは、データベースサーバーとは別のサーバーに保存されます。RAMは12 GBです。INNODBバッファープールのサイズは6 GBです。追加のmem.poolは32 MBです。クエリキャッシュのサイズは2 GBです。ネットバッファーの長さは最大16 Mです。パケットサイズ1 GB。

mysqlのバージョンは5.0.67です。

バックアップが実行されていない場合、ユーザーはパフォーマンスに満足しています。

バックアップの実行中にINNODBバッファープールのヒット率が100％に近い高い値になっています。保留中の読み取りまたは保留中の書き込みはありません。innodb wait freeは0です。CPU使用率は高くありません。最小9％から最大15％mysqlbackupが実行されているかどうかに関係なく、クエリキャッシュヒット率は約40％と低くなっています。現在、Windowsタスクマネージャーは、10 GBのRAMが使用されていることを表示しています。2 GBのRAMしか利用できない状態でクエリキャッシュを増やす必要がありますか？mysqlld-ntは9.2 GBのRAMを使用し、mysqldumpは5 MBのRAMを使用しています。Alos氏は、-compressオプションの有無にかかわらず、ダンプファイルのサイズは同じであることに注意しました。

iNNODBバッファープールのサイズを減らす必要がありますか？

ありがとう

Windowsには既知の問題があり、大きなファイルを別のサーバーにプッシュすると、すべてのメモリがユーザープロセスではなくシステムキャッシュに割り当てられることになります。タスクマネージャーの[物理メモリ（MB）]セクションで、システムキャッシュに割り当てられているメモリの量を確認できます。

これは、ローカルディスクにバックアップしてから、リモートマシンにそのファイルをプルさせることで解決できます。

状況に応じて、mysqldumpのパフォーマンスを向上させるために私が考えていることがいくつかあります。コマンドは次のとおりです。

mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert --set-charset --compress- -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

最初に気付くのは、出力をファイルシステムにリダイレクトしていることです。「devNas」と表示されているので、これはネットワーク接続ストレージであると想定します。私はバックアップ用のNASのファンですが、運用トラフィックとは別の物理NICに接続する必要があります。帯域幅を飽和させていなくても、競合します。--quickフラグを使用すると、メモリに保持する代わりにすべての行をフラッシュするため、これはさらに問題になります。

次に目にするのは、-compressを起動したことです。-hスイッチを使用していないため、mysqlをローカルで実行しているようです。これは、このコンテキストでは不要なローカルCPUを使用する場合があります。--compressは必要ですか？mysqldumpクライアントとmysqlサーバー間のデータのみを圧縮し、ファイルの内容は圧縮しません。

次に、-single-transactionフラグを使用していることを確認します。これは、mysqldumpの一部としてすべての選択をテストするため、余分なCPUが発生します。

これはパフォーマンスとは関係ありませんが、MyISAM（手動）でのみ機能する--disable-keysを使用しています。

mysqldumpをオフラインのホストからリモートで実行し、完了後にダンプファイルをNASに移動して、この操作を可能な限り帯域外にしてみてください。

観測＃1

InnoDBに対してmysqldumpを実行する際に注意する点があります。

InnoDBバッファープールに存在するダーティページは、最初にディスクにフラッシュする必要があります。mysqldumpは、ダーティページがまだあるInnoDBテーブルのフラッシュをトリガーします。

innodb_max_dirty_pages_pctというサーバーオプションがあります。デフォルト値は75がMySQL 5.5で、5.5より前のバージョンのMySQLでは90です。実稼働環境では、この数をデフォルト値のままにしても問題ありません。

InnoDBバッファープールにダーティページがたくさんあるかどうかを確認するには、次のコマンドを実行します。

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

ところでこれから示すようにページは16Kです：

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

InnoDBとmysqldumpの場合、2つの状況でこの数を減らすことができます。

CIRCUMSTANCE 1：永久に0に設定します

これをmy.iniに追加するだけです。

[mysqld]
innodb_max_dirty_pages_pct=0

これにより、InnoDBバッファープールが無駄のない状態に保たれます。ダンプされているInnoDBテーブルをフラッシュする手順は、mysqldumpが動作する前に、可能な限り少数のダーティページ（おそらく0）をフラッシュする必要があるため、迅速です。

唯一の欠点は、トラフィック量の多いDBからmysqldumpを実行する場合、ダーティページをより頻繁にフラッシュするため、書き込みI / Oがわずかに増加する可能性があります。これを実行することにより、mysqlをrestartnigせずにそうであるかどうかを判断できます。

SET GLOBAL innodb_max_dirty_pages_pct = 0;

設定を12〜24時間のままにします。書き込みパフォーマンスが許容できる場合は、問題ありません。そうでない場合は、次のように設定し直してください。

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2：mysqldumpの約1時間前に0に設定します

SET GLOBAL innodb_max_dirty_pages_pct = 0;

mysqldumpを実行する

SET GLOBAL innodb_max_dirty_pages_pct = 90;

観測＃2

あなたは持っている--complete-挿入を mysqldumpをオプションとして。これにより、VALUES句の前のすべてのINSERTステートメントに列名が埋め込まれます。--extended-insertを使用しても、挿入される行のバッチごとに、mysqldumpに送信される列名があります。--complete-insertを削除することで、mysqldumpに送信されるバイト数を減らすことができます。

勧告

スレーブとしてセットアップできる別のWindowsサーバーがある場合は、本番マシンからではなく、そのスレーブからmysqldumpを実行します。