公司是数据存储容灾的行业, 目前有套双控软件是使用couchdb及其复制功能来实现两个节点的数据同步. 目前面临的问题是couchdb小众且非关系型数据库, 学习成本高, 招聘不容易, 因此想尝试是否能用sql db进行替换.
我们的目标是多节点间数据一致即可.
问题:
- 目前双控是两个节点, 以后实现多活会是四节点. tidb是基于raft进行复制, 推荐是n>=3且是奇数, 是否能适用我们的场景.
- 如果可行, 假设某节点掉线并重新上线后, 如何查询该节点数据已重新与其他节点一致?
公司是数据存储容灾的行业, 目前有套双控软件是使用couchdb及其复制功能来实现两个节点的数据同步. 目前面临的问题是couchdb小众且非关系型数据库, 学习成本高, 招聘不容易, 因此想尝试是否能用sql db进行替换.
我们的目标是多节点间数据一致即可.
问题:
TiDB 存储节点之间通过 raft 复制来保证数据的一致性,默认是 3 副本,奇数个节点是满足大多数可用的最少节点数,比如 3 节点和 4 节点的多数节点都是 2,可用性上没有差别;两节点可以在集群内部通过设置 label 标签的方式使数据分布在不同的节点上,但是单个集群至少需要 3 个存储节点,通过增加更多节点实现性能和存储的水平扩容。
1、默认 3 副本可以在同城 3 机房部署(异地网络延迟高,使用专线成本高),结合 label 设置实现机房之间的容灾,即每个机房都有一份完整的数据副本,且各机房都可以接入应用端访问数据库,任何1个机房不可用不会影响可用性和数据的完整性,满足 3 机房多活的需求;以后实现四节点多活,我理解每个节点是拥有一份完整的数据,可以通过增加副本数的方式,比如改为 5 副本,并结合 label 标签属性使数据分布在 5 个节点(机房),达到四节点多活的目标。
2、某个节点掉线重现上线后,会自动通过 raft log 或 snapshot 方式获取 leader 节点的数据并最终同步;可以查看该节点上的 region 和 leader 数量和状态了解数据的分布,当同步一致后,其他可用节点会将 leader 和 region transfer 到该节点上,达到数据分布平衡。
@qizheng-PingCAP 首先感谢你的回复, 你的回答和我的设想有些出入.
是我之前的描述不够清晰. 我重新更正一下:
简单来说就是要借助tidb的raft复制(但节点数是2或4)和sql功能, 但不需要region分片. 请问tidb适合我们这样的场景吗?
如果数据量不大,希望实现数据的双向复制和 sql 功能,可以考虑先迁移到 mysql 部署双主节点实现双活,如果考虑一致性可以用 MGR 或 MySQL Cluster 方案,多活可以通过 mysql binlog 复制到其他从集群或节点。
如果是一个双控节点的话确实用mysql 部署双主节点方便, 但考虑到以后会是四节点, 能一步规划到位就更佳. 相比MGR 或 MySQL Cluster, 我并不熟悉, 但tidb我有自己的测试环境, 更熟悉一些.
而且tidb原生是分布式db我想运维上能更省事. 当然目前是db调研阶段, 想接触更多的选择, 如果确实不合需求那也只能另选方案.
如果要求四节点,每个节点上有一份完整的副本,集群也可以运行,并且 raft 会确保多数节点即三个节点的数据是一致的,但是宕掉任意两个节点,集群就不可用了,需要再评估下;为了确保每个“双控节点” 的可用性,需要增加冗余节点,即部署五副本五个节点,多的这个节点单独放置且通过策略不调度 leader 到上面 ,只进行投票,这样保证每组“双控节点“ 出现故障,另外一组的可用性,这样类似两地三中心的场景。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。