不要删除 /var/lib.mysql！！！ 不要轻易删除mysql-bin.00000X！！！
binlog日志 数据恢复
在系统下进行
查看数据库备份信息--/usr/bin/mysqlbinlog --no-defaults /var/lib/mysql/mysql-bin.000002
恢复数据--/usr/bin/mysqlbinlog --no-defaults /var/lib/mysql/mysql-bin.000002 | mysql (密码有无) demo
1.基于位置恢复（感觉较好）
先查看数据库备份信息：1.在系统下查看，有点凌乱；2.在库中进行查看 show master logs; show master status; 通过binlog日志查看操作记录show binlog events in 'mysql-bin.00000X';
误删的数据，找到要恢复的起始位置，退出数据库，在系统下进行数据恢复
/usr/bin/mysqlbinlog --no-defaults --start-position 378 --stop-position 1125 /var/lib/mysql/mysql-bin.000002 | mysql demo
2..基于时间的恢复（在系统下查看在系统下数据恢复）
/usr/bin/mysqlbinlog --no-defaults --stop-datetime='19-11-23 23:37:18 ' --stop-datetime='19-11-23 23:45:55' /var/lib/mysql/mysql-bin.000002|mysql -u root -p root
3.不完全恢复
利用物理备份或者逻辑备份的基础上，在结合binlog的一种恢复操作
授权
grant all/update.../repalication slave on *.* to tom@'%'/192.168.112.132 identified by '123456';
set default role r1;设置r1为默认角色，下次连接自动开启
set role r1;开启角色
角色创建功能，大大降低了维护用户权限的复杂度
flush privileges;//授权及增删改后记得刷新有效
为什么需要角色
1.在实际工作中，有大量的用户其权限是一样的，比如只读权限。如果每次在创建完用户后，DBA再去对每个用户去分别授权，那会是一件非常麻烦的事情。
2.使用role的好处是DBA只需对权限种类进行划分，然后将不同权限授予不同的role,而不必再去关注到底有哪些具体的用户。
3.当角色权限发生变化时，比如添加成员或者删除成员，系统管理员都无需执行任何关于权限的操作。