UUID是软件构建标准，不蠢数包含重复检查。在高并发，包括多线程并发，多实例并发都有小概率出现重复的uuid。分布式情带兆首况下，尽量使用成熟猜旦的uuid生成方案，不要用自带的。
问题现象：
环境情况：
MySQL:5.7.21架构1主2从M--此纯M—SLAVE
现象分析：
1、每60秒产生一次报腊扒裤警2、相同的uuid
问题原因分析：
原因
Uuid 重复问题
机器上的auto.conf id问题
网络问题
备份时停止同步问题
slave 超时时间slave_net_timeout
版本配置问轮简题
排查思路：
1Uuid 重复问题都是唯一
2机器上的Auto.conf都是唯一
3网络问题利用iptables模拟
4备份停止时的操作备份时间不对
5Master 数据 不更新Slave 超时时间问题有的db组大量更新还是存在
6Slave 重启很像，但是凌晨没人重启
测试步骤：
根据上面的排查思路准备环境进行开始测试。
环境：
Master：10.110.10.31
Slave:10.110.10.30互为主从
Sysbench:用来测试插入数据配置同步（略）
测试
Uuid 与auto.conf 相同因为做主从配置时通常拷贝数据，因此有可能存在auto相同的情况，但是一一确认后发现不同。
测试slave 重启，master日志情况
在10.110.10.30 上执行如下
Stopslave;Startsalve;
发现日志如下：
Master 日志：
2020-08-05T17:48:46.033859+08:00 63510[Note] While initializing dump thread for slavewithUUID,founda zombie dumpthreadwiththe same UUID.Masteriskilling the zombie dumpthread(8398).2020-08-05T17:48:46.034067+08:0063510[Note]Startbinlog_dumptomaster_thread_id(63510)slave_server(9013100), pos(,4)
解说：
发现日志很符合线上报错的日志，但是查日志发现每60秒就会产生，线上也不可能频繁重启slave。
测试网络
在10.110.10.31 上执行IP tables 限制30访问，查看日志情况
iptables-IINPUT-s10.110.10.30-jDROP
slave 同步状态
mysql show slave status\G;*************************** 1. row ***************************Slave_IO_State: Reconnecting after a failed master event readMaster_Host: 10.110.10.31Master_User: replicMaster_Port: 3070Connect_Retry: 60Master_Log_File: mysql-bin.000008Read_Master_Log_Pos: 2659Relay_Log_File: relay-bin.000010Relay_Log_Pos: 2832Relay_Master_Log_File: mysql-bin.000008Slave_IO_Running: ConnectingSlave_SQL_Running: Yes
30上日志：
2020-08-05T20:08:04.931077+08:0063498[Warning]Storing MySQL user nameorpassword informationinthe master info repositoryisnotsecureandisthereforenotrecommended. Please consider using the USERand PASSWORD connection optionsforSTART SLAVE; see the'START SLAVE Syntax'inthe MySQL Manualformore information.2020-08-05T20:08:34.869063+08:0063510[Note] Aborted connection63510to db:'unconnected'user:'replic'host:'10.110.10.30'(failed on flush_net())2020-08-05T20:08:34.925537+08:0063792[Note] Start binlog_dump tomaster_thread_id(63792) slave_server(9013100), pos(,4)
解说：
发现日志访问master 出现flush_net() 关键字，但是线上并没有，因此排除网络问题。
备份停止时的操作xtrabackup
因为备份是利用percona 的xtrabackup工具，加了slave信息保持一致性的参数 --slave-info 但是发现时间对应不上因此排除
思路中断
此时发现常规的想法已经实现不通，需要查下同步参数，翻阅官方文档发现同步参数slave_net_timeout，根据参数定义为slave 在没有收到master 数据时的超时时间，会再次重新连接master，感觉有点线索了。对slave_net_timeout开始进行测试。此值默认为60
缩短 slave 网络超时时间,但没数据
在10.110.10.30 上执行如下：
Stopslave;setglobalslave_net_timeout=5;startsalve;
测试日志：
10.110.10.31 上的日志:
2020-08-06T09:59:31.226156+08:00 65500 [Note] While initializingdump thread for slavewithUUID,founda zombie dumpthreadwiththe same UUID.Masteriskilling the zombiedumpthread(65499).2020-08-06T09:59:31.226273+08:0065500[Note]Startbinlog_dump tomaster_thread_id(65500) slave_server(901311100), pos(mysql-bin.000008,828)2020-08-06T09:59:32.237103+08:0065501[Note]Whileinitializing dump threadforslavewithUUID,foundazombie dumpthreadwiththe same UUID.Masteriskilling the zombie dumpthread(65500).2020-08-06T09:59:32.237253+08:0065501[Note]Startbinlog_dump tomaster_thread_id(65501) slave_server(901311100), pos(mysql-bin.000008,828)2020-08-06T09:59:33.245805+08:0065502[Note]Whileinitializing dump threadforslavewithUUID,foundazombie dumpthreadwiththe same UUID.Masteriskilling the zombie dumpthread(65501).2020-08-06T09:59:33.245910+08:0065502[Note]Startbinlog_dumptomaster_thread_id(65502)slave_server(901311100), pos(mysql-bin.000008,828)
10.110.10.30 上的日志:
2020-08-06T10:02:01.030159+08:0018[Warning] Storing MySQL usernameorpassword informationinthe master info repositoryisnotsecureandisthereforenotrecommended. Please consider using the USERandPASSWORDconnection optionsforSTART SLAVE; see the'START SLAVE Syntax'inthe MySQLManualformore information.
解说：
发现结果日志已经符合预期，当slave_net_timeout时间过短，会频繁重连，发现产生日志和问题一样，那么接下来我插入数据看下情况
缩短 slave 网络超时时间,但有数据插入
在10.110.10.30 上执行如下：
Stopslave;setglobalslave_net_timeout=5;startsalve;
插入数据：
sysbench/root/sysbench-1.0.19/tests/include/oltp_legacy/oltp.lua--mysql-host=10.110.10.30--mysql-user=root --mysql-password='xxx'--mysql-port=3070--mysql-db=sbtest --oltp-table-size=10000000--oltp-tables-count=1--threads=1--events=500000--time=1200--report-interval=1prepare
日志：
解说：
发现已经没有日志输出，说明插入数据时，说明slave_net_timeout在有master 有binlog日志产生的情况下没问题，只有在空闲时会发生。
再次中断
可以验证slave_net_timeout 是产生问题的原因，但是线上有很多组db 没有日志产生也没有报错，反而写入量大的会存在问题，此时陷入迷惑中，因为此理由不能说服领导啊。继续看官方文档。发下如下信息
发现有个MASTER_HEARTBEAT_PERIOD参数，意思是多长时间对master 进行探测是否存活，默认为slave_net_timeout的一半也就是30，有线索了继续测试
MASTER_HEARTBEAT_PERIOD测试
对于发生问题的db机器进行查询MASTER_HEARTBEAT_PERIOD参数的值，发现为1800
而正常机器都是30，发现其中猫腻。
mysql select * from mysql.slave_master_info\G*************************** 1. row ***************************Number_of_lines: 25Master_log_name: mysql-bin.000651Master_log_pos: 131563718Connect_retry: 60Heartbeat: 1800
在10.110.10.30slave上执行
slave：上
mysqlstop slave;Query OK, 0 rows affected (0.00 sec)mysqlchange master to master_heartbeat_period = 1800;Query OK, 0 rows affected, 1 warning (0.11 sec)mysqlstart slave;Query OK, 0 rows affected (0.00 sec)
查看日志：
Slave上：
Master上：
发现问题已经复现
这个确实是从5.5 升级到5.7 的版本，slave_net_timetou原来是3600，Heartbeat：1800，因此问题已经定位。
关于是否重复，首先要说一下uuid生成的原理
UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的
UUID由以下几部分的组合：
（1）当前日期和时间，UUID的第一个部分与时间有关，如果你在生成一个段羡袜UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。
（2）时钟序列。
（3）全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
通过组成可以看派顷出，首先每台机器的mac地址是不一样的，那么如果出现重复，可能是同一时间下生成的id可能相同，不会存在不同时间内生成重复的数据
至于说同一时间产生重复的数据，就目前来说，是不会的除非极高的高并发（如果发生了，也可以通过原子性操作避免），
所以基本上就认为握激不会重复好了
从一定意义上讲，这个UUID号称是世界级的不重复，也就是说有生之年这个ID肯定是不春敏大重复的，但也只是个相对的拿凳概扒竖念。小概率事件不可能发生。
点击看一下就知道了有些事缓昌睁存文件可以不要的你删除就好。
拓展：
1、UUID含义是通用唯一识别码 (Universally Unique Identifier)，这 是一个软件建构的标准，也是被开源软件基金会 (Open Software Foundation, OSF) 的组织应用在分布式计算环境 (Distributed Computing Environment, DCE) 领域的重要部分。
2、作用
UUID 的目的是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。如此一来，每个人都可以建立不与其它人冲突的 UUID。在这样的情况下，就不需考虑数据库建立时的名称重复问题。目前最广泛应用的 UUID，即是微软的 Microsoft's Globally Unique Identifiers (GUIDs)，而其他重要的应用，则有 Linux ext2/ext3 档案系统、LUKS 加密分割区、GNOME、KDE、Mac OS X 等等。
3、应用
使用UUID的好处在分布式的软件系统中(比如:DCE/RPC, COM+,CORBA)就能体现出来，它能保证每个节点所生成的标识都不会重复，并且随着WEB服务等整合技术的发展，UUID的优势将更加明显。根据使用的特定机制，UUID不仅需要保证是彼此不相同的，或者最少也是与公元3400年之前其他任何生成的通用唯一标识符有非常大的区别。UUID最少在3000+年内不会重复。
通用唯一标识符还可以迟运用来指向码迅梁大多数的可能的物体。微软和其他一些软件公司都倾向使用全球唯一标识符(GUID)，这也是通用唯一标识符的一种类型，可用来指向组建对象模块对象和其他的软件组件。第一个通用唯一标识符是在网络计算机系统(NCS)中创建，并且随后成为开放软件基金会(OSF)的分布式计算环境(DCE)的组件。
UUID含义是通用唯一识别码，这是一个软件构建的标准，也是被开源软件基金会的组织应用在分布式计算环境领域的一部分。
作用
UUID的目的是让分布式系统中的所有元素，都能有唯一的辨别资讯，而不需要通过中央控制端来做辨识资讯的指定。如此一来，每个人都可以建立不与其它人冲突的UUID。在这样的情况下，就不需要考虑数据库建立时的名称重复问题。目前最广泛应用的UUID，即是微软的Microsoft's
Globally Unique Identifiers，而其他重要的应用，则有Linux
ext2/ext3档案系统、LUKS加密分割区、GNOME、KDE、Mac OS X等。
组成
UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的API。按照开放软件基金会制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和陵橡枝和许多可能的数字。
UUID由以下几部分的组合
①当前日期和时间，UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。
②时钟序列。
③全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
UUID的唯一缺陷在于生成的结果串会比较长。关于UUID这个标准使用最普遍的是微软的GUID。在ColdFusion中可以用CreateUUID()函数很简单地生成UUID，其格式为：xxxxxxxx-xxxx-
xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每个 x 是 0-9 或 a-f
范围内的一个十六进制的数字。而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
(8-4-4-4-12)，可以从cflib下载CreateGUID() UDF进行转换。
应用
使用UUID的好处在分布式的软件系统中就能体现出来，它能保证每个节点所生成的标识都不会重复，并且随着Web服务等整合技术的发展，UUID的优势将更加明显。根据使用的特定机制，UUID不仅需要保证是彼此不相同的，或者最少也是与公元3400年之前其他任何生成的通用唯一标识符有非常大的区别。
通用唯一标识符还可以用来指向大多数的可能的物体。微软和其他一些软件公司都倾向使用全球唯一标识符，这也是通用唯一标识符的一种类型，可用来指向组建对象模块对象和其他的软件组件。第一个通用唯一标识符是在网络计算机系统中创建，并且随后成为开放软件基金会的分布式计唤如戚算环境的组件。
本文转载自互联网，如有侵权，联系删除
