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 に MySQL と Redis をインストールする方法

この記事はCentOS 7.3システム環境をベースに、MySQLとRedisのインストールと使用につ...

Javascript での JSBridge に関する予備的研究

目次JSBridgeの起源JSBridgeの双方向通信原理JSはネイティブを呼び出すネイティブコール...

JavaScript を使用してソートアルゴリズムを実装する方法

目次バブルソート選択ソート挿入ソート要約するバブルソートバブルソートは、シーケンスの右側から始めて、...

Linux システムで Java 環境変数を設定する方法

Java環境変数を設定するここで、環境変数は etc/profile に設定され、つまり、すべてのユ...

CentOS7でパーティションのサイズを変更する方法

昨日、ある人のシステムのインストールを手伝ったのですが、自動パーティション分割をクリックするのを忘れ...

MySQL 学習のまとめ: InnoDB ストレージ エンジンのアーキテクチャ設計の予備的な理解

1. ストレージエンジン前のセクションでは、SQL 実行プランは、エグゼキュータ コンポーネントがス...

Dockerコンテナのネットワークポート設定プロセスの詳細な説明

ネットワークポートの公開実際、Docker にはネットワーク ポートの公開に関わる 2 つのパラメー...

MySQL テーブル全体の暗号化ソリューション keyring_file の詳細な説明

例示するMySql Community Edition は、5.7.11 以降、テーブルベースのデー...

JSはシンプルなカウンターを実装します

HTML CSS および JavaScript を使用して、プラス、マイナス、ゼロの 3 つのボタン...

MySQL 5.7 でパスワードを変更するときに発生する ERROR 1054 (42S22) の解決方法

MySQL 5.7 を新しくインストールしました。ログインすると、パスワードが間違っているというメッ...

Vueコンポーネントの再利用と拡張の詳細な説明

目次概要延長は必要ですか?スロットJavaScript ユーティリティ関数拡張コンポーネントの複数の...

メタタグを簡単に説明すると

META タグは、一般的に タグと呼ばれ、HTML Web ページのソース コード内の重要な HTM...

Tomcat で複数の war パッケージを展開する方法と手順

1 背景JDK1.8-u181とTomcat8.5.53がインストールされました。インストール後、環...

Linux システムのパフォーマンスを分析するための top コマンドの詳細な説明

Linux topコマンドの紹介top コマンドは、Linux でよく使用されるパフォーマンス分析ツ...

ネイティブjsは9マスグリッドのドラッグアンドドロップを実現します

ネイティブJSを使用して9つの正方形のグリッドを記述し、9つのグリッドの位置をドラッグして変更する効...