2014年12月13，接到用户的投诉说电子商场第一次登录，需要修改密码才能登录。一听到这个脑大了，该从哪里排查呢：
1、肯定是查看网站访问日志，access.log没发现有问题。
2、用户登录不了，那肯定是login站点，查看这个站点的日志发现大部分信息都是线上连接数据库失败。(说明：因为我这里线上还原刚开始的时候只有一台主库，后来建了主从同步，但是一直没有用从库。看到这个报错首先我就切换去从库查看从库状态）
3、发现从库上面有一条报错大致意思是：update salt=‘o‘ and password="xxx",怎么会有这个操作。
4、问开发是谁执行了这条语句，后来有人反应说是今天他操作了这条。发现语句出错之后立刻停止，我的第一反应是直接跳过这个事物，应该就可以恢复了，但是后来才发现，我们是主从库，我们连的是主库。
5、又没头绪了，问一下开发salt是什么意思，说是一个生存的密钥严重，用户注册的密码就自动生成了这个。
6、试着统计一下salt这个看看有多少条，select count(*) where salt=‘0‘ from XX。一下出现了7万多条，也就是说这么多个用户现在密码是登录不了，只能修改密码重新生成密钥。
7、跟领导请示是要商家一个一个修改密码不管了，还是要回原来的数据，领导说由于数量大尽量要前面的数据，今天修改或者新注册的用户就不用管了。
8、接下来就是思考如何恢复了，我这里是定时任务是每天凌晨3点钟开始备份数据库。和表。
方案一：
停库操作：
因为数据量不是很大，可以停掉数据库，然后吧凌晨3点钟的数据全部恢复。然后根据二进制日志文件，恢复在程序员操作之前的时间点。预计2个小时内完成。
方案二：
不停库操作:
先把，凌晨3点的备份的表导入到另一个库。然后通过update的方式，salt=0的操作全部用原来的数据来今天替换。条件是id相等的情况下。
9：领导说不能停库的。而且要及时完成不能等到今天晚上，好吧只能通过第二种方式，叫来数据库的开发人员执行mysql语句。大致是 update databases1.table1,databases2,table2 set salt=salt where databases1.id=databases2.id
10:执行成功之后认证没有问题，收工。
#过程当中遇到了许许多多问题，慢慢一步一步走，因为我数据库预计需要待加强，后面的语句是开发人员帮助完成的。小小的纪录一下，以后慢慢学习。