mysql crash-safe_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的性能影响也最小.

阅读(3677) | 评论(0) | 转发(0) |