原因：
公司由于正在发展期，服务器上线业务上线，因为我是安全运维，从安全考虑我把线上mysql数据库的权限收回，因为以前权限太大。
删除掉root，还有一个账号的所有权限%，我们都知道%代表任意地址登录，如果被黑，可以得到数据库密码然后破解服务器密码然后可以任意乱搞，为了安全着想，所以我设置了iptables和ssh权限。
/etc/hosts.allow
sshd:*.*.*.*:allow //只允许公司ip SSH登录
/etc/hosts.deny
sshd ：ALL //拒绝所有SSH登录
然后通过vpn连接公司内网在跳转到内部服务器 然后在ssh外网服务器
Connecting to 192.168.1.21:22...
Connection established.
To escape to local shell, press ‘Ctrl+Alt+]‘.
Last login: Tue Mar 15 09:27:02 2016 from 192.168.1.158
[[email protected] ~]# ssh 外网服务器
[email protected]外网服务器‘s password:
Last login: Thu Mar 17 16:52:38 2016 from 公司地址
这样本来是没问题的，但是研发开发的mysql存储过程是w这个用户，然后用的是%这个任意地址访问。
而且权限是all，这样就报错了。并且我处理mysql权限的时候没有及时跟研发沟通，尚自做主删除了%的权限。
然后半夜 客户提现的时候，都报错所有人多提现了。
处理方式：
首先我调整了系统时间，让所有用户无法提现
date -s 03/17/2016
date -s 23:30:00
然后创建用户w用户all权限，先让其正常使用
因为做了计划任务自动备份mysql
2016-03-17_23-40-01
然后做过主从，对比备份数据和线上数据
然后还原数据
然后调回系统时间
ntpdate time.nist.gov
刷新redis缓存
flushall
教训：
擅做主张：因为运维部门就我一个人，上面是研发部经理，没有及时跟研发部经理沟通删除权限用户造成事故。
没有及时沟通：如果删除前，在讨论组里跟研发部门开发存储过程的同事沟通，及时更改存储过程用户，删除后就不会造成这个影响。
经过这次事故后，以后做任务操作要跟领导说下，然后跟研发部沟通下，尽管如果没有他们的事，也可以沟通做了什么操作及时记录，还好及时补救，做了数据库备份，主从等操作。还原回去，现在数据正常。但是这个锅我还是要背的。毕竟是我自己的错，有错就认，及时更改。以后不犯。