【 TiDB 使用环境】生产/测试
【 TiDB 版本】
7.5.1,8.1.0
【复现路径】
tidb有2个节点
通过连接1执行建表,并新开连接2执行查询
当这两个连接不在同一个tidb节点上时,连接2有几率短时间内报错:table not exists
【遇到的问题：问题现象及影响】
需要手工等待一段时间以后,才可以在连接2上查到新建的表
【资源配置】*进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图
【附件：截图/日志/监控】
如下图日志,在tidb-1上create table,在tidb-0上select ,会报错
你可以脚本等待一个时间
应该是预期的结果，tidb 的 schema version 存储在pd，schema version 的变化并非实时被告知所有 tidb-server
F1 算法论文：
Asynchronous schema change Because there is no global
membership in F1, we cannot synchronize the schema
change across all F1 servers. In other words, different
F1 servers may transition to using a new schema at
different times.
你日志里那条是 start ddl job，不能证明其完成了吧
状态是synced,应该算完成了吧
道理明白,但是应用的时候很恶心啊,需要业务代码端做手工轮询等待,我们线上环境,最多有需要等超过一分钟的,已经属于影响用户体验了
理论上可以加个同步机制,哪怕是手工触发也行
是的，但从日志看，没发现你说的一个节点创表，第二个节点看不到的情况
func (do *Domain) loadSchemaInLoop(ctx context.Context, lease time.Duration) {
defer util.Recover(metrics.LabelDomain, “loadSchemaInLoop”, nil, true)
// Lease renewal can run at any frequency.
// Use lease/2 here as recommend by paper.
ticker := time.NewTicker(lease / 2)
一个搜主意，看代码里 loadschema 应该是 1/2 lease 做，所以是不是可以降低 lease 设置？调整的影响不确定
我觉得楼上说的对，那个只是开始时间，不是结束时间，执行这个看看记录的结束时间是什么时间？
ADMIN SHOW DDL JOBS
