mysql 相减_Mysql主从复制主库崩溃后如何重新指定新主

Mysql一主多从复制主库崩溃后如何提升从库为主库

当主库崩溃后，需要提升一台从库来代替它，这个过程不太容易，如果只有一个备库，可以直接使用这台备库，但如果有超过一台备库，就需要做一些额外的工作。

另外还有潜在的丢失复制事件的问题，可能主库已经发生的修改还没有更新到它的任何一台从库上，甚至还有可能一条语句在主库上执行了回滚，但是在从库上没有回滚。这样备库可能超过主库的逻辑复制位置，如果能在某一点恢复主库数据，也许就可以取得丢失的语句并手动执行它们。

在以下步骤中，需要确保在计算中使用 master_log_file 和 read_master_log_pos 的值，以下是对主备拓扑结构中备份的提升过程

1. 确定那台备库数据最新，检查每台备库上的 show slave stauts 的输出，找出 master_log_file 和 read_master_log_pos最新的那个

2. 让所有备库执行完所有从崩溃钱的旧主库那获取的中继日志，如果在未完成前修改备库的主库，它会完全抛弃剩下的日志事件，从而无法获知该备库从那个地方停止

3. 在新主库上执行stop slave

stop slave;

show slave status;

4. 在新主库上执行 rest slave all，使其断开于老主库的连接，并丢弃master.info里面的记录信息(如果连接信息记录在my.cnf里，会无法正确工作)，这里我们不建议将该信息放到my.cnf中去

reset slave all;

show slave status;

5. 在新主库上 show master status 记录新主库的二进制日志信息

show master status;

6. 比较每台备库和新主库的master_log_file 和 read_master_log_pos值

7. 将客户端连接上新主库恢复程序应用(保证生产环境可以正常运行)

8. 在每台备库上执行 change master to 语句，使用之前新主库上使用 show master status 获取二进制作为，来指向新的主库。

这些操作都是基于在所有备库上都已经设置了 log_bin 和 log_slave_updates, 如果没有设置这两个选项是无法做到这一点的。

确定期望日志的位置

如果备库和新主库的位置不相同，则需要找出最后一条执行的事件在新主库的二级制日志中的位置，然后在使用change master to，可以通过mysqlbinlog工具来找到备库上最后一条执行的命令，然后在主库上查找相同的查询，进行简单的计算即可得到。

为了便于描述，假设每个日志事件有一个自增的数字id，最新的备库，也就是新主库，在旧主库崩溃时获得了编号为100的事件。假设有两个备库 rep2 和 rep3， rep2已经获取了99编号的事件，rep3获取了99编号的事件，如果把两台备库都指向新主库同一个日志位置，他们将从101开始复制，从而导致数据不一致，但是只要新主库的二级制日志已经通过log_slave_updates打开，就可以在新主库的二进制日志中找到99 和100 号日志，从而能将数据恢复到一致状态。

由于服务器重启，不同配置 ，日志轮转 或者 flush logs 等命令，同一个事件在不同的服务器上可能由不同的偏移量，找到这些事件或者中继日志中解析出每台备库的最后一个事件，并使用该命令解析新主库的二级制日志，并找到相同的查询， mybinlog会打印出该事件的偏移量，我们就可以使用该偏移量在change master to 中使用该偏移量。

更快的方法是吧新主库和停止的别克上的字节偏移量相减，就可以得到期望的查询位置，然后只需要验证一下就可以据此启动新的复制。

测试案例演示

一主两个从，在一个测试机上搭建3个mysql实例 端口分别为 3306 3307 3308

，3307 为主库，3306 和3308 为从库

1. 模拟从库位置不统一情况先将从库3308 停止slave

stop slave;

show slave status;

2. 主库3307 上继续插入数据 和删除数据操作

delete from mytest where id =2;

update mytest set myname ='ceshi' where id =4;

insert into mytest(myname) values('m'),('n'),('o');

show master status ;

3. 查询从库3306 和其slave情况

select * from test.mytest;

show slave status;

4. 模拟主库3307 崩溃，将mysql实例2停机

5. 在从库3306 和3308 中读取slave信息获取最新的从库

show slave status;

从上面连个图片中我们确定3306 是最新的日志，我们使用3306为主库

6. 切换3306为主库

show master status;

stop slave;

reset slave all;

show slave status;

set global read_only=0;

show variables like '%read_only%'

这里要确认 log_bin 和 log_slave_updates 之前是开启的，如果之前没有开启则无法保证3308正确同步3306数据，另外我们这里因为提升3306为主库，所以要把 read_only注释掉，允许3306 可写

7. 将客户端指定到3306， 程序等可以正常运行，保证生产恢复

8. 将3308的复制主库指向3306，先确定偏移量

3306 slave日志偏移量为2058 3308slave日志偏移量为 1231 相差为2058-1231=827

新主库3306的master日志偏移量为2022,我们以此向前827步 也就是 2022-827=1195

我们使用 mysqlbinlog去查看3306的主日志mysql3306-bin.000004

mysqlbinlog -vv /data/3306/mysql3306-bin.000004

找到偏移量在1195附近的信息

有个1191 ，这个正是我们需要的偏移节点，我们把它后面的执行的sql打印出来

mysqlbinlog --start-position="1191" -vv /data/3306/mysql3306-bin.000004

注意这里position 一定要写对，必须是日志中有的，如果你写个1190是无法获取需要的内容的

从上面几个截图正好对应我们第2步中在主库3307的操作，所有我们确定使用偏移量1191即可

9. 在3308上设置复制

change master to master_host='10.106.216.182',

master_user='repl',

master_port=3306,

master_password='123456',

master_log_file='mysql3306-bin.000004',

master_log_pos=1191;

start slave;

show slave status;

10. 检查新的主从数据情况

select * from test.mytest

11. 主库上继续操作 并在从库上校验是否正确同步

update test.mytest

set myname='go'

where id=28;

delete from test.mytest

where id in (10,12,14);

主从一致，切换完成。