MySQLSlave同一server_id的沖突原因分析
來(lái)源：懂視網(wǎng)
責(zé)編：小采
時(shí)間：2020-11-09 09:56:04
MySQLSlave同一server_id的沖突原因分析
MySQLSlave同一server_id的沖突原因分析:今天分析一個(gè)詭異問(wèn)題，一個(gè)模擬Slave線程的程序，不斷的被Master Server給kill掉，最終發(fā)現(xiàn)是因?yàn)橛袃蓚€(gè)Slave使用同樣一個(gè)server id去連接Master Server，為什么兩個(gè)Slave用同一個(gè)server id會(huì)被Master Server給Kill呢？分析了源碼，這源于
導(dǎo)讀MySQLSlave同一server_id的沖突原因分析:今天分析一個(gè)詭異問(wèn)題，一個(gè)模擬Slave線程的程序，不斷的被Master Server給kill掉，最終發(fā)現(xiàn)是因?yàn)橛袃蓚€(gè)Slave使用同樣一個(gè)server id去連接Master Server，為什么兩個(gè)Slave用同一個(gè)server id會(huì)被Master Server給Kill呢？分析了源碼，這源于
今天分析一個(gè)詭異問(wèn)題，一個(gè)模擬Slave線程的程序，不斷的被Master Server給kill掉，最終發(fā)現(xiàn)是因?yàn)橛袃蓚€(gè)Slave使用同樣一個(gè)server id去連接Master Server，為什么兩個(gè)Slave用同一個(gè)server id會(huì)被Master Server給Kill呢？分析了源碼，這源于MySQL Replication
我們首先看看一個(gè)Slave注冊(cè)到Master會(huì)發(fā)生什么，首先Slave需要向Master發(fā)送一個(gè)COM_REGISTER_SLAVE類型的請(qǐng)求（sql_parse.cc）命令請(qǐng)求，這里Master會(huì)使用register_slave函數(shù)注冊(cè)一個(gè)Slave到slave_list。
| 代碼如下 |
|
|
case COM_REGISTER_SLAVE:
{
if (!register_slave(thd, (uchar*)packet, packet_length))
my_ok(thd);
break;
}
|
在注冊(cè)Slave線程的時(shí)候會(huì)發(fā)生什么呢？我們略去無(wú)用的代碼直接看重點(diǎn)：（repl_failsafe.cc）
| 代碼如下 |
|
|
int register_slave(THD* thd, uchar* packet, uint packet_length)
{
int res;
SLAVE_INFO *si;
uchar *p= packet, *p_end= packet + packet_length;
.... //省略
if (!(si->master_id= uint4korr(p)))
si->master_id= server_id;
si->thd= thd;
pthread_mutex_lock(&LOCK_slave_list);
unregister_slave(thd,0,0); //關(guān)鍵在這里，先取消注冊(cè)server_id相同的Slave線程
res= my_hash_insert(&slave_list, (uchar*) si); //把新的Slave線程注冊(cè)到slave_list
pthread_mutex_unlock(&LOCK_slave_list);
return res;
.....
}
|
這是什么意思呢？這就是重連機(jī)制，slave_list是一個(gè)Hash表，server_id是Key，每一個(gè)線程注冊(cè)上來(lái)，需要?jiǎng)h掉同樣server_id的Slave線程，再把新的Slave線程加到slave_list表中。
線程注冊(cè)上來(lái)后，請(qǐng)求Binlog，發(fā)送COM_BINLOG_DUMP請(qǐng)求，Master會(huì)發(fā)送binlog給Slave，代碼如下：
| 代碼如下 |
|
|
case COM_BINLOG_DUMP:
{
ulong pos;
ushort flags;
uint32 slave_server_id;
status_var_increment(thd->status_var.com_other);
thd->enable_slow_log= opt_log_slow_admin_statements;
if (check_global_access(thd, REPL_SLAVE_ACL))
break;
/* TODO: The following has to be changed to an 8 byte integer */
pos = uint4korr(packet);
flags = uint2korr(packet + 4);
thd->server_id=0; /* avoid suicide */
if ((slave_server_id= uint4korr(packet+6))) // binlog.server_id==0
kill_zombie_dump_threads(slave_server_id);
thd->server_id = slave_server_id;
general_log_print(thd, command, "Log: '%s' Pos: %ld", packet+10,
(long) pos);
mysql_binlog_send(thd, thd->strdup(packet + 10), (my_off_t) pos, flags); //不斷的發(fā)送日志給slave端
unregister_slave(thd,1,1); //發(fā)送完成后清理Slave線程，因?yàn)閳?zhí)行到這一步肯定是binlog dump線程被kill了
/* fake COM_QUIT -- if we get here, the thread needs to terminate */
error = TRUE;
break;
}
|
mysql_binlog_send函數(shù)在sql_repl.cc，里面是輪詢Master binlog，發(fā)送給Slave。
再來(lái)簡(jiǎn)單看看unregister_slave做了什么（repl_failsafe.cc）：
| 代碼如下 |
|
|
void unregister_slave(THD* thd, bool only_mine, bool need_mutex)
{
if (thd->server_id)
{
if (need_mutex)
pthread_mutex_lock(&LOCK_slave_list);
SLAVE_INFO* old_si;
if ((old_si = (SLAVE_INFO*)hash_search(&slave_list,
(uchar*)&thd->server_id, 4)) &&
(!only_mine || old_si->thd == thd)) //拿到slave值
hash_delete(&slave_list, (uchar*)old_si); //從slave_list中拿掉
if (need_mutex)
pthread_mutex_unlock(&LOCK_slave_list);
}
}
|
這就可以解釋同樣的server_id為什么會(huì)被kill，因?yàn)橐坏┳?cè)上去，就會(huì)現(xiàn)刪除相同server_id的Slave線程，然后把當(dāng)前的Slave加入，這是因?yàn)橛袝r(shí)Slave斷開(kāi)了，重新請(qǐng)求上來(lái)，當(dāng)然需要踢掉原來(lái)的線程，這就是線程重連機(jī)制。
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
MySQLSlave同一server_id的沖突原因分析
MySQLSlave同一server_id的沖突原因分析:今天分析一個(gè)詭異問(wèn)題，一個(gè)模擬Slave線程的程序，不斷的被Master Server給kill掉，最終發(fā)現(xiàn)是因?yàn)橛袃蓚€(gè)Slave使用同樣一個(gè)server id去連接Master Server，為什么兩個(gè)Slave用同一個(gè)server id會(huì)被Master Server給Kill呢？分析了源碼，這源于
