也可以采用北京万里开源软件有限公司的集群解决方案，后端使用开源的MySQL存储数据，优点是有任何问题他们都可以帮忙解决，而且不用担心系统后续的扩展、集群高可用等情况，他们的工程师还开发过MySQL核心代码，找他们可以睡个安稳觉，缺点是不免费，他们还有自己的国产数据库GreatDB，100%兼容MySQL。
对于初创企业，可以考虑选择免费的开源解决方案，毕竟遇到的问题可能有限，如果要想长期稳定发展，还是选择万里开源这样的公司比较靠谱一些。
1.Mysql cluster: share-nothing,分布式节点架构的存储方案，以便于提供容错性和高性能。
需要用到mysql cluster安装包，在集群中的每一个机器上安装。
有三个关键概念：Sql节点（多个），数据节点（多个），管理节点（一个），数据节点之间采用的是同步复制来保证各节点之间的数据一致性。
同步复制：
a) Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。
b) 每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。
c) Master等待所有Slave发送OK或ABORT消息，如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；如果 Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。
e) 每个Slave等待来自Master的OK或ABORT消息。如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。
f) Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。
由于同步复制一共需要4次消息传递，故mysql cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。
2.主从（Master-Slave）: 主从机器上安装mysql community（普通版）就可以。
主从之间是通过mysql的replication来保证数据的一致性。相对mysql cluster的数据同步方式来讲是异步的。
Replication：主节点要开启binlog，设置一个唯一的服务器id（局域网内唯一）；从节点设置服务器id，binlog记录了master上的所有 *** 作，会被复制到从节点的relaylog并在从节点上回放。
业务有两个 MySQL 集群是通过 MQ 进行同步的，昨晚 MQ 出现异常，报了很多主键冲突，想请 dba 帮忙校验一下两个集群的数据是否一致。
当接到这个需求的时候并没当回事，隐约有点印象 pt-table-checksum 能通过 dsn 实现 MySQL 的数据校验，所以当时就应承下来了。不曾想，啪啪打脸，回想起来真是草率了。
本文参考的是 pt-table-checksum 的校验逻辑，基于数据块去遍历每个表，然后比对 checksum 的值判断该块是否一致，本文主要是想聊聊我在实现数据校验脚本过程中遇到的问题以及解决思路，希望对大家有帮助。
利用线上的配置文件搭建一套主从环境。
这个用例将通过 dsn 方式连接从库。
这个用例将通过 dsn 方式连接从库，但是会将从库的复制链路 stop 掉，并清空复制信息。
熟悉 pt-table-checksum 的朋友应该都知道，该工具是基于主键(非空唯一键)进行扫描数据行，其实这个逻辑针对整型单列主键实现起来很简单，但是如果是联合主键且是字符型，好像就没那么简单了，有兴趣的可以思考一下。下面我先说一下大致的逻辑：
第一步：判断 _min_rowid 是否为空，为空就取该表的第一行，并记作 _min_rowid 。
第二步：根据 _min_rowid 作为条件进行扫描该表，取下一个数据块的数据，记录数据块的最后一行数据的主键值，记录 checksum 的值，并记下 _min_rowid 。
第三步：判断_min_rowid是否为空，非空重复第二步，为空退出检查。
通过上述三个步骤可以看到，如果是单列整型的主键，实现起来很简单，但是问题来了，业务的表的主键五花八门，有的是联合主键，有的是字符型的联合主键，还有整型+字符型的联合主键，那么上述的实现方式显然是有问题的。所以实现起来需要多考虑几个问题：
鉴于存在上述两个问题，可以参考如下实现逻辑：
假如有这么一个联合主键字段 primary key(a,b,c) 都是整型，该如何编写遍历 sql 呢？起初我的想法很简单，具体如下：
至此在编写校验脚本过程遇到的两个问题就算告一段落了，剩下的就是各种逻辑处理了，不过多赘述，有兴趣的可以自行阅读脚本文件。
本着最低程度影响业务，所以取消加锁逻辑。但是又要保证该数据块的数据一致性，如果这个数据块是个热数据，当前正在变更，那么校验的时候难免会不一致。所以只能通过多次校验实现，默认是校验20次，其中有一次校验结果是一致，就认为是一致的，如果前5次校验过程中，这个数据块的数据没有变化，也视为不一致（可能是因为延迟，也可能是真的不一致）。
pt-table-checksum 不校验表结构，改写时添加表结构的校验。
可以基于表的并行校验，可由用户指定并行数，但是脚本有个安全机制，如果用户指定的并行数大于当前 cpu 空闲核心数，就会按当前（空闲核心数-1）作为并行数。
添加网络监控，由用户指定网络上限百分比，当网卡流量超过这个百分比就暂停任务，等待网卡流量低于阈值才会继续任务。这个主要是出于对于中间件（mycat）的场景或者分布式数据库（tidb）的场景。
支持定时任务功能，用户可以使用这个功能规避业务高峰，仅在业务低峰进行数据校验。
不仅限于主从节点的校验，只要目标对象支持 MySQL 的标准 SQL 语法就能做数据校验。
校验逻辑是通过 SQL 采集目标节点的数据库，如果目标数据库系统当前存在异常，无疑是雪上加霜，将会触发未知问题，所以添加超时机制，单次取数据块的阈值是5s，超过5秒就放弃等待重试。测试发现，有时候即便触发超时了，但是 SQL 任务还是会在目标数据库的 processlist 中能看到，所以又添加了一个 kill 机制，超时后会触发一个 kill processlist id 的动作。另外为了避免 kill 错，在每个 SQL 对象添加了一个32位的 md5 值，每次 kill 的时候会校验这个 md5 值。
本工具借鉴 pt-table-checksum 工具思路改写，可以检查随意两个 mysql（支持 mysql sql 语法的数据库）节点的数据一致性。
基于主键以一个块遍历数据表，比对checksum的值，块的大小可通过参数指定。 （1）获取该表的第一个数据块的查询SQL。 （2）将两个目标节点的数据块的checksum的值，记录到临时文件，file1 file2。 （3）比对file1 file2是否一致。
第一步：先开启一个 screen 监控网络
第二步：新开启一个screen执行校验任务
（1）info.log 文件
（2）list目录
（3）md5 目录
（4）pri 目录
（5）res 目录
这是 table 目录下记录某个数据块不一致的一个例子
这是 diff 目录下记录某个数据行不一致的一个例子
（6）skip.log 文件
本工具是参考了 pt-table-checksum 工具的一些思路并结合自身经验进行改写，尚有很多不足之处，仅做学习交流之用， 如有线上环境使用需求，请在测试环境充分测试。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）