当主库发生宕机,从库如何接管主库

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

当主库发生宕机,从库如何接管主库

1、主库崩溃,日志不在情况(会丢数据)

查看从库已经同步到哪了,确定数据丢失的时间范围,确定从库的中继日志是否被SQL_thread进程解析完(即传输过来的中断日志是否在从库上重放完)。

1.1、如何确定数据丢失的时间范围

登录从库服务器,进入mysql数据库,执行以下命令,查看相关的参数:

mysql> show slave status\G                                           

Master_Log_File            表示IO thread读取到的binlog日志文件名

Read_Master_Log_Pos        IOthread读取到的binlog日志文件位置

Relay_Log_File              slave 在本地缓存的relay 日志的文件名

Relay_Log_Pos              slave 在本地缓存的relay 日志的文件位置

Relay_Master_Log_File       SQL thread执行到masterbinlog文件名

Exec_Master_Log_Pos        SQL thread 执行到masterbinlog文件位置

Seconds_Behind_Master       SQL thread相对master的延迟时间(该值理论上显示了备库的延时,但由于各种各样的原因,并不总是准确的)

1)通过Master_Log_File Read_Master_Log_Pos可查看到从库服务器拉取主库服务器日志的文件名与位置。(从库 IO thread进程所做的事)

2)通过Relay_Log_FileRelay_Los_Pos两个值可以得到从库在本地缓存的中继日志文件名与文件位置。

3)通过Relay_Master_Log_FileExec_Master_Log_Pos可以得到从库重放binlog到主库的哪个日志文件哪个位置。(从库 SQL thread进程所做的事)

1.1.1、查看从库同步的位置:

方法一:通过Master_Log_File Read_Master_Log_Pos可以确定从库只同步到主库的哪个日志文件哪个位置上。

方法二:查看master.info

wKioL1YHq3iR6jcqAAC2pQNWHG4449.jpg

1.1.2、查看从库同步的时间:

如果想要知道具体时间,可以查看中继日志

[root@slavemysql]# pwd

/var/lib/mysql

[root@slavemysql]# mysqlbinlog relay-bin.000005

查看内容如下:

wKioL1YHq8zh_mHrAAC6r4u47bM957.jpg

1.2、确定从库的中继日志是否被sql_thread进程解析完

比较Master_Log_FileRelay_Master_Log_File是否相同,比较Read_Master_Log_PosExec_Master_Log_Pos是否相同,如果两者都相同,那么代表解析完,如果有任何一个不一样,要等待sql_thread解析完。

1.3、如果从库之前有配置只读不写操作,还要作相关修改,操作请看下面的第4点。

2、主库崩溃,日志还在情况

关闭从库的io_thread,在主库上插入几条数据,(来模拟主库宕机,日志没有完全同步到从库的情况)。

从库操作:

mysql>stop slave io_thread;

QueryOK, 0 rows affected (0.06 sec)

主库操作,在apex_db库下插入以下数据:

mysql>insertinto apex_tb values(100,'apexdb');

QueryOK, 1 row affected (0.10 sec)

mysql>insert into apex_tb values(101,'apexdb');

QueryOK, 1 row affected (0.00 sec)

mysql>insert into apex_tb values(111,'apexdb');

QueryOK, 1 row affected (0.06 sec)

mysql>insert into apex_tb values(121,'apexdb');

QueryOK, 1 row affected (0.06 sec)

mysql>insert into apex_tb values(131,'apexdb');

QueryOK, 1 row affected (0.06 sec)

2.1、如何判断从库是否与宕机的主库同步了

2.1.1、查看主库的最新日志,通过mysqlbinlog查看

# cd /var/lib/mysql

# mysqlbinlog master-bin.000003

内容如下:

wKiom1YHq-DRhQHtAAH8ar7-07g399.jpg

可以看出主库的最新日志文件名是master-bin.000003,位置是2679

2.1.2、登录从库,查看同步的位置

登录从库服务器,进入mysql数据库,执行以下命令,查看相关的参数:

 mysql> show slave status\G                                  

wKiom1YHrB-DZJesAAHN9Ipa45I523.jpg

从以上参数可以看出,从库不同步。

2.1.3、登录主库,把主库的日志(master-bin.000003master-bin.000004……传送给从库

# scpmaster-bin.000003  192.168.1.133:/tmp/

2.2、同步的情况,如果从库被设置为只读不写操作,要作相应的修改。

具体操作请看下面的第4点。

2.3、不同步的情况,从库操作

cd /tmp

mysqlbinlog--start-position=1530 master-bin.000003 > a.sql

mysql -uroot -papex_db <a.sql

登录数据库查看数据是否同步。

2.4、如果从库之前有配置只读不写操作,还要作相关修改,操作请看下面的第4点。

3、主库存活,从库怎么切换

3.1、查看主从库是否同步

3.1.1主库操作,查看写入日志的位置

wKiom1YHrEGTp6WFAADtSF7yTyE574.jpg

3.1.2从库操作,查看从库同步的位置

 

wKioL1YHrF7THEW5AAFuP141Fjw216.jpg

3.1.13.1.2数据可以看成主库的日志都已经传输到从库。

3.1.3、主库设置为只读操作

flush tableswith read lock;

3.1.4、断开主从库之间复制进程(IO_thread

从库设置:

mysql>stopslave io_thread;

3.1.5、确定从库的中继日志是否被sql_thread进程解析完

比较Master_Log_FileRelay_Master_Log_File是否相同,比较Read_Master_Log_PosExec_Master_Log_Pos是否相同,如果两者都相同,那么代表解析完,如果有任何一个不一样,要等待sql_thread解析完。

3.2、如果从库之前有配置只读不写操作,还要作相关修改,操作请看下面的第4点。

4、如果之前从库是只读不写操作,要进行以下操作:

4.1、使用set命令修改read_only参数的值,并修改从库的配置文件my.cnf,把read_only参数修改为read_only=0参数,实现不管是否有没有重启mysql服务,都能实现从库接管主库,对外提供读写操作。

4.1.1、临时修改法,实现不重启数据库,从库能提供读写

mysql>set global read_only=0;

4.1.2、修改配置文件read_only值为0,实现重启数据库,从库也能提供读写

#vi /usr/my.cnf

read_only=0

#service mysql restart

使用4.1.1与4.1.2实现不管是否有没有重启mysql服务,都能实现从库接管主库,对外提供读写操作。

4.2、授权,给从库授于update,delete,insert权限

#mysql –uroot –p

#grantupdate,delete,insert on *.* to apextest@’%’ identified by ‘123456’;

#flushprivileges;



本文转自 corasql 51CTO博客,原文链接:http://blog.51cto.com/corasql/1698576,如需转载请自行联系原作者

相关文章
举例:在从库上备份,到主库上恢复
在备库上备份,在主库上恢复 control file和recovery catalog的同步
|
NoSQL Redis
Redis哨兵集群主库故障数据恢复
Redis哨兵集群主库故障数据恢复
264 0
Redis哨兵集群主库故障数据恢复
|
SQL 关系型数据库 MySQL
主库挂了,从库谋权篡位的那些事!
大家好,我是Leo。一个Java后端的程序员。之前我们介绍了MySQL如何保证高可用的相关技术点,比如可靠性优先策略,可用性优先策略,主从延迟,主从延迟的来源以及解决方案。今天我们继续上一篇文章遗留的问题作一个延伸,今天介绍一下从库的延迟问题!以及主库宕机,从库的抉择!
主库挂了,从库谋权篡位的那些事!
|
NoSQL Redis
Redis哨兵集群主库故障数据恢复(九)
Redis哨兵集群主库故障数据恢复 当主库修复后重新上线首先通过哨兵知道谁是当前的主库,然后就会去找主库同步数据,并且会自动修改配置文件,当数据同步后,想恢复的主库重新成为主库则需要把主库的权重调高,然后重新选举,这时原来的主库就能成为新的主库,调整完再将主库的权重值调成默认的
231 0
Redis哨兵集群主库故障数据恢复(九)
|
运维
简单记录一次ADG备库同步故障
这是一套11g的老库,主库3节点,备库1节点。项目上于昨天晚上做某测试扩容了表空间,在其他位置新建了9个数据文件,在备库无法创建这个非标准位置的datafile,从而导致同步中断。
355 0
|
SQL 运维 分布式计算
NameNode主备宕机引发的思考
大家都知道在双十一这些电商大型营销活动期间,电商网站的访问量等是平时的N倍。每当这个时候到来,无论是开发还是运维人员都严阵以待生怕服务出现问题。很不幸,笔者的一个朋友在一家电商公司上班,在双十一时,恰恰就出现了NameNode宕机的生产事故。 鉴于涉及到一些公司私密信息,不便发一些排查问题截图,同时,JVM调优作为大数据从业者必备技能,笔者打算后续分篇系统阐述,这里仅就问题现象、问题分析、解决方案三个层面阐述这次生产事故从产生、排查到最终解决的历程。希望能给大家带来一定思考,避免此类事情的发生以及提供出现类似问题时处理的一个思路。
一主两从的环境,如果主库挂了,如何选举一个从库作为主库?
一主两从的环境,如果主库挂了,如何选举一个从库作为主库? 如图: 如果M挂了,怎么从S1和S2中选举一个从库作为主库? 传统复制的解决方法 (1)查看从库状态: S1:show slave status; S2:show slave status; root@l...
925 0
|
NoSQL Redis
|
存储 关系型数据库 MySQL

热门文章

最新文章