一、確保MySQL開啟了binlog日志功能
在/etc/my.cnf文件里的[mysqld]區塊添加：
#這個是存儲的位置為mysql配置文件的位置
log-bin=mysql-bin
然后重啟mysql服務生效
二、創建數據庫
先創建一個ops數據庫
create database ops;
use ops;
創建一個customers表并寫上表結構
create table customers(
id int not null auto_increment,
name char(20) not null,
age int not null,
primary key(id)
)engine=InnoDB;
查看創建好的表
desc customers;
表中插入數據：
insert into customers values(1,"wangbo","24");
insert into customers values(2,"guohui","22");
insert into customers values(3,"zhangheng","27");
檢查插入數據：
select * from customers;
三、進行數據庫全量備份
mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/alidata/mysql_bakcup/ops_$(date +%F).sql.gz
ls /alidata/mysql_bakup
參數說明：
-B: 指定數據庫
-F：刷新日志
-R：備份存儲過程等
-x：鎖表
--master-data：在備份語句里添加CHANGE MASTER語句以及binlog文件及位置信息
四、再次插入數據
insert into customers values(4,"liupeng","21");
insert into customers values(5,"xiaoda","31");
insert into customers values(6,"fuaiai","26");
查看最新插入的數據
select * from customers；
五、模擬誤操作、刪除ops數據庫
drop database ops;
此時,全備之后到誤操作時刻之間，用戶寫入的數據在binlog中，需要恢復出來！
查看全備之后新增的binlog文件
cd /alidata/mysql_bakcup
#解壓出已經備份好的數據庫
gzip -d ops_2019-04-23.sql.gz
ls
查看數據庫變化的時刻
grep CHANGE ops_2019-04-23.sql
這是全備時候的binlog文件位置 mysql-bin.000006的第106行
因此在該文件之前的binlog文件中的數據都已經包含在這個全備的sql文件中了
移動到binlog文件，并導出sql文件，提出其中的drop語句
查看mysql數據存放目錄，由如下信息可知在/var/lib/mysql目錄下
ps -ef |grep mysql
cd /var/lib/mysql
cp mysql-bin.000006 /alidata/mysql_bakcup/
cd /alidata/mysql_bakcup/
mysqlbinlog mysql-bin.000006 >006bin.sql #即將binlog日志轉化為可正常導入的sql文件
vim 006bin.sql 刪除里面drop語句
注意：在恢復全備數據之前必須將binlog文件移出，否則恢復過程中，會繼續寫入語句到binlog，最終導致增量恢復數據部分變的比較混亂
六、恢復數據
mysql -uroot -p <ops_2019-04-23.sql
查看數據庫，看看ops庫在不在
show databases
use ops；
select * from customers;
#此時恢復了全備時刻時候的數據
接著，使用006bin.sql文件恢復全備時刻到刪除ops數據庫之前，新增的數據
mysql -uroot -p ops <006bin.sql
再次查看數據庫，發現備份到刪除數據庫之前的那部分數據也恢復了！
select * from customers;
以上就是mysql數據庫增量數據恢復的實例過程！
最后總結幾點：
1）本案例適合認為SQL語句造成的誤操作或者沒有主從復制等熱備情況宕機時的修復
2）恢復條件為mysql要開啟binlog日志功能，并且要全備和增量所有數據
3）恢復時建議對外定制更新，即禁止更新數據庫
4）先恢復全量，然后把全備時刻點以后增量日志，按順序恢復成SQL文件，然后把文件中有問題的SQL語句刪除，在恢復到數據庫
