次のエディターは、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 -----------------
パラメータの説明:
-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)
(5)
mysql> drop database ops;
Query OK, 1 row affected (0.04 sec)
[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;
[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 ファイルは、事前に移動する必要があります完全なデータを復元します。そうしないと、回復プロセス中にステートメントがバイナリログに書き込まれ続け、最終的に増分回復データ部分が混乱を引き起こします
[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语句
[root@vm-002 backup]# mysql -uroot -p < ops_2016-09-25.sql Enter password: [root@vm-002 backup]#
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]#
********************************************** **
最後に、いくつかのポイントをまとめてみましょう:1) このケースは、人間の SQL ステートメントまたはマスター/スレーブ レプリケーションを使用しないホット スタンバイのダウンタイムによって引き起こされた誤操作を修復するのに適しています 2) 回復条件は、mysql が binlog ログ機能を有効にする必要があり、すべてのデータが完全に準備され、増分されている必要があります 3) 回復するときは、外部更新を停止することをお勧めします。つまり、データベースの更新は禁止されます 4) 最初にフルボリュームを復元し、次に完全バックアップ時点以降の増分ログが SQL ファイルに順番に復元され、その後ファイル内の問題のある SQL ステートメントが削除されます (時刻と場所のポイントも使用できます) ) を実行し、データベースに復元します。
以上がmysqlデータベースを誤って削除した後のデータ回復操作に関するサンプルコードの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。