[FAQ] stale read/follower read在读写分离场景下的区别?

假如我有一个2地三中心(如北京2,重庆1)的应用,重庆作为灾备中心,但也承接了部分读业务流量,写还是写到北京,然后在重庆读,为了减少网络延时带来的性能损耗,看官网文档是可以利用stale read来解决,我的问题是:

1,stale read和follower read 本质都是读其他副本,他们区别是什么?仅仅是因为follower可以强一致读?如果follower read前提下,配置成重庆读重庆,是不是性能不如 stale read?

2,如果业务的确要求强一致读,follower read的强一致读的延迟有多久,或者说READ要被阻塞多久才能返回强一致数据(假设重庆PING 北京 25ms)

1 个赞

谈谈理解,可能不太正确

  1. follower read需要和leader发起通信获取commit_index,并等到apply到该点,一致性时点是事务开始时。 stale read 是在SQL中as of timestamp直接指定某个时间点或指定时间范围TIDB_BOUNDED_STALENESS()自动指定一个时间点的数据,是某个历史时刻的一致数据,有点类似闪回查询。
  2. follower read开启需要设置session级参数tidb_replica_read,没有地理位置的感知能力,会把请求发到远端数据中心。 stale read在多数据中心时是需要tidb server设置和tikv 一样的数据中心级lable标签 ,这样会把请求发到所在数据中心,实现就近读。
  3. follower read 不仅有网络通信还要等apply ,具体延时还受磁盘IO、CPU影响。
1 个赞

多谢了,概念上已经清晰很多;
工程上,如果需要满足这种就近读或读写分离场景,建议用TICDC/TIBINLOG还是stale read呢?

1 个赞

binlog官方已经逐步放弃了,stale read还要每次SQL加上时间条件 感觉不适合业务处理,历史数据查询还行

指的是 通过系统变量 tidb_snapshot 读取历史数据吗?看文档也是推荐stale read啊

1 个赞

原理是一样的 ,都是通过GC时间内的MVCC数据库获取历史时间点数据,这里意思是用stale read的就不用设置tidb_snapshot变量这种方式了 。

stale read是适用于能容忍不用读实时数据的情况

能估计个大概的LAG吗?假设2中心PING延迟25ms下的stale read表现

1 个赞

:joy:这个真估不出来,看看有没有相关经验的回复吧

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。