MySQL中server_id一致带来的问题

简 介

我们都知道在MySQL搭建复制环境的时候,需要设置每个server的server_id不一致,如果主库与从库的server_id一致,那么复制会失败。但是最近在解决一个客户的问题的时候,遇到一个有意思的现象,客户环境有三台数据库服务器,一主两从,客户的两台从库设置了相同server_id,在排查问题的过程中,查看MySQL错误日志,发现有很多奇怪的信息。 我们模拟了客户的环境,并进行测试、分析,最终在代码中找到了我们想要的答案。下面就是我们测试、分析、总结的步骤以及内容。

测试步骤

环境介绍

  • 主库 IP:192.168.1.130 server_id:3656
  • 从库A IP:192.168.1.36 server_id:56
  • 从库B IP:192.168.1.57 server_id:56

三台主机除server_id之外,其余配置如下:

server_id = 123
[client]
socket = /home/mysql/data/mysqldata5.5/sock/mysql.sock
[mysqld]
#server_id = 365
server_id = 123
port = 3306
skip_name_resolve = 1
binlog_format = ROW
#binlog_format = STATEMENT
basedir = /home/mysql/program/mysql5.5.36
datadir = /home/mysql/data/mysqldata5.5/mydata
socket = /home/mysql/data/mysqldata5.5/sock/mysql.sock
pid-file = /home/mysql/data/mysqldata5.5/sock/mysql.pid
tmpdir = /home/mysql/data/mysqldata5.5/tmpdir
log-error = /home/mysql/data/mysqldata5.5/log/error.log
slow_query_log
slow_query_log_file = /home/mysql/data/mysqldata5.5/slowlog/slow-query.log
log-bin = /home/mysql/data/mysqldata5.5/binlog/mysql-bin
relay-log = /home/mysql/data/mysqldata5.5/relaylog/mysql-relay-bin
innodb_data_home_dir = /home/mysql/data/mysqldata5.5/innodb_ts
innodb_log_group_home_dir = /home/mysql/data/mysqldata5.5/innodb_log
#innodb_undo_directory = /home/mysql/data/mysqldata5.5/undo/
sync_binlog=1
innodb_file_per_table=1
#skip_grant_tables
expire_logs_days = 1
log_slave_updates = ON
#replicate-same-server-id=1
skip_slave_start
#innodb_undo_tablespaces=1

5.5.36版本现象

初始搭建环境之后,查看各主机状态。搭建环境的步骤就省略。

主库(192.168.1.130)

主库通过show processlist语句查看,只有一个dump线程,但是通过多次刷新,可以看到连接的是不同的服务器。可以看到每次通过show processlist语句显示的dump线程的Host字段中,IP:PORT的值是不断在更新的,说明dump线程在不断的重连,才会出现占用不同的端口的现象。

从库A(192.168.1.36)

通过show slave status\G命令查看复制状态,多次执行可以看到Slave_IO_Running字段显示的内容,出现YES或者Connnecting两种状态。可以看到I/O线程在不断的进行重连。

并且通过tail -f命令查看error log,可以看到I/O线程一直在尝试重新连接。

可以看到在错误日志中打印的信息是,I/O线程连接 。

从库B(192.168.1.57)

从库B现象与从库A一致。

5.6.36版本现象

搭建环境步骤不在赘述。

主库(192.168.1.130)

show processlist查看有两个dump线程,并且多次刷新,发现Host字段中的IP:PORT并没有修改,说明dump线程一直保持连接。

从库A(192.168.1.36)

tail -f /home/mysql/data/mysqldata5.6/log/error.log查看错误日志,没有不断断开连接 。

从库B(192.168.1.57)

tail -f /home/mysql/data/mysqldata5.6/log/error.log查看错误日志,没有不断断开连接 。

原因分析

http://www.penglixun.com/tech/database/mysql_multi_slave_same_serverid.html这是彭立勋写的关于多个slave使用相同server_id时冲突的原因的一篇文章。按照彭大大的分析,我理解的是,slave的I/O线程连接上主库的时候,主库上会调用register_slave()这个函数,在这个函数中又调用了unregister_slave()函数,会将之前使用相同server_id的线程给注销掉。从而导致从库的I/O线程不断断开重连。 但是仔细看了一下unregister_slave()函数的代码,并没有发现MySQL是根据server_id来注销dump线程的。并且进一步比较了一下5.5.36和5.6.36版本的代码,并没有发现不同。而从库设置server_id一致导致I/O线程不断重连的现象只在5.5版本中看到,在5.6版本中并没有这个现象,所以导致5.5现象的原因不是在unregister_slave()函数中。 进一步看了一下彭大大的文章,发现有人在下面评论,说主要是kill_zombie_slave_threads()函数导致的。于是看了一下kill_zombie_slave_threads()函数的逻辑,发现MySQL应该就是在这一步根据server_id将线程kill了。

  • 5.5.36版本 首先来看下5.5.36版本的kill_zombie_dump_threads()函数的代码。看到这个函数传入的参数是一个uint32类型的slave_server_id,在函数中做的事情是,遍历MySQL中的所有线程,如果遍历到一个线程是dump线程并且线程的server_id是等于传入的参数值话,则跳出遍历循环,并对kill掉这个线程。
void kill_zombie_dump_threads(uint32 slave_server_id)                           
{                                                                               
  mysql_mutex_lock(&LOCK_thread_count);                                         
  I_List_iterator<THD> it(threads);                                             
  THD *tmp;                                                                     
  while ((tmp=it++))                                                            
  {                                                                             
    if (tmp->command == COM_BINLOG_DUMP &&                                      
      tmp->server_id == slave_server_id)                                       
    {                                                                           
     mysql_mutex_lock(&tmp->LOCK_thd_data);    // Lock from delete             
     break;                                                                    
    }                                                                           
  }                                                                             
  mysql_mutex_unlock(&LOCK_thread_count);                                       
  if (tmp)                                                                      
  {                                                                             
    /*                                                                          
     Here we do not call kill_one_thread() as                                  
     it will be slow because it will iterate through the list                  
     again. We just to do kill the thread ourselves.                           
    */                                                                          
    tmp->awake(THD::KILL_QUERY);                                                
    mysql_mutex_unlock(&tmp->LOCK_thd_data);                                    
  }                                                                             
} 
  • 5.6.35版本 再来看一下5.6.36版本的kill_zombie_dump_threads()函数的代码实现,与5.5.36大不相同。首先传入的参数是一THD类型的指针,在函数中实现的逻辑同样是遍历MySQL中的所有线程,如果找到dump线程,首先看一下这个线程有没有uuid字段(因为uuid是在5.6之后的版本才有的,这边是为了兼容5.5),如果有uuid则用uuid进行比较,如果没有uuid,则用server_id进行比较。
void kill_zombie_dump_threads(THD *thd)                                                                                                  
{                                                                               
  String slave_uuid;                                                            
  get_slave_uuid(thd, &slave_uuid);                                             
  if (slave_uuid.length() == 0 && thd->server_id == 0)                          
    return;                                                                     


  mysql_mutex_lock(&LOCK_thread_count);                                         
  THD *tmp= NULL;                                                               
  Thread_iterator it= global_thread_list_begin();                               
  Thread_iterator end= global_thread_list_end();                                
  bool is_zombie_thread= false;                                                 
  for (; it != end; ++it)                                                       
  {                                                                             
    if ((*it) != thd && ((*it)->get_command() == COM_BINLOG_DUMP || (*it)->get_command() == COM_BINLOG_DUMP_GTID))         
    {                                                                           
     String tmp_uuid;                                                          
     get_slave_uuid((*it), &tmp_uuid);                                         
     if (slave_uuid.length())                                                  
     {                                                                         
       is_zombie_thread= (tmp_uuid.length() && !strncmp(slave_uuid.c_ptr(),                         
                                         tmp_uuid.c_ptr(), UUID_LENGTH)); 


     else                                                                      
     {                                                                         
       /*                                                                      
       ¦ Check if it is a 5.5 slave's dump thread i.e., server_id should be    
       ¦ same && dump thread should not contain 'UUID'.                        
       */                                                                      
       is_zombie_thread= (((*it)->server_id == thd->server_id) && !tmp_uuid.length());                                 
     }                                                                         
     if (is_zombie_thread)                                                     
     {                                                                         
       tmp= *it;                                                               
       mysql_mutex_lock(&tmp->LOCK_thd_data);  // Lock from delete             
       break;                                                                  
     }                                                                         
    }                                                                           
  }                                                                             
  mysql_mutex_unlock(&LOCK_thread_count);                                       
  if (tmp)                                                                      
  {                                                                             
    /*                                                                          
    ¦ Here we do not call kill_one_thread() as                                  
    ¦ it will be slow because it will iterate through the list                  
    ¦ again. We just to do kill the thread ourselves.                           
    */                                                                          
    if (log_warnings > 1)                                                       
    {                                                                           
     if (slave_uuid.length())                                                  
     {                                                                       
 sql_print_information("While initializing dump thread for slave with "  
"UUID <%s>, found a zombie dump thread with the " 
 "same UUID. Master is killing the zombie dump "   
 "thread(%lu).", slave_uuid.c_ptr(),               
 tmp->thread_id);                                  
     }                                                                         
     else                                                                      
     {                                                                         
       sql_print_information("While initializing dump thread for slave with "  
 "server_id <%u>, found a zombie dump thread with the "
"same server_id. Master is killing the zombie dump "
 "thread(%lu).", thd->server_id,                   
 tmp->thread_id);                                  
     }                                                                         
    }                                                                           
    tmp->duplicate_slave_id= true;                                              
    tmp->awake(THD::KILL_QUERY);                                                
    mysql_mutex_unlock(&tmp->LOCK_thd_data);                                    
  }                                                                             
}                                    

函数调用

  • 知道了kill_zombie_dump_threads()线程实现的逻辑,那MySQL是在什么地方会调用这个函数的呢。看了一下函数是在case COM_BINLOG_DUMP中被调用的。 在5.5.36版本中是在
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);  
unregister_slave(thd,1,1);                                                
/*  fake COM_QUIT -- if we get here, the thread needs to terminate */     
 error = TRUE;                                                             
break;                                                                    
}    

在5.6.36版本中也是在case COM_BINLOG_DUMP中,只不过是将之前的逻辑封装在了com_binlog_dump()函数中了,kill_zombie_dump_threads()也是在com_binlog_dump()函数中调用的。

case COM_BINLOG_DUMP:                                                         
error= com_binlog_dump(thd, packet, packet_length);                                                                                  
break;    

case COM_BINLOG_DUMP中所进行的操作就是将dump线程通知I/O线程拉取新的binlog。

总 结

整理下来的话,基本上可以确定主要是因为kill_zombie_dump_threads()函数导致在5.6之前的版本中,如果是一主多从的架构中,如果在从库之间的server_id如果设置为一样,会出现从开I/O线程不断断开重连的现象。因为在5.6之前的版本中,还没有UUID的概念,MySQL使用server_id来区分是否是同一台机器,而在5.6之后的版本是使用的UUID来区分。 总结一句,就是数据库之间的server_id不要设置成一样,不然可能会有一些不可预知的错误。

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2017-08-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构

阿里面试答案——Spring框架

2053
来自专栏微服务生态

玩转EhCache之最简单的缓存框架

Ehcache是一个用Java实现的使用简单,高速,实现线程安全的缓存管理类库,ehcache提供了用内存,磁盘文件存储,以及分布式存储方式等多种灵活的cach...

3874
来自专栏程序猿DD

Hystrix降级逻辑中如何获取触发的异常?

通过之前Spring Cloud系列教程中的《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》一文,我们已经知道如何通过Hyst...

1253
来自专栏陈树义

Dubbo配置方式详解

Dubbo 是一个分布式服务框架,致力于提供高性能和透明化的 RPC 远程服务调用方案,是阿里巴巴 SOA 服务化治理方案的核心框架,每天为 2,000+ 个服...

4517
来自专栏java学习

你竟敢说你懂Spring框架?有可能你是没看到这些...(上)

所以,特地去搜刮了一些关于spring的面试题,希望能帮助各位同学在升职加薪的路上,一去不复返。

1102
来自专栏依乐祝

ASP.NET Core WebApi使用Swagger生成api说明文档看这篇就够了

将 Swagger 生成器添加到 Startup.ConfigureServices 方法中的服务集合中:

1881
来自专栏LeoXu的博客

Tapestry 教程(七)在Tapestry中一起使用Hibernate

好了,你填写了所有的输入域,提交了这个表单(没有任何验证错误),瞧:你又回到了相同的表单,所有的格子里面都是空的。发生了什么,数据都到哪儿去了?

603
来自专栏Java3y

纳税服务系统一(用户模块)【简单增删改查、日期组件、上传和修改头像】

前言 为了更好地掌握SSH的用法,使用一个纳税服务系统来练手…..搭建SSH框架环境在上一篇已经详细地说明了。http://blog.csdn.net/hon_...

5759
来自专栏JavaQ

深入理解Spring之九:DispatcherServlet初始化源码分析

DispatcherServlet是SpringMVC的核心分发器,它实现了请求分发,是处理请求的入口,本篇将深入源码分析它的初始化过程。 首先,从Dispat...

3775
来自专栏Java架构师学习

Spring面试底层原理的那些问题,你是不是真的懂Spring?

3594

扫码关注云+社区