MySQL 手動リカバリデータベーステスト操作

1. イベントの背景

MySQL データベースは、毎日 0:00 に自動的に完全にバックアップされます
。ある日の午前 9:00 に、Ergouzi は誤ってデータベースを削除しました。
完全にバックアップされたデータファイルと増分 binlog ファイルを通じてデータを復元する必要があります。

2. 主な考え方と原則

1. 完全に準備された SQL ファイル、binlog ファイル、およびそのロケーションポイント情報に記録されている CHANGE MASTER ステートメントを使用して、binlog ファイルの増分部分を見つけます。

2. mysqlbinlog コマンドを使用して、上記の binlog ファイルを SQL ファイルとしてエクスポートし、その中の Drop ステートメントを削除します。

3. 完全バックアップファイルと増分binlogファイルのSQLファイルをエクスポートすることで、完全なデータを復元できます。

3. プロセスの概略図

ここに画像の説明を挿入

4. 運用プロセス

Linux コンソールにコマンドを直接入力するだけです。データベースにログインした後に mysqldump コマンドを入力しないでください。

[root@Server db]# mysqldump -u用户名 -p 数据库名 > 数据库名.sql

シミュレートされたデータ

CREATE TABLE `student` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` char(20) NOT NULL,
  `age` tinyint(2) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8

mysql> insert student values(1,'zhangsan',20); 
mysql> insert student values(2,'lisi',21); 
mysql> insert student values(3,'wangwu',22);

完全なコマンド

mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz`

パラメータの説明:

-B 指定数据库
-F 刷新日志
-R 备份存储过程等
-x 锁表
--master-data 在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息

データの挿入とデータベースの削除を続行します

mysql> insert student values(4,'xiaoming',20);
mysql> insert student values(5,'xiaohong',20);

データ挿入時に誤操作をシミュレートし、テストデータベースを削除します。

mysql> drop database test;

現時点では、完全バックアップの時点から誤操作の瞬間までの間に、ユーザーが書き込んだデータがバイナリログに保存されているため、復元する必要があります。
完全バックアップ後に新しく追加された binlog ファイルを表示する

cd /server/backup/

ls

test_2020-08-19.sql.gz

 gzip -d test_2020-08-19.sql.gz

grep CHANGE test_2020-08-19.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

これは完全バックアップ時の binlog ファイルの場所、つまり mysql-bin.000003 の 107 行目なので、このファイルより前の binlog ファイル内のデータは、この完全バックアップ SQL ファイルに含まれています。ファイルを作成して
SQL を読み取り、drop ステートメントを削除します

cp /data/3306/mysql-bin.000003 /server/backup/

mysqlbinlog -d test mysql-bin.000003 >mysql-bin.000003.sql

次に、vim を使用して mysql-bin.000003.sql ファイルを編集し、drop ステートメントを削除します。

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

mysql -uroot -p < test_2020-08-19.sql 
mysql -uroot -p -e "select * from test.student;"

±—±--------±----+
| id | 名前 | 年齢 |
±—±---------±----+
| 1 | zhangsan | 20 |
| 2 | リシ | 21 |
| 3 | ワンウー | 22 |
±—±---------±----+

このとき、完全バックアップ時のデータが復元され、その後、完全バックアップ時からデータベースの削除までの間に、mysql-bin.000003.sql ファイルを使用して新しいデータが復元されます。

mysql -uroot -p test < mysql-bin.000003.sql 
mysql -uroot -p -e "select * from test.student;"

±—±--------±----+
| id | 名前 | 年齢 |
±—±---------±----+
| 1 | zhangsan | 20 |
2 | リシ | 20 |
| 3 | ワンウー | 20 |
| 4 | シャオミン | 20 |
| 5 | シャオホン | 20 |
±—±---------±----+

この時点で、回復プロセス全体が完了しました。非常に簡単ではありませんか? そうです、それはとても簡単です！！

V. まとめ

1. 人為的なSQL文による誤動作やマスタースレーブレプリケーションなどのホットバックアップがない場合の修復に適しています。
2. 回復条件は、すべてのデータに対して完全に準備され、増分される必要があります。
3. リストア時には外部更新を停止する、つまりデータベースの更新を禁止することをお勧めします。
4. 最初に全量を復元し、次に完全バックアップ時点以降の増分ログを SQL ファイルに順番に復元します。次に、ファイル内で問題のある SQL ステートメントを削除し (時刻と場所のポイントを使用することもできます)、次に次の場所に復元します。データベース。

無事に回復されましたことおめでとうございます!