web-dev-qa-db-ja.com

InnoDBを別のマシンに復元する

現在、すべてのMySQLデータベースのPercona XtraBackupで作成されたバックアップがあります。

私の具体的なシナリオは、テストのために1か月前のInnoDBデータベーススナップショットをローカルマシンに復元したいのですが、Perconaのドキュメントでその手順を見つけることができないようです。

Googleを読んでいると、自分のマシンでtar.gzファイルを抽出し、トランザクションログを「再生」する必要があるという結論に達しました。

したがって、私の質問は、どのような具体的な手順が必要か、DBスナップショットを自分のマシンに復元する際の注意事項は何ですか。

最後に、XtraBackupを単独で使用しても、問題が発生した場合にデータを復元できるとは限りません。たとえば、サーバーがバックアップを停止させた場合、トランザクションログがなければ役に立たないでしょう。したがって、私の質問の一般的な言い回しは、希望する任意のマシンでデータを確実に復元できるようにするためにどのような手順を踏む必要があるかです。

私の専門分野はデータベース管理ではないことに注意してください。

回答で与えられた指示に従って、私はバックアップアーカイブを抽出し、正常に完了したinnobackupex --apply-log .を使用してバックアップを「準備」しました。次に、mysqlを停止し、すべてのファイルをバックアップディレクトリからmysqlデータディレクトリにコピーして、mysqlを再起動しました。

（ルートパスワードをリセットした後）ログインすると、DBとそのテーブルを（管理者を使用して）表示できますが、1つを選択すると、テーブルが存在しないというエラーが発生します。したがって、私は最初に別のマシンに復元する方法、次にバックアップがいつでも/どこでも必要なときに使用できることを確認する方法について、まだ元の質問にあります。

余談ですが、私が読んでいるところから、各テーブルに.idbファイルがあるはずですが、そのようなものは何も表示されません。

私はすべてを正しく行っているようです。私のバックアップスクリプトには

#!/bin/bash
BDIR="/disk2/backup/mysql"

/usr/bin/innobackupex --user=backup --password=xxx --ibbackup=xtrabackup --stream=tar /tmp | gzip -c -9 > $BDIR/`date -u +%Y-%m-%dT%H:%M:%SZ`.tar.gz

また、ファイルをオフサイトでrsyncします。

ファイルをダウンロードし、抽出（tar -ixvzf）、上記のようにログを適用し、mysqlを停止してファイルをdatadir（cp）にコピーし、権限を適用し、起動してログインします。バックアップデータベースを参照するとエラーが発生する

140730 16:28:49 [エラー] InnoDBの内部データディクショナリからテーブルlead @ 002dmanager @ 002dbackup/crm_Word_banが見つからないか、開けません。テーブルの.frmファイルは存在します。 InnoDBデータファイルを削除して再作成したが、対応するInnoDBテーブルの.frmファイルを削除するのを忘れたか、.frmファイルを別のデータベースに移動した可能性がありますか？または、このバージョンのエンジンがサポートしていないインデックスがテーブルに含まれています。

すべてのdbテーブル。

サーバー上のMySQLバージョンは5.1、ローカルバージョンは5.5です

mysqlinnodbrestorebackupxtrabackup
2
user67435

Percona XtraBackupを使用して完全バックアップを作成、保存、復元する方法に関する公式ドキュメント を参照してください。 Percona XtraBackupは、データ損失がないことを保証します：

次のように要約できます。

  1. バックアップを実行します（innobackupex）。オプションで、バックアップの実行と同時にリモートで送信、圧縮、暗号化などを行うことができます。これは、元のデータベースサーバーにアクセスする必要がある唯一のポイントです。

  2. 最初のステップでリモートで送信しなかった場合は、ここで送信してください。ローカルバックアップは便利ですが、実際のバックアップ戦略ではありません。バックアップを完了するには、構成ファイル（/etc/my.cnfとバイナリ実行可能ファイルを他のソース（たとえば、ディストリビューション）から取得できない場合）もコピーする必要があります。

  3. バックアップとリカバリプロセスの間のいつでも、準備フェーズ（innobackupex --apply-log）。これには、元のサーバーではなく、バックアップファイルのみが必要です。 これにより、トランザクションログが作成されます

  4. それを適用した後、サーバーがダウンしている間にファイルを元のディレクトリにコピーして戻します。あなたはそれをinnobackupex --copy-backローカルにファイルがある場合、または単に(s)cp/rsync。 ファイルの権限を適切なユーザー（通常はmysqlユーザー）に変更することを忘れないでください。

  5. サーバーを起動します。完了です。

これにより、完全バックアップが復元されます。これが安全な方法であることを保証するために、Galeraクラスターはこれを使用してノードを自動的に（人間の介入なしに）複製できます。これは、利用可能な最も安全で最速の方法です。

個々の.ibdファイルが表示されない場合、いくつかの理由が考えられます。MyISAMまたはそれらを使用しない別のエンジンを使用しているか、InnoDBをinnodb_file_per_table = 0、またはコピープロセスで一部のファイルを失った（またはファイルのアクセス権が間違っている）。最後の起動以降の完全なエラーメッセージとエラーログ、およびdatadirの再帰的なリストを提供してください。

Percona XtraBackupのトレーニングの作成者として、私はそれを扱うときに私たちが行うすべての 典型的なばかげた間違い にかなり精通しています。

追加情報をありがとう、フォローアップとしての私の提案は次のとおりです。

  1. XtraBackupの最新バージョン innodbプラグインがない5.1とは互換性がありません 。 MySQL 5.1をストックInnoDB（プラグインまたはPercona/MariaDBではない）で使用していますか？また、新しい形式のMySQLにバイナリ形式でリカバリするには、追加のアップグレード手順/予防策が必要になる場合があります。これはバイナリ形式で実行できます。提案：古いバージョンのXtrabackupを使用するか、サーバーをアップグレードしてください。プラグインなしの5.1は6年前のリリースで、どこでもほとんどサポートされていません。 <5.1に固執したい場合は、代替のバックアップツールも提供できます（ただし、非常に高速なものはほとんどありません）。

  2. 私はデータベース/テーブル名が好きではありません-再確認するだけです、db：lead @ 002dmanager @ 002dbackup table：crm_Word_banがテーブルの1つの正しい名前であり、それが.frmの正確な名前であることを確認できますファイル？ファイルシステムの問題を破棄したい。

1
jynus