web-dev-qa-db-ja.com

Percona-Cluster：バックアップと復元の手順

3ノードのperconaクラスターの1つのノードから取得した完全バックアップを復元しようとしています（perconaクラスター5.5、galera 2.1、wsrep sstメソッドはrsync、innodbテーブルのみ）。

バックアップは次のように行われました。

rm -rf /tmp/backup/mysqldb
innobackupex --user=bkpuser --password=xxxx --galera-info --no-timestamp /tmp/backup/mysqldb/
innobackupex --apply-log --use-memory=2G /tmp/backup/mysqldb/

私が試みている復元手順は次のとおりです。

  1. 3つのノードすべてでmysqlをシャットダウンします
  2. 最初のノード
    1. mysqlデータディレクトリの内容を削除します
    2. mysql redologs/binlogs、doublewriteファイルなどを削除します（これらは別のフォルダーにあります）
    3. データベースインスタンスのデータベーステーブルスペースファイルをコピーバックします
    4. mysqlデータベースのデータベーステーブルスペースファイルをコピーバックします
    5. やり直し/ビンログ、ファイルの二重書き込みなど
    6. mysqlをwsrep_urls = gcomm://で開始して、クラスターを初期化します
  3. 2番目と3番目のノード
    1. mysql redologs/binlogs、doublewriteファイルなどを削除します
    2. galera.cacheとgrastate.datを削除します
    3. mysqlを開始します（wsrep_urls = gcomm://firstnode:port,gcomm://secondnode:port,gcomm://thirdnode:port）
  4. クラスタがすべて同期されたら、完全なwsrep_urls構成で最初のノードを再起動します

（wsrep_urlsが非推奨になっていることは知っていますが、まだwsrep_cluster_addressを使用できるようにガレラを取得していません。）

私の問題は、2番目と3番目のノードがSSTの後にエラーを報告することです。テーブルごとに、次のエラーが表示されます。

130225 15:44:43 [ERROR] Cannot find or open table myTestDb/settings from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem.

Mysql show tablesはテーブルを既存のものとして表示しますが、それらから選択しようとすると、エラーTable 'myTestDb.settings' does not exist ..を報告します。

Mysqlを起動してsstを要求する前に、ローカルテーブルスペースファイルを削除しようとしましたが、同じ結果になります。

復元はどのように実行すればよいですか？バックアップファイルをすべてのノードにコピーして戻す必要がありますか？

backup-restorationperconapercona-xtradb-cluster
1
Hank

使用しているSSTメソッドについては言及していません。エクストラバックアップだと思いますか？

2番目と3番目のノードで説明する症状は、ibdata1ファイルにあるInnodbデータディクショナリが欠落している（そして再初期化されている）ように聞こえます。 1番目のノードの適切な場所からコピーされていない可能性があります。

Trxログや「別のフォルダ」内のファイルの二重書き込みなどについて言及されました。 my.cnfのInnodb設定は何ですか？あなたは、perchance、innodb_data_home_dirを設定しますか（そしてそれはあなたの標準のdatadirの外にあります）？

もしそうなら、それはおそらくこのバグです： https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1098566 、またはおそらくそれに類似したもの。

1
Jay Janssen

答えを見つけるのに多くの時間がかかりました。ドナーノードからinnobackup.backup.logを読み取り、追加ノードで作成されているデータを観察すると、なぜこれが発生するのかがわかります。

私はまったく同じ問題を抱えています。私の場合、カスタマイズされたinnodb_data_home_dirをコメントアウトすると、innodb_log_group_home_dirの値で問題が解決します。

グループと同期した後、それらの値を有効にしてファイルをコピーするだけです。

お役に立てれば。

1
Sam wen