---
title: "Backup"
slug: "clouddbformysql-backup-classic"
updated: 2026-09-17T09:31:49Z
published: 2026-09-17T09:31:49Z
canonical: "guide.ncloud-docs.com/clouddbformysql-backup-classic"
stale: true
---

> ## Documentation Index
> Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Backup

Classic環境で利用できます。

Backupでは、Cloud DB for MySQLを使用中のユーザーのキャッシュデータを安全に保存するために、サーバ別に設定しておいたバックアップ情報を確認できます。また、障害が発生してキャッシュデータが消失した場合は、保管していたバックアップファイルで復元を行います。高可用性設定を使用するサーバだけでなく、Stand Alone Serverもバックアップと復元機能を使用できます。ただし、Stand Aloneサーバでは時点復元機能はサポートされません。

まず、バックアップと復元を使用する前に Cloud DB for MySQLで提供しているバックアップに関する基本的な実行ルールを理解することをお勧めします。バックアップの基本的な実行ルールは、次の通りです。

- バックアップの実行方式
  - 1日1回、毎日実施
  - 自動設定とユーザー定義設定のうち選択
    - 自動設定: MySQL Server作成時に任意の時間が指定され、それ以降は初めてバックアップされた時間と類似の時間にバックアップを実行
    - ユーザー定義設定: ユーザーが選択した時間+15分以内にバックアップを開始
    - 例外状況
      - DB作成後の30分以内にはバックアップを実行
      - DB設定が変更される場合、ユーザー指定バックアップ時間 +5分後に実行
- バックアップファイル
  - 保管期間: ユーザーの設定応じて最大30日間まで保存可能
  - 保存位置: 別途のデータストレージ(バックアップファイルのサイズに応じてストレージ契約を行う)

## Backup画面

Backupを利用するための基本的な説明は、次の通りです。

![database-database-5-4_main_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_main_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)

| 領域 | 説明 |
| --- | --- |
| ① メニュー名 | 現在確認中のメニューの名前 |
| ② 基本機能 | Cloud DB for MySQLの詳細情報を確認、Backup画面を更新 |
| ③ バックアップのリスト | 設定しておいたサーバ別のバックアップ設定および設定情報 |

## バックアップ設定リスト確認

運用中の MySQL Server別バックアップ設定リストを確認できます。バックアップ設定リストを確認する方法は、次の通りです。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **Backup**メニューをクリックします。
3. バックアップ設定リストが表示されたら、必要な情報を確認します。  

![database-database-5-4_backuplistdetails_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_backuplistdetails_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
  - DBサービス名: ユーザーが指定した DB Serviceの名前
  - Backup保管日: バックアップファイルをデータストレージに保存して保存する最大日数
  - Backup開始時間: 毎日1回、バックアップを行う時間
  - Backupデータサイズ: 完了したバックアップファイルのサイズ
  - 最終 Backupの日時: 最近行われたバックアップの日付
  - 詳細情報を見る: サーバ別に作成されたバックアップファイルリストの詳細情報と復元、Object Storageに保存

### サーバ別バックアップファイルリスト確認

バックアップを完了し、サーバ別に作成したバックアップファイルリストを確認する方法は、次の通りです。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **Backup**メニューをクリックします。
3. 詳細情報を確認するバックアップ設定行の**詳細情報を見る**で **[詳細履歴]** ボタンをクリックします。
4. バックアップファイルの詳細情報を確認します。  

![database-database-5-4_backupdetails_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_backupdetails_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
  - Backupの日付: バックアップを行った日付
  - Backup開始時間: バックアップを開始した時刻
  - Backup完了時間: バックアップを完了した時刻
  - 所要時間: バックアップ完了までにかかった時間
  - Backupサイズ: バックアップ完了後に作成されたバックアップファイルのサイズ(MB)
  - データストレージ: 当該 MySQL Serverのデータストレージ容量

## コンソールでデータ復元

Cloud DB for MySQLでは、バックアップファイルを利用して消失したデータを復元し、簡単かつ速やかに MySQL Serverを作成できるサービスを提供します。また、時点復元機能を使用して復元できる時間範囲内で、ユーザーが希望する時間帯にデータを復元できます。

### Backupファイルの復元

自動バックアップを通じて作成された Backupファイルを使用してデータを復元できます。 作成されたバックアップファイルを使用してデータを復元する方法は、次の通りです。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **Backup**メニューをクリックします。
3. 復元するバックアップ設定の行の **[詳細履歴]** ボタンをクリックします。
4. バックアップファイルを選択し、 **[Backupファイル復元]** ボタンをクリックします。
5. **Backupファイル復元**のポップアップが表示されたら、復元のために必要な情報を確認するか、入力します。  

![clouddbformysql-backup_restorepopup_classic_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/clouddbformysql-backup_restorepopup_classic_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
  - Backup時間: 復元できる時間範囲(最大7日)
  - Backup完了時間: 復元したい時点
  - DB Serverタイプ: 復元する MySQL Serverタイプ
  - DB Server名: 復元する MySQL Server名
6. **[復元する]** ボタンまたは **[作成]** ボタンをクリックします。
7. **[確認]** ボタンをクリックします。
8. **DB Server**メニューをクリックします。
9. 復元中のサーバのステータスを確認します。
  - Recoveryタイプとして作成される
  - 作成中: ユーザーが入力した情報で MySQL Serverを作成(復元)しているステータス
  - 設定中: ユーザーが入力した情報で MySQL Serverを作成(復元)して構成しているステータス
  - 運用中: ユーザーが入力した情報で MySQL Serverの作成(復元)と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできるステータス

              参考

              

サーバ復元完了まで数分かかります。

### 時点復元

希望する特定時点でデータを復元できます。復元する時点は、復元できる範囲内で、分単位まで指定できます。 時点復元機能でデータを復元する方法は、次の通りです。

              参考

              

Stand Aloneタイプの Serverは時点復元機能を提供しません。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **Backup**メニューをクリックします。
3. 復元するバックアップ設定の行の **[詳細履歴]** ボタンをクリックします。
4. **[時点復元]** ボタンをクリックします。  

![database-database-5-4_restorepointhover_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_restorepointhover_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
5. **時点復元**のポップアップが表示されたら、復元のために必要な情報を確認するか、入力します。  

![database-database-5-4_restorepoint_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_restorepoint_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
  - DBが復元できる時間: 復元できる時間範囲(最大7日)
  - DBの復元時間: 復元したい時点
  - Private Subドメイン(VPC環境): 復元するサーバで使用する Private Subドメイン(選択不可)
  - DB Serverタイプ: 復元する MySQL Serverタイプ
  - DB Server名: 復元する MySQL Server名
  - Subnet: 復元する MySQL Serverのサブネット情報
6. **[復元する]** ボタンまたは **[作成]** ボタンをクリックします。
7. **[確認]** ボタンをクリックします。
8. **DB Server**メニューをクリックします。
9. 復元中のサーバのステータスを確認します。
  - Recoveryタイプとして作成される
  - 作成中: ユーザーが入力した情報で MySQL Serverを作成(復元)しているステータス
  - 設定中: ユーザーが入力した情報で MySQL Serverを作成(復元)して構成しているステータス
  - 運用中: ユーザーが入力した情報で MySQL Serverの作成(復元)と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできるステータス

### 復元された Serverに新しい DB Service作成

復元機能を通じて作成した Recovery Serverに基づき、新しい DB Serviceを作成して当該 Serverを Stand Aloneまたは高可用性構成 Serverに変更できます。Serverの仕様、DB設定、バックアップ時間は同様に維持されます。バックアップ時間を別途設定していない Serverを復元した場合、保管日は1日に設定されます。

              参考

              

データストレージの暗号化された Recovery Serverは高可用性構成の DB Serviceのみ作成できます。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **DB Server**メニューをクリックします。
3. 新しい DB Serviceを作成する Recovery Serverをクリックし、 **[DB管理]** ボタンをクリックします。
4. **[新規 DBサービス作成]** ボタンをクリックします。
5. **新規 DBサービス作成**のポップアップが表示されたら、高可用性サポートの有無を選択して DBサービス名を入力し、 **[はい]** ボタンをクリックします。  

![database-database-5-4_newService_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_newService_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
6. 作成中のサーバのステータスを確認します。
  - 作成中: ユーザーが入力した情報で MySQL Serverを作成しているステータス
  - 設定中: ユーザーが入力した情報で MySQL Serverを作成して構成しているステータス
  - 運用中: ユーザーが入力した情報で MySQL Serverの作成と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできるステータス

## Object Storageに保存

Cloud DB for MySQLでは、作成したバックアップファイルを Object Storageに保存してバックアップ時に使用できます。保存していたバックアップファイルを Object Storageに保存する方法は、次の通りです。

              参考

              

- Object Storageのご利用の申し込み時に、別途料金が発生します。Object Storageの紹介や料金プランについての説明は、NAVERクラウドプラットフォームポータルの **[サービス > Storage > Object Storage](https://www.ncloud.com/product/storage/objectStorage)** メニューをご参照ください。

1. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Database** > **Cloud DB for MySQL**メニューを順にクリックします。
2. **Backup**メニューをクリックします。
3. Object Storageに保存するファイルがあるバックアップ設定行の **[詳細履歴]** ボタンをクリックします。
4. バックアップファイルを選択し、 **[Object Storageにエクスポート]** ボタンをクリックします。  

![database-database-5-4_objhover_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_objhover_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
5. **Object Storageにエクスポート**のポップアップが表示されたら、保存するバケットとフォルダをクリックして選択します。  

![database-database-5-4_objpopup_vpc_ko.png](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/database-database-5-4_objpopup_vpc_ja.png?sv=2026-02-06&spr=https&st=2026-10-26T12%3A39%3A32Z&se=2026-10-26T13%3A39%3A32Z&sr=c&sp=r&sig=s3Mhf4WmWpKLayFsKLLluEUZybsTXKkbNkMVZ7A29ys%3D)
6. **[Object Storageにエクスポート]** ボタンをクリックします。
7. **[確認]** ボタンをクリックします。

              注意

              

- Object Storageに送信する際は、バケットのロック解除と適切なアクセス制御、ACL設定が必要です。
- 日本リージョンの場合、Object Storageバケットのアクセス制御設定を解除してください。
- Object Storageにエクスポートを完了するまで、数分かかります。

## バックアップユーティリティの使用

Percona Xtrabackup、mysqldumpユーティリティを使用して MySQL Serverのデータをバックアップし、復元できます。

### Xtrabackupを通じたバックアップファイルの復元

NAVERクラウドプラットフォームの Object Storageにバックアップファイルを保存し、Xtrabackupを使用してサーバでデータを復元できます。

Object Storageに保存したバックアップファイルを Xtrabackupを通じて復元するための前提条件は、次の通りです。

- ユーザーの別途サーバにインストールされた MySQLのメジャーバージョンが バックアップした MySQLのメジャーバージョンと同じ
- バックアップファイルの復元に必要な xtrabackup binaryが存在
- 復元する MySQL Serverに `datadir` 変数が設定されている my.cnfファイルが存在
- 復元コマンドを実行する OSユーザーが、`datadir` ディレクトリにアクセスと書き込みを実行可能
- 復元するサーバで MySQLが Shutdownのステータス

              参考

              

- サーバが CentOS以外の OSを使用する場合、[ダウンロードリンク](https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/)で使用中の OSイメージに合う Xtrabackup binaryをダウンロードします。MySQL 8.0以上のバージョンを使用している場合、復元したい MySQLのバージョンと同じバージョンの Xtrabackupをダウンロードします。
- Xtrabackup binaryのオプションに関する説明は、[Perconaの公式ドキュメント(英語)](https://www.percona.com/doc/percona-xtrabackup/2.4/index.html)をご参照ください。

Xtrabackupを使用してデータを復元するには、次のステップを順に行います。CentOS 7.8アプリケーションサーバを基準に説明します。

#### 1.Object Storageでバックアップファイルを準備

1. [Object Storageに保存](/docs/ja/clouddbformysql-backup-classic#ObjectStorage%EC%97%90%EC%A0%80%EC%9E%A5)を参照して復元する MySQL Serverのバックアップファイルを Object Storageに保存します。
2. NAVERクラウドプラットフォームコンソールの Classic環境で、**Menu** > **All Services** > **Storage** > **Object Storage** > **Bucket Management**メニューを順にクリックし、バックアップファイルを保存したバケットをクリックします。
3. 保存したバックアップファイルをクリックし、**編集 > 権限管理**メニューを順にクリックします。
4. 全体公開項目を**公開**に変更し、 **[確認]** ボタンをクリックします。
5. 保存したバックアップファイルの詳細情報から Link項目のリンクをコピーします。

#### 2.Xtrabackupを使用してデータを復元

1. [Cloud DB for MySQL を開始する](/docs/ja/clouddbformysql-start#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%84%9C%EB%B2%84%EC%A0%91%EC%86%8D%ED%85%8C%EC%8A%A4%ED%8A%B8)を参照してアプリケーションサーバにアクセスします。

```
# vi /etc/my.cnf

[mysqld]
innodb_undo_tablespaces = 2
```
  - MySQL 5.7バージョン Serverの場合、my.cnfファイルの `[mysqld]` 構文の下に `innodb_undo_tablespaces = 2` 構文を追加します。
2. 以下のコマンドにコピーしたリンクを入れ、実行してバックアップファイルをダウンロードします。

```
# wget [Link]

-- 例
# wget https://kr.object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735
```
  - バックアップファイルダウンロードを完了すると、Object Storageの権限管理で**公開**設定を**公開しない**に変更します。
3. 以下のコマンドを順に実行し、Xtrabackupをダウンロードします。

```
# cd ~ 

# wget https://www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.9/binary/tarball/percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz

# tar xzf percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz

# cd ./percona-xtrabackup-2.4.9-Linux-x86_64

# XTRABACKUP_DIR=`pwd`
```

```
# cd ~ 

# wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.0/Percona-XtraBackup-8.0.23-16/binary/tarball/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz

# tar xzf percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz

# cd ./percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17

# XTRABACKUP_DIR=`pwd`
```
  - MySQL 5.7バージョン
  - MySQL 8.0バージョン
4. 以下のコマンドを実行し、my.cnfファイルの絶対パスを設定します。

```
# MYSQL_CONF=/etc/my.cnf
```
5. 以下のコマンドを順に実行して、テンポラリディレクトリを作成してバックアップファイルをコピーします。

```
# cd ~

# mkdir backup

# cd ./backup/

# cp ~/[バックアップファイル名] .

-- 例
# cp ~/20211013_BACKUP.1634094735 .
```
6. 以下のコマンドを順に実行して `BACKUP_DIR`のパスをテンポラリディレクトリの場所に指定し、各パスが正常に指定されているか確認します。

```
# BACKUP_DIR=`pwd`

# echo $XTRABACKUP_DIR

# echo $MYSQL_CONF

# echo $BACKUP_DIR
```
7. 以下のコマンドを順に実行して、実行中の MySQLを終了し、`xbstream`からファイルを抽出します。

```
# systemctl stop mysqld

# cd $BACKUP_DIR

# cat [アップロードした_ バックアップファイル] | ${XTRABACKUP_DIR}/bin/xbstream -x

-- 例
# cat 20211013_BACKUP.1634094735 | ${XTRABACKUP_DIR}/bin/xbstream -x
```
8. 以下のコマンドを実行して作成したテンポラリディレクトリにバックアップファイルを復元します。

```
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --apply-log ${BACKUP_DIR}/
```

```
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --prepare --target-dir=${BACKUP_DIR}/
```
  - MySQL 5.7バージョン
  - MySQL 8.0バージョン
9. my.cnfファイルを開いて datadirの場所を確認した後、以下のコマンドを実行して datadir変数に該当するディレクトリを他のテンポラリバックアップフォルダに移動します。

```
# mv [data directory場所] /[new_directory場所]

-- 例
# mkdir /new_directory
# mv /var/lib/mysql /new_directory
```
10. 以下のコマンドを実行して、新規で作成した MySQLディレクトリにバックアップファイルを移動します。

```
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --move-back ${BACKUP_DIR}
```

```
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --move-back --target-dir=${BACKUP_DIR}/
```
  - MySQL 5.7バージョン
  - MySQL 8.0バージョン
11. 以下のコマンドを順に入力して datadir場所に移動し、datadir権限を `mysql`に変更します。

```
# cd /var/lib/mysql

# chown -R mysql:mysql [data directoryパス]

-- 例
# chown -R mysql:mysql /var/lib/mysql
```
  - 変更を完了し、`ll` コマンドを実行して権限が正常に変更されているか確認できます。
12. My.cnfファイルの `[mysqld]` 構文下に「skip-grant-tables」構文を追加します。

```
# vi /etc/my.cnf

[mysqld]
skip-grant-tables
```
13. 以下のコマンドを順に実行して MySQLを開始し、新しい rootアカウントを作成します。

```
# systemctl start mysqld

mysql -u root -p

mysql > flush privileges;
mysql > create user root@localhost identified by 「パスワード」;
mysql > grant all privileges on *.* to root@localhost with grant option;
mysql > flush privileges;
```
  - `create` 実行時、`ERROR 1396 (HY000): Operation CREATE USER failed for 'root'@'localhost'` エラーが発生する場合があります。この場合、`drop user 'root'@'localhost';` コマンドを実行して既存 rootアカウントを削除し、もう一度 `create`を実行します。
14. My.cnfファイルの `[mysqld]` 構文の下に追加した `skip-grant-tables` 構文を削除し、以下のコマンドを実行して MySQLを再起動します。

```
# systemctl restart mysqld
```

### mysqldumpを通じた DBバックアップと復元

mysqldumpユーティリティを使用して、アプリケーションサーバから MySQL Serverのバックアップと復元を実行できます。

#### mysqldumpを通じた DBバックアップ

Mysqldumpユーティリティを使用してサーバで DBをバックアップする方法は、次の通りです。

              参考

              

- Cloud DB for MySQLは Global Transaction Identifier(GTID)を使用するため、GTIDを使用しない MySQL DBを復旧するには、バックアップ実行時に `--set-gtid-purged=OFF` オプションを追加してください。
- バックアップを実行した直後に Cloud DB for MySQLとの Replication接続を行う場合、GTIDを使用できるように `--set-gtid-purged=OFF` オプションを削除します。
- Cloud DB for MySQLのバックアップを他の Cloud DB for MySQLサービスに復旧する場合 `--set-gtid-purged=OFF` オプションを有効にし、ユーザー DBのみにバックアップを行います。

1. [Cloud DB for MySQL を開始する](/docs/ja/clouddbformysql-start#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%84%9C%EB%B2%84%EC%A0%91%EC%86%8D%ED%85%8C%EC%8A%A4%ED%8A%B8)を参照してアプリケーションサーバにアクセスします。
2. 以下のコマンドを実行して希望する DBをバックアップします。  

User ID、パスワード、Privateドメイン、DB名は、コンソール **DB Server**メニューの各サーバの詳細情報で確認できます。

```
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p  -h [DB Privateドメイン] -P [DBアクセスポート] --single-transaction --databases [バックアップするデータベース名] > [作成するバックアップファイル名].sql

-- 例
# mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --databases dbdb > dumpfile.sql
```

```
--mysqldump 5.7と以下のバージョン
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p  -h [DB Privateドメイン] -P [DBアクセスポート] --single-transaction --all-databases > [作成するバックアップファイル名].sql

-- 例
# mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --all-databases  > dumpfile.sql

--mysqldump 8.0バージョン
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p  -h [DB Privateドメイン] -P [DBアクセスポート] --single-transaction --column-statistics=0 --all-databases > [作成するバックアップファイル名].sql

-- 例
# mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --column-statistics=0  --all-databases  > dumpfile.sql
```
  - 特定の DBのみバックアップ
  - DB全体をバックアップ

#### mysqldumpを通じたバックアップファイルの復元

mysqldumpユーティリティを使用してサーバでバックアップファイルを復元する方法は、次の通りです。

1. [Cloud DB for MySQL を開始する](/docs/ja/clouddbformysql-start#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%84%9C%EB%B2%84%EC%A0%91%EC%86%8D%ED%85%8C%EC%8A%A4%ED%8A%B8)を参照してアプリケーションサーバにアクセスします。
2. 以下のコマンドを実行して、希望するバックアップファイルを復元します。

```
# mysql -u root -p < [バックアップファイル名].sql

-- 例
# mysql -u root -p < dumpfile.sql

-- `--set-gtid-purged=OFF` オプションを除いたバックアップファイルで復元を実行する際に `ERROR 3546 (HY000)` エラーが発生する場合、まず以下のコマンドを順に実行した後、復元を実行

# mysql -u root - p

mysql> reset master;
```

## Replication接続

Slave Serverと Master Serverの Replication接続を実行し、接続ステータスを確認できます。

Replication接続を実行する方法は、次の通りです。

              参考

              

Master Serverは Privateドメインを使用するサーバであり、Slave Serverは localサーバです。

1. [DB User管理](/docs/ja/database-database-5-2#DBUser%EA%B4%80%EB%A6%AC)を参照して、Replication接続に使用するユーザーアカウントを作成します。
  - HOST(IPアドレス)には、Slave Serverが位置したアプリケーションサーバのプライベート IPアドレスを入力します。
2. 以下の設定を my.cnfファイルの `[mysqld]` 構文の下に追加します。

```
# Replication
server-id = 2
log-bin = mysql-bin
relay-log = relay-bin
report-host = ncp-mysql-server
master_info_repository = FILE
relay_log_info_repository = FILE
slave_type_conversions = ALL_NON_LOSSY
log_slave_updates # required! GTID 
read_only # required!

# Replication GTID
enforce-gtid-consistency # required! GTID 
gtid-mode = ON # required! GTID
```
  - `server-id`は、Replication構成内で各サーバを区分できるように固有の値で設定し、1~4294967295間の数字のみ入力できます。
3. 以下のコマンドを実行して MySQLを再起動します。

```
systemctl restart mysqld
```
4. [バックアップユーティリティを使用する](/docs/ja/clouddbformysql-backup-classic#%EB%B0%B1%EC%97%85%EC%9C%A0%ED%8B%B8%EB%A6%AC%ED%8B%B0%EC%82%AC%EC%9A%A9)を参照して DBをバックアップします。
5. 以下のコマンドを順に実行して、rootアカウントで Slave Serverにアクセスし、Masterを変更します。

```
mysql -u root -p

mysql> CHANGE MASTER TO
 MASTER_HOST = 'DB Privateドメイン',
 MASTER_USER = 'User_ID',
 MASTER_PASSWORD = 'ユーザーのパスワード',
 MASTER_PORT = 3306,
 MASTER_AUTO_POSITION = 1;
 
 -- 例
 mysql> CHANGE MASTER TO
    -> MASTER_HOST = 'db-1qv7d.cdb.ntruss.com',
    -> MASTER_USER = 'replication',
    -> MASTER_PASSWORD = 'password1!',
    -> MASTER_PORT = 3306,
    -> MASTER_AUTO_POSITION = 1;
```

1. 以下のコマンドを実行して、Slave Serverから Master Serverに接続します。

```
mysql> START SLAVE;
```

### 接続確認

Replication接続を完了し、接続ステータスを確認するには、以下のコマンドを実行した後に表をご参照ください。

```
mysql> show slave status \G;
```

| 項目 | 説明 |
| --- | --- |
| `Slave_IO_State` | Slave Serverの現在のステータス |
| `Master_Host` | Slave Serverが接続された Master Serverのホスト名または IPアドレス |
| `Master_User` | Slave Serverが Master Serverに接続する時に使用するユーザーアカウント |
| `Master_Port` | Slave Serverが Master Serverに接続したポート |
| `Connect_Retry` | 接続が切断された時に再試行する時間(デフォルト値: 60秒) `CHANGE MASTER TO` コマンドを通じて変更可能 |
| `Master_Log_File` | I/Oスレッドが現在読み取っている Master Serverのバイナリログファイル名 |
| `Read_Master_Log_Pos` | I/Oスレッドが現在読み取っている Master Serverのバイナリログファイルの位置 |
| `Relay_Log_File` | SQLスレッドが現在読み取っている Slave Serverのリレーログファイル名 |
| `Relay_Log_Pos` | SQLスレッドが現在読み取っている Slave Serverのリレーログファイルの位置 |
| `Relay_Master_Log_File` | SQLスレッドで実行した最新イベントが含まれているソースバイナリログファイル名 |
| `Slave_IO_Running` | Slave Serverの I/Oスレッド動作ステータスとして、以下の3つの値の中から1つを通じて Master Serverとの接続の有無を表示 - `No`: スレッドが実行されない - `Connecting`: スレッド実行中、Master Serverに接続できない - `Yes`: スレッド実行中、Master Serverに接続される |
| `Slave_SQL_Running` | SQLスレッドが開始されているかを表示 |
| `Replicate_Do_DB` | `--replicate-do-db` オプションで指定された DBリスト |
| `Replicate_Ignore_DB` | `--replicate-ignore-db` オプションで指定されたデータベースリスト |
| `Replicate_Do_Table` | `--replicate-do-table` オプションで指定されたデータベースリスト |
| `Replicate_Ignore_Table` | `--replicate-ignore-table` オプションで指定されたデータベースリスト |
| `Replicate_Wild_Do_Table` | `--replicate-wild-do-table` オプションで指定されたデータベースリスト |
| `Replicate_Wild_Ignore_Table` | `--replicate-wild-ignore-table` オプションで指定されたデータベースリスト |
| `Last_Errno`, `Last_Error` | `Last_SQL_Errno`項目と同じ値で、`RESET MASTER`、`RESET SLAVE`コマンドで値をリセット可能 (Slave Serverの SQLスレッドがエラー転送された時に、まずそのエラーをレポートした後に SQLスレッドを停止させるため、`SHOW SLAVE STATUS` コマンドを実行した場合 `Slave_SQL_Running`の値が `YES`であってもこの項目の値が0とは表示されない) |
| `Skip_Counter` | システム変数の `SQL_Slave_Skip_Counter`の現在値を表示 |
| `Exec_Master_Log_Pos` | SQLスレッドが読み取って実行した現在 Master Serverのバイナリログファイル場所として、次に処理されるトランザクションまたはイベントの開始を表示 (新しい Slave Serverを接続する場合、`CHANGE MASTER TO` コマンドで `MASTER_LOG_POS` オプションに値を指定すると接続した Slave Serverが当該時点から読み取りを開始) |
| `Relay_Log_Space` | 存在するすべてのリレーログファイルのサイズを合わせた値 |
| `Until_Condition` | `START_SLAVE` コマンドに指定された値として、以下の値の中から1つを表示 - `None`: `UNTIL` 節が指定されていない - `Master`: Slave Serverが Master Serverのバイナリログファイルを設定 - `Relay`: Slave Serverがリレーログファイルを設定 |
| `Until_Log_File` | SQLスレッドを実行して中断するログファイル名 |
| `Until_Log_Pos` | SQLスレッドが実行を中断するログファイルのポジション値 |
| `Master_SSL_Allowed` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータとして、以下の値の中から1つを表示 - `Yes`: SSL接続を許可 - `No`: SSL接続を許可しない - `Ignored`: SSL接続が許可されているが、Slave Serverに SSLサポートが有効になっていない |
| `Master_SSL_CA_File` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Master_SSL_CA_Path` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Master_SSL_Cert` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Master_SSL_Cipher` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Master_SSL_Key` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Seconds_Behind_Master` | Slaver Serverのレプリケーション速度がどれほど遅くなったかを表示 |
| `Master_SSL_Verify_Server_Cert` | Slave Serverが Master Serverに接続する時に使用される SSLパラメータ |
| `Last_IO_Errno` | 直近に I/Oスレッドを止めたエラー番号 |
| `Last_IO_Error` | 直近に I/Oスレッドを止めたエラーメッセージ |
| `Last_SQL_Errno` | 直近に SQLスレッドを止めたエラー番号 |
| `Last_SQL_Error` | 直近に SQLスレッドを止めたエラーメッセージ |
| `Replicate_Ignore_Server_Ids` | Slave Serverで `CHANGE MASTER TO` 構文の `IGNOER_SERVER_IDS` オプションを実行した内容 |
| `Master_Server_Id` | Master Serverの `server_id` 値 |
| `Master_UUID` | Master Serverの `server_uuid` 値 |
| `Master_Info_File` | master.infoファイルの場所 |
| `SQL_Delay` | Slave Serverが Master Serverとのレプリケーションを何秒遅延させるかを表示 |
| `SQL_Remaining_Delay` | `Slave_SQL_Running_State` が `Waiting until MASTER_DELAY seconds after master executed event` の場合の残り時間を表示 (以外の場合には `NULL`) |
| `Slave_SQL_Running_State` | SQLスレッドの動作ステータス |
| `Master_Retry_Count` | Slave Serverと Master Serverの接続が切断された場合、再アクセスを試行する回数 |
| `Master_Bind` | Slave Serverがバインドしたネットワークインターフェース |
| `Last_IO_Error_Timestamp` | 最近に発生した I/Oエラーの発生時刻 (YYMMDD HH:MM:SS) |
| `Last_SQL_Error_Timestamp` | 最近に発生した SQLエラーの発生時刻 (YYMMDD HH:MM:SS) |
| `Retrieved_Gtid_Set` | Slave Serverが取得したすべてのトランザクションに相応する GTID集合 (GTIDを使用しない場合はスペース) |
| `Executed_Gtid_Set` | バイナリログに作成された GTID集合 (GTIDを使用しない場合はスペース) |
| `Auto_Position` | `Auto_Position`の使用時は1、未使用時は0 |

### Replicationエラーの解決

Master Serverと Slave Serverの `Executed_Gtid_Set`値が異なる場合、`show slave status \G;`コマンドで接続ステータスを確認した時に `Slave_SQL_Running`と `Slave_IO_Running`のいずれかが `No`と表示され、以下のようなエラーが表示されることがあります。

**Slave_SQL_Running: No**

```
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'e0b74649-41d7-11ec-afb6-f220af895dd6:2' at master log mysql-bin.000001, end_log_pos 751. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
```

**Slave_IO_Running: No**

```
Last_IO_Error: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period.
```

`Executed_Gtid_Set`値を変更して Replicationエラーを解決する方法は、次の通りです。

              注意

              

`GTID_PURGED`値を再設定する場合、データ不一致が発生しないように MySQLの公式ドキュメントと Perconaの公式ドキュメントをご参照ください。

- [MySQL公式ドキュメント(英語)](https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html)
- [Percona公式ドキュメント(英語)](https://www.percona.com/blog/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/)

1. 以下のコマンドをそれぞれ実行し、Master Serverと Slave Serverの `Executed_Gtid_Set` の値が同じであるか確認します。
  - Master Server:  `show global variables like &apos;gtid_executed&apos;;`
  - Slave Server: `show slave status \G;`
2. 以下のコマンドを実行し、`GTID_PURGED`値を再設定します。

```
① GTID_PURGEDの再設定
mysql> stop slave;
mysql> reset master;
mysql> set global GTID_PURGED="マスター Executed_Gtid_Setの値";
mysql> start slave;

② rootアカウントの再設定
mysql> flush privileges;
mysql> create user root@localhost identified by「パスワード」;
mysql> grant all privileges on *.* to root@localhost with grant option;
mysql> flush privileges;
```