前言:
主从复制做为MySQL的精髓, 它有两大困难:主从数据的延时与数据的不一致性。本文主要表达的内容是如何排查数据不一致性。针对数据不一致的排查处理,各位业界大佬们都有丰富的处理经验,我就不多哔哔。我今天来主要给大家介绍工作中碰到奇葩示例:由于一个极隐式的骚操作,导致从库丢失数据(数据丢失量在每天将近万条记录)!
环境描述:
业务环境:短时间内(几个月的时间),业务蓬勃发展,客户量从一两万一下增加到几十万用户。
数据库环境:如下图
问题描述:
某一天,主库10.0.0.1的CPU使用率突然升高,均值达到80%+,导致keepalived的VIP漂移至从库10.0.0.2。理论上丢失的是切换过程中的几秒钟数据,业务侧对丢失这几秒数据表示没关系。那这个事件到此应该就结束了!
然而,当天晚上,业务打电话过来说:丢失了部分用户信息,导致用户登入不了,已经被客户投诉了,要求帮忙恢复数据并查找数据丢失原因。领导对于这个事也很看重,因为丢失数据,这是一个比较敏感的话题,特别是还被客户投诉了。
数据恢复,这块就不具体深入。稍微提下,这边因为新主10.0.0.2已经有数据写入,只能对比用户表数据把新主少的数据导入进去。