ホームページ  >  記事  >  データベース  >  mysqlデータベースを誤って削除した後のデータ回復操作に関するサンプルコードの共有

mysqlデータベースを誤って削除した後のデータ回復操作に関するサンプルコードの共有

黄舟
黄舟オリジナル
2017-03-27 13:15:291363ブラウズ

次のエディターは、mysqlデータベースを誤って削除した後のデータ回復操作手順に関する記事を提供します。編集者はこれがとても良いものだと思ったので、皆さんの参考として今から共有します。編集者をフォローして見てみましょう

日常の運用と保守作業において、mysql データベースのバックアップは非常に重要です。 Web サイトにとってデータベースは重要であるため、mysql データの管理に失敗することはあり得ません。
それでは、人は必ず間違いを犯すでしょう。いつか脳がショートして、データベースを削除するという間違いを犯すでしょう。 ? ?

以下は、MySQL データベースを誤って削除した場合の復旧計画の説明です。

1. 作業シナリオ

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

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

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

3. 例

-- ---
まず、mysql で binlog ロギング機能が有効になっていることを確認します /etc/my.cnf ファイルに [mysqld] ブロックを追加します:
log-bin=mysql-bin
次に、mysql サービスを再起動します
- --------------------------------------

(1) ops ライブラリの下にtable customer

mysql> use ops;
mysql> create table customers(
-> id int not null auto_increment,
-> name char(20) not null,
-> age int not null,
-> primary key(id)
-> )engine=InnoDB;
Query OK, 0 rows affected (0.09 sec)

mysql> show tables;
+---------------+
| Tables_in_ops |
+---------------+
| customers |
+---------------+
1 row in set (0.00 sec)

mysql> desc customers;
+-------+----------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | char(20) | NO | | NULL | |
| age | int(11) | NO | | NULL | |
+-------+----------+------+-----+---------+----------------+
3 rows in set (0.02 sec)

mysql> insert into customers values(1,"wangbo","24");
Query OK, 1 row affected (0.06 sec)

mysql> insert into customers values(2,"guohui","22");
Query OK, 1 row affected (0.06 sec)

mysql> insert into customers values(3,"zhangheng","27");
Query OK, 1 row affected (0.09 sec)

mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 24 |
| 2 | guohui | 22 |
| 3 | zhangheng | 27 |
+----+-----------+-----+
3 rows in set (0.00 sec)

(2) 次に、完全バックアップを実行します

[root@vm-002 ~]# mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/opt/backup/ops_$(date +%F).sql.gz
Enter password: 
[root@vm-002 ~]# ls /opt/backup/ops_2016-09-25.sql.gz
-----------------

パラメータの説明:

-B: データベースを指定します

-F: ログを更新します
-R: バックアップ
ストレージプロセスetc-x: ロックテーブル
--master-data: CHANGE MASTER ステートメントとバイナリログファイルと場所情報をバックアップステートメントに追加します
-----------------

(3) もう一度データを挿入します

mysql> insert into customers values(4,"liupeng","21");
Query OK, 1 row affected (0.06 sec)

mysql> insert into customers values(5,"xiaoda","31");
Query OK, 1 row affected (0.07 sec)

mysql> insert into customers values(6,"fuaiai","26");
Query OK, 1 row affected (0.06 sec)

mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 24 |
| 2 | guohui | 22 |
| 3 | zhangheng | 27 |
| 4 | liupeng | 21 |
| 5 | xiaoda | 31 |
| 6 | fuaiai | 26 |
+----+-----------+-----+
6 rows in set (0.00 sec)

(4) このとき、テストデータベースは誤って削除されていました binlog で、復元する必要があります!


(5)

新しく表示完全バックアップ後に追加された binlog ファイルです

mysql> drop database ops;
Query OK, 1 row affected (0.04 sec)
これは完全バックアップ時の binlog ファイルの場所ですつまり、 mysql-bin.000002 の 106 行目なので、このファイルより前の binlog ファイル内のデータはすでに含まれていますこの完全な SQL ファイル内 (6) binlog ファイルを移動して SQL ファイルとしてエクスポートし、その中の Drop ステートメントを削除します


以下に示すように、Mysql データ ストレージ ディレクトリは /var/lib/ の下にあります。 mysql

[root@vm-002 ~]# cd /opt/backup/
[root@vm-002 backup]# ls
ops_2016-09-25.sql.gz
[root@vm-002 backup]# gzip -d ops_2016-09-25.sql.gz 
[root@vm-002 backup]# ls
ops_2016-09-25.sql
[root@vm-002 backup]# grep CHANGE ops_2016-09-25.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=106;

binlog ファイルを SQL ファイルにエクスポートし、vim で編集して、その中の Drop ステートメントを削除します

[root@vm-002 backup]# ps -ef|grep mysql
root 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 backup]# 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 test
[root@vm-002 mysql]# cp mysql-bin.000002 /opt/backup/

注:

binlog ファイルは、事前に移動する必要があります完全なデータを復元します。そうしないと、回復プロセス中にステートメントがバイナリログに書き込まれ続け、最終的に増分回復データ部分が混乱を引き起こします

(7) データの回復

[root@vm-002 backup]# mysqlbinlog -d ops mysql-bin.000002 >002bin.sql
[root@vm-002 backup]# ls
002bin.sql mysql-bin.000002 ops_2016-09-25.sql
[root@vm-002 backup]# vim 002bin.sql #删除里面的drop语句

データベースをチェックして、 ops ライブラリはそこにあります

[root@vm-002 backup]# mysql -uroot -p < ops_2016-09-25.sql 
Enter password: 
[root@vm-002 backup]#
この時点で完全バックアップ時のデータが復元されます

その後、002bin.sql ファイルを使用して、完全バックアップ時からデータベースの削除までの間に新しいデータを復元します

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| ops |
| test |
+--------------------+
4 rows in set (0.00 sec)

mysql> use ops;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 0 |
| 2 | guohui | 0 |
| 3 | zhangheng | 0 |
+----+-----------+-----+
3 rows in set (0.00 sec)

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

[root@vm-002 backup]# mysql -uroot -p ops <002bin.sql
Enter password: 
[root@vm-002 backup]#

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

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

最後に、いくつかのポイントをまとめてみましょう:


1) このケースは、人間の SQL ステートメントまたはマスター/スレーブ レプリケーションを使用しないホット スタンバイのダウンタイムによって引き起こされた誤操作を修復するのに適しています

2) 回復条件は、mysql が binlog ログ機能を有効にする必要があり、すべてのデータが完全に準備され、増分されている必要があります

3) 回復するときは、外部更新を停止することをお勧めします。つまり、データベースの更新は禁止されます

4) 最初にフルボリュームを復元し、次に完全バックアップ時点以降の増分ログが SQL ファイルに順番に復元され、その後ファイル内の問題のある SQL ステートメントが削除されます (時刻と場所のポイントも使用できます) ) を実行し、データベースに復元します。

以上がmysqlデータベースを誤って削除した後のデータ回復操作に関するサンプルコードの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。