すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:論理バックアップファイルから自己管理 MySQL インスタンスに ApsaraDB RDS for MySQL インスタンスのデータを復元する

    ドキュメントセンター

    ApsaraDB RDS:論理バックアップファイルから自己管理 MySQL インスタンスに ApsaraDB RDS for MySQL インスタンスのデータを復元する

    最終更新日:Nov 09, 2025

    このトピックでは、mysqldump を使用して、論理バックアップファイルから自己管理 MySQL インスタンスに ApsaraDB RDS for MySQL インスタンスのデータを復元する方法について説明します。

    説明

    前提条件

    • RDS インスタンスが次の要件を満たしていること:

      • RDS インスタンスは MySQL 8.0、MySQL 5.7、MySQL 5.6、または MySQL 5.5 を実行していること。

      • シリーズ: 高可用性 (HA) シリーズ

      • RDS インスタンスがローカル SSD を使用していること。

      説明

      RDS インスタンスの [基本情報] ページで上記情報を確認できます。

    • RDS インスタンス用に論理バックアップファイルが作成されていること。 詳細については、「ApsaraDB RDS for MySQL インスタンスの自動バックアップポリシーを設定する」をご参照ください。

    ランタイム環境

    自己管理インスタンスは 64 ビット Linux オペレーティングシステムにインストールされ、RDS インスタンスと同じ MySQL バージョンを実行します。 このトピックでは、CentOS 7 と MySQL 5.7 を例として使用します。

    手順

    1. [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDS インスタンスを見つけ、インスタンスの ID をクリックします。

    2. 左側のナビゲーションウィンドウで、バックアップと復元 をクリックします。

    3. 基本バックアップリスト > データバックアップ リストで、ダウンロードする論理バックアップファイルを見つけ、[操作] 列の ダウンロード をクリックします。

      説明

    4. ダウンロード ダイアログボックスで、外部ダウンロード URL の右側にある コピー をクリックして URL をコピーします。

      重要

      • インターネット経由でのバックアップダウンロードには無料クォータが提供されます。 インターネット経由でバックアップファイルをダウンロードするために消費するトラフィック量が無料クォータを超えた場合、消費した超過トラフィックに対して課金されます。 詳細については、「課金」をご参照ください。

      • Elastic Compute Service (ECS) インスタンスが RDS インスタンスと同じ Virtual Private Cloud (VPC) にある場合は、内部 URL を使用して論理バックアップファイルをダウンロードできます。 このダウンロード方法はより高速で安定しています。

    5. 自己管理データベースがデプロイされている Linux オペレーティングシステムにログインし、次のコマンドを実行して論理バックアップファイルをダウンロードします: 

      wget -c '<External download URL of the data backup file>' -O <Custom file name>.tar
      説明

      • -c オプションは、再開可能なダウンロード機能を有効にします。

      • -O オプションは、ダウンロードした論理バックアップファイルが指定されたファイル名に基づいて保存されることを指定します。

    6. システムデータベースとユーザー作成データベースの圧縮ファイルを含む、論理バックアップファイルを解凍します。

      1. 次のコマンドを実行してバックアップファイルを解凍します:

        tar xvf <Custom file name>.tar -C /tmp
        説明

        • 解凍中に This does not look like a tar archive などのエラーメッセージが表示された場合は、ダウンロードしたファイルが RDS インスタンスの論理バックアップファイル であるかどうかを確認してください。

        • 解凍中に Wrote only 512 of 10240 bytes. Exiting with failure status due to previous errors などのエラーメッセージが表示された場合は、ディスク領域がいっぱいになっていないか確認してください。 構成を変更 してディスク領域を拡張し、再試行できます。

      2. 次のコマンドを実行して、解凍後のディレクトリ構造を表示します:

        tree /tmp/backup_root/  # 解凍後の実際のルートディレクトリに置き換えます

        複数レベルのバックアップファイル構造の例:

        /tmp/backup_root/
├── database1/   # ターゲットデータベース 1 のディレクトリ
│ ├── schema.sql # データベース構造ファイル
│ └── data.sql   # データファイル
├── database2/   # ターゲットデータベース 2 のディレクトリ
│ ├── schema.sql
│ └── data.sql
└── config.txt    # バックアップメタデータ (不要)

    7. 次のコマンドを実行して、ターゲットデータベースディレクトリに移動します:

      cd /tmp/backup_root/database_name  # 実際のデータベース名に置き換えます

    8. 次のコマンドを実行して、復元するターゲットデータベースの圧縮ファイル (.sql.gz 拡張子) を解凍します: 

      gzip -d schema.sql.gz  # 構造ファイルを解凍します
gzip -d data.sql.gz    # データファイルを解凍します
      説明

      解凍によって取得された .sql ファイルは、ステップ 10 でインポートされます。

    9. 次のコマンドを実行して、データベースにログインし、空のデータベースを作成します:

      説明

      後続のステップで使用されるユーザーは、.sql ファイル内のすべての SQL 文を実行する権限を持っている必要があります。

      mysql -u user -p<Database password>
create database <The name of the empty database>;
exit

    10. 次のコマンドを実行して、.sql ファイルをデータベースにインポートします: 

      # テーブルスキーマのインポート
mysql -u user -p <The name of the empty database> < schema.sql

# データのインポート
mysql -u user -p <The name of the empty database> < data.sql
      説明

      • 上記のコマンドが正常に実行されると、パスワードの入力を求めるメッセージが表示されます。 パスワードを入力して Enter キーを押します。

      • 「Can't find master key from keyring」というエラーメッセージが表示された場合は、RDS インスタンスがすべての前提条件を満たしているかどうかを確認してください。

    11. 復元結果を確認します。 データベースにデータが表示されれば、移行は成功です。

      mysql -u user -p
mysql> USE <The name of the empty database>;
mysql> SHOW TABLES;       # テーブルが存在するかどうかを確認します
mysql> SELECT COUNT(*) FROM <Table name>;  # データ量を確認します

    よくある質問

    • RDS インスタンスに論理バックアップファイルがないのはなぜですか？

      デフォルトでは、ApsaraDB RDS は物理バックアップを作成します。 必要に応じて、論理バックアップを手動で作成する必要があります。 詳細については、「ApsaraDB RDS for MySQL インスタンスの自動バックアップポリシーを設定する」をご参照ください。

    • 論理バックアップファイルをダウンロードするときに、バックアップセットの復元ポイント の値が 0 になるのはなぜですか？

      ApsaraDB RDS for MySQL インスタンスの物理バックアップファイルとログバックアップファイルを使用して、特定の時点にデータを復元できます。 したがって、特定の バックアップセットの復元ポイント (タイムスタンプ) が表示されます。 論理バックアップファイルは、特定の時点にデータを復元するために使用することはできません。 したがって、[整合性時間] の値は 0 です。

    • ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. エラーを解決するにはどうすればよいですか？

      この問題は GTID が原因で発生します。 次の方法で問題を解決できます:

      • GTID 機能を有効にします。 次に、このトピックの「手順」セクションの手順を繰り返してデータを復元します。

      • GTID 機能を有効にしたくない場合は、インポートファイル (.sql 拡張子) 内のすべての GTID_PURGED コンテンツをコメントアウトします。 次に、このトピックの「手順」セクションの手順を繰り返してデータを復元します。

      • プライマリインスタンスとセカンダリインスタンス間でデータをレプリケートする必要がない場合は、データベースにログインして RESET MASTER コマンドを実行します。 次に、このトピックの「手順」セクションの手順を繰り返してデータを復元します。

    • ERROR 3546 (HY000) at line 26: @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED エラーを解決するにはどうすればよいですか？

      インポートファイル (.sql 拡張子) に GTID 情報が含まれている場合、データベースに他の GTID 情報が含まれていてはなりません。 データベースにログインし、RESET MASTER コマンドを実行してデータベースをリセットします。 次に、このトピックの「手順」セクションの手順を繰り返してデータを復元します。

      restmaster

    • データが自己管理インスタンスに復元された後、データが自己管理インスタンスのセカンダリインスタンスに自動的に同期されないのはなぜですか？

      インポートファイル (.sql 拡張子) に SESSION.SQL_LOG_BIN= 0 が含まれているかどうかを確認できます。 この設定により、プライマリインスタンスでの操作がセカンダリインスタンスに同期されなくなります。

      SQL_LOG_BIN