- 印刷する
- PDF
Backup
- 印刷する
- PDF
Classic/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を利用するための基本的な説明は、次のとおりです。
領域 | 説明 |
---|---|
① メニュー名 | 現在確認中のメニューの名前 |
② 基本機能 | Cloud DB for MySQLの詳細情報を確認、Backup画面を更新 |
③ バックアップのリスト | 設定しておいたサーバ別のバックアップ設定および設定情報 |
バックアップ設定リスト確認
運用中の MySQL Server別バックアップ設定リストを確認できます。バックアップ設定リストを確認する方法は、次のとおりです。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- Backup メニューをクリックします。
- バックアップ設定リストが表示されたら、必要な情報を確認します。
- DBサービス名: ユーザーが指定した DB Service名
- Backup保管日: バックアップファイルをデータストレージに保存して保存する最大日数
- Backup開始時間: 毎日1回、バックアップを行う時間
- Backupデータサイズ: 完了したバックアップファイルのサイズ
- 最終 Backupの日時: 最近行われたバックアップの日付
- 詳細情報を見る: サーバ別に作成されたバックアップファイルリストの詳細情報と復元、Object Storageに保存
サーバ別バックアップファイルリスト確認
バックアップを完了し、サーバ別に作成したバックアップファイルリストを確認する方法は、次のとおりです。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- Backup メニューをクリックします。
- 詳細情報を確認するバックアップ設定行の 詳細情報を見る で [詳細履歴] ボタンをクリックします。
- バックアップファイルの詳細情報を確認します。
- Backupの日付: バックアップを行った日付
- Backup開始時間: バックアップを開始した時刻
- Backup完了時間: バックアップを完了した時刻
- 所要時間: バックアップ完了までにかかった時間
- Backupサイズ: バックアップ完了後に作成されたバックアップファイルのサイズ(MB)
- データストレージ: 当該 MySQL Serverのデータストレージ容量
コンソールでデータ復元
Cloud DB for MySQLでは、バックアップファイルを利用して消失したデータを復元し、簡単かつ速やかに MySQL Serverを作成できるサービスを提供しています。また、時点復元機能を使用して復元できる時間範囲内で、ユーザーが希望する時間帯にデータを復元できます。
Backupファイルの復元
自動バックアップを通じて作成された Backupファイルを使用してデータを復元できます。
作成されたバックアップファイルを使用してデータを復元する方法は、次のとおりです。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- Backup メニューをクリックします。
- 復元するバックアップ設定の行の [詳細履歴] ボタンをクリックします。
- バックアップファイルを選択し、 [Backupの復元] ボタンをクリックします。
- 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と異なるアベイラビリティーゾーンのサブネット
- [復元する] ボタンまたは [作成] ボタンをクリックします。
- [確認] ボタンをクリックします。
- DB Server メニューをクリックします。
- 復元中のサーバの状態を確認します。
- Recoveryタイプに作成される
- 作成中: ユーザーが入力した情報で MySQL Serverを作成(復元)している状態
- 設定中: ユーザーが入力した情報で MySQL Serverを作成(復元)して構成している状態
- 運用中: ユーザーが入力した情報で MySQL Serverの作成(復元)と設定が完了し、アプリケーションサーバから MySQL Serverにアクセスできる状態
サーバ復元完了まで数分かかります。
時点復元
希望する特定時点でデータを復元できます。復元する時点は、復元できる範囲内で、分単位まで指定できます。
時点復元機能でデータを復元する方法は、次のとおりです。
Stand Aloneタイプの Serverは時点復元機能を提供しません。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- Backup メニューをクリックします。
- 復元するバックアップ設定の行の [詳細履歴] ボタンをクリックします。
- [時点復元] ボタンをクリックします。
- 時点復元 のポップアップが表示されたら、復元のために必要な情報を確認するか、入力します。
- DBが復元できる時間: 復元できる時間範囲(最大7日)
- DBの復元時間: 復元したい時点
- Private Subドメイン(VPC環境): 復元するサーバで使用する Private Subドメイン(選択不可)
- DB Serverタイプ: 復元する MySQL Serverタイプ
- DB Server名: 復元する MySQL Server名
- [復元する] ボタンまたは [作成] ボタンをクリックします。
- [確認] ボタンをクリックします。
- DB Server メニューをクリックします。
- 復元中のサーバの状態を確認します。
- 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のみ作成できます。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- DB Server メニューをクリックします。
- 新しい DB Serviceを作成する Recovery Serverをクリックし、 [DB管理] ボタンをクリックします。
- [新規 DBサービス作成] ボタンをクリックします。
- 新規 DBサービス作成 のポップアップが表示されたら、高可用性サポートの有無を選択して DBサービス名を入力し、[はい] ボタンをクリックします。
- 作成中のサーバの状態を確認します。
- 作成中: ユーザーが入力した情報で 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 メニューをご参照ください。
Secure Zoneに作成された MySQL Serverの場合、まず NAVERクラウドプラットフォームの Secure Zoneで関連する Policyを追加する必要があります。 Policy作成 のポップアップの Source IPアドレス、Destination IPアドレス項目でそれぞれ MySQLサーバと Object Storageを選択します。Secure Zoneに関する詳細は、Secure Zoneをご参照ください。
- NAVERクラウドプラットフォームコンソールで、 Services > Database > Cloud DB for MySQL メニューを順にクリックします。
- Backup メニューをクリックします。
- Object Storageに保存するファイルがあるバックアップ設定行の [詳細内容] ボタンをクリックします。
- バックアップファイルを選択し、 [Object Storageにエクスポートする] ボタンをクリックします。
- Object Storageにエクスポートする のポップアップが表示されたら、保存するバケットとフォルダをクリックして選択します。
- [Object Storageにエクスポートする] ボタンをクリックします。
- [確認] ボタンをクリックします。
- 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を使用する場合、ダウンロードリンクで使用中の OSイメージに合う Xtrabackup binaryをダウンロードします。
- Xtrabackup binaryのオプションに関する説明は、Perconaの公式文書(英語)をご参照ください。
Xtrabackupを使用してデータを復元するには、次のステップを順に行います。CentOS 7.8アプリケーションサーバを基準に説明します。
1. Object Storageでバックアックファイルを準備
- Object Storageに保存を参照して復元する MySQL Serverのバックアックファイルを Object Storageに保存します。
- NAVERクラウドプラットフォームコンソールで、 Services > Storage > Object Storage > Bucket Management メニューを順にクリックし、バックアップファイルを保存したバケットをクリックします。
- 保存したバックアップファイルをクリックし、 編集 > 権限管理 メニューを順にクリックします。
- 全体公開項目を 公開 に変更し、 [確認] ボタンをクリックします。
- 保存したバックアップファイルの詳細情報から Link項目のリンクをコピーします。
2. XtraBackupを使用してデータを復元
Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
- MySQL 5.7バージョン Server場合、 my.cnfファイルの
[mysqld]
構文の下にinnodb_undo_tablespaces = 2
構文を追加します。
- MySQL 5.7バージョン Server場合、 my.cnfファイルの
以下のコマンドにコピーしたリンクを入れ、実行してバックアップファイルをダウンロードします。
- バックアップファイルダウンロードを完了すると、 Object Storageの権限管理で 公開 設定を 公開しない に変更します。
# wget [Link] -- 例 # wget https://kr.beta-object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735
以下のコマンドを順に実行し、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`
以下のコマンドを実行し、my.cnfファイルの絶対パスを設定します。
# MYSQL_CONF=/etc/my.cnf
以下のコマンドを順に実行して、テンポラリディレクトリを作成してバックアップファイルをコピーします。
# cd ~ # mkdir backup # cd ./backup/ # cp ~/[バックアップファイル名] . -- 例 # cp ~/20211013_BACKUP.1634094735 .
以下のコマンドを順に実行して
BACKUP_DIR
のパスをテンポラリディレクトリの場所に指定し、各パスが正常に指定されているか確認します。# BACKUP_DIR=`pwd` # echo $XTRABACKUP_DIR # echo $MYSQL_CONF # echo $BACKUP_DIR
以下のコマンドを順に実行して、実行中の MySQLを終了し、
xbstream
からファイルを抽出します。# systemctl stop mysqld # cd $BACKUP_DIR # cat [アップロードした_ バックアップファイル] | ${XTRABACKUP_DIR}/bin/xbstream -x -- 例 # cat 20211013_BACKUP.1634094735 | ${XTRABACKUP_DIR}/bin/xbstream -x
以下のコマンドを実行して作成したテンポラリディレクトリにバックアップファイルを復元します。
- 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}/
my.cnfファイルを開いて datadirの場所を確認した後、以下のコマンドを実行して datadir変数に該当するディレクトリを他のテンポラリバックアップフォルダに移動します。
# mv [data directory場所] /[new_directory場所] -- 例 # mv /var/lib/mysql /new_directory
以下のコマンドを実行して、新規で作成した 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}/
以下のコマンドを順に入力して datadir場所に移動し、datadir権限を
mysql
に変更します。- 変更を完了し、
ll
コマンドを実行して権限が正常に変更されているか確認できます。
# cd /var/lib/mysql # chown -R mysql:mysql [data directoryパス] -- 例 # chown -R mysql:mysql /var/lib/mysql
- 変更を完了し、
My.cnfファイルの
[mysqld]
構文下に「skip-grant-tables」構文を追加します。以下のコマンドを順に実行して 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;
My.cnfファイルの
[mysqld]
構文の下に追加したskip-grant-tables
構文を削除し、以下のコマンドを実行して MySQLを再起動します。# systemctl restart mysqld
Mysqldumpを通じた DBバックアップと復元
mysqldumpユーティリティを使用して、アプリケーションサーバから MySQL Serverのバックアップと復元を実行できます。
Mysqldumpを通じた DBバックアップ
Mysqldumpユーティリティを使用してサーバで DBをバックアップする方法は、次のとおりです。
- Cloud DB for MySQLは、GTID(Global Transaction Identifier)を使用するため、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のみにバックアップを行います。
Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
以下のコマンドを実行して希望する DBをバックアップします。
User ID、パスワード、Privateドメイン、DB名は、コンソール DB Server メニューの各サーバの詳細情報で確認できます。- 特定の DBのみバックアップ
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Privateドメイン] -S [mysql.sock場所] --single-transaction --databases [バックアップするデータベース名] > [作成するバックアップファイル名].sql -- 例 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --databases dbdb > dumpfile.sql
- DB全体をバックアップ
--mysqldump 5.7と以下のバージョン # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Privateドメイン] -S [mysql.sock場所] --single-transaction --all-databases > [作成するバックアップファイル名].sql -- 例 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --all-databases > dumpfile.sql --mysqldump 8.0バージョン # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Privateドメイン] -S [mysql.sock場所] --single-transaction --column-statistics=0 --all-databases > [作成するバックアップファイル名].sql -- 例 # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.beta-cdb.ntruss.com -S /var/lib/mysql/mysql.sock --single-transaction --column-statistics=0 --all-databases > dumpfile.sql
mysqldumpを通じたバックアップファイルの復元
mysqldumpユーティリティを使用してサーバでバックアップファイルを復元する方法は、次のとおりです。
- Cloud DB for MySQL を開始するを参照してアプリケーションサーバにアクセスします。
- 以下のコマンドを実行して、希望するバックアップファイルを復元します。
# 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サーバです。
DB User管理を参照して、Replication接続に使用するユーザーアカウントを作成します。
- HOST(IPアドレス)には、Slave Serverが位置したアプリケーションサーバのプライベート IPアドレスを入力します。
以下の設定を 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
以下のコマンドを実行して MySQLを再起動します。
systemctl restart mysqld
バックアップユーティリティを使用するを参照して DBをバックアップします。
以下のコマンドを順に実行して、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;
- 以下のコマンドを実行して、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つの値のいずれかで 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 コマンドに指定された値で、以下の値のいずれかを表示
|
Until_Log_File | SQLスレッドを実行して中断するログファイル名 |
Until_Log_Pos | SQLスレッドを実行して中断するログファイルのポジション値 |
Master_SSL_Allowed | Slave Serverが Master 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サーバのコピー速度がどれだけ遅くなったかを表示 |
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
と表示され、以下のようなエラーが表示されることがあります。
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.
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の公式文書をご参照ください。
- 以下のコマンドをそれぞれ実行し、Master Serverと Slave Serverの
Executed_Gtid_Set
の値が同じであるか確認します。- Master Server:
show global variables like 'gtid_executed';
- Slave Server:
show slave status \G;
- Master Server:
- 以下のコマンドを実行し、
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;