すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Oct 16, 2024

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

背景情報

ApsaraDB RDS for MySQLを使用すると、RDSインスタンスのデータをバックアップファイルから自己管理データベースに復元できます。 物理バックアップファイルからの復元や論理バックアップファイルからの復元など、さまざまな復元方法がサポートされています。 データ復元方法の選択方法の詳細については、「データ復元方法の概要」をご参照ください。

次の操作を実行して、RDSインスタンスのバックアップ方法を確認できます。ApsaraDB RDSコンソールにログインし、RDSインスタンスの詳細ページに移動します。 インスタンスの詳細ページの左側のナビゲーションウィンドウで、バックアップと復元 をクリックします。 表示されるページで、[基本バックアップ] > [データバックアップ] を選択します。

image

説明

物理バックアップファイルが作成されていない場合は、このトピックで説明する操作を実行する前に、手動で物理バックアップファイルを作成できます。 詳細については、「ApsaraDB RDS For MySQLインスタンスの手動バックアップ」をご参照ください。

シナリオ

説明

このトピックで説明する手順は、ダウンロードした物理バックアップファイルを新しいApsaraDB RDS for MySQLインスタンスに復元する必要があるシナリオには適用できません。 このタイプの復元を実行するには、このトピックで説明する手順に従って、最初に物理バックアップファイルを自己管理型MySQLデータベースに復元してから、自己管理型MySQLデータベースのデータを新しいApsaraDB RDS for MySQLインスタンスに復元します。「MySQL 5.7またはMySQL 8.0を実行する自己管理型インスタンスのバックアップデータをApsaraDB for RDSインスタンスに復元する」を参照してください。

  • 今後、RDSインスタンスを長期間使用しない場合は、RDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元できます。 これにより、RDSインスタンスのデータを保持できます。

  • RDSインスタンスがリリースされ、取得できませんが、インスタンスの物理バックアップファイルをダウンロードした場合、RDSインスタンスのデータを物理バックアップファイルから自己管理MySQLデータベースに復元できます。

前提条件

  • RDSインスタンスは次の要件を満たしています。

    • RDSインスタンスは、MySQL 8.0、MySQL 5.7、MySQL 5.6、またはMySQL 5.5を実行します。

    • RDSインスタンスはRDS High-availability Editionを実行します。

    • RDSインスタンスはローカルディスクを使用しています。

    説明
    • RDSインスタンスの 基本情報 ページに移動して、上記の情報を取得できます。

    • 物理バックアップファイルは、RDSインスタンスがRDS High-availability Editionを実行している場合にのみダウンロードできます。 RDSインスタンスがRDS Basic Editionを実行している場合、その他のFAQに記載されている手順に基づいて、RDSインスタンスのデータを復元できます。

  • RDSインスタンスのテーブルは、透過的データ暗号化 (TDE) を使用して暗号化されません。 詳細については、「TDEの設定」をご参照ください。

    重要
    • TDEを使用して一部のテーブルを暗号化すると、復元中にエラーが発生します。 RDSインスタンスのバックアップファイルをダウンロードする前に、暗号化されたテーブルを復号化する必要があります。 詳細については、「TDEの設定」をご参照ください。

    • 次の操作を実行して、TDEが有効になっているかどうかを確認できます。RDSインスタンスの [データセキュリティ] ページに移動します。 次に、[TDE] タブをクリックします。

  • RDSインスタンスへのログインに使用するRAMユーザーには、バックアップファイルをダウンロードする権限が付与されます。 RAMユーザーに権限を付与する方法の詳細については、「読み取り専用権限を持つRAMユーザーにバックアップファイルのダウンロード権限を付与する」をご参照ください。

制限事項

影響

  • 自己管理型MySQLデータベースで他のサービスが実行されている場合、RDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元すると、サービスは利用できなくなります。

  • このトピックで説明する復元方法は、RDSインスタンスのデータを自己管理MySQLデータベースの新しいデータディレクトリに復元するために使用されます。 これは、自己管理データベースの元のデータには影響しません。

実装

セクションでは、物理バックアップファイルからデータを復元するために実行する必要がある手順について説明します。

  1. ApsaraDB RDSコンソールでRDSインスタンスの完全物理バックアップを実行します。

  2. 物理バックアップファイルをコンピューターにダウンロードし、qpressツールを使用してファイルを解凍します。

  3. Percona XtraBackupを使用して、解凍されたバックアップファイルから自己管理型MySQLデータベースのデータディレクトリにデータを復元します。

  4. 自己管理MySQLデータベースを再起動します。 その後、自己管理MySQLデータベースでRDSインスタンスのデータを表示できます。

使用上の注意

  • ダウンロードURLは、生成後1時間のみ有効です。 ダウンロードURLの有効期限が切れた場合、ページを更新して最新のダウンロードURLを取得できます。

  • 物理バックアップファイルを変更または削除しないことを推奨します。 物理バックアップファイルを変更または削除すると、ファイルが破損して復元できない場合があります。 RDSインスタンスの物理バックアップファイルを変更する必要がある場合は、RDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元してから、ファイルを変更することを推奨します。

課金ルール

  • 手動バックアップを実行する必要がある場合は、手動バックアップファイルの保存に使用されるバックアップストレージに注意してください。 バックアップストレージの使用量が無料クォータを超えた場合、使用した過剰なバックアップストレージに対して課金されます。 詳細については、「バックアップストレージ料金」をご参照ください。

  • 自己管理型MySQLデータベースがオンプレミスマシンにデプロイされている場合は、インターネット経由でバックアップファイルをダウンロードする必要があります。 バックアップファイルをダウンロードするときに生成されるトラフィックが無料クォータを超えた場合、過剰なインターネットトラフィックに対して課金されます。 詳細については、「バックアップファイルのダウンロード」をご参照ください。

    説明

    自己管理型MySQLデータベースが、RDSインスタンスと同じリージョンおよび仮想プライベートクラウド (VPC) にあるElastic Compute Service (ECS) インスタンスにデプロイされている場合、内部ネットワーク経由でバックアップファイルをダウンロードできます。 この場合、トラフィック料金は発生しません。

準備

環境の準備

  1. この例では、CentOS 7.9 64ビットが使用されています。 自己管理MySQLデータベースが他のLinuxディストリビューションを実行する場合は、必要なコマンドを使用します。

  2. 自己管理型MySQLデータベースをデプロイします。 データベースのメジャーエンジンのバージョンは、RDSインスタンスのバージョンと同じである必要があります。 たとえば、自己管理型MySQLデータベースとRDSインスタンスはどちらもMySQL 8.0を実行します。

    次のコマンドを実行して、自己管理型MySQLデータベースのメジャーエンジンバージョンを照会できます。

    mysql --version
  3. 自己管理型MySQLデータベースの構成ファイルのディレクトリを照会します。

    構成ファイルのディレクトリは、自己管理型MySQLデータベースのメジャーエンジンバージョンによって異なります。 この例では、次のディレクトリが関係しています。

    • MySQL 8.0またはMySQL 5.7: /etc/my.cn f

    • MySQL 5.6: /usr/my.cn f

    • MySQL 5.5: ディレクトリを作成するには、echo "[mysqld]" | sudo tee /etc/my.cn fコマンドを実行する必要があります。

    次のコマンドを実行して、自己管理MySQLデータベースの構成ファイルのディレクトリを照会できます。

    sudo find / -name my.cnf
    説明

    クエリ結果がリストされたディレクトリと一致しない場合は、後続のコマンドを実行するときに正しいディレクトリを使用してください。

  4. mysql_bkdataという名前のバックアップ解凍ディレクトリを作成して、解凍されたバックアップファイルを保存します。

    次のコマンドを実行して、バックアップ解凍ディレクトリを作成できます。

    sudo mkdir /var/mysql_bkdata
    sudo chown -R $USER:$USER /var/mysql_bkdata
    説明

    上記のコマンドの $USER:$USERパラメーターは、現在のユーザーとユーザーグループを示します。 値は環境変数から取得されます。 パラメーターの値を変更する必要はありません。

  5. バックアップファイルのデータが復元されるmysql_newdataという名前のデータディレクトリを作成します。 このディレクトリのデータは、データベースの起動時に使用されます。

    次のコマンドを実行して、データディレクトリを作成できます。

    sudo mkdir /var/mysql_newdata
    sudo chown -R $USER:$USER /var/mysql_newdata
    説明

    上記のコマンドの $USER:$USERパラメーターは、現在のユーザーとユーザーグループを示します。 値は環境変数から取得されます。 パラメーターの値を変更する必要はありません。

ツールの準備

  1. Percona XtraBackupをインストールします。

    • RDSインスタンスがMySQL 8.0を実行している場合は、インスタンスが存在するホストのオペレーティングシステム (OS) に基づいてPercona XtraBackupをダウンロードしてインストールします。

      重要

      MySQL 8.0を実行するRDSインスタンスは、redoログファイルをサポートします。 オープンソースのPercona XtraBackupには、これらのインスタンスの互換性の問題があります。 ApsaraDB RDSが提供するXtraBackupツールの使用を推奨します。

      ホスト環境

      XtraBackup 8.0のインストール

      インストールコマンドの例

      説明

      この例では、XtraBackup 8.0は /Xtraabackup8.0ディレクトリにダウンロードされます。 実際のインストールコマンドは、ダウンロードディレクトリによって異なります。 XtraBackup 8.0の実際のダウンロードディレクトリに基づいてインストールコマンドを調整します。

      Linux 6 (x86_64)

      RDS XtraBackup 8.0

      sudo yum localinstall -y /XtraBackup8.0/t-rds-xtrabackup-80-8.0.31-20230817110455.alios6.x86_64

      Linux 7 (x86_64)

      RDS XtraBackup 8.0

      sudo yum localinstall -y /XtraBackup8.0/t-rds-xtrabackup-80-8.0.31-20230817110455.alios7.x86_64.rpm

      Linux 7 (ARM AArch64)

      RDS XtraBackup 8.0

      sudo yum localinstall -y /XtraBackup8.0/t-rds-xtrabackup-80-8.0.31-20230817110455.alios7.aarch64.rpm

      Linux 8 (ARM AArch64)

      RDS XtraBackup 8.0

      sudo yum localinstall -y /XtraBackup8.0/t-rds-xtrabackup-80-8.0.31-20230817110455.al8.aarch64.rpm
      説明

      インストール後、Percona XtraBackupの実行ファイルは /u01 /xtraabackup80 /binディレクトリに格納され、Linuxシステムの環境変数PATHには追加されません。

      任意のディレクトリでPercona XtraBackup関連のコマンドを実行する場合は、次の方法を使用できます。

      • フルパスを指定したコマンドを実行できます。 このトピックでは、複数のコマンドでフルパスを指定します。 例: /u01 /xtraabackup80 /bin /xtraabackup -- xxxxxx

      • /u01/xtrabackup80/binディレクトリをシステムのPATH環境変数に手動で追加できます。

    • RDSインスタンスがMySQL 5.7、MySQL 5.6、またはMySQL 5.5を実行している場合は、Percona XtraBackup 2.4をダウンロードしてインストールします。 詳細については、「Percona XtraBackup 2.4ドキュメント」をご参照ください。

      この例では、Percona XtraBackup 2.4.28がインストールされています。 サンプルコマンド:

      wget https://downloads.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.28/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm
      sudo yum localinstall -y percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm
  2. qpressツールをインストールします。

    ## Download the TAR package of the executable file.
    wget "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20230406/flxd/qpress-11-linux-x64.tar"
    
    ## Decompress the downloaded TAR package to obtain the executable file.
    tar -xvf qpress-11-linux-x64.tar
    
    ## Configure execute permissions on the qpress file.
    sudo chmod 775 qpress
    
    ## Copy the qpress file to the /usr/bin directory.
    sudo cp qpress /usr/bin

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

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

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

  3. 表示されるページで、基本バックアップリスト > [データバックアップ] を選択します。 ダウンロードする物理バックアップファイルを見つけて、[操作] 列の [インスタンスバックアップのダウンロード] をクリックします。

  4. [インスタンスバックアップセットのダウンロード] ダイアログボックスで、[内部URL] または [パブリックURL] の横にあるimageアイコンをクリックします。

    重要
    • 内部URLを使用してバックアップファイルをダウンロードする場合は、ログオン先のサーバーとRDSインスタンスが同じVPCにあることを確認してください。 サーバーとRDSインスタンスがクロスリージョンVPCにある場合、またはサーバーがクラシックネットワークにあり、RDSインスタンスがVPCにある場合、内部URLを使用してバックアップファイルをダウンロードすることはできません。

    • 外部URLを使用してバックアップファイルをダウンロードすると、過剰なインターネットトラフィックに対して課金されます。 詳細については、「課金ルール」をご参照ください。

    • ダウンロードURLは、生成後1時間のみ有効です。 ダウンロードURLの有効期限が切れた場合、ページを更新して最新のダウンロードURLを取得できます。

    • 物理バックアップファイルを変更または削除しないことを推奨します。 物理バックアップファイルを変更または削除すると、ファイルが破損して復元できない場合があります。 物理バックアップファイルを変更する必要がある場合は、RDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元してから、ファイルを変更することを推奨します。

  5. 自己管理型MySQLデータベースが存在するLinuxサーバーにログインし、次のコマンドを実行して物理バックアップファイルをダウンロードします。

    wget -c 'https://****.bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qp
    説明
    • コマンドのhttps:// **** .bak.rds.aliyuncs.com/****_xb.qp?**** をコピーしたダウンロードURLに置き換えます。 バックアップファイルをダウンロードした後、それを保存し、機密保持します。

    • test_xb.qpは、保存するファイルの新しい名前を指定します。 カスタムファイル名を指定できますが、ファイル名の拡張子はダウンロードURLのファイル名の拡張子と同じである必要があります。

    • 2021年1月20日以降、ApsaraDB RDS for MySQLの物理バックアップファイルのファイル名拡張子が _xb.qpに変更されます。 物理バックアップファイルのファイル名拡張子が _qp.xbの場合、ファイルのファイル名拡張子として _qp.xbも使用する必要があります。 ダウンロードリンクでバックアップファイルのファイル名拡張子を表示できます。 詳細については、「 [製品の変更 /機能の変更] 新しい物理バックアップファイル形式が一部のApsaraDB RDS For MySQLインスタンスに段階的に導入されました」をご参照ください。

    • RDSインスタンスがMySQL 5.5を実行している場合、物理バックアップファイルのファイル名拡張子はtar.gzです。

FAQに関するファイルのダウンロード

  • データファイルをダウンロードするときにエラーが報告されるのはなぜですか?

    wget -c 'https:// **** .bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qpコマンドを実行してデータファイルをダウンロードする場合、単一引用符 (') のペアを使用してダウンロードURLを囲む必要があります。 このように、アプリケーションはダウンロードURLを識別することができる。

ステップ2: バックアップファイルを解凍

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

重要
  • コマンドを実行する前に、自己管理型MySQLデータベースが存在するサーバーにPercona XtraBackupqpressがインストールされていることを確認してください。 詳細については、「準備」をご参照ください。 ツールをインストールしない場合、解凍コマンドは実行できません。

  • コマンドを実行するときは、test_xb.qpを保存したバックアップファイルの名前に置き換え、/var/mysql_bkdata/ を作成したバックアップ解凍ディレクトリに置き換えます。

### MySQL 8.0
qpress -do  test_xb.qp | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

### MySQL 5.5/5.6/5.7
qpress -do  test_xb.qp | xbstream -x -v -C /var/mysql_bkdata/

バックアップファイルのファイル名拡張子が_xb.qpでない場合は、次のいずれかの方法でバックアップファイルを解凍します。

.tar.gz

tar -izxvf test.tar.gz -C /var/mysql_bkdata/

.xb.gz

### MySQL 8.0
gzip -d -c test.xb.gz | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

### MySQL 5.5/5.6/5.7
gzip -d -c test.xb.gz | xbstream -x -v -C /var/mysql_bkdata/

_qp.xb

## Step 1: Parse the file.
cat test_qp.xb | xbstream -x -v -C /var/mysql_bkdata/

## Step 2: Decompress the file.
### MySQL 5.5/5.6/5.7
innobackupex --decompress --remove-original /var/mysql_bkdata/

### MySQL 8.0
/u01/xtrabackup80/bin/xtrabackup --decompress --remove-original --target-dir=/var/mysql_bkdata/

FAQについての减圧

  • ダウンロードしたバックアップファイルを解凍したときにシステムがエラーを報告した場合はどうすればよいですか?

    次の操作を実行して, エラーの原因を特定し, エラーを解決してください。

    バックアップファイルが物理バックアップファイルであるかどうかを確認します。

    バックアップファイルに次のいずれかの有効なファイル名拡張子があるかどうかを確認します。xb.qp,. tar.gz,. xb.gz、および_qp.xb.

    解凍コマンドは、バックアップファイルのファイル名拡張子によって異なります。

    解凍中に次のエラーメッセージが表示されることがあります。

    • sh: qpress: command not foundというエラーメッセージが表示されます。

      解決策: 自己管理MySQLデータベースが存在するサーバーにqpressがインストールされているかどうかを確認します。 詳細は、「前提条件 (Prerequisites)」をご参照ください。

    • innobackupexが見つからないことを示すエラーメッセージが表示されます。 このエラーは、バックアップファイルのファイル名拡張子が_qp.xbの場合に報告されます。

      解決策: 自己管理MySQLデータベースが存在するサーバーにPercona XtraBackupがインストールされているかどうかを確認します。 詳細は、「前提条件 (Prerequisites)」をご参照ください。

    • 前述のcatコマンドを実行すると、can't change to dir to xx( errorcode:no such file or directory) というエラーメッセージが表示されます。 このエラーは、バックアップファイルのファイル名拡張子が_qp.xbの場合に報告されます。

      解決策: 解凍したファイルを格納するディレクトリまたはファイル名が正しいかどうかを確認します。

ステップ3: データを復元

重要

自己管理型MySQLデータベースにデータを復元する前に、データベースを停止します。

ps -ef | grep '[m]ysql' コマンドを実行して、MySQL関連のプロセスが存在するかどうかを確認できます。 MySQL関連のプロセスが存在する場合は、sudo kill -9 <PID> コマンドを実行してプロセスを終了します。

MySQL 8.0を実行するRDSインスタンスのデータを復元する

  1. 修復の準備をします。

    /u01/xtrabackup80/bin/xtrabackup --defaults-file=/var/mysql_bkdata/backup-my.cnf  --prepare --target-dir=/var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    デフォルトのMySQL設定を含む構成ファイルのディレクトリ。

    物理バックアップファイルが解凍された後、backup-my.cn fという名前のファイルが取得され、バックアップ解凍ディレクトリに格納されます。この例では /var/mysql_bkdata/ です。

    -準備する

    Percona XtraBackupの準備に使用されるコマンド。

    -- target-dir

    バックアップ解凍ディレクトリ。この例では /var/mysql_bkdata/ です。

  2. 自己管理型MySQLデータベースのdatadirパラメーターを変更します。

    1. データベースの構成ファイルを変更します。

      sudo vim /etc/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、datadirパラメーターの値を /var/mysql_newdataに変更します。

      datadir = /var/mysql_newdata

      mysql_newdataは、自己管理mysqlデータベースの新しいデータディレクトリを指定します。 詳細については、「準備」をご参照ください。

    3. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  3. データを復元します。

    sudo xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    my.cn fファイルのディレクトリ。 データが復元されるデータディレクトリは、設定ファイルのdatadirパラメーターから取得できます。

    -- コピーバック

    Percona XtraBackupによって実行される復元コマンド。

    -- target-dir

    バックアップ解凍ディレクトリ。この例では /var/mysql_bkdata/ です。 Percona XtraBackupは、このディレクトリ内のデータを自己管理MySQLデータベースのデータディレクトリに復元します。

MySQL 5.7を実行するRDSインスタンスのデータを復元

  1. 修復の準備をします。

    innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    デフォルトのMySQL設定を含む構成ファイルのディレクトリ。

    物理バックアップファイルが解凍された後、backup-my.cn fという名前のファイルが取得され、バックアップ解凍ディレクトリに格納されます。この例では /var/mysql_bkdata/ です。

    -- apply-log

    Percona XtraBackupの準備に使用されるコマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 バックアップ解凍ディレクトリにはバックアップファイルが格納されます。

  2. 自己管理型MySQLデータベースのmy.cn f設定ファイルを変更します。

    1. データベースの構成ファイルを変更します。

      sudo vim /etc/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、datadirパラメーターの値を /var/mysql_newdataに変更します。

      datadir = /var/mysql_newdata

      mysql_newdataは、自己管理型mysqlデータベースの新しいデータディレクトリを指定します。 詳細については、「準備」をご参照ください。

    3. 次のコンテンツをmy.cn fファイルに追加します。

      innodb_undo_tablespaces=2
      innodb_undo_directory=/var/mysql_newdata
      重要

      innodb_undo_tablespacesパラメーターの値は、/var/mysql_bkdata/backup-my.cn fファイルの値と同じである必要があります。 値を照会するには、cat /var/mysql_bkdata/backup-my.cnf | grep innodb_undo_tablespacesコマンドを実行します。

    4. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  3. データを復元します。

    sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    my.cn fファイルのディレクトリ。 データが復元されるデータディレクトリは、設定ファイルのdatadirパラメーターから取得できます。

    -- コピーバック

    Percona XtraBackupによって実行される復元コマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 Percona XtraBackupは、ディレクトリ内のデータを自己管理MySQLデータベースのデータディレクトリに復元します。

MySQL 5.6を実行するRDSインスタンスのデータを復元

  1. 修復の準備をします。

    innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    デフォルトのMySQL設定を含む構成ファイルのディレクトリ。

    物理バックアップファイルが解凍された後、backup-my.cn fという名前のファイルが取得され、バックアップ解凍ディレクトリに格納されます。この例では /var/mysql_bkdata/ です。

    -- apply-log

    Percona XtraBackupの準備に使用されるコマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 バックアップ解凍ディレクトリにはバックアップファイルが格納されます。

  2. 自己管理型MySQLデータベースのdatadirパラメーターを変更します。

    1. データベースの構成ファイルを変更します。

      sudo vim /usr/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、datadirパラメーター設定を追加します。

      datadir = /var/mysql_newdata

      mysql_newdataは、自己管理型mysqlデータベースの新しいデータディレクトリを指定します。 詳細については、「準備」をご参照ください。

    3. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  3. データを復元します。

    sudo innobackupex --defaults-file=/usr/my.cnf --copy-back /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    my.cn fファイルのディレクトリ。 データが復元されるデータディレクトリは、設定ファイルのdatadirパラメーターから取得できます。

    -- コピーバック

    Percona XtraBackupによって実行される復元コマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 Percona XtraBackupは、ディレクトリ内のデータを自己管理MySQLデータベースのデータディレクトリに復元します。

MySQL 5.5を実行するRDSインスタンスのデータを復元

  1. 修復の準備をします。

    innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    デフォルトのMySQL設定を含む構成ファイルのディレクトリ。

    物理バックアップファイルが解凍された後、backup-my.cn fという名前のファイルが取得され、バックアップ解凍ディレクトリに格納されます。この例では /var/mysql_bkdata/ です。

    -- apply-log

    Percona XtraBackupの準備に使用されるコマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 バックアップ解凍ディレクトリにはバックアップファイルが格納されます。

  2. 自己管理型MySQLデータベースのmy.cn f設定ファイルを変更します。

    1. データベースの構成ファイルを変更します。

      sudo vim /etc/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、datadirパラメーター設定を追加します。

      datadir = /var/mysql_newdata

      mysql_newdataは、自己管理型mysqlデータベースの新しいデータディレクトリを指定します。 詳細については、「準備」をご参照ください。

    3. 次のコンテンツをmy.cn fファイルに追加します。

      innodb_log_file_size=1048576000
      重要

      innodb_log_file_sizeパラメーターの値は、/var/mysql_bkdata/backup-my.cn fファイルの値と同じである必要があります。 値を照会するには、cat /var/mysql_bkdata/backup-my.cnf | grep innodb_log_file_sizeコマンドを実行します。

    4. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  3. データを復元します。

    sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/

    パラメーター

    パラメーター

    説明

    -- defaults-file

    my.cn fファイルのディレクトリ。 データが復元されるデータディレクトリは、設定ファイルのdatadirパラメーターから取得できます。

    -- コピーバック

    Percona XtraBackupによって実行される復元コマンド。

    このパラメーターの後にバックアップ解凍ディレクトリが続きます。この例では /var/mysql_bkdata/ です。 Percona XtraBackupは、ディレクトリ内のデータを自己管理MySQLデータベースのデータディレクトリに復元します。

FAQ about data restoration

  • xtraabackup: Unknownエラー3613エラーメッセージが表示された場合はどうすればよいですか?

    Percona XtraBackupを最新バージョンに更新して、もう一度お試しください。

  • 私は何をしますか?元のデータディレクトリ /var/mysql_newdataが空ではありません! エラーメッセージが表示されますか?

    sudo rm -rf /var/mysql_newdata/* コマンドを実行して、フォルダー内のファイルをクリアします。 その後、復元操作を再度実行します。

  • 私は何をしますか?InnodDB: データファイル内の暗号化情報: 。/xxx.ibdは復号化できません。キーリングプラグインが正常にロードされ、初期化されているかどうかを確認してください。 エラーメッセージが表示されますか?

    RDSインスタンスでTDEが有効になっているかどうかを確認します。

    • TDEが有効になっている場合は、TDE暗号化テーブルが存在するかどうかを確認します。 TDE暗号化されたテーブルが存在する場合は、テーブルを復号化し、このトピックで提供されている手順に基づいてデータを復元します。 詳細については、「前提条件」および「TDEの設定」をご参照ください。

    • TDEが無効になっている場合は、必要なバージョンのPercona XtraBackupがインストールされていることを確認します。 詳細については、「 準備」をご参照ください。

  • ダウンロードしたバックアップファイルにTDE暗号化されたデータが含まれていて、データを復元するときにエラーが発生した場合はどうすればよいですか?

    ダウンロードしたバックアップファイルを使用してデータを復元することはできません。 RDSインスタンスに暗号化されたテーブルが存在する場合、データの復元時にエラーが発生します。 エラーを解決するには、テーブルを復号し、このトピックで提供されている手順に基づいてデータを復元します。 詳細については、「前提条件」および「TDEの設定」をご参照ください。

  • データの復元中にinnobackupex: File 'undo001' not found (Errcode: 2 - No Such file or directory) というエラーメッセージが表示された場合はどうすればよいですか?

    undoファイルはシステムファイルです。 ファイルはデータベースのバージョンによって異なります。 この問題を解決するには、自己管理型MySQLデータベースがRDSインスタンスと同じデータベースバージョンを実行しているかどうかを確認します。

ステップ4: データベースの起動

MySQL 8.0またはMySQL 5.7

  1. オプションです。 ApsaraDB RDSコンソールにログインし、「ApsaraDB RDS for MySQLインスタンスのパラメーターの表示」の手順に基づいて、lower_case_table_namesパラメーターの値を表示します。 値が1の場合、自己管理MySQLデータベースのmy.cn f設定ファイルを変更する必要があります。

    1. データベースの構成ファイルを変更します。

      sudo vim /etc/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、次のコンテンツをファイルに追加します。

      lower_case_table_names=1
    3. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  2. dataディレクトリに対する権限を付与します。

    sudo chown -R mysql:mysql /var/mysql_newdata
  3. 次のコマンドを実行して、MySQLプロセスを開始します。

    sudo mysqld --defaults-file=/etc/my.cnf --user=mysql --datadir=/var/mysql_newdata &

    パラメーター

    パラメーター

    説明

    -- defaults-file

    自己管理MySQLデータベースの構成ファイルのディレクトリ。 この例では、/etc/my.cn fが使用されます。 [準備] セクションに基づいて、構成ファイルのディレクトリを取得できます。

    --user

    データベースを開始したユーザー。 値はmysqlとして固定されています。

    -- datadir

    データベースの起動に使用されるデータディレクトリ。 この例では、/var/mysql_newdataが使用されています。 データディレクトリは、[準備] セクションに基づいて取得できます。

MySQL 5.6

  1. オプションです。 ApsaraDB RDSコンソールにログインし、「ApsaraDB RDS for MySQLインスタンスのパラメーターの表示」の手順に基づいて、lower_case_table_namesパラメーターの値を表示します。 値が1の場合、自己管理MySQLデータベースのmy.cn f設定ファイルを変更する必要があります。

    1. データベースの構成ファイルを変更します。

      sudo vim /usr/my.cnf

      構成ファイルのディレクトリを照会する方法の詳細については、「準備」をご参照ください。

    2. iを押して挿入モードに入り、次のコンテンツをファイルに追加します。

      lower_case_table_names=1
    3. Escキーを押して編集モードを終了し、:wqと入力してファイルを保存して終了します。

  2. dataディレクトリに対する権限を付与します。

    sudo chown -R mysql:mysql /var/mysql_newdata
  3. 次のコマンドを実行して、MySQLプロセスを開始します。

    sudo mysqld --defaults-file=/usr/my.cnf --user=mysql --datadir=/var/mysql_newdata &

    パラメーター

    説明

    -- defaults-file

    自己管理MySQLデータベースの構成ファイルのディレクトリ。 この例では、/usr/my.cn fが使用されます。 [準備] セクションに基づいて、構成ファイルのディレクトリを取得できます。

    --user

    データベースを開始したユーザー。 値はmysqlとして固定されています。

    -- datadir

    データベースの起動に使用されるデータディレクトリ。 この例では、/var/mysql_newdataが使用されています。 データディレクトリは、[準備] セクションに基づいて取得できます。

MySQL 5.5

  1. dataディレクトリに対する権限を付与します。

    sudo chown -R mysql:mysql /var/mysql_newdata
  2. 次のコマンドを実行して、MySQLプロセスを開始します。

    sudo mysqld --defaults-file=/etc/my.cnf --user=mysql --datadir=/var/mysql_newdata &

    パラメーター

    説明

    -- defaults-file

    自己管理MySQLデータベースの構成ファイルのディレクトリ。 この例では、/etc/my.cn fが使用されます。 [準備] セクションに基づいて、構成ファイルのディレクトリを取得できます。

    --user

    データベースを開始したユーザー。 値はmysqlとして固定されています。

    -- datadir

    データベースの起動に使用されるデータディレクトリ。 この例では、/var/mysql_newdataが使用されています。 データディレクトリは、[準備] セクションに基づいて取得できます。

FAQ about startup

  • Ubuntuオペレーティングシステムでmysqld: [ERROR] Failed to open required default file: /etc/my.cn fエラーメッセージが表示されるのはなぜですか? どうすればよいですか。

    このエラーは、セキュリティプログラムAppArmorがUbuntuオペレーティングシステムで提供されているために発生します。 Ubuntuオペレーティングシステムを使用している場合は、エラーメッセージが表示されます。 この場合、apparmorの設定を変更するには、apt install -y AppArmor-utilsおよびaa-complaint /usr/sbin/mysqldコマンドを実行する必要があります。

  • 復元タスクが完了した後、自己管理型MySQLデータベースを使用しているときにエラー1105不明なエラーエラーメッセージが表示された場合、または自己管理型MySQLデータベースを起動できない場合はどうすればよいですか?

    次のSQL文を実行して、ストレージエンジンを変更します。

    USE mysql;
    ALTER TABLE proc engine=myisam;
    ALTER TABLE event engine=myisam;
    ALTER TABLE func engine=myisam;
    説明

    上記のステートメントの実行時にERROR 1067 (42000): 'modified' の無効なデフォルト値エラーメッセージが表示された場合は、最初にSET SQL_MODE='ALLOW_INVALID_DATES '; ステートメントを実行します。

  • データが復元された後のrootユーザーのパスワードは何ですか?

    次のいずれかの方法でパスワードを取得できます。

    • RDSインスタンスがMySQL 5.7またはMySQL 8.0を実行している場合、RDSインスタンスのルートユーザーのパスワードは、自己管理型MySQLデータベースのルートユーザーのパスワードと同じです。

    • RDSインスタンスがMySQL 5.5またはMySQL 5.6を実行している場合、RDSインスタンスのルートユーザーのパスワードをリセットする必要があります。 詳細については、「オープンソースMySQLドキュメント」をご参照ください。

  • 起動中にInnodDB: Assertion failure in thread 140xxx in file page0zip.icne xxxエラーメッセージが表示された場合はどうすればよいですか?

    ディスク容量不足が原因でエラーが発生する可能性があります。 自己管理型MySQLデータベースが存在するサーバーのディスクのサイズを変更し、再試行できます。

  • [ERROR] Failed to open the relay log xxx[ERROR] Slave: Failed to initialize the master info xxx、および [ERROR] Failed to create or recover reporitories 起動中にエラーメッセージが表示されますか?

    RDSインスタンスは高可用性 (HA) モードで動作しますが、自己管理型MySQLデータベースにはプライマリノードとセカンダリノードは含まれません。 これはデータベースの起動には影響しません。 エラーメッセージは無視できます。

ステップ5: データベースに接続して復元を確認

  1. 次のコマンドを実行して自己管理型MySQLデータベースにログインし、MySQLが実行されていることを確認します。

    mysql -u<The username of the account that is used to connect to the RDS instance> -p<The password of the preceding account>
    説明
    • コマンドは、復元が成功したかどうかを確認するために使用されます。 テーブル内のデータのみをクエリする場合は、テーブルに対する権限を持つアカウントを使用してコマンドを実行できます。 特権アカウントを使用する必要はありません。

    • サードパーティのツール、クライアント、またはコマンドラインを使用してデータベースに接続することもできます。 詳細については、「データベースクライアントまたはCLIを使用したApsaraDB RDS For MySQLインスタンスへの接続」をご参照ください。

  2. 次のSQL文を実行して、RDSインスタンスにデータベースが存在するかどうかを確認します。

    SHOW DATABASES;

FAQに関する接続と検証

  • RDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元した後、データの時間フィールドで示される時間と、自己管理型MySQLデータベースが存在するサーバーのローカル時間は、異なるタイムゾーンに属します。 これはなぜですか。 データの時間フィールドで示される時刻と現地時間が同じタイムゾーンに属することを確認するにはどうすればよいですか?

    自己管理型MySQLデータベースのタイムゾーンがRDSインスタンスのタイムゾーンと異なる場合、自己管理型MySQLデータベースのtime_zoneパラメーターの値を変更して、RDSインスタンスのtime_zoneパラメーターの値との整合性を確保する必要があります。 RDSインスタンスのtime_zoneパラメーターがsystemに設定されている場合、RDSインスタンスが存在するリージョンを照会し、セルフマネージドMySQLデータベースのtime_zoneパラメーターをリージョンのタイムゾーンに設定する必要があります。

  • 自己管理型MySQLデータベースに接続したときにAccess denied for user 'XXX' エラーメッセージが表示された場合はどうすればよいですか?

    RDSインスタンスへの接続に使用されるアカウントのユーザー名とパスワードが正しいかどうかを確認します。 アカウントはRDSインスタンスに作成する必要があります。

  • 自己管理型MySQLデータベースに接続するときにパスワードを忘れた場合はどうすればよいですか?

    アカウントのユーザー名またはパスワードを忘れた場合は、コマンドを実行してMySQLプロセスを開始するときに -- skip-grant-tablesパラメーターを設定します。 プロセスの開始後、権限チェックは無視され、パスワードフリーモードでデータベースにログインできます。 データベースにログインした後、アカウントのユーザー名とパスワードを変更できます。

  • 自己管理データベースに接続した後、システムデータベースまたは一部のデータベースのみを表示できる場合はどうすればよいですか。

    自己管理データベースを再起動します。 次に、元のRDSインスタンスのルートアカウントまたは特権アカウントを使用して、自己管理データベースに接続します。

次のステップ

その他のFAQ

RDSインスタンスのデータを指定された時間範囲で自己管理型MySQLデータベースに復元するにはどうすればよいですか。

ApsaraDB RDSコンソールで、特定の時間範囲内に生成されたログバックアップファイルをダウンロードできます。 次に、ログバックアップファイルを使用して、RDSインスタンスのデータを自己管理型MySQLデータベースに復元できます。 詳細については、「バックアップファイルのダウンロード」および「特定の時点にデータを復元する」をご参照ください。

ダウンロードしたデータバックアップファイルを使用して、RDSインスタンスのデータを自己管理型MySQLデータベースに復元できます。 他にどの方法がありますか?

Data Transmission Service (DTS) を使用して、RDSインスタンスから自己管理型MySQLデータベースにデータを移行することもできます。 詳細については、「ApsaraDB RDS For MySQLインスタンスから自己管理型MySQLデータベースへのデータの移行」をご参照ください。

RDS Basic Editionを実行するRDSインスタンスのデータを復元または移行するにはどうすればよいですか。

RDS Basic Editionを実行するRDSインスタンスは、スナップショットバックアップのみをサポートします。 RDSインスタンスがRDS Basic Editionを実行している場合、次のいずれかの方法を使用してデータを復元または移行できます。

別のRDSインスタンスにダウンロードしたデータバックアップファイルからRDSインスタンスのデータを復元できますか。

いいえ。ダウンロードしたバックアップファイルを使用して、RDSインスタンスのデータを別のRDSインスタンスに復元することはできません。 DTSを使用してRDSインスタンス間でデータを移行することを推奨します。 詳細については、「ApsaraDB RDS For MySQLインスタンス間のデータ移行」をご参照ください。

複数のRDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元できますか?

いいえ、複数のRDSインスタンスのデータを物理バックアップファイルから自己管理型MySQLデータベースに復元することはできません。 複数のRDSインスタンスのデータを物理バックアップファイルから異なる自己管理型MySQLデータベースに復元できます。 次に、DTSまたはmysqldumpを使用してデータを移行できます。 詳細については、「DTSを使用してデータを移行する」または「mysqldump拡張機能を使用してセルフマネージドMySQLインスタンスからApsaraDB RDS For MySQLインスタンスにデータを移行する」をご参照ください。