谁能推荐一个成熟的一致性哈希的 mysql 分库方案

[xing393939]

RT ，重点想了解怎么无缝迁移复制数据的，有成熟方案或者这方面的文章吗？

[iyaozhen]

即使一致性 hash 也不能完全无痛扩容。比如增加一个节点，需要计算一下把其它节点的数据复制到新节点去，这个要看具体的策略了。

还是之前先预估好分库分表的大小，然后使用 DB Proxy 屏蔽分库分表和读写分离的逻辑。

[xss]

提供一个思路吧,没验证过可行性,不是专业搞数据库的.
首先 A 库是需要扩容的库.
设置一个 B 库,作为 A 库的 Slave.但是在正式从 A 库同步数据之前,先在 B 库里设置一个触发器,作用如下.
1. 新建一个 C 库,采用新的 hash 计算策略.
2. B 库中的触发器根据 C 库的策略向 C 库写数据.
然后 A 库的内容会根据新的策略入 C 库.
最后启用 C 库作为新的数据库,等 B 库向 C 库同步完 A 库的数据后,将 A,B 库下线.

[wander2008]

这种问题问出来了说明需要找人了。只少一百万搞？

[blueswhisper]

分库是切分业务关联不是特别紧密的表到单独的库，以减轻当前数据库的压力。 楼主想问的是分表吧，将一张数据量超大的表按照一定的规则映射到不同的数据库分段存储,也就是 sharding 。 sharding 方案要结合业务场景考虑的，一致性 hash 不是万能药，一般来说 sharding 方案的设计就需要保证不会出现单片数据过热的情况，一旦方案实施后几年内是不需要再考虑 sharding 数据迁移的问题（因为 sharding 后的数据大致是均匀分布的）。 就算因为某种外部因素导致不得不迁移数据，还是建议业务低谷期阻断到数据库的访问，停机迁移数据，保证数据一致性。 因为一般需要落库的数据都是有状态的，保险起见还是停机迁移。 既然停机迁移，用不用一致性 hash 也无所谓了。