如何生成惟一的server Id，server_id为什么不能重复？

咱们都知道MySQL用server-id来惟一的标识某个数据库实例，并在链式或双主复制结构中用它来避免sql语句的无限循环。这篇文章分享下我对server-id的理解，而后比较和权衡生成惟一server-id的几种方式。

server_id的用途

简单说来，server_id有两个用途： 
1. 用来标记binlog event的源产地，就是SQL语句最开始源自于哪里。 
2. 用于IO_thread对主库binlog的过滤。若是没有设置 replicate-same-server-id=1 ，那么当从库的io_thread发现event的源与本身的server-id相同时，就会跳过该event，不把该event写入到relay log中。从库的sql_thread天然就不会执行该event。这在链式或双主结构中能够避免sql语句的无限循环。

注意：相同server-id的event在io_thread这一层就过滤了；而对于replicate-(do|ignore)-等规则，则是在sql_thread这一层过滤的。io_thread和sql_thread都有过滤的功能。

server_id为什么不能重复

在同一个集群中，server-id一旦重复，可能引起一些诡异问题。 
看看下面两种状况：

图1：主库与从库的server-id不一样，可是两个或多个从库的server-id相同

这种状况下复制会左右摇摆。当两个从库的server-id相同时，若是从库1已经链接上主库，此时从库2也须要链接到主库，发现以前有server-id相同的链接，就会先注销该链接，而后从新注册。 
参考下面的代码片断：

repl_failsafe (register_slave) download

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

int register_slave(THD* thd, uchar* packet, uint packet_length) { int res; SLAVE_INFO *si; ... if (!(si->master_id= uint4korr(p))) si->master_id= server_id; si->thd= thd; pthread_mutex_lock(&LOCK_slave_list); /* 先注销相同server-id的链接*/ unregister_slave(thd,0,0);  /* 从新注册*/ res= my_hash_insert(&slave_list, (uchar*) si); pthread_mutex_unlock(&LOCK_slave_list); return res; ... }

两台从库不停的注册，不停的注销，会产生不少relay log文件，查看从库状态会看到relay log文件名不停改变，从库的复制状态一会是yes一会是正在链接中。

图2：链式或双主结构中，主库与从库的server-id相同

从库1同时又是relay数据库，它能正确同步，而后把relay-log内容重写到本身的binlog中。当server-id为100的从库2 io线程获取binlog时，发现全部内容都是源自于本身，就会丢弃这些event。所以从库2没法正确同步主库的数据。只有直接写relay server的event能正确同步到从库2。 
上面两种状况能够看到，在同一个replication set中，保持server-id的惟一性很是重要。

server_id的动态修改

无心中发现 server-id 居然是能够动态修改的，可别高兴的太早。好处是，上面图1的状况下，直接修改其中一个从库的server-id就能够解决server-id冲突的问题。坏处很隐蔽，以下图的结构： 

如今假设active-master由于某种缘由与passive-master的同步断开后，passive-master上进行了一些ddl变动。而后某dba突发奇想把passive-master的server-id修改成400。当双master的复制启动后，那些以前在passive-master上执行的server-id为200的ddl变动，会今后陷入死循环。若是是 alter table t engine=innodb ，它会一直不停，可能你会发现。可是像 update a=a+1； 这样的sql，你很难发现。固然这种场景只是个人杜撰，这儿有个更真实的例子 主备备的两个备机转为双master时出现的诡异slave lag问题 。 
举这两个例子只是想说明修改server-id有点危险，最好不要去修改，那么能一步到位生成它吗？

如何生成惟一的server_id

经常使用的方法有以下几种：

1. 采用随机数

mysql的server-id是4字节整数，范围从0-4294967295，所以采用该范围内的随机数来做为server-id产生冲突的可能性是很是小的。

2. 采用时间戳

直接用date +%s来生成server-id。一天86400秒来计算，日后计算50年，最大的server-id也才使用到86400*365*50，彻底在server-id范围内。

3. 采用ip地址+端口

这是咱们常常采用的方法。例如ip为192.168.122.23，端口为3309，那么server-id能够写为122233309。产生冲突的可能性比较小：遇到*.*.122.23 或者*.*.12.223，并且搭建了同一个replication set的3309才会出现。

4. 采用集中的发号器

在管理服务器上采用自增的id来统一分配server-id。这能够保证不冲突，可是须要维护中心节点。

5. 分开管理每一个replication set

在每一个replication set中为mysql库增长一个管理表，保证每一个从库的server-id不冲突。

哪种更好

上面的几种方法都不赖，可是：

1. 方法4加了维护负担，并且开发环境、测试环境、线上环境都维护一套发号器的话，有点麻烦，混在一块儿又可能遇到网段隔离的风险，还有发号器数据库权限的问题难于控制。因此不推荐。

2. 方法5实现了自治，可是管理成本有点高。从库要可以写主库的server-id表，复杂。

3. 5种方法都存在的问题是，使用冷备的数据来扩容，server-id须要手动去修改，不然就与冷备源的server-id冲突。并且，当mysql启动的时候，你没法判断该mysql是刚经过备份扩容的，仍是以前一直正常运行的。因此你不知道这个server-id到底要不要改。而我但愿server-id对dba彻底透明，又毫不产生冲突，便可完全屏蔽这个讨厌的东西。

建议的方法

其实很简单。ipv4是4字节的整数，与server-id的范围彻底同样。咱们认为只有ip地址+端口才能惟一的肯定一个mysql实例，因此老是但愿把ip信息和端口信息都集成到server-id中。可是别忘了，一个ip上不能同时启动两个同样的端口。因此，server-id只需采用ip地址的整数形式！自定义的mysql启动脚本强制对server-id进行检查，发现server-id不对就进行纠正，而后启动。上面全部的问题，都会迎刃而解。

欢迎拍砖。