tidb在双控场景应用的疑问

公司是数据存储容灾的行业, 目前有套双控软件是使用couchdb及其复制功能来实现两个节点的数据同步. 目前面临的问题是couchdb小众且非关系型数据库, 学习成本高, 招聘不容易, 因此想尝试是否能用sql db进行替换.

我们的目标是多节点间数据一致即可.

问题:

  1. 目前双控是两个节点, 以后实现多活会是四节点. tidb是基于raft进行复制, 推荐是n>=3且是奇数, 是否能适用我们的场景.
  2. 如果可行, 假设某节点掉线并重新上线后, 如何查询该节点数据已重新与其他节点一致?

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 首先感谢你的回复, 你的回答和我的设想有些出入.

是我之前的描述不够清晰. 我重新更正一下:

  1. 一个双控节点是一个2U服务器刀片上有两个控制节点, 每个节点都会安装一套os及我们的存储管理软件, 它们后边连接的是共享的存储阵列. 每个控制节点db里存储的都是整个双控节点的完整状态数据.
  2. 我们的数据量不大. 我们需要的是双控的每个控制节点的数据完全一致, 任何一个控制节点掉线, 剩余那个节点的数据还是完整的, 即不关心数据分布均衡, 而是要完整, 这实际跟多写的效果类似,向任何一个节点写入的数据都会复制到另一个节点.
  3. 多活四节点其实就是一个双控节点会向另一个双控节点同步业务数据, 状态数据还是存储在db里, 还是需要每个控制节点都有完整的数据. 因此按照图 4个节点同时坏三个, 剩余节点的数据就不完整了,而我们场景要求剩余的节点的数据还是要完整的.

简单来说就是要借助tidb的raft复制(但节点数是2或4)和sql功能, 但不需要region分片. 请问tidb适合我们这样的场景吗?

如果数据量不大,希望实现数据的双向复制和 sql 功能,可以考虑先迁移到 mysql 部署双主节点实现双活,如果考虑一致性可以用 MGR 或 MySQL Cluster 方案,多活可以通过 mysql binlog 复制到其他从集群或节点。

如果是一个双控节点的话确实用mysql 部署双主节点方便, 但考虑到以后会是四节点, 能一步规划到位就更佳. 相比MGR 或 MySQL Cluster, 我并不熟悉, 但tidb我有自己的测试环境, 更熟悉一些.

而且tidb原生是分布式db我想运维上能更省事. 当然目前是db调研阶段, 想接触更多的选择, 如果确实不合需求那也只能另选方案.

如果要求四节点,每个节点上有一份完整的副本,集群也可以运行,并且 raft 会确保多数节点即三个节点的数据是一致的,但是宕掉任意两个节点,集群就不可用了,需要再评估下;为了确保每个“双控节点” 的可用性,需要增加冗余节点,即部署五副本五个节点,多的这个节点单独放置且通过策略不调度 leader 到上面 ,只进行投票,这样保证每组“双控节点“ 出现故障,另外一组的可用性,这样类似两地三中心的场景。