与单台机器相比,MongoDB和TokuMX的分片在应用横向扩展上做得很好,但也带来了新的挑战到台面上。其中之一是如何处理正在运行系统迁移的影响。许多用户使用哈希片键试图完全避免迁移,但如果不适合应用,一些人将均衡窗口(balancing window)安排在低峰期。

随着TokuMX 1.4分片的改进,用户一般不需要担心迁移了。 昨日我介绍了两个大的改进,这个是一个较长的故事:

在MongoDB中和TokuMX 1.3及更早的版本,迁移是一个复杂的过程,涉及到许多锁,后台线程,协调,以及大量的内部命令在路由mongos,分片服务器(mongod)和配置服务器(config server)之间来回。 这在MongoDB中是必要的,确保沿途没有数据丢失,而且对迁移块的所有修改的不会因为迁移丢失或重复。 为了安全,此前TokuMX发布的版本实施了类似的算法,但现在已经利用内部事务,使迁移更简单,更可靠,更快速。 我要深入一些细节来展示事务是如何帮助我们的。

要迁移一个块,基本上有三个步骤:克隆现有的数据,追赶迁移过程中的修改,并以两阶段提交的形式在服务器之间提交。 在MongoDB中,克隆通过一些基于磁盘上的位置特定的命令,排序现有文档,然后分批转移。 在此期间修改是(如果有太多的变化,以保持在内存中,迁移将失败)跟踪在内存中,并最终所有修改过的文档重新拷贝(或删除)以赶上变化。 每个克隆的文档需要添加为一个更新插入(upsert)操作,以避免重复的文档(该操作必须是幂等)。

为了安全,两阶段提交是需要的,所以我们并没有改变。 在TokuMX 1.3我们保留了克隆命令,但有他们只是在内部做正常的查询(因为片键关键是聚簇的键,文档已经正确的排序以快速访问),并且我们改变了跟踪修改(相关代码)本质上是记录修改到看起来像OPLOG的临时集合。

在TokuMX,每一个更新插入(upsert)需要先查询,看看是否该文档已经存在,并且该查询可能花费一个随机I/O,这将是缓慢的。 重要的是需要注意到TokuMX的分形树索引插入可以比这个快得多,而不会造成任何随机I/O。

在TokuMX 1.4,我们已经完全废除克隆命令(与1.3兼容性除外),相反的,我们开启一个的MVCC的快照事务(并开始记录修改),然后在提供方分片的数据块上做一个正常的游标查询,就像任何其他的游标,而不是来回发送命令。 在接收方,我们现在发送插入(insert )消息而不是做隐藏有查询的upserts操作,我们可以做是因为我们用快照事务来从提供方读出。 在追赶阶段将仍然只是重放发生在提供方的操作即可。 (太NB了,有木有!)

这简化了过程并使测试更容易,但性能如何呢? 在提供方,唯一的工作就在片键上做范围查询,片键默认是聚簇的,而且是快速的顺序I/O 。 在接收方,事情有点复杂。 虽然我们不再自动做upserts查询,我们仍然需要检查的“_id”字段的唯一性。 如果片键就是{_id:1},那么唯一性检查将是在顺序的键上,所以I/O是没有问题的,而且会非常快。 但是,如果片键是别的,那么这些将是随机的查询,并且可能是缓慢的。

如果我们当我们第一次插入的数据已经做了(唯一性检查),为什么要为唯一性检查而烦恼? 分片集合除了片键外不能保证索引的唯一性。 这意味着,一个行为不端的应用程序可以插入具有相同_id两个文档,​​但片键不同的,因此他们最初进入不同的分片。 如果迁移移动这些文档到相同的分片,我们要检测具有相同的_id的文档。 如果以下两个适用,然后在迁移过程中跳过了唯一性检查可能会导致数据丢失:

  • 集合的片键不是主键。 这不是shardCollection的默认行为,但是是可能的,对现有的集合分片时尤其如此。
  • 应用程序手动指定文档_id,并指定相同的_id到两个不同的文档, 这已经是MongoDB中的误用 。

为了在任何情况下保护我们的用户,TokuMX 1.4在迁移过程中始终做了独特的检查,数据丢失是不可能的。 (默认情况下)。

TokuMX 1.4有一个新的设置叫 migrateUniqueChecks 控制这种行为。 它的默认值是“true”,但如果你知道下列任何都是正确的,你可以关闭这个:

  • 你是用主键分片。
  • 你用MongoDB来为应用程序指定_id(即使用默认_id)。
  • 你知道你的_id都是全局唯一的,并且如果他们不是,愿意承担后果。 如果任何这些适用,你可以启动分片时设置 --setParameter migrateUniqueChecks=false 。 如果你这样做,那么在接收方分片中也将不会有随机I/O,在批量克隆阶段,迁移将显著加快。 在没有更新操作的工作负载,你其实可以在群集上做一个完整的迁移而在任何分片上不引起任何随机I/O。

TokuMX 1.4.0块迁移现在比以往任何时候都更快。 看看块迁移的 benchmark ,看看他们是多么快。

参考: http://www.tokutek.com/2014/02/whats-new-in-tokumx-1-4-part-5-faster-chunk-migrations/

0 回复
需要 登录 后方可回复, 如果你还没有账号你可以 注册 一个帐号。