mysql 架构篇系列 3 复制运行状态监控与选项参数说明

一. 概述

　　在上一篇中，搭建了一主一从的复制架构，这篇通过一些诊断方法来了解复制的运行状态和一些选项参数说明。上次mysql主从服务关机,今天在打开mysql服务，出现了错误信息。

　　1.首先 启动主从mysql服务

　　2.在从库上执行START SLAVE， 开始复制。

　　3.在从库上执行SHOW PROCESSLIST;  slave已经连接上master, 并开始接受并执行日志。

BEGIN
/*!*/;
# at 1714
#181029 14:41:21 server id 1  end_log_pos 1860 CRC32 0x9fdf71e9     Query    thread_id=2    exec_time=0    error_code=0
use `test`/*!*/;
SET TIMESTAMP=1540795281/*!*/;
-- 全部更新
update  testbackup  set `name`=concat(`name`,'hello123')
/*!*/;
# at 1860
#181029 14:41:21 server id 1  end_log_pos 1891 CRC32 0x4b7199d3     Xid = 579
COMMIT/*!*/;

View Code 　　总结：在binlog_format格式为row时，mysql实际上在binlog是一行行记录数据的变更。当格式为statement时是按语句级记录。 row格式比statement格式更能保证从库数据的一致性（复制是记录，而不是单纯操作sql），但row格式下的binlog的日志量很可能会增大好几倍，在设置时需要考虑磁盘空间问题。

 

三. 刷新磁盘频率

　　对于支持事务引擎（如innodb）来说, 每个事务提交时都需要写binlog,对于不支持事务的引擎(例myisam)来说，每个sql语句执行完成时，都需要写binlog。 为了保证binlog安全,mysql引入了 sync_binlog 参数来控制binlog刷新到磁盘的频率。

　　关于sync_binlog在： mysql 开发进阶篇系列 19 MySQL Server(innodb_flush_log_at_trx_commit与sync_binlog)中有介绍。

-- 查看binlog格式
SHOW VARIABLES LIKE '%sync_binlog%'

　　当sync_binlog=1时，是最安全的，当主机突然断点，系统最多损失最近的一条事务的数据。但是在多个事务并发提交时，mysql不得不按顺序处理请求，同时高频率的刷新binlog对I/O影响明显，很大程度影响了mysql的性能。

　　所以一般线上系统mysql的sync_binlog不会设置为1, 而是2或0,在数据安全性和更高的并发之间获取一个平衡。