MySQL 从库Crash-safe设置的几种性能影响测试

                        MySQL 从库Crash-safe设置的几种性能影响测试



       默认情况下slave的io线程把从主库dump过来的位置记录在master.info文件，sql线程的执行进度
存放在relay-log.info的文件中.如果io线程把binlog传送过来了，然后再更新master.info文件，而在
更新master.info文件的过程中,slave服务器就crash掉了．这时候master.info还是老的位置，在下一次
重新启动的时候，io线程还是从master.info读取信息，所以就会导致io线程会重复拉取binlog报错的
情形.
   
  　为了保证这种情况不发生，mysql引入了sync_master_info和sync_relay_log_info两个参数.这两个
参数表示在每次接收到事件后就更新master.info和relay-log.info两个文件,使用fdatasync()这个函数
直接同步文件系统和磁盘.由于需要频繁同步文件系统和磁盘数据，设置参数为1对slave的性能影响非常大




首先把这两个参数设置为1
mysql> show global variables like '%sync%';
+-----------------------------------------+-------+
| Variable_name                           | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay          | 0     |
| binlog_group_commit_sync_no_delay_count | 0     |
| innodb_flush_sync                       | ON    |
| innodb_sync_array_size                  | 1     |
| innodb_sync_spin_loops                  | 30    |
| sync_binlog                             | 1     |
| sync_frm                                | ON    |
| sync_master_info                        | 1     |
| sync_relay_log                          | 10000 |
| sync_relay_log_info                     | 1     |




查看mysql进程打开的文件情况.


[root@localhost fd]# ls -l | egrep -e '47|46'
lrwx------ 1 root root 64 Apr 16 19:33 46 -> /usr/local/mysql/data/master.info
lrwx------ 1 root root 64 Apr 16 19:33 47 -> /usr/local/mysql/data/relay-log.info


对mysql进行跟踪，在主库上使用sysbench执行3000个事务.
[root@localhost ~]# strace  -f  -o b.out -p 11819


过滤fdatasync函数调用情况
[root@localhost ~]# cat b.out | egrep -e  'fdatasync\(47|fdatasync\(46'  | wc -l
25689


由于每次都需要调用fdatasync函数，我们发现被调用了25000多次.


现在我们设置这两个参数为0的情况
sync_master_info=0
sync_relay_log_info=0


[root@localhost fd]# ls -l | egrep -e '47 -|45 -'
lrwx------ 1 root root 64 Apr 16 19:59 45 -> /usr/local/mysql/data/master.info
lrwx------ 1 root root 64 Apr 16 19:59 47 -> /usr/local/mysql/data/relay-log.info


[root@localhost ~]# strace  -f  -o c.out -p 13457
Process 13457 attached with 29 threads




当设置为0后，对fdatasync的调用直接为0
[root@localhost ~]# cat c.out | egrep -e  'fdatasync\(47|fdatasync\(45'


在5.7的的标准设置下


sync_master_info=10000
sync_relay_log_info=10000


这时候对fdatasync只有两次
[root@localhost ~]# cat e.out | egrep -e  'fdatasync\(47|fdatasync\(45'
14531 fdatasync(45
14531 fdatasync(45




后续又引进了把master.info和relay-log.info直接存放到数据库中以表的形式存放,
直接当成事务的一部分来进行提交.一定要是支持事务


master_info_repository=TABLE
relay_log_info_repository=TABLE


[root@localhost fd]# ls -l | grep master | grep info
lrwx------ 1 root root 64 Apr 16 20:04 24 -> /usr/local/mysql/data/mysql/slave_master_info.ibd


[root@localhost fd]# ls -l | grep relay | grep info
lrwx------ 1 root root 64 Apr 16 20:04 23 -> /usr/local/mysql/data/mysql/slave_relay_log_info.ibd


[root@localhost ~]# cat d.out | grep fsync | grep 23
13935 fsync(23
13935 fsync(23)                         = 0
[root@localhost ~]# cat d.out | grep fsync | grep 24
13935 fsync(24)                         = 0




这时候通过把这两个表当成普通的表来进行更新.并没有产生fsync或fdatasync疯长的情况出现.




结论：为了保证slave在crash时的可靠性,1,如果从库innodb_flush_trx_at_commit设置1,那么把master_info_repository和
relay_log_info_repository两个参数都设置为TABLE;2,当设置为FILE时，可以适当把两个参数调小; 3,最不可靠的情形就是
设置这两个参数为0,不过IO的性能影响也最小.