mysql5.7,启用基于logical_clock的多线程复制,发现error日志增长很快，查看日志发现大量关于多线程复制的Note级别日志。1

2

3

4

5

6

7

8

9

10

11

12

13

14

152018-07-03T03:22:01.638371+08:00 8941 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 298; events assigned = 3043329; worker queues filled over ove

rrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 725810947700 waited (count) when Workers occupied = 5346 wait

ed when Workers occupied = 0

2018-07-03T03:24:22.589147+08:00 8941 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 141; events assigned = 3044353; worker queues filled over ove

rrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 725810947700 waited (count) when Workers occupied = 5346 wait

ed when Workers occupied = 0

2018-07-03T03:27:00.554437+08:00 8941 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 158; events assigned = 3045377; worker queues filled over ove

rrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 725818557700 waited (count) when Workers occupied = 5346 wait

ed when Workers occupied = 0

2018-07-03T03:32:00.079699+08:00 8941 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 300; events assigned = 3047425; worker queues filled over ove

rrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 725846344900 waited (count) when Workers occupied = 5346 wait

ed when Workers occupied = 0

2018-07-03T03:34:04.567887+08:00 8941 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 124; events assigned = 3048449; worker queues filled over ove

rrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 725852036800 waited (count) when Workers occupied = 5346 wait

ed when Workers occupied = 0

通过日期可以看到，日志的打印频率大概在3分钟左右。error log是mysql 出现问题时的重要分析日志，大量的note日志可能很快就把重要日志信息埋没,给分析日志信息带来了不便。而且日志量随时间递增，还必须有rotate机制，不然占用大量磁盘空间。那么这个日志的打印频率能不能调低一些呢？

我看了下源码这块的实现(rpl_slave.cc 4800)1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29*ptr_ev= NULL; // announcing the event is passed to w-worker

if (rli->is_parallel_exec() && rli->mts_events_assigned % 1024 == 1)

{

time_t my_now= my_time(0);

if ((my_now - rli->mts_last_online_stat) >=

mts_online_stat_period)

{

sql_print_information("Multi-threaded slave statistics%s: "

"seconds elapsed = %lu; "

"events assigned = %llu; "

"worker queues filled over overrun level = %lu; "

"waited due a Worker queue full = %lu; "

"waited due the total size = %lu; "

"waited at clock conflicts = %llu "

"waited (count) when Workers occupied = %lu "

"waited when Workers occupied = %llu",

rli->get_for_channel_str(),

static_cast

(my_now - rli->mts_last_online_stat),

rli->mts_events_assigned,

rli->mts_wq_overrun_cnt,

rli->mts_wq_overfill_cnt,

rli->wq_size_waits_cnt,

rli->mts_total_wait_overlap,

rli->mts_wq_no_underrun_cnt,

rli->mts_total_wait_worker_avail);

rli->mts_last_online_stat= my_now;

我们从两个if语句可以看到，这个信息的打印受三个条件的控制：rli->is_parallel_exec() 这是个inline函数，它判断是否在使用多线程复制

rli->mts_events_assigned % 1024 == 1 多线程执行的event个数刚刚超过1024个。也就是说按evnet个数来算，每隔1024个event打印一次。

最后还有个时间限制：(my_now - rli->mts_last_online_stat) >= mts_online_stat_period，距离上一次统计超过既定的间隔mts_online_stat_period。这个变量是60*2 ,代码里写死了。1

2

3

4/*

Statistics go to the error log every # of seconds when --log-warnings > 1

*/

const long mts_online_stat_period= 60 * 2;

由此可以判断，这个日志打印频率最少为2分钟，没法改了。但上面的代码注释中给了提示，当–log-warnings > 1时，这个统计间隔才生效，意味着可以通过修改日志打印级别来控制。

自mysql5.7.2，log-warnings被废弃，引用了新的变量log_error_verbosity。这个变量有三个值：1、2、3，默认是3. 他们的意义是：

1 – Errors Only

2 – Errors and warnings

3 – Errors, warnings, and notes

我们可以修改这个变量为2 ，不再打印Note信息。1set global log_error_verbosity=2;