MySQLデータベースを誤って削除した後にデータを回復するための手順

MySQLデータベースを誤って削除した後にデータを回復するための手順

日々の運用・保守作業において、MySQL データベースのバックアップは重要です。ウェブサイトにとってデータベースは重要なので、MySQL データを間違いなく管理する必要があります。
そうなると、人間はミスを犯すのは避けられません。ある日、脳がショートしてデータベースが誤って削除されてしまったらどうなるでしょうか。どうすればいいのでしょうか。 ? ?

次に、MySQL データベースが誤って削除された場合の復旧計画について説明します。

1. 作業シナリオ

(1)MySQLデータベースは毎晩12:00に自動的に完全バックアップされます。
(2)ある朝、仕事中の9時に同僚が気を失い、データベースを落としてしまいました!
(3)緊急復旧が必要です!バックアップされたデータ ファイルと増分 binlog ファイルは、データの回復に使用できます。

2. データ復旧のアイデア

(1)完全なSQLファイルに記録されたCHANGE MASTER文、binlogファイルとその位置情報を使用して、binlogファイル内の増分部分を見つけます。
(2)mysqlbinlogコマンドを使用して、上記のbinlogファイルをsqlファイルにエクスポートし、dropステートメントを削除します
(3)フルバックアップファイルと増分バイナリログファイルのSQLファイルをエクスポートすることで、完全なデータを復元することができます。

3. 例

----------------------------------------
まず、 MySQL で binlog が有効になっていることを確認します。
/etc/my.cnf ファイルの [mysqld] セクションに以下を追加します。
ログ bin = mysql bin
次に、mysqlサービスを再起動します。
----------------------------------------

(1)opsデータベースの下にcustomersテーブルを作成する

mysql> ops を使用します。
mysql> テーブル customers( を作成
-> id int not null auto_increment、
-> 名前 char(20) が null ではない、
-> 年齢 int が null ではない、
-> 主キー(ID)
->)エンジン=InnoDB;
クエリは正常、影響を受けた行は 0 行 (0.09 秒)

mysql> テーブルを表示します。
+---------------+
| テーブル_in_ops |
+---------------+
| 顧客 |
+---------------+
セット内の 1 行 (0.00 秒)

mysql> desc 顧客;
+-------+----------+------+-----+---------+----------------+
| フィールド | タイプ | Null | キー | デフォルト | 追加 |
+-------+----------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | 自動増分 |
| 名前 | char(20) | NO | | NULL | |
| 年齢 | int(11) | NO | | NULL | |
+-------+----------+------+-----+---------+----------------+
セット内の3行(0.02秒)

mysql> customers に値 (1、"wangbo"、"24") を挿入します。
クエリは正常、1 行が影響を受けました (0.06 秒)

mysql> customers の値に (2、"guohui"、"22") を挿入します。
クエリは正常、1 行が影響を受けました (0.06 秒)

mysql> customers の値に挿入します (3、"zhangheng"、"27")。
クエリは正常、1 行が影響を受けました (0.09 秒)

mysql> customers から * を選択します。
+----+-----------+-----+
| ID | 名前 | 年齢 |
+----+-----------+-----+
| 1 | 王波 | 24 |
| 2 | 国慧 | 22 |
| 3 | 張衡 | 27 |
+----+-----------+-----+
セット内の 3 行 (0.00 秒)

(2)今すぐフルバックアップを実行する

[root@vm-002 ~]# mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/opt/backup/ops_$(日付 +%F).sql.gz
パスワードを入力してください:
[root@vm-002 ~]# ls /opt/backup/
ops_2016-09-25.sql.gz

-----------------

パラメータの説明:

-B: データベースを指定する
-F: ログを更新
-R: バックアップ保存処理など
-x: テーブルをロック
--master-data: CHANGE MASTER ステートメントと binlog ファイルおよび場所の情報をバックアップ ステートメントに追加します。
-----------------

(3)再度データを挿入する

mysql> customers の値に挿入します (4、liupeng、21)。
クエリは正常、1 行が影響を受けました (0.06 秒)

mysql> customers の値に挿入します (5、"xiaoda"、"31");
クエリは正常、1 行が影響を受けました (0.07 秒)

mysql> customers に値 (6、fuaiai、26) を挿入します。
クエリは正常、1 行が影響を受けました (0.06 秒)

mysql> customers から * を選択します。
+----+-----------+-----+
| ID | 名前 | 年齢 |
+----+-----------+-----+
| 1 | 王波 | 24 |
| 2 | 国慧 | 22 |
| 3 | 張衡 | 27 |
| 4 | liupeng | 21 |
| 5 | シャオダ | 31 |
| 6 | ふあいあい | 26 |
+----+-----------+-----+
セット内の 6 行 (0.00 秒)

(4)誤ってテストデータベースが削除されました。

mysql> データベース操作を削除します。
クエリは正常、1 行が影響を受けました (0.04 秒)

このとき、フルバックアップ時からエラー操作時までの間に、ユーザーが書き込んだデータはバイナリログに残っており、復元する必要があります。

(5)フルバックアップ後に新しく追加されたbinlogファイルを表示する

[root@vm-002 ~]# cd /opt/backup/
[root@vm-002 バックアップ]# ls
ops_2016-09-25.sql.gz
[root@vm-002 バックアップ]# gzip -d ops_2016-09-25.sql.gz 
[root@vm-002 バックアップ]# ls
ops_2016-09-25.sql
[root@vm-002 バックアップ]# grep CHANGE ops_2016-09-25.sql 
-- MASTER を MASTER_LOG_FILE='mysql-bin.000002'、MASTER_LOG_POS=106 に変更します。

これは、完全な準備時の binlog ファイルの場所、つまり mysql-bin.000002 の 106 行目です。したがって、このファイルの前の binlog ファイル内のデータは、この完全な sql ファイルにすでに含まれています。

(6)binlogファイルを移動し、dropステートメントを削除してsqlファイルとしてエクスポートします。

mysqlデータ保存ディレクトリを確認すると、/var/lib/mysqlにあることがわかります。

[root@vm-002 バックアップ]# ps -ef|grep mysql
ルート 9272 1 0 01:43 pts/1 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 9377 9272 0 01:43 pts/1 00:00:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[root@vm-002 バックアップ]# cd /var/lib/mysql/
[root@vm-002 mysql]# ls
ibdata1 ib_logfile0 ib_logfile1 mysql mysql-bin.000001 mysql-bin.000002 mysql-bin.index mysql.sock テスト
[root@vm-002 mysql]# cp mysql-bin.000002 /opt/backup/

binlogファイルをsqlファイルにエクスポートし、vimで編集してdropステートメントを削除します。

[root@vm-002 バックアップ]# mysqlbinlog -d ops mysql-bin.000002 >002bin.sql
[root@vm-002 バックアップ]# ls
002bin.sql mysql-bin.000002 ops_2016-09-25.sql
[root@vm-002 backup]# vim 002bin.sql #内部のdrop文を削除

知らせ:

完全バックアップ データを復元する前に、binlog ファイルを削除する必要があります。削除しないと、リカバリ プロセス中にステートメントが binlog に書き込まれ続け、最終的に増分リカバリ データが混乱する原因になります。

(7)データの回復

[root@vm-002 バックアップ]# mysql -uroot -p < ops_2016-09-25.sql
パスワードを入力してください:
[root@vm-002 バックアップ]#

データベースをチェックして、opsライブラリが存在するかどうかを確認します。

mysql> データベースを表示します。
+--------------------+
| データベース |
+--------------------+
| 情報スキーマ |
|mysql |
| オペレーション |
| テスト |
+--------------------+
セット内の 4 行 (0.00 秒)

mysql> ops を使用します。
テーブル名と列名の補完のためのテーブル情報の読み取り
-Aでこの機能をオフにすると起動が速くなります。

データベースが変更されました
mysql> customers から * を選択します。
+----+-----------+-----+
| ID | 名前 | 年齢 |
+----+-----------+-----+
| 1 | 王波 | 0 |
| 2 | guohui | 0 |
| 3 | 張衡 | 0 |
+----+-----------+-----+
セット内の 3 行 (0.00 秒)

この時点で、完全復旧時のデータが復元されました

次に、002bin.sql ファイルを使用して、完全な準備時からデータベースの削除時までの間に新しく追加されたデータを復元します。

[root@vm-002 バックアップ]# mysql -uroot -p ops <002bin.sql
パスワードを入力してください:
[root@vm-002 バックアップ]#

再度データベースを確認すると、フルバックアップからデータベースの削除までの間のデータも復元されていることがわかりました。 !

mysql> customers から * を選択します。
+----+-----------+-----+
| ID | 名前 | 年齢 |
+----+-----------+-----+
| 1 | 王波 | 24 |
| 2 | 国慧 | 22 |
| 3 | 張衡 | 27 |
| 4 | liupeng | 21 |
| 5 | シャオダ | 31 |
| 6 | ふあいあい | 26 |
+----+-----------+-----+
セット内の 6 行 (0.00 秒)

上記は、MySQL データベースの増分データ復旧のプロセス例です。

**********************************************

最後に、いくつかの点をまとめてみましょう。

1) このケースは、人間の SQL 文による誤った操作によって発生したダウンタイムを修復する場合や、マスタースレーブレプリケーションなどのホットスタンバイがない場合に適用されます。

2) リカバリ条件は、MySQL で binlog 機能を有効にし、すべてのデータを完全形式と増分形式でバックアップする必要があることです。

3) 復元時には、外部更新を停止し、データベースの更新を禁止することをお勧めします。

4) 最初に全量を復元し、次にフルバックアップ時点以降の増分ログを順番に SQL ファイルに復元し、ファイル内の問題のある SQL ステートメントを削除して (時間と場所のポイント別に復元することもできます)、データベースに復元します。

MySQL データベースを誤って削除した後のデータ復旧に関する上記の手順は、編集者があなたと共有するすべての内容です。これが参考になれば幸いです。また、123WORDPRESS.COM をサポートしていただければ幸いです。

以下もご興味があるかもしれません:
  • MySQL バイナリログデータ復旧: 誤ってデータベースを削除した場合の詳細な説明
  • MySQLデータベースの操作とメンテナンスのデータ復旧方法
  • Navicat for MySQLのスケジュールされたデータベースバックアップとデータ復旧の詳細
  • MySQLバイナリログを介してデータベースデータを復元する方法の詳細な説明
  • mysqldump (MySQL データベースのバックアップとリカバリ) の使用方法についての簡単な説明
  • mysql バイナリ ログ ファイル データベースの復元
  • MySQLデータベースのログファイル(binlog)を自動的に復元する方法を説明します
  • 時点別のMySQLデータベース復旧実績

<<:  docker-compose でデプロイしたときに MySQL にアクセスできなくなる問題の簡単な分析

>>:  JSキャンバスは描画ボードと署名ボードの機能を実現します

推薦する

Dockerイメージのローカル移行の実装

最近 Docker を勉強しているのですが、よく問題に遭遇します。Docker イメージをダウンロー...

MySQL マスタースレーブレプリケーション切断の一般的な修復方法

目次01 問題の説明02 ソリューション1. 他のスレーブライブラリを見つけてすぐに置き換える2. ...

docker compose の記述ルールについての簡単な説明

この記事ではクラスタの展開に関連する内容は紹介しませんバージョン制約Docker エンジン >...

JavaScript ステートメントの一般的な for ループの詳細な説明

JavaScript には、for、for in、for of、forEach ループなど、多くのル...

SQL 実践演習: オンライン モール データベース ユーザー情報データ操作

オンラインショッピングモールデータベース - ユーザー情報データ運用プロジェクトの説明電子商取引の台...

HTML 要素の高さ、offsetHeight、clientHeight、scrollTop などの詳細な説明。

要素に関するいくつかの属性フロントエンドの日常的な開発では、一部のページのプロパティを取得または監視...

Vue Element フロントエンドアプリケーション開発のための従来の JS 処理機能

目次1. 従来のコレクションに対するフィルター、マップ、および削減処理方法2. 再帰処理3. for...

HTMLページが3秒後に自動的にジャンプする3つの一般的な方法

実際には、N 秒後にページを自動的にジャンプさせるにはどうすればよいかという問題によく遭遇します。私...

Vue+canvas は、ウォーターフォール チャートを上から下までリアルタイムに更新する効果を実現します (QT と同様)

早速ですが、デモ画像をご紹介します。実装されている機能は、左側に凡例、右側にウォーターフォール チャ...

クリーンで美しいウェブデザインのための4つの原則

この記事では、 Webデザインに関連するこれら4 つの原則について説明します。これら4 つの原則を念...

Ubuntu環境でのPHP関連のパスと変更方法

Ubuntu環境におけるPHP関連パスPHP パス /usr/bin/php phpize5 /us...

Mysql Explainコマンドの使用と分析

mysql explain コマンドは、MySQL がインデックスを使用して選択ステートメントを処理...

SSHトンネルを使用してMySQLサーバーに接続する方法

序文場合によっては、データベースのイントラネット アドレスしか知らず、イントラネット経由で接続できな...

MySQL マスタースレーブレプリケーションと読み取り書き込み分離の詳細な説明

記事マインドマップマスター/スレーブ レプリケーションと読み取り/書き込み分離を使用する理由は何です...

NginxはLua+Redisを使用してIPを動的にブロックします

1. 背景日常的なウェブサイトのメンテナンスでは、このような要件に頻繁に遭遇します。特定のクローラー...