Backup

VPC環境で利用できます。

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を利用するための基本的な説明は、次の通りです。

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

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

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. Backupメニューをクリックします。
3. バックアップ設定リストが表示されたら、必要な情報を確認します。
   
   • DBサービス名: ユーザーが指定した DB Serviceの名前
   • Backup保管日: バックアップファイルをデータストレージに保存して保管する最大日数
   • Backup開始時間: 毎日1回バックアップを行う時間
   • Backupデータのサイズ: 完了したバックアップファイルのサイズ
   • 最終 Backup日時: 最近実行完了したバックアップの日付
   • 詳細情報を見る: サーバ別に作成されたバックアップファイルリストの詳細情報と復元、 Object Storageに保存

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

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

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. Backupメニューをクリックします。
3. 詳細情報を確認するバックアップ設定行の詳細情報を見るで [詳細履歴] ボタンをクリックします。
4. バックアップファイルの詳細情報を確認します。
   
   • Backup日: バックアップを行った日付
   • Backup開始時間: バックアップを開始した時刻
   • Backup完了時間: バックアップを完了した時刻
   • 所要時間: バックアップ完了までにかかった時間
   • Backupサイズ: バックアップ完了後に作成されたバックアップファイルのサイズ(MB)
   • データストレージ: この MySQL Serverのデータストレージサイズ

コンソールでデータ復元

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

Backupファイルの復元

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

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. Backupメニューをクリックします。
3. 復元するバックアップ設定の行の [詳細履歴] ボタンをクリックします。
4. バックアップファイルを選択し、 [Backupファイル復元] ボタンをクリックします。
5. Backupファイル復元のポップアップが表示されたら、復元のために必要な情報を確認するか、入力します。
   
   • Backup時間: 復元できる時間範囲(最大7日)
   • Backup完了時間: 復元したい時点
   • Private Subドメイン(VPC環境): 復元するサーバで使用する Private Subドメイン(選択不可)
   • DB Serverタイプ: 復元する MySQL Serverタイプ
   • DB Server名: 復元する MySQL Serverの名前
   • 新規 DBサービスで作成: 復元するサーバを新規サービスとして作成
   • DBサービス名: 新規 DBサービスの名前
   • 高可用性: 新規サービスの作成時に高可用性で作成
   • Multi Zone: 互いに異なるアベイラビリティーゾーンに Standby Master Serverと Master Serverを作成
   • Subnet: Master Subnetと異なるアベイラビリティーゾーンのサブネット
   • データストレージタイプ: 復元するデータストレージのタイプ
6. [復元する] ボタンまたは [作成] ボタンをクリックします。
7. [確認] ボタンをクリックします。
8. DB Serverメニューをクリックします。
9. 復元中のサーバのステータスを確認します。
   • Recoveryタイプに作成される
   • 作成中: ユーザーが入力した情報で MySQL Serverを作成(復元)しているステータス
   • 設定中: ユーザーが入力した情報で MySQL Serverを作成(復元)して構成しているステータス
   • 運用中: ユーザーが入力した情報で MySQL Serverの作成(復元)と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできるステータス

時点復元

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

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. Backupメニューをクリックします。
3. 復元するバックアップ設定の行の [詳細履歴] ボタンをクリックします。
4. [時点復元] ボタンをクリックします。
   
5. 時点復元のポップアップが表示されたら、復元のために必要な情報を確認するか、入力します。
   
   • DB復元可能時間: binlog_expire_logs_secondsの設定値内の時間
   • DB復元時間: 復元したい時点
   • Private Subドメイン(VPC環境): 復元するサーバで使用する Private Subドメイン(選択不可)
   • DB Serverタイプ: 復元する MySQL Serverタイプ
   • DB Server名: 復元する MySQL Serverの名前
   • 新規 DBサービスで作成: 復元するサーバを新規サービスとして作成
   • DBサービス名: 新規 DBサービスの名前
   • 高可用性: 新規サービスの作成時に高可用性で作成
   • Multi Zone: 互いに異なるアベイラビリティーゾーンに Standby Master Serverと Master 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日に設定されます。

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. DB Serverメニューをクリックします。
3. 新しい DB Serviceを作成する Recovery Serverをクリックし、 [DB管理] ボタンをクリックします。
4. [新規 DBサービス作成] ボタンをクリックします。
5. 新規 DBサービス作成のポップアップが表示されたら、高可用性サポートの有無を選択して DBサービス名を入力し、 [はい] ボタンをクリックします。
   
6. 作成中のサーバのステータスを確認します。
   • 作成中: ユーザーが入力した情報で MySQL Serverを作成しているステータス
   • 設定中: ユーザーが入力した情報で MySQL Serverを作成、構成しているステータス
   • 運用中: ユーザーが入力した情報で MySQL Serverの作成と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできるステータス

Object Storageに保存

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

1. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Database > Cloud DB for MySQLメニューを順にクリックします。
2. Backupメニューをクリックします。
3. Object Storageに保存するファイルがあるバックアップ設定行の [詳細履歴] ボタンをクリックします。
4. バックアップファイルを選択し、 [Object Storageにエクスポート] ボタンをクリックします。
   
5. Object Storageにエクスポートのポップアップが表示されたら、保存するバケットとフォルダをクリックして選択します。
   
6. [Object Storageにエクスポート] ボタンをクリックします。
7. [確認] ボタンをクリックします。

バックアップユーティリティを使用する

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のステータス

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

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

1. Object Storageに保存を参照して復元する MySQL Serverのバックアップファイルを Object Storageに保存します。
2. NAVERクラウドプラットフォームコンソールの VPC環境で、 > Services > Storage > Object Storage > Bucket Managementメニューを順にクリックし、バックアップファイルを保存したバケットをクリックします。
3. 保存したバックアップファイルをクリックし、編集 > 権限管理メニューを順にクリックします。
4. 全体公開項目を公開に変更し、 [確認] ボタンをクリックします。
5. 保存したバックアップファイルの詳細情報から Link項目のリンクをコピーします。

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

1. Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
   • MySQL 5.7バージョン Server場合、my.cnfファイルの [mysqld] 構文の下に innodb_undo_tablespaces = 2 構文を追加します。

   # vi /etc/my.cnf
   
   [mysqld]
   innodb_undo_tablespaces = 2
   

2. 以下のコマンドにコピーしたリンクを入れ、実行してバックアップファイルをダウンロードします。
   • バックアップファイルダウンロードを完了すると、Object Storageの権限管理で公開設定を公開しないに変更します。

   # wget [Link]
   
   -- 例
   # wget https://kr.beta-object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735
   

3. 以下のコマンドを順に実行し、Xtrabackupをダウンロードします。
   • MySQL 5.7バージョン

   # 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`
   

   • MySQL 8.0バージョン

   # 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 8.4バージョン

   # cd ~
   
   # wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.4/Percona-XtraBackup-8.4.0-4/binary/tarball/percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34.tar.gz
   
   # tar xzf percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34.tar.gz
   
   # cd ./percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34
   
   # XTRABACKUP_DIR=`pwd`
   

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. 以下のコマンドを実行して作成したテンポラリディレクトリにバックアップファイルを復元します。
   • MySQL 5.7バージョン

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

   • MySQL 8.0以上のバージョン

   # ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --prepare --target-dir=${BACKUP_DIR}/
   

9. my.cnfファイルを開いて datadirの場所を確認した後、以下のコマンドを実行して datadir変数に該当するディレクトリを他のテンポラリバックアップフォルダに移動します。

   # mv [data directory場所] /[new_directory場所]
   
   -- 例
   # mkdir /new_directory
   # mv /var/lib/mysql /new_directory
   

10. 以下のコマンドを実行して、新規で作成した MySQLディレクトリにバックアップファイルを移動します。
    • MySQL 5.7バージョン

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

    • MySQL 8.0以上のバージョン

    # ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --move-back --target-dir=${BACKUP_DIR}/
    

11. 以下のコマンドを順に入力して datadir場所に移動し、datadir権限を mysqlに変更します。
    • 変更を完了し、ll コマンドを実行して権限が正常に変更されているか確認できます。

    # cd /var/lib/mysql
    
    # chown -R mysql:mysql [data directoryパス]
    
    -- 例
    # chown -R mysql:mysql /var/lib/mysql
    

12. My.cnfファイルの [mysqld] 構文下に「skip-grant-tables」構文を追加します。

    # vi /etc/my.cnf
    
    [mysqld]
    skip-grant-tables
    

13. 以下のコマンドを順に実行して MySQLを開始し、新しい rootアカウントを作成します。
    • create 実行時、ERROR 1396 (HY000): Operation CREATE USER failed for 'root'@'localhost' エラーが発生する場合があります。この場合、drop user 'root'@'localhost'; コマンドを実行して既存 rootアカウントを削除し、もう一度 createを実行します。

    # 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;
    

14. My.cnfファイルの [mysqld] 構文の下に追加した skip-grant-tables 構文を削除し、以下のコマンドを実行して MySQLを再起動します。

    # systemctl restart mysqld
    

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

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

Mysqldumpを通じた DBバックアップ

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

1. Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
2. 以下のコマンドを実行して希望する DBをバックアップします。
   User ID、パスワード、Privateドメイン、DB名は、コンソール DB Serverメニューの各サーバの詳細情報で確認できます。
   • 特定の DBのみバックアップ

   # 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.beta-cdb.ntruss.com -P 3306 --single-transaction --databases dbdb > dumpfile.sql
   

   • DB全体をバックアップ

   --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.beta-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.beta-cdb.ntruss.com -P 3306 --single-transaction --column-statistics=0  --all-databases  > dumpfile.sql
   

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

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

1. Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
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接続を実行する方法は、次の通りです。

1. DB User管理を参照して、Replication接続に使用するユーザーアカウントを作成します。
   • HOST(IPアドレス)には、Slave Serverが位置したアプリケーションサーバのプライベート IPアドレスを入力します。
2. 以下の設定を my.cnfファイルの [mysqld] 構文の下に追加します。
   • server-idは、Replication構成内で各サーバを区分できるように固有の値で設定し、1~4294967295間の数字のみ入力できます。

   # 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 
   

3. 以下のコマンドを実行して MySQLを再起動します。

   systemctl restart mysqld
   

4. バックアップユーティリティを使用するを参照して 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.beta-cdb.ntruss.com',
    -> MASTER_USER = 'replication',
    -> MASTER_PASSWORD = 'password1!',
    -> MASTER_PORT = 3306,
    -> MASTER_AUTO_POSITION = 1;

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

mysql> START SLAVE;

接続確認

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

mysql> show slave status \G;

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エラーを解決する方法は、次の通りです。

1. 以下のコマンドをそれぞれ実行し、Master Serverと Slave Serverの Executed_Gtid_Set の値が同じであるか確認します。
   • Master Server: show global variables like 'gtid_executed';
   • 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;