Fork me on GitHub

MySQL主从管理与维护

字数统计: 698字   |   阅读时长≈ 2分 
1
上一个文章可以成功部署MySQL主从,主从同步状态如何以及relay log等等信息如何监控？

MySQL主从部署

如何确定MySQL主从关系？

主库:

1
2
mysql> show proccesslist;    
#此命令可以看到哪些客户端在与主库连接，可以辅助判断从库。不代表列出的都是从库。

从库:

1
mysql> show slave status\G;   #此命令可以看到从库运行状态等等信息，下面详细说。

主从维护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
mysql> show slave status\G;

*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
-----------------------------------------
       Master_Host: 10.0.0.52
       Master_User: repl
       Master_Port: 3306
       Connect_Retry: 60
       Master_Log_File: mysql-bin.000007
       Read_Master_Log_Pos: 211	  

以上信息来自于从库的master.info文件,列出了主库与连接端口等
作用:
    1.从库用来连接主库
    2.从库会拿着Master_Log_File和Read_Master_Log_Pos, 去问主库有没有比这个新的数据,有的话就给我.
1
2
3
4
5
6
7
8
9
----------------------------------------------------------------- 
 Relay_Log_File: 3307-relay-bin.000006
  Relay_Log_Pos: 374
  Relay_Master_Log_File: mysql-bin.000007

以上信息来自于relay-log.info
作用:	
	1.记录了已经应用过的最后一个relay信息会被记录到此文件中
	2.为了断点恢复
1
2
3
4
5
-----------------------------------------------------------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

从库线程状态		
1
2
3
4
-----------------------------------------------------------------
Seconds_Behind_Master: 0
		
从库落后主库多久
1
2
3
4
5
6
7
-----------------------------------------------------------------				
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error: 
			   
线程的具体的报错代码和详细信息	
1
2
3
4
-----------------------------------------------------------------			   
SQL_Delay: 0	

SQL线程延时配置					
1
2
3
4
-----------------------------------------------------------------					
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

SQL线程运行状态

故障排查1：

1
2
3
4
5
6
7
8
9
10
11
监控主从复制状态:
Last_IO_Error: error reconnecting to master 'repl@10.0.0.52:3306' - retry-time: 60  retries: 1

原因：
1、主库没启动，或者宕机
2、网络通信问题
3、防火墙
4、复制用户和密码、端口号、地址有问题
5、mysql自动解析，会将连接的IP解析成主机名（skip-name-resolve）
6、从库IO异常关闭
7、bug

故障排查2：

1
2
3
4
5
6
7
8
9
10
11
从库记录的已经主库已经给我传送的binlog事件的坐标，一般在繁忙的生产环境下会落后于主库（show master status）
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 729

落后太远的原因：
硬件条件有关的
主要还是网络问题
主库存放二进制日志的存储性能太低。

主库DUMP太繁忙，一主多从环境下。
从库IO线程太忙

故障排查3：

1
2
3
4
5
6
7
8
9
主库update，从库迟迟的没有更新。

特殊情况，日志已经传过来了，数据并没有同步

跟SQL线程有很大关系：
1、没开启SQL线程
2、传的东西有问题（你要做的事情，我提前已经做了，不想重复做了，然后他就死了）
3、SQL线程忙。
4、人为控制了（delay节点、延时节点，一般生产设置为3-6小时之间，可以保证过去3-6小时之间的误操作，可以避免）。

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true


不论我写了什么...
其实都是错的......