これまでの 3 つの記事では、論理バックアップと物理バックアップを含む、MySQL データベースの一般的なバックアップ方法を紹介しました。この記事では、MySQL データベースのデータ復旧に関連する内容をまとめます。これらのデータ復旧ソリューションは、以前のバックアップ コンテンツで紹介されました。ここでは、復旧ソリューションをまとめ、データベースのバイナリ ログと組み合わせたデータ復旧を実演します。 1. 復旧計画 1. データ量がそれほど大きくない場合は、mysql client コマンドまたは source コマンドを使用して、mysqldump コマンドでバックアップしたデータを復元できます。 2. ポイントインタイムリカバリにmysqlbinlogを使用する 1. はじめに mysqlbinlog はバイナリ ログからステートメントを読み取るツールで、インストール後に mysql に付属します。 2. バイナリログリカバリの原理 mysqldump を使用してデータベースをバックアップすると、生成されたバックアップ ファイルには、データベース DML 操作の時点とバックアップ時のバイナリ ログ位置情報が含まれます。単一データベースの場合は、特定の時点から開始してポイントインタイム リカバリを実行できます。マスター スレーブ アーキテクチャの場合は、バックアップ中に --master-data=2 および --single-transaction に従って、時点または位置ポイントに基づいてリカバリを完了できます。 3. バイナリログリカバリの例 (1)単一データベースのリカバリ例 データベースを作成し、テストデータを挿入する mysql> SHOW CREATE DATABASE test_db; mysql> テーブル `student` を作成します ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, `age` tinyint(4) デフォルト NULL, 主キー (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 デフォルト CHARSET=utf8; mysql> INSERT INTO 学生 (名前、年齢) VALUES('Jack',23),('Tomcat',24),('XiaoHong',22),('ZhangFei',29); mysqldumpを使用してフルバックアップを実行し、バックアップ時にログをロールし、バイナリログファイル名とログの場所を記憶します。 [root@WB-BLOG ~]# mysqldump -uroot -proot -h127.0.0.1 -P3306 --databases test_db --single-transaction --triggers --routines --flush-logs --events > /tmp/test_db.sql [root@WB-BLOG ~]# mysql -e "バイナリログを表示" > bin_pos_`date +%F`.out この時点で、バイナリログファイル名とログポイントの場所を次のように表示します。 mysql> バイナリログを表示します。 +------------------+-----------+ | ログ名 | ファイルサイズ | +------------------+-----------+ |mysql-bin.000001 | 1497 | |mysql-bin.000002 | 397 | +------------------+-----------+ セット内の 2 行 (0.00 秒) しばらく使用した後、誤って次のステートメントを実行し、データベース内のすべてのデータを変更しました。 mysql> UPDATE STUDENT SET name = 'admin'; しばらくして、おそらく数分か数時間後、誰かがウェブサイトのログインに問題があると報告しました。確認したところ、多くのデータが誤って変更されたことがわかりました。この期間中、次の新しいレコードなどの書き込み操作がまだありました。 mysql> 学生にINSERT INTO(名前、年齢) VALUES('Hbase',23),('BlackHole',30); このとき、データを復元する必要があります。まず、データが書き込まれないように、テーブルをロックし、書き込みサービスを一時停止し、ユーザーにシステムメンテナンスを通知してから、次の操作を実行します。 #データベースにログインし、テーブルをロックします。この時点では、テーブルは読み取りのみ可能で、書き込みはできません。mysql> USE test_db; mysql> LOCK TABLE 学生の読み取り; #次に、セッション ウィンドウを再度開きます (再度開くことに注意してください)。そうしないと、セッションが終了した後にロックが解除されます。次に、既存のデータとバイナリ ログ ファイルを圧縮してバックアップします [root@WB-BLOG mysql_logs]# tar zcvf mysql_data.tar.gz /mysql_data/* [root@WB-BLOG mysql_logs]# tar zcvf mysql_bin.tar.gz /mysql_logs/* #最新のフルバックアップデータをインポートします [root@WB-BLOG ~]# mysql -uroot -proot -h127.0.0.1 -P3306 < /tmp/test_db.sql # フルバックアップ中のバイナリログファイルとログポイントを表示します [root@WB-BLOG ~]# cat bin_pos_2018-06-24.out ログ名 ファイルサイズ mysql-bin.000001 1497 mysql-bin.000002 397 #ポイント 861 以降のバイナリ ログ ファイルを SQL ファイルに変換します [root@WB-BLOG bin]# ./mysqlbinlog /mysql_logs/mysql-bin.000002 --start-position=397 > /tmp/tmp.sql # vim エディタを使用してこの sql ファイルを編集し、無条件 UPDATE ステートメントを見つけて削除し、UPDATE ステートメントを削除した後の sql スクリプトの内容をデータベース [root@WB-BLOG bin] にインポートします。# vim /tmp/tmp.sql `test_db`/*!*/ を使用します。 タイムスタンプを 1522088753/*!*/ に設定します。 update student set name = 'admin' #この文を削除 [root@WB-BLOG bin]# mysql -uroot -proot -h127.0.0.1 -P3306 < /tmp/tmp.sql #データベースにログインして、データが復元されたかどうかを確認します。誤って変更されたデータが復元されたかどうかを確認し、テーブルのロックを解除してデータを再度準備することができます。mysql> UNLOCK TABLES; (2)マスタースレーブアーキテクチャのデータ復旧例 環境 メインデータベース: 192.168.199.10 (node01) まず、スレーブ データベースの SQL スレッドを停止し、スレーブ データベース上のすべてのデータをバックアップして、バックアップ ファイルに「SHOW SLAVE STATUS」情報を入力します。「SHOW SLAVE STATUS」の出力情報には、マスター データベースへの現在のアプリケーションの情報が記録されます。 #スレーブ データベースにログインし、SQL スレッドをシャットダウンします。mysql> STOP SLAVE SQL_THREAD; クエリは正常、影響を受けた行は 0 行 (0.01 秒) #次に、現在スレーブライブラリに適用されているマスターライブラリのバイナリログファイル情報を記録します [root@node02 mysql_data]# mysql -e "SHOW SLAVE STATUS \G" > slave_`date +%F`.info [root@node02 mysql_data]# mysqldump -uroot -proot -h127.0.0.1 -P3306 --databases test_db --routines --triggers --single-transaction > /tmp/mysql_test_db_`date +%F`.sql スレーブでバックアップが完了したら、スレーブの SQL スレッドを再起動します。 mysql> スレーブ SQL_THREAD を開始します。 クエリは正常、影響を受けた行は 0 行 (0.01 秒) SQL スレッドが開始されると、バックアップ期間中のマスター データベース上の DML 操作がスレーブ データベースに再同期されます。マスターデータベースでエラーが発生し、条件を追加せずに学生テーブルのすべてのデータを更新すると、テーブル内のすべてのデータが変更されます。このとき、同期操作により、スレーブデータベースも変更されます。 # メイン データベースにログインし、データベースの外部ユーザーを一時的にサービスを提供しないように変更してから、ログをロールします。 mysql> UPDATE mysql.user SET Host = '127.0.0.1' WHERE User='tomcat'; クエリは正常、1 行が影響を受けました (0.00 秒) #権限テーブルを更新しますmysql> FLUSH PRIVILEGES; クエリは正常、影響を受けた行は 0 行 (0.00 秒) #ローリング logmysql> FLUSH LOGS; クエリは正常、影響を受けた行は 0 行 (0.01 秒) #スレーブデータベースのバックアップデータとバックアップ時のスレーブデータベースのスレーブ情報をマスターデータベース [root@node02 mysql_data] に転送します# scp /tmp/mysql_test_db_2018-06-24.sql 192.168.199.10:/root/ [root@node02 mysql_data]# scp スレーブ_2018-06-24.info node01:/root/ マスターライブラリのデータディレクトリとバイナリログファイルディレクトリをバックアップします [root@node01 mysql_logs]# tar zcvf mysql_master_data.tar.gz /mysql_data/* [root@node01 mysql_logs]# tar zcvf mysql_logs.tar.gz /mysql_logs/* データベースの最新のバックアップからデータをインポートする [root@node01 mysql_logs]# mysql -uroot -proot -h127.0.0.1 -P3306 < /root/mysql_test_db_2018-03-26.sql #注: 上記の操作ではメイン データベースのテーブルをロックできません。そうしないと、完全バックアップ データをインポートできません。 バックアップ時にスレーブデータベースから適用されたマスターデータベースのバイナリログファイル名と場所を表示します。 [root@node01 mysql_logs]# cat /root/slave_2018-03-26.info Master_Log_File: master-bin.000002 #バックアップ中に適用されるマスターバイナリログファイルの名前 Read_Master_Log_Pos: 395 #バックアップ中に適用されるマスターバイナリログファイルの場所 このログ ファイルとログ ポイントから開始して、ログ ポイント 395 以降のログ ファイルを SQL スクリプトに変換します。バイナリ ログ ファイルが複数ある場合は、次に示すように、それらを同時に SQL スクリプトに変換できます。 [root@node01 mysql_logs]# mysqlbinlog /mysql_logs/master-bin.000002 --start-position=395 > /tmp/tmp.sql #master-bin.000003、master-bin.000004、master-bin.000005 を /tmp.sql ファイルにマージします [root@node01 mysql_logs]# mysqlbinlog /mysql_logs/master-bin.00000{3,4,5} --start-position=395 > /tmp/tmp.sql 間違った更新ステートメントを見つけて削除し、増分SQLスクリプトをデータベースにインポートします。 [root@node01 mysql_logs]# vim /tmp/tmp.sql `test_db`/*!*/ を使用します。 学生セット名を 'admin' に更新します #この文を削除します [root@node01 mysql_logs]# mysql -uroot -proot -h127.0.0.1 -P3306 < /tmp/tmp.sql データベースにログインして、データが正常かどうか、誤って変更されたデータが復元されているかどうかを確認します。復元されている場合は、マスターデータベースのデータをバックアップし、スレーブデータベースに転送して、スレーブデータベースのリカバリを完了します。 [root@node01 mysql_data]# mysqldump -uroot -proot -h127.0.0.1 -P3306 --databases test_db --routines --triggers --single-transaction --master-date=1 > /tmp/master_test_db_`date +%F`.sql [root@node01 mysql_data]# scp /tmp/master_test_db_2018-06-24.sql node01:/root/ #スレーブ データベースが読み取り専用に設定されている場合、最初に読み取り専用制限を削除する必要があります。mysql> SET GLOBAL read_only = OFF; クエリは正常、影響を受けた行は 0 行 (0.00 秒) #データベース [root@node02 mysql_logs] からデータをインポートします。# mysql -uroot -proot -h127.0.0.1 -P3306 < /root/master_test_db_2018-06-24.sql # 読み取り専用スレーブを有効にする mysql> SET GLOBAL read_only = ON; クエリは正常、影響を受けた行は 0 行 (0.00 秒) マスター データベースにバックアップするときに --master-date=1 パラメータが追加されたため、データベースからインポートした後にマスター変更操作を再実行する必要はありません。 スレーブデータベースにログインし、SHOW SLAVE STATUS 情報が正常かどうかを確認します。正常であれば、マスターデータベースにログインし、再度認証テーブルを変更してから、外部にサービスを提供します。 mysql> UPDATE mysql.user で Host = '192.168.0.%' を設定し、 User = 'tomcat' とします。 mysql> 権限をフラッシュします。 クエリは正常、影響を受けた行は 0 行 (0.00 秒) 実行が完了すると、マスタースレーブデータが復元されます。 ここまでで、データ復旧の紹介は完了です。上記では、フルバックアップとバイナリログを使用した、シングルインスタンスデータベースとマスタースレーブデータベースのデータ復旧プロセスを紹介しました。ご質問がある場合は、コメントしてご指摘ください。皆様も123WORDPRESS.COMを応援して頂ければ幸いです。 以下もご興味があるかもしれません:
|
<<: PHP+nginx サービス 500 502 エラーのトラブルシューティングのアイデアの詳細な説明
HTMLでCSSを定義するには、埋め込み、リンク、インラインの3つの方法が一般的に使用されます。 1...
最近、会社で DELL R730 サーバーを購入したのですが、偶然次のチュートリアルを見つけたので、...
コードをコピーコードは次のとおりです。 <span style="font-fami...
ブラウザの互換性は、実際の開発では見落とされがちな最も重要な部分です。古いバージョンのブラウザの互換...
導入コンパイル、インストール、問題の解決後、Nginx は正常に動作していますが、現時点では Ngi...
1. ブリッジ: デフォルトでは VMnet0 が使用されます1. 原則:ブリッジは、それぞれ 2...
mysql5.6.28のインストールと設定方法1. 基本的なシステム情報を確認し、yumでインストー...
序文プロジェクトのリリースでは、常に特定の状況に応じたパッケージ化が必要です。Angular CLI...
目次1. 関数の定義1.1 JavaScript の関数1.2 TypeScriptの関数2. オプ...
参照: https://www.jb51.net/article/112612.htmシステム内のJ...
目次1. Jquery を使用する手順: (1)jsライブラリをインポートする(2)ページ読み込みイ...
序文プロジェクトのニーズにより、ストレージ フィールドは JSON 形式で保存されます。プロジェクト...
目次1. Dockerをインストールする2. コードを書く3. Dockerfileを書く4. 画像...
目次1. ChildNodes属性のトラバーサル2. 要素シリーズ属性のトラバーサル以前は、chil...
この記事では、MySQL 8.0.12のインストールチュートリアルを参考までに紹介します。具体的な内...