ALTER DATABASE ... READ ONLY 在所有者值不变时完成同步,而不发布架构版本,导致其他 TiDB 节点永久分歧

□ 错误报告

1. 最小繁殖步骤(需要) 分会功能/放行-8.5-只读@48e340f5bf7fe4a19c2763fa2bf41d3c013536a (追踪问题#62122).

A. 单位断言

使用 dbInfo 调用修改SchemaRead 。 (原始内容存档于2017-10-12). Read only === (帮助). 仅读 :

观察:ver == 0,无 schema diff 写作,工作仍报告 州: syenced 预期:ver!=0,发布diff

B. 纯 SQL, 2 TiDB 节点

数据d;
d.t.表(d INT Primary Key, v VARCHAR(16));
其他数据只读为 1; - 两个节点现在都缓存只读为 1

然后从两个不同的TiDB节点同时发射只读取的Altter Database = 0。 创造了两个工作,只有一个分配一个计划版本:

职业类型
116 修改方案只读取同步 < -- 已公布
115 修改计划只读取同步 < -- 真实工作,vr 58 - > 59

[job worker.go:1124]"schema版本不变" jobID=116

N工作,N-1计划版本. 串行冗余的 ALTER 完全没有工作, 因为执行器侧面检查( pkg/ ddl/ executor.go: 428) 对提交节点缓存的短路 工作提交前的InfoSchema。

C. 端到端——如何成为永久停产

在独立集群上再出两次,最近一次是在一款新建而无前作历史的集群上: PD 1 + TiKV 1 (stock pingcap/{pd,tikv}:v8.5.8, max-replicas=1) + TiDB ×2 运行分支二进制(Git分支:特性/release-8.5-read 只读出,Git Communication Hash:48e340f5bf).

1. 数据d+表;只读的替代数据=1. 两个节点报告只有1个。
2. 启动日志备份, 继续锁定时抓取快照( snapshot carage Read Only=1) 。
3. 其他数据只读为0-记录。 等待日志检查站通过.
4. 放下数据库,然后恢复PiTR。

恢复将数据库元重写为 ReadOnly=0出带子——没有DDL任务,没有diff,没有每个数据库版本的出出出出出出出出出出出出出出出. 如果没有任何内容迫使节点重新读取数据库的元,它们会无限期地保留被缓存的ReadOnly=1(关于生产中为什么会发生这种情况,参见§3). 纠正的解锁是无声的:

在恢复两个节点只读后=1,INSERT - > ERROR 3989,计划版本104 (a). ` 其他数据只读为 0; -- 无错误,无警告 计划版本 104 - > 104 < -- 无核查

重试无益. 四次解锁尝试产生了4个工作,4个日志行,零版本增量:

[job worker.go:1124] "schema版本不变" jobID=159
[job worker.go:1124] "schema版本不变" jobID=160
[job worker.go:1124]"schema版本不变" jobID=161
[job worker.go:1124] "schema版本不变" jobID=162

其中之一的整个生命周期——注解状态:synced,错误::

[job worker.go:830] "运行的DDL工作"工作ID=159
[job worker.go:1124] "schema版本不变" jobID=159
[job worker.go:423] (英语).
. . . . . . .