RDS MySQL論理バックアップのセルフマネージドデータベースへの復元 - ApsaraDB RDS

論理バックアップは標準的な mysqldump ファイルです。ApsaraDB RDS for MySQL インスタンスから Linux 上のセルフマネージド MySQL データベースへ、特定のデータベースまたはテーブルを復元する必要がある場合に、この方法を使用します。本ガイドでは、バックアップのダウンロード、解凍、およびデータのインポートについて説明します。

説明

ポイントインタイムリストアの場合は、ログバックアップと組み合わせて物理バックアップファイルを使用してください。どの方法が適しているか不明な場合は、「データ復元方法の概要」をご参照ください。

仕組み

RDS コンソールから論理バックアップファイルをダウンロードします。
.tar アーカイブを解凍し、その後データベースごとの .sql.gz ファイルを解凍します。
空のターゲットデータベースを作成し、mysql を使用してスキーマファイルとデータファイルをインポートします。

前提条件

開始する前に、以下を満たしていることを確認してください。

以下のすべてを満たす ApsaraDB RDS for MySQL インスタンス（[基本情報] ページでご確認ください）：
- メジャーバージョン： 8.0、5.7、5.6、または 5.5
- エディション： High-availability Edition
- ストレージタイプ：ローカル SSD
論理バックアップファイルが作成済みであること。論理バックアップは手動で作成する必要があります。システムはデフォルトで物理バックアップを作成します。詳細については、「手動バックアップ」をご参照ください。
RDS インスタンスと同じ MySQL メジャーバージョンを実行している Linux ホストで、解凍後のバックアップファイルを保存するのに十分な空きディスク容量があること。

説明

本ガイドでは、CentOS 7 および MySQL 5.7 を例として使用します。

バックアップファイルのダウンロード

インスタンスページに移動します。上部メニューで RDS インスタンスが存在するリージョンを選択し、インスタンス ID をクリックします。
左側のナビゲーションペインで、[バックアップと復元] をクリックします。
[ベースバックアップ] > [データバックアップ] タブで、復元したい論理バックアップファイルを見つけ、[操作] 列の [インスタンスバックアップファイルのダウンロード] をクリックします。

説明
[インスタンスバックアップファイルのダウンロード] が使用できない場合は、インスタンスエディションがバックアップダウンロードをサポートしているかどうかを確認してください。
[インスタンスバックアップファイルのダウンロード] ダイアログボックスで、ダウンロード URL をコピーします。
- ECS インスタンスと RDS インスタンスが同じ VPC にある場合 (推奨)、内部ネットワーク URL をコピーします。これは、特に大きなバックアップファイルの場合、より高速で安定しています。
- それ以外の場合、外部ダウンロード URL をコピーします。インターネットバックアップダウンロードには無料クォータが適用されます。クォータを超えるトラフィックには料金が発生します。詳細については、「課金」をご参照ください。

Linux ホストで次のコマンドを実行して、バックアップファイルをダウンロードします。<download_url> をコピーした URL に、<custom_file_name> を任意の名前に置き換えてください。

フラグ	説明
`-c`	再開可能なダウンロードを有効にします。中断された場合、停止した位置からダウンロードが再開されます
`-O`	指定した名前でファイルを保存します

wget -c '<download_url>' -O <custom_file_name>.tar

バックアップファイルの解凍

.tar アーカイブを展開します。

説明
This does not look like a tar archive が表示された場合は、物理バックアップではなく RDS 論理バックアップファイルをダウンロードしたことを確認してください。Wrote only 512 of 10240 bytes が表示された場合は、ディスク容量が不足しています。インスタンス構成を変更してディスク容量を増やしてから、再試行してください。
```
tar xvf <custom_file_name>.tar -C /tmp
```

展開後のディレクトリ構造を確認します。アーカイブには、データベースごとに 1 つのサブディレクトリが含まれており、それぞれにスキーマファイルとデータファイルがあります。

tree /tmp/backup_root/   # tar によって作成された実際のルートディレクトリに置き換えてください。

想定される出力：

/tmp/backup_root/
├── database1/   # ターゲットデータベース 1 のディレクトリ
│ ├── schema.sql.gz # データベーススキーマファイル
│ └── data.sql.gz   # データファイル
├── database2/   # ターゲットデータベース 2 のディレクトリ
│ ├── schema.sql.gz
│ └── data.sql.gz
└── config.txt    # バックアップメタデータ (オプション)

復元するデータベースのディレクトリに移動します。
```
cd /tmp/backup_root/<database_name>
```
.sql.gz ファイルを解凍します。
```
gzip -d schema.sql.gz
gzip -d data.sql.gz
```
これにより、次のステップでインポートする schema.sql と data.sql が生成されます。

データのインポート

MySQL にログインし、空のターゲットデータベースを作成します。使用するユーザーは、.sql ファイル内のすべての SQL ステートメントを実行する権限を持っている必要があります。

プレースホルダー	説明	例
`<user>`	MySQL ユーザー名	`root`
`<password>`	MySQL パスワード (`-p` の後にスペースなし)	`mypassword`
`<target_database_name>`	作成する空のデータベースの名前	`restored_db`

 mysql -u <user> -p<password>

 CREATE DATABASE <target_database_name>;
 EXIT;

プレースホルダーを次のように置き換えます。

スキーマをインポートし、次にデータをインポートします。

説明
Can't find master key from keyring が表示された場合は、インスタンスが本ガイドに記載されている前提条件を満たしていない可能性があります。RDS インスタンスのエディションとストレージタイプを確認してください。
```
 # テーブルスキーマをインポート
 mysql -u <user> -p <target_database_name> < schema.sql

 # データをインポート
 mysql -u <user> -p <target_database_name> < data.sql
```
各コマンドの後にパスワードの入力を求められたら、入力してください。

復元の検証

MySQL にログインし、テーブルとデータが存在することを確認します。

 mysql -u <user> -p

 USE <target_database_name>;
 SHOW TABLES;                            -- テーブルが存在することを確認
 SELECT COUNT(*) FROM <table_name>;      -- 行数を検証

テーブルとデータが表示されれば、復元は完了です。

よくある質問

インスタンスに論理バックアップがないのはなぜですか?

RDS はデフォルトで物理バックアップを作成します。論理バックアップを取得するには、手動で作成する必要があります。詳細については、「手動バックアップ」をご参照ください。

論理バックアップの復元ポイントインタイム値が 0 になっているのはなぜですか?

特定時点への復元には、物理バックアップとログバックアップの組み合わせが必要です。論理バックアップは特定時点への復元をサポートしていないため、[特定時点への復元] フィールドには 0 が表示されます。

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty を修正するにはどうすればよいですか?

このエラーは、ターゲットデータベースにすでにグローバルトランザクション識別子 (GTID) 履歴が含まれていることを示しています。次のいずれかの方法を使用してください。

ターゲットデータベースで GTID を有効にし、インポートを再実行してください。
GTID_PURGED のすべての行を .sql ファイル内でコメントアウトし、インポートを再実行してください。
プライマリ/セカンダリレプリケーションを使用していない場合は、ターゲットデータベースで RESET MASTER を実行して GTID 履歴をクリアしてから、インポートを再実行してください。

ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED を修正するにはどうすればよいですか?

.sql ファイルに、ターゲットデータベース内の既存の GTID 履歴と競合する GTID 情報が含まれています。RESET MASTER を実行して GTID 履歴をクリアしてから、インポートを再実行してください。

復元されたデータがプライマリデータベースにのみ存在し、セカンダリデータベースに同期されないのはなぜですか?

.sql ファイルに SESSION.SQL_LOG_BIN= 0 が含まれているため、インポート中にバイナリロギングが無効になり、変更がセカンダリデータベースにレプリケートされません。インポートファイルでこの設定を確認してください。

次のステップ

ApsaraDB RDS インスタンスのバックアップ — 今後の復元を容易にするために、自動バックアップを設定します。
mysqldump を使用した MySQL データの移行 — セルフマネージドデータベースから RDS インスタンスへデータを移行します。
RDS MySQL mysqldump オプション — ApsaraDB RDS for MySQL でサポートされているすべての mysqldump フラグのリファレンスです。