mysql timespec重定义_MySQL：半同步（二）主库端回调函数

最新推荐文章于 2024-03-18 10:38:28 发布

友枝枝

最新推荐文章于 2024-03-18 10:38:28 发布

阅读量321

点赞数

文章标签： mysql timespec重定义

本文链接：https://blog.csdn.net/weixin_42509815/article/details/114330449

版权

源码版本5.7.29

主库端的回调函数比较多，比较复杂

一、回调函数：repl_semi_binlog_dump_start

调用线程：dump线程

#0 repl_semi_binlog_dump_start (param=0x7fffe8150ba0, log_file=0x7fffe81520c0 "", log_pos=4) at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master_plugin.cc:127

#1 0x00000000013dca8e in Binlog_transmit_delegate::transmit_start (this=0x2d1c980 , thd=0x7ffdec000b90, flags=0, log_file=0x7fffe81520c0 "", log_pos=4,

observe_transmission=0x7fffe8151e24) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_handler.cc:726

#2 0x000000000182233e in Binlog_sender::init (this=0x7fffe8151490) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_binlog_sender.cc:119

#3 0x0000000001822611 in Binlog_sender::run (this=0x7fffe8151490) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_binlog_sender.cc:208

#4 0x000000000182040a in mysql_binlog_send (thd=0x7ffdec000b90, log_ident=0x7fffe81520c0 "", pos=4, slave_gtid_executed=0x7fffe8151e90, flags=0)

at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_master.cc:421

#5 0x00000000018202d6 in com_binlog_dump_gtid (thd=0x7ffdec000b90, packet=0x7ffdec00a8b1 "", packet_length=123) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_master.cc:405

#6 0x00000000014b76ef in dispatch_command (thd=0x7ffdec000b90, com_data=0x7fffe8152c90, command=COM_BINLOG_DUMP_GTID) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1754

#7 0x00000000014b5a94 in do_command (thd=0x7ffdec000b90) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1060

#8 0x00000000015e9d32 in handle_connection (arg=0x7019220) at /home/mysql/soft/percona-server-5.7.29-32/sql/conn_handler/connection_handler_per_thread.cc:325

#9 0x00000000018b97f2 in pfs_spawn_thread (arg=0x6f595f0) at /home/mysql/soft/percona-server-5.7.29-32/storage/perfschema/pfs.cc:2198

#10 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0

#11 0x00007ffff5f2b8dd in clone () from /lib64/libc.so.6

回调方式：

Binlog_sender::init

Binlog_sender::check_start_file之后调用插件函数

if (RUN_HOOK(binlog_transmit, transmit_start,

(thd, m_flag, m_start_file, m_start_pos,

&m_observe_transmission)))

调入

binlog_transmit_delegate->transmit_start

调入

repl_semi_binlog_dump_start(Binlog_transmit_param *param, //server id和flag

const char *log_file, //文件名

my_off_t log_pos)//位点

如果是GTID这里pos没有实际意义，因为这个时候刚刚读取了从库发送过来的binlog位点信息，但是gtid实际没有传输实际的位点信息。

函数过程：

repl_semi_binlog_dump_start

->get_user_var_int("rpl_semi_sync_slave", &semi_sync_slave, NULL); //获取线程rpl_semi_sync_slave参数，这是io线程会发起的设置参考从库repl_semi_slave_request_dump的回调函数

//本参数为dump线程设置，通过调用函数repl_semi_slave_request_dump进行,写入到semi_sync_slave变量中

->如果semi_sync_slave不为0，则说明是开启了半同步的从库

->Ack_receiver::add_slave 本函数主要讲dump线程纳入ack receiver线程管理

->slave.thread_id= thd->thread_id(); //将dump线程processlist id加入

->slave.server_id= thd->server_id; //server id为从库的server id

...其他属性

->mysql_mutex_lock(&m_mutex); //防止同时修改 ack_receiver 的属性 ,因为ack_receiver是全局唯一的内存结构，比如有多个dump线程同时启动

->m_slaves.push_back(slave); //将slave 信息写入到Ack_receiver的m_slaves数组中

->修改属性m_slaves_changed为true

->mysql_cond_broadcast(&m_cond);//做唤醒操作

->mysql_mutex_unlock(&m_mutex);//解锁

->my_set_thread_local(THR_RPL_SEMI_SYNC_DUMP, &SEMI_SYNC_DUMP); //设置函数共享数据THR_RPL_SEMI_SYNC_DUMP

->repl_semisync.add_slave()/增加变量Rpl_semi_sync_master_clients

->rpl_semi_sync_master_clients++;

->如果日志处于info级别输出日志

sql_print_information("Start %s binlog_dump to slave (server_id: %d), pos(%s, %lu)",

semi_sync_slave != 0 ? "semi-sync" : "asynchronous",

param->server_id, log_file, (unsigned long)log_pos);

也就是加入的半同步的从库的的server id，位点信息

总的说来这个钩子就是在启动的时候判断主从是否是半同步，如果是需要加入到ack receiver进行管理和更改统计值Rpl_semi_sync_master_clients，加入的是dump线程 processlist id如下证明

(gdb) p slave.thread_id

$2 = 85

(gdb) n

140 slave.net_compress= thd->get_protocol_classic()->get_compression();

(gdb) p thd->server_id

$3 = 631

mysql> show processlist;

+----+--------+--------------------+------+------------------+------+---------------------------------------------------------------+------------------+-----------+---------------+

+----+--------+--------------------+------+------------------+------+---------------------------------------------------------------+------------------+-----------+---------------+

| 85 | repsem | 192.168.1.63:41434 | NULL | Binlog Dump GTID | 49 | Master has sent all binlog to slave; waiting for more updates | NULL | 0 | 0 |

+----+--------+--------------------+------+------------------+------+---------------------------------------------------------------+------------------+-----------+---------------+

二、回调函数：repl_semi_binlog_dump_end

调用线程：dump线程

#0 ReplSemiSyncMaster::remove_slave (this=0x7ffdb3fff1c0 ) at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master.cc:586

#1 0x00007ffdb3df30e1 in repl_semi_binlog_dump_end (param=0x7fffe8192dc0) at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master_plugin.cc:180

#2 0x00000000013dccc8 in Binlog_transmit_delegate::transmit_stop (this=0x2d1c980 , thd=0x7ffde0000be0, flags=0)

at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_handler.cc:740

#3 0x00000000018224dd in Binlog_sender::cleanup (this=0x7fffe8193490) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_binlog_sender.cc:183

#4 0x0000000001822c2d in Binlog_sender::run (this=0x7fffe8193490) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_binlog_sender.cc:319

#5 0x000000000182040a in mysql_binlog_send (thd=0x7ffde0000be0, log_ident=0x7fffe81940c0 "", pos=4, slave_gtid_executed=0x7fffe8193e90, flags=0)

at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_master.cc:421

#6 0x00000000018202d6 in com_binlog_dump_gtid (thd=0x7ffde0000be0, packet=0x7ffde000a901 "", packet_length=83) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_master.cc:405

#7 0x00000000014b76ef in dispatch_command (thd=0x7ffde0000be0, com_data=0x7fffe8194c90, command=COM_BINLOG_DUMP_GTID) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1754

#8 0x00000000014b5a94 in do_command (thd=0x7ffde0000be0) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1060

#9 0x00000000015e9d32 in handle_connection (arg=0x36a8a20) at /home/mysql/soft/percona-server-5.7.29-32/sql/conn_handler/connection_handler_per_thread.cc:325

#10 0x00000000018b97f2 in pfs_spawn_thread (arg=0x36d4480) at /home/mysql/soft/percona-server-5.7.29-32/storage/perfschema/pfs.cc:2198

#11 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0

#12 0x00007ffff5f2b8dd in clone () from /lib64/libc.so.6

回调方式：

Binlog_sender::run

->THD_STAGE_INFO(m_thd, stage_waiting_to_finalize_termination);

进入状态waiting_to_finalize_termination

->是否是由于出现了重复的dump线程

->Binlog_sender::cleanup

->RUN_HOOK(binlog_transmit, transmit_stop, (thd, m_flag));

->Binlog_transmit_delegate::transmit_stop

函数过程：

Binlog_transmit_delegate::transmit_stop

->是否是半同步

如果是

->ack_receiver.remove_slave(current_thd);//ack_receiver去掉当前dump线程

-> mysql_mutex_lock(&m_mutex); //加锁准备修改Ack_receiver的全局结构信息

->for (it= m_slaves.begin(); it != m_slaves.end(); it++)

迭代m_slaves，在所有的dump线程中进行循环迭代

找到删除m_slaves.erase(it); //删除

->mysql_mutex_unlock(&m_mutex);//解锁

->repl_semisync.remove_slave();

->lock();//加锁

->rpl_semi_sync_master_clientst-- //统计值减去1

->如果半同步开启(getMasterEnabled() && is_on())

->如果rpl_semi_sync_master_clients小于了参数rpl_semi_sync_master_wait_for_slave_count设置

且(rpl_semi_sync_master_wait_no_slave设置false 或者是 abort_loop关闭数据库)

->如果是 abort_loop关闭数据库

需要比较当前收到的ack的pos和最新提交的pos是否一致。不一致则输出警告

sql_print_warning("SEMISYNC: Forced shutdown. Some updates might " "not be replicated.");

->switch_off()//关闭半同步

总说的这里是在dump线程退出之前进行的操作，就是在ack_receiver中将本dump线程去掉，然后判断是否需要关闭半同步：

如果rpl_semi_sync_master_clients小于了参数rpl_semi_sync_master_wait_for_slave_count设置退化为异步复制

三、回调函数:repl_semi_report_binlog_update

调用线程：用户线程

(gdb) bt

#0 repl_semi_report_binlog_update (param=0x7ffdf416a1a0, log_file=0x2d66935 "binlog.000002", log_pos=322)

at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master_plugin.cc:59

#1 0x00000000013db911 in Binlog_storage_delegate::after_flush (this=0x2d1c800 , thd=0x7ffdc8000c20, log_file=0x2d66935 "binlog.000002",

log_pos=322) at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_handler.cc:589

#2 0x0000000001803351 in MYSQL_BIN_LOG::ordered_commit (this=0x2d668a0 , thd=0x7ffdc8000c20) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:10282

#3 0x000000000180192a in MYSQL_BIN_LOG::commit (this=0x2d668a0 , thd=0x7ffdc8000c20, all=false) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:9494

#4 0x00000000015c686c in trans_commit_stmt (thd=0x7ffdc8000c20) at /home/mysql/soft/percona-server-5.7.29-32/sql/transaction.cc:470

#5 0x00000000014c090b in mysql_execute_command (thd=0x7ffdc8000c20, first_level=true) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:5330

#6 0x00000000014c2025 in mysql_parse (thd=0x7ffdc8000c20, parser_state=0x7ffdf416c4a0, update_userstat=false) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:5927

#7 0x00000000014b6c5f in dispatch_command (thd=0x7ffdc8000c20, com_data=0x7ffdf416cc90, command=COM_QUERY) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1539

#8 0x00000000014b5a94 in do_command (thd=0x7ffdc8000c20) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1060

#9 0x00000000015e9d32 in handle_connection (arg=0x3385e00) at /home/mysql/soft/percona-server-5.7.29-32/sql/conn_handler/connection_handler_per_thread.cc:325

#10 0x00000000018b97f2 in pfs_spawn_thread (arg=0x7005b10) at /home/mysql/soft/percona-server-5.7.29-32/storage/perfschema/pfs.cc:2198

#11 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0

#12 0x00007ffff5f2b8dd in clone () from /lib64/libc.so.6

回调方式：

MYSQL_BIN_LOG::ordered_commit

->flush阶段 flush之后

->if (RUN_HOOK(binlog_storage, after_flush,

(thd, file_name_ptr, flush_end_pos)))

->如果sync_binlog !=1 这里通知dump线程发送binlog

调入

binlog_storage_delegate->after_flush(THD *thd,const char *log_file,my_off_t log_pos)

Binlog_storage_param param;

param.server_id= thd->server_id; //拿到从库的server id

调入

repl_semi_report_binlog_update

函数过程:

repl_semi_report_binlog_update(Binlog_storage_param *param,const char *log_file,my_off_t log_pos)

传入参数为从库server_id,主库binlog filename,binlog最新刷新到的pos位点

->repl_semisync.getMasterEnabled()

是否开启了半同步，这里是在初始化的时候根据参数rpl_semi_sync_master_enabled判断的

及全局ReplSemiSyncMaster.master_enabled_的设置

->ReplSemiSyncMaster::writeTranxInBinlog(const char* log_file_name,my_off_t log_file_pos)

这里带入binlog filename和binlog最新刷新到的pos位置，对位点进行存储

->上锁准备修改 ReplSemiSyncMaster全局变量信息

lock();

->如果commit_file_name_inited_已经初始化，也就是已经接收过提交的位点信息

->调用ActiveTranx::compare进行简单比较，当前位点和commit file位点进行比较

->如果大于

复制当前位点信息到commit_file_name_和commit_file_pos_

->如果小于

不做操作

->如果没有初始化

复制当前位点信息到commit_file_name_和commit_file_pos_

同时commit_file_name_inited_设置为true代表已经初始化

->如果半同步状态处于正常状态

由参数rpl_semi_sync_master_wait_for_slave_count和rpl_semi_sync_master_wait_no_slave共同控制

->插入活跃事务链表

active_tranxs_->insert_tranx_node(log_file_name, log_file_pos)

如果插入失败调用ReplSemiSyncMaster::switch_off，并且打印出警告

sql_print_warning("Semi-sync failed to insert tranx_node for binlog file: %s, position: %lu",

log_file_name, (ulong)log_file_pos);

总的说来这个回调函数主要用在binlog flush阶段之后，发送之前，用于将活跃的事务的位点信息放入到活跃事务链表中。

四、回调函数:repl_semi_report_commit

用户线程，堵塞等待ack

当参数设置rpl_semi_sync_master_wait_point设置为after commit的时候调用，这里简单记录一下主要研究after sync，这个参数是修改立即生效。如下是函数内部的判断：

if (rpl_semi_sync_master_wait_point == WAIT_AFTER_COMMIT &&

is_real_trans && param->log_pos)

#0 ReplSemiSyncMaster::commitTrx (this=0x7ffdf438b1c0 , trx_wait_binlog_name=0x7ffddc006d90 "binlog.000005", trx_wait_binlog_pos=3560)

at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master.cc:715

#1 0x00007ffdf417ef33 in repl_semi_report_commit (param=0x7fffe81d3dd0) at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master_plugin.cc:113

#2 0x00000000013db38c in Trans_delegate::after_commit (this=0x2d1c740 , thd=0x7ffddc000c00, all=false)

at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_handler.cc:553

#3 0x0000000001802212 in MYSQL_BIN_LOG::process_after_commit_stage_queue (this=0x2d668a0 , thd=0x7ffddc000c00, first=0x7ffddc000c00)

at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:9743

#4 0x00000000018038ac in MYSQL_BIN_LOG::ordered_commit (this=0x2d668a0 , thd=0x7ffddc000c00) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:10413

#5 0x000000000180192a in MYSQL_BIN_LOG::commit (this=0x2d668a0 , thd=0x7ffddc000c00, all=false) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:9494

#6 0x0000000000ea64b8 in ha_commit_trans (thd=0x7ffddc000c00, all=false, ignore_global_read_lock=false) at /home/mysql/soft/percona-server-5.7.29-32/sql/handler.cc:1839

#7 0x00000000015c680d in trans_commit_stmt (thd=0x7ffddc000c00) at /home/mysql/soft/percona-server-5.7.29-32/sql/transaction.cc:465

#8 0x00000000014c090b in mysql_execute_command (thd=0x7ffddc000c00, first_level=true) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:5330

#9 0x00000000014c2025 in mysql_parse (thd=0x7ffddc000c00, parser_state=0x7fffe81d64a0, update_userstat=false) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:5927

#10 0x00000000014b6c5f in dispatch_command (thd=0x7ffddc000c00, com_data=0x7fffe81d6c90, command=COM_QUERY) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1539

#11 0x00000000014b5a94 in do_command (thd=0x7ffddc000c00) at /home/mysql/soft/percona-server-5.7.29-32/sql/sql_parse.cc:1060

#12 0x00000000015e9d32 in handle_connection (arg=0x6fe6df0) at /home/mysql/soft/percona-server-5.7.29-32/sql/conn_handler/connection_handler_per_thread.cc:325

回调方式：

commit队列处理之后

MYSQL_BIN_LOG::process_after_commit_stage_queue

(THD *head= first; head; head= head->next_to_commit)

此处为一个循环，和after sync的回调不一样，明显这里是循环队列中的每一个事务

->transaction_delegate->after_commit

thd->get_trans_fixed_pos(&param.log_file, &param.log_pos);

这里寻找到到本事务的log file和pos带入

->repl_semi_report_commit

最重要的就是

return repl_semisync.commitTrx(binlog_name, param->log_pos);

具体这个函数做什么参考下面的after sync

五、回调函数:repl_semi_report_binlog_sync

用户线程，堵塞等待ack，可以说这事最重要的函数了

当参数设置rpl_semi_sync_master_wait_point设置为after sync的时候调用，这里主要研究本回调函数这个参数是修改立即生效

#0 ReplSemiSyncMaster::commitTrx (this=0x7ffdf438b1c0 , trx_wait_binlog_name=0x7ffddc006ea0 "binlog.000005", trx_wait_binlog_pos=3880)

at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master.cc:715

#1 0x00007ffdf417ee82 in repl_semi_report_binlog_sync (param=0x7fffe81d3ed0, log_file=0x7ffddc006ea0 "binlog.000005", log_pos=3880)

at /home/mysql/soft/percona-server-5.7.29-32/plugin/semisync/semisync_master_plugin.cc:80

#2 0x00000000013dc824 in Binlog_storage_delegate::after_sync (this=0x2d1c800 , thd=0x7ffddc000c00, log_file=0x7ffddc006ea0 "binlog.000005", log_pos=3880)

at /home/mysql/soft/percona-server-5.7.29-32/sql/rpl_handler.cc:709

#3 0x0000000001802bb6 in call_after_sync_hook (queue_head=0x7ffddc000c00) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:10036

#4 0x000000000180384e in MYSQL_BIN_LOG::ordered_commit (this=0x2d668a0 , thd=0x7ffddc000c00) at /home/mysql/soft/percona-server-5.7.29-32/sql/binlog.cc:10390