MySQL多個(gè)Slave同一server_id的沖突原因分析

P-Linux

本文內(nèi)容遵從CC版權(quán)協(xié)議, 可以隨意轉(zhuǎn)載, 但必須以超鏈接形式標(biāo)明文章原始出處和作者信息及版權(quán)聲明
網(wǎng)址: http://www.penglixun.com/tech/da ... _same_serverid.html

今天分析一個(gè)詭異問題，一個(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的重連機(jī)制。

我們首先看看一個(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ā)生什么呢？我們略去無用的代碼直接看重點(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è)上來，需要?jiǎng)h掉同樣server_id的Slave線程，再把新的Slave線程加到slave_list表中。

線程注冊(cè)上來后，請(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))) // mysqlbinlog.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。

再來簡(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斷開了，重新請(qǐng)求上來，當(dāng)然需要踢掉原來的線程，這就是線程重連機(jī)制。

切記，一個(gè)MySQL集群中，絕不可以出現(xiàn)相同server_id的實(shí)例，否則各種詭異的問題可是接踵而來。

erlangs

lz有見地，這種踏實(shí)認(rèn)真研究精神卻是這個(gè)論壇最缺失的。
納爾遜·曼德拉 發(fā)表于 2011-01-09 15:14

你要在C版則經(jīng)�？梢钥吹�,因?yàn)椴簧賒ba不擅長(zhǎng)看源文件,他們喜歡從國(guó)內(nèi)外別人分析的文章中獲取經(jīng)驗(yàn),所有只要有個(gè)正常人站在一群陽(yáng)萎者中間就顯得特別利害.
我意思是說源代碼分析其實(shí)是個(gè)很正常的現(xiàn)象,dba在原有業(yè)務(wù)經(jīng)驗(yàn)基礎(chǔ)上分析起來事半功倍.

justlooks

不錯(cuò)

ruochen

一個(gè)MySQL集群中，絕不可以出現(xiàn)相同server_id的實(shí)例-----這個(gè)是做復(fù)制的鐵律

Coolriver

對(duì)頭，沒有c基本功，做什么系統(tǒng)和dba都是半拉子，能從原理知道他怎么運(yùn)行的才是王道。
我都知道你怎么編得 ...
納爾遜·曼德拉 發(fā)表于 2011-01-11 20:51

    你要火了.
    不過,做數(shù)據(jù)庫(kù),明白原理是一方面,更重要的是要把這個(gè)原理和現(xiàn)有的業(yè)務(wù)模型結(jié)合起來.讓業(yè)務(wù)跑的更順利.

erlangs

你要火了.
    不過,做數(shù)據(jù)庫(kù),明白原理是一方面,更重要的是要把這個(gè)原理和現(xiàn)有的業(yè)務(wù)模型結(jié)合起 ...
Coolriver 發(fā)表于 2011-01-11 22:23

   
對(duì)業(yè)務(wù)層不了解很影響源碼閱讀,或者根本讀不了,自我感覺有爭(zhēng)論時(shí)深入源碼了解,這樣方可百戰(zhàn)不怠,LZ的做法是對(duì)的,mysql源碼非常注重?cái)?shù)據(jù)結(jié)構(gòu)和算法,這和操作系統(tǒng)以及編譯器等所不同的地方,這是走向技術(shù)顛峰的3座大山.