web-dev-qa-db-ja.com

InnoDBのmysqlhotcopyに相当するものはありますか？

現在、私はmysqldumpを使用してバックアップを作成していますが、これは低速ですが問題ありません。大きな問題はデータベースの復元であり、これには数日かかります。ダンプは約7GBgzipで圧縮されているため、小さなデータベースではありませんが、mysqlで妥当な範囲外にあるべきではありません。

それで、私の他のオプションは何ですか？ mysqlhotcopyのようなものは完璧でしょう。

mysqlbackupdatabaseinnodb
4
taw

Perconaの Xtrabackup を見てください。これは、ホットバックアップを可能にし、完全に無料です。

8
Nick Kavadias

あなたが持っている場合 --innodb_file_per_table .ibdファイルと関連するテーブルをあるデータベースから別のデータベースに移動できるよりも有効にするには、RENAMETABLEステートメントを使用します。

RENAME TABLE db1.tbl_name TO db2.tbl_name;

.ibdファイルの「クリーンな」バックアップがある場合は、次のようにして、元のMySQLインストールに復元できます。

このALTERTABLEステートメントを発行して、現在の.ibdファイルを削除します。

ALTER TABLE tbl_name DISCARD TABLESPACE;

バックアップ.ibdファイルを適切なデータベースディレクトリにコピーします。

このALTERTABLEステートメントを発行して、テーブルに新しい.ibdファイルを使用するようにInnoDBに指示します。

ALTER TABLE tbl_name IMPORT TABLESPACE;

このコンテキストでは、「クリーンな」.ibdファイルバックアップは、次の要件が満たされているバックアップです。

.ibdファイルには、トランザクションによるコミットされていない変更はありません。

.ibdファイルにマージされていない挿入バッファエントリはありません。

パージにより、削除マークが付けられたすべてのインデックスレコードが.ibdファイルから削除されました。

mysqldは、.ibdファイルの変更されたすべてのページをバッファープールからファイルにフラッシュしました。

次の方法を使用して、クリーンなバックアップ.ibdファイルを作成できます。

Mysqldサーバーからのすべてのアクティビティを停止し、すべてのトランザクションをコミットします。

SHOW ENGINE INNODB STATUSがデータベースにアクティブなトランザクションがないことを示し、InnoDBのメインスレッドステータスがWaiting for serveractivityになるまで待ちます。次に、.ibdファイルのコピーを作成できます。

.ibdファイルのクリーンコピーを作成する別の方法は、市販のInnoDBホットバックアップツールを使用することです。

3
JohnZ

InnoDB/Oracle Hot Backupツール があります。これにはお金がかかります。私はそれを使ったことがありませんが、缶に書かれていることをしていると思います。

個人的には、InnoDBテーブルの LVMスナップショット を取得し、スナップショットからバックアップします-復元時に、システムクラッシュがInnoDBに発生したようです。これは、起動時に通常のログ再生プロセスを実行します。 。私はバックアップへのベルトとブレーサーのアプローチが好きなので、通常のスナップショットと-rsyncsを頻度の低いmysqldumpsと組み合わせます（そして、かなり最近のSQLダンプをぶら下げておくと便利な場合がありますとにかく周り）。

1
Stephen Veiss

mysql_manager ruby​​gemにホットコピーのサポートを追加しましたが、それはmysqlディレクトリ全体のホットコピーのみをサポートします。これは、同期期間が許容できるまでテーブルロックなしで繰り返しrsyncを実行し、最後のrsyncを実行する前にFLUSH TABLES WITH READ LOCKを使用してロックを取得することで実現します。 rsyncを使用しているため、リモートホストもサポートします。

使い方はとても簡単です。

最初にgemをインストールします。

gem install mysql_manager

これがあなたがそれを実行する方法です。

mysql-manager --hotcopy \
              --hotcopy:data-dir /var/lib/mysql/ \
              --hotcopy:backup-dir [email protected]:/tmp/mysql/ \
              --hotcopy:rsync-args "-av --exclude=*.err" \
              --hotcopy:rsync-ttl 30 \
              --db:user root \
              --db:pass $MYSQL_ROOT_PASSWORD
0
Erik Osterman

ダンプ/復元ソリューションではなく、現在の復元に非常に時間がかかる理由を知っていると思います。

非常に大規模なデータベース（最大40GB）がいくつかあり、1時間以内にサイズを復元しました。

復元中に挿入を高速化するためにmysqldumpが行うことの1つは、インデックスをオフにし、すべての挿入を実行してから、インデックスをテーブルに適用することです。

いくつかのmysql変数が十分に大きくない場合、mysqlは「キーキャッシュによる修復」または同様の何かであると言います...これは非常に、非常に、非常に遅いです。

適切な変数が十分に大きく設定されている場合、「並べ替えによる修復」と表示されます。これははるかに高速です。

頭のてっぺんから正確な変数を思い出せませんが、そう思われる場合は、コメントで知らせてください。詳細を追跡できるかどうかを確認できます。

Nickが述べたように、PerconaのXtrabackupも一見の価値があります。

0
Jarod Elliott

MyISAMテーブルがある場合は、それらをInnoDBに変更することをお勧めします。これが私が使うものです：

    mysql -u root --password=<password> --database=db_name -B -N -e "SHOW TABLES" | awk '!/not_this_db/ && !/or_this_one/ && /^[a-z]/ {print "ALTER TABLE", $1, "ENGINE=INNODB;"}' | mysql -u root --password=<password> --database=db_name

上記の例では、小文字で始まるdbのみなど、awk正規表現を使用してデータベースを除外および含めることができます。もちろん、これにより変更中にテーブルがロックされます。

次に、xtrabackupを使用して、テーブルをロックしたり、ディスクを使いすぎたりせずに、データベース全体を別のサーバーに直接コピーしますIO（ssh rsaキーの設定後）：

innobackupex --throttle=500 --compress --stream=xbstream /doesntneedtoexist | ssh user@otherhost "xbstream -x -C /root/backup/"

次に、ログの適用手順を完全に分離して実行し、運用サーバーのディスクスペース、IO、およびCPUを節約できます。

xtrabackupを使用するためのPerconaのHowTO

0
Brad

InnoDBを使用している場合は、パフォーマンスを向上させるために構成できるパラメーターが多数あります。 InnoDBを使用している場合、innodb_file_per_tableが非常に小さい場合は静かです。このパラメータのサイズを合計の少なくとも50％に増やしてRAM）、復元にかか​​る時間を確認してください。

これとは別に、innodb_thread_concurrencyパラメーターを増やすことができます。

Perconaxtrabackupも試してください。私はそれをDbのTBに使用していますが、これは完全に機能します。

0
user3057232