如何为mysql分片集群设置片键

Posted 2023-05-02

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何为mysql分片集群设置片键相关的知识，希望对你有一定的参考价值。

参考技术A mysql的cluster方案有很多官方和第三方的选择，选择多就是一种烦恼，因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：
高可用性：主服务器故障后可自动切换到后备服务器可伸缩性：可方便通过脚本增加DB服务器负载均衡：支持手动把某公司的数据请求切换到另外的服务器，可配置哪些公司的数据服务访问哪个服务器
需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点本回答被提问者采纳参考技术B 以每24小时作为一份时间（而非自然日），根据用户的配置有两种工作模式：带状模式中，用户仅定义开始日期时，从开始日期（含）开始，每份时间1个分片地无限增加下去；环状模式中，用户定义了开始日期和结束日期时，以结束日期（含）和开始日期（含）之间的时间份数作为分片总数（分片数量固定），以类似取模的方式路由到这些分片里。

1. DBLE 启动时，读取用户在 rule.xml 配置的 sBeginDate 来确定起始时间
2. 读取用户在 rule.xml 配置的 sPartionDay 来确定每个 MySQL 分片承载多少天内的数据
3. 读取用户在 rule.xml 配置的 dateFormat 来确定分片索引的日期格式
4. 在 DBLE 的运行过程中，用户访问使用这个算法的表时，WHERE 子句中的分片索引值（字符串），会被提取出来尝试转换成 Java 内部的时间类型
5. 然后求分片索引值与起始时间的差，除以 MySQL 分片承载的天数，确定所属分片

1. DBLE 启动时，读取用户在 rule.xml 配置的起始时间 sBeginDate、终止时间 sEndDate 和每个 MySQL 分片承载多少天数据 sPartionDay
2. 根据用户设置，建立起以 sBeginDate 开始，每 sPartionDay 天一个分片，直到 sEndDate 为止的一个环，把分片串联串联起来
3. 读取用户在 rule.xml 配置的 defaultNode
4. 在 DBLE 的运行过程中，用户访问使用这个算法的表时，WHERE 子句中的分片索引值（字符串），会被提取出来尝试转换成 Java 内部的日期类型
5. 然后求分片索引值与起始日期的差：如果分片索引值不早于 sBeginDate（哪怕晚于 sEndDate），就以 MySQL 分片承载的天数为模数，对分片索引值求模得到所属分片；如果分片索引值早于 sBeginDate，就会被放到 defaultNode 分片上

与MyCat的类似分片算法对比

中间件
DBLE
MyCat

分片算法种类 date 分区算法按日期（天）分片
两种中间件的取模范围分片算法使用上无差别

开发注意点
【分片索引】1. 必须是字符串，而且 java.text.SimpleDateFormat 能基于用户指定的 dateFormat 来转换成 java.util.Date
【分片索引】2. 提供带状模式和环状模式两种模式
【分片索引】3. 带状模式以 sBeginDate（含）起，以 86400000 毫秒（24 小时整）为一份，每 sPartionDay 份为一个分片，理论上分片数量可以无限增长，但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话，会路由失败（如果有 defaultNode，则路由至 defaultNode）
【分片索引】4. 环状模式以 86400000 毫秒（24 小时整）为一份，每 sPartionDay 份为一个分片，以 sBeginDate（含）到 sEndDate（含）的时间长度除以单个分片长度得到恒定的分片数量，但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话，会路由失败（如果有 defaultNode，则路由至 defaultNode）
【分片索引】5. 无论哪种模式，分片索引字段的格式化字符串 dateFormat 由用户指定
【分片索引】6. 无论哪种模式，划分不是以日历时间为准，无法对应自然月和自然年，且会受闰秒问题影响

运维注意点
【扩容】1. 带状模式中，随着 sBeginDate 之后的数据出现，分片数量的增加无需再平衡
【扩容】2. 带状模式没有自动增添分片的能力，需要运维手工提前增加分片；如果路由策略计算出的分片并不存在时，会导致失败
【扩容】3. 环状模式中，如果新旧 [sBeginDate,sEndDate] 之间有重叠，需要进行部分数据迁移；如果新旧 [sBeginDate,sEndDate] 之间没有重叠，需要数据再平衡

配置注意点
【配置项】1. 在 rule.xml 中，可配置项为 <propertyname="sBeginDate"> 、 <propertyname="sPartionDay"> 、 <propertyname="dateFormat"> 、 <propertyname="sEndDate"> 和 <propertyname="defaultNode">
【配置项】2.在 rule.xml 中配置 <propertyname="dateFormat">，符合 java.text.SimpleDateFormat 规范的字符串，用于告知 DBLE 如何解析sBeginDate和sEndDate

【配置项】3.在 rule.xml 中配置 <propertyname="sBeginDate">，必须是符合 dateFormat 的日期字符串

【配置项】4.在 rule.xml 中配置 <propertyname="sEndDate">，必须是符合 dateFormat 的日期字符串；配置了该项使用的是环状模式，若没有配置该项则使用的是带状模式

【配置项】5.在 rule.xml 中配置 <propertyname="sPartionDay">，非负整数，该分片策略以 86400000 毫秒（24 小时整）作为一份，而 sPartionDay 告诉 DBLE 把每多少份放在同一个分片

【配置项】6.在 rule.xml 中配置 <propertyname="defaultNode"> 标签，非必须配置项，不配置该项的话，用户的分片索引值没落在 mapFile 定义

MongoDB高可用与分片

一、复制

在MongoDB中，创建副本集后就可以使用复制功能了，副本集是一组服务器，其中一个用于处理写操作的主节点primary，还有多个用于保存主节点数据副本的从节点secondary。如果主节点崩溃了，则从节点会选取出一个新的主节点。

如果使用复制功能时有一台服务器停止运行了，那么仍然可以从副本集中的其它服务器访问数据。如果服务器上的数据已损坏或无法访问，则可以从副本集中的其它成员中创建一个新的数据副本。

副本集中的每个成员都必须能够连接到其它成员，如果收到有关成员无法访问到其它成员，则可能需要更改网络配置以允许它们之间的连接。

二、如何进行选举

当一个从节点无法与主节点连通时，它就会联系并请求其它的副本集成员将自己选举为主节点。

其它成员会做几项健全性检查：

它们能否连接到主节点，而这个主节点是发起选举的节点无法连接到的？
这个发起选举的从节点是否有最新数据？
有没有其它更高优先级的成员可以被选举为主节点？

MongoDB在3.2版本中引入了第1版复制协议。这是一个类PAFT的协议，并且包含了一些特定于MongoDB的副本集概念，比如仲裁节点、优先级、非选举成员、写入关注点等。还提出了很多新概念，比如更短的故障转移时间，大大减少了检测主节点失效的时间，它还通过使用term ID来防止重复投票。

RAFT是一种共识算法，它被分解成了相对独立的子问题。共识是指多台服务器或进程在一些值上达成一致的过程。RAFT确保了一致性，使得同一序列的命令产生相同序列的结果，并在所部署的各个成员中达到相同序列的状态。

副本集成员相互间每隔两秒发送一次心跳。如果某个成员在10秒内没有反馈心跳，则其它成员会将不良成员标记为无法访问。选举算法将尽最大努力尝试让具有最高优先权的从节点发起选举。成员优先权会影响选举的时机和结果。优先级高的从节点要比优先级低的从节点更快发起选举，而且也更有可能成为主节点。然而，低优先级的从节点也是有可能被短暂的选举为主节点的，副本集成员会继续发起选举直到可用的最高优先级成员被选举为主节点。被选举为主节点的从节点必须拥有最新的复制数据。

三、优先级

优先级用于表示一个成员称为主节点的优先程度，取值范围是0 ~ 100。数值越大，优先级越高。默认为1，如果将priority设置为0，表示此节点永远无法成为主节点，这样的成员还有一个名字~被动成员。

四、选举仲裁者

大多数小型项目，MongoDB只有两个副本集，为了参与选举，MongoDB支持一种特殊类型的成员，称为仲裁者，其唯一作用就是参与仲裁。仲裁者不参与存储数据，也不会为程序提供服务，它只是为了帮助只有两个副本集的集群选举主节点（为了满足大多数），需要注意的是，只能有一个仲裁者。

仲裁者的缺点：

假设有一个主节点，两个从节点，一个仲裁者。如果一个从节点停止运行了，那么就需要一个新的从节点，并且将主节点的数据复制到新的从节点，复制数据会父服务器造成很大的压力，降低程序运行速度。所以，尽可能使用奇数的从节点，而不是使用仲裁者。

五、同步

MongoDB通过保存操作日志oplog使多台服务器间保持相同的数据，oplog中保存着主节点执行的每一次写操作。oplog存在于主节点local数据库中的一个固定集合中，从节点通过查询此集合以获取需要复制的操作。

每个从节点同样维护着自己的oplog，用来记录它从主节点复制的每个操作。这使得每个成员都可以被用作其他成员的同步源。如果应用某个操作失败，则从节点会停止从当前数据源复制数据。

如果一个从节点由于某种原因停止工作了，它重新启动后，会从oplog中的最后一个操作开始同步。由于这些操作是先应用到数据上然后再写入oplog，因此从节点可能会重复已经应用到数据上的操作。MongoDB在设计时考虑了这点，oplog中的操作执行一次和多次，效果都是一样的，oplog中的每个操作都是幂等的。

六、处理过时数据

如果某个从节点的数据远远落后于同步源当前的操作，那么这个从节点就是过时的。过时的从节点无法赶上同步源，如果继续同步，从节点就需要跳过一些操作。此时，需要从其它节点进行复制，看看其它成员是否有更长的oplog以继续同步。如果都没有，该节点当前的复制操作将停止，需要进行完全同步或从最近的备份中恢复。

为了避免出现不同步的节点，让主节点拥有比较大的oplog以保存足够多的操作日志。

七、哈希片键

为了尽可能快地加载数据，哈希片键是最好的选择。哈希片键可以使任何字段随机分发。如果打算在大量查询中使用升序键，但又想在写操作时随机分发，哈希片键是不错的选择，不过需要注意的是，哈希片键无法执行指定目标的范围查询。

创建哈希片键：

db.users.createIndex("name":"hashed")

有一点需要注意，哈希片键的字段，不能是数组。

Error: hashed indexes do not currently support array values.

八、多热点

单独的mongod服务器在执行升序写操作时效率最高，这与分片相冲突，当写操作分发在集群中时分片效率最高。每个分片上都有几个热点，便于写操作在集群中均匀分发。

可以使用复合片键实现均匀分发，复合片键的第一个值可以是一个基数较小的值，片键的第二部分是一个升序值，这意味着在块的内部，值总是在增加的。

九、分片规则

1、分片的限制

比如上图的异常，片键不能是数组，大多数特殊类型的索引不能用作片键。特别是，不能在地理空间索引上进行分片。

2、片键的基数

片键与索引类似，在基数高的字段上进行分片，性能会更好。如果有一个status键，只有“正常”、“异常”、“错误”几个值，MongoDB是无法将数据拆分成3个以上的块（因为目前只有三个值），如果想将一个取值较小的键作为片键，那么可以将其与另一个拥有多值的键组成复合片键，比如createTime字段。这样复合片键就拥有了较高的基数。