Skip to content

Commit 540d21c

Browse files
author
SqlRush
committed
docs: explain Resource-X last-current carrier
1 parent 80b8283 commit 540d21c

8 files changed

Lines changed: 979 additions & 0 deletions

‎docs/architecture/overview.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,9 @@ and safe rejoin, see
2020
For the target block-X acquisition model, logical identity, bounded retry,
2121
T1/T2/T3 write fencing, reconfiguration sweep, and ticket-path cutover, see
2222
[Resource-X：从逻辑资源到可写 X 的完整链路](resource-x/README.md).
23+
For the narrowly proven `N + PI` case, exact last-current lineage,
24+
proof-image retention, master revalidation, and fail-closed fallback, see
25+
[Resource-X Last-Current Carrier：从 N+PI 到唯一可写 X](resource-x-last-current-carrier/README.md).
2326
For a focused explanation of how one immutable request generation keeps
2427
duplicates, retries, reconnects, successors, local buffer activation, and
2528
formation recovery attached to the same acquisition, see

‎docs/architecture/resource-x-last-current-carrier/01-n-plus-pi-and-oracle-boundary.md‎

Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
# 01：N+PI 问题、Oracle 公开行为与设计边界
2+
3+
## 1. 先区分 mode、buffer state 与版本身份
4+
5+
讨论 `N+PI` 时，最危险的误区是把“节点持有某份字节”与“节点拥有修改权限”混为一谈。
6+
7+
| 概念 | 回答的问题 | 能否单独授权写入 |
8+
|---|---|---:|
9+
| resource mode | 节点当前拥有什么全局访问权 | 只有经协调的 X 才可能进入写路径 |
10+
| buffer state | 本地缓存中的块处于 current、shared current、PI 等哪种状态 | 不能脱离全局 authority 单独授权 |
11+
| page/image identity | 这份字节属于哪个块、哪个版本边界 | 只能证明内容身份，不能证明 holder 权限 |
12+
| lineage | 这份字节是否是最后一次 current 转换的直接产物 | 是候选必要条件，但仍需 master grant |
13+
14+
`N + PI` 因而表达的是：节点没有当前修改权限，但本地保留了一份过去镜像。它没有回答这份 PI
15+
是否晚于其他 PI，也没有回答最后 current holder 是否已经安全完成交接。
16+
17+
```mermaid
18+
flowchart LR
19+
X[X mode + current bytes] -->|normal handoff| NPI[N mode + retained PI]
20+
X -->|block sent| RX[requester receives current]
21+
RX --> GX[requester obtains global X]
22+
23+
NPI -. does not imply .-> WRITE[write permission]
24+
NPI -. does not identify .-> LATEST[latest bytes]
25+
```
26+
27+
## 2. Oracle 已公开的正常 Cache Fusion 路径
28+
29+
**Oracle 已验证：** 对 changed block 的修改请求，GCS 把请求转发给最后修改该块的实例；该实例
30+
通过 interconnect 发送 current block，降级其资源并保留 PI，请求者取得 X/global 角色。Oracle
31+
还明确说明，一个块在集群中同时只能有一个 XCUR 副本，修改块前必须取得 XCUR。
32+
33+
```mermaid
34+
sequenceDiagram
35+
participant R as Requester
36+
participant G as GCS / resource master
37+
participant H as Last modifier / current holder
38+
39+
R->>G: request block for modification
40+
G->>H: forward request
41+
H->>H: freeze current bytes
42+
H-->>R: send current block over interconnect
43+
H->>H: X -> N, retain PI
44+
R->>R: receive current, take X/global role
45+
R-->>G: arrival / assume notification
46+
```
47+
48+
这个公开流程的重要含义不是某个具体消息顺序，而是三个角色必须同时成立：
49+
50+
1. GCS/resource master 协调全局资源；
51+
2. last modifier/current holder 提供 current bytes；
52+
3. requester 在 acquisition 完成后成为唯一 XCUR。
53+
54+
Oracle 官方资料还说明，当一个实例只有 PI、没有 most-recent current buffer，却发起写盘相关
55+
请求时，GCS 会把请求转发给 current/most-recent holder，而不是把“拥有 PI”直接解释为 current
56+
authority。
57+
58+
## 3. PI 的公开用途和边界
59+
60+
**Oracle 已验证：** PI 是 changed block 在转移后由原 holder 保留的过去镜像。PI 参与写协议、
61+
checkpoint/flush 协调以及实例失败后的块恢复；实例恢复会使用在线 redo，PI 可作为相关块恢复的
62+
起点。
63+
64+
**Oracle 未公开：** Oracle 官方资料没有披露一种“当目录中没有 current holder 时，从任意 PI
65+
中挑出最新一份，直接提升为新 current-X”的内部算法、wire 字段或版本证书。这里应当表述为
66+
“没有公开证据”，而不是“Oracle 一定没有这种内部优化”。
67+
68+
```mermaid
69+
flowchart TD
70+
PI[Past image] --> CR[consistent/recovery input]
71+
PI --> FLUSH[GCS-coordinated write/flush]
72+
PI --> START[instance-recovery starting point]
73+
START --> REDO[redo reconstructs required current state]
74+
75+
PI -. not sufficient alone .-> XAUTH[new writable X authority]
76+
```
77+
78+
## 4. 为什么 N+PI 是歧义状态
79+
80+
同一块可能经历多轮 holder 转移：
81+
82+
```mermaid
83+
flowchart LR
84+
A[Node A: X, version v1] -->|handoff| B[Node B: X, version v2]
85+
A --> API[Node A: PI of v1]
86+
B -->|handoff| C[Node C: X, version v3]
87+
B --> BPI[Node B: PI of v2]
88+
C -->|lifecycle gap| NONE[GRD shows no current holder]
89+
90+
API --> SET[PI bitmap = A,B,C?]
91+
BPI --> SET
92+
SET -. bitmap cannot rank v1/v2/v3 .-> UNKNOWN[which bytes are last current?]
93+
```
94+
95+
位图可以说“谁可能持有 PI”，但不能回答：
96+
97+
- 哪一份 PI 对应最后一次 X owner；
98+
- PI 是否在转换后又被刷新、替换或失效；
99+
- page identity 与全局 authority generation 是否仍属于同一轮；
100+
- formation、source incarnation 或 master session 是否已经变化；
101+
- 这份 PI 是否只是较早恢复起点，而非可直接安装的 current bytes。
102+
103+
普通 watermark 也只能证明某个数值边界或发现倒退。如果它没有原子绑定到具体转换、具体 source
104+
和具体 image，就不能补足上述缺口。
105+
106+
## 5. PGRAC 的窄适配：last-current carrier
107+
108+
PGRAC 不建立“PI 可晋升”的通用规则，而只承认下面这个窄命题：
109+
110+
> 如果一份 retained image 能被证明是最后一个 X owner 在最后一次 `X -> N+PI` 转换中原子
111+
> 冻结的 exact bytes，并且该血缘到 grant 时仍然 current，那么它可以作为 current bytes 的
112+
> carrier；写 authority 仍只能由 resource master 单独提交。
113+
114+
```mermaid
115+
flowchart TD
116+
OBS[N + PI observed] --> LINEAGE{exact last-X lineage exists?}
117+
LINEAGE -->|no| SAFE[fail closed]
118+
LINEAGE -->|yes| PAIR{proof and exact image retained together?}
119+
PAIR -->|no| SAFE
120+
PAIR -->|yes| CURRENT{master revalidation still exact?}
121+
CURRENT -->|no| SAFE
122+
CURRENT -->|yes| AUTH[commit one X authority grant]
123+
AUTH --> INSTALL[requester exact install]
124+
```
125+
126+
这条路径与 Oracle 的外部安全约束一致：由 master 协调、N 不可写、块走 cache-to-cache、全局只有
127+
一个可修改 current。它的 certificate、retained pair 和复核算法是 **PGRAC 自研适配**。
128+
129+
## 6. 三条路径不能混为一谈
130+
131+
| 路径 | 输入 | 输出 | 适用条件 |
132+
|---|---|---|---|
133+
| 正常 current-holder transfer | 明确的 current/most-recent holder | current bytes + 新 X grant | 首选正常路径 |
134+
| exact last-current carrier | 最后 X→N+PI 原子证书和同快照 image | 经复核的 carrier + 新 X grant | 仅窄 N+PI gap |
135+
| PI+redo recovery | 恢复起点、redo 与 recovery authority | 重建后的 current | 无法证明直接 carrier 或发生故障恢复 |
136+
137+
exact carrier 不是 recovery 的替代品。只要 lineage 不完整、source 已漂移、页面版本有冲突或
138+
formation 已变化，就必须返回 fail-closed/recovery 分支。
139+
140+
## 7. Oracle 官方资料
141+
142+
- [Oracle9i RAC：Cache Fusion and the Global Cache Service](https://docs.oracle.com/cd/A91202_01/901_doc/rac.901/a89867/pslkgdtl.htm)
143+
- [Oracle9i RAC：Write Protocol、PI 与 Recovery](https://docs.oracle.com/cd/A97630_01/rac.920/a96597/pslkgdtl.htm)
144+
- [Oracle RAC Administration Guide：GCS、GES、GRD 与 Cache Fusion](https://docs.oracle.com/en/database/oracle/oracle-database/21/racad/real-application-clusters-administration-and-deployment-guide.pdf)
145+
- [Oracle RAC：Managing Backup and Recovery](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery.html)
146+
- [Oracle RAC：Monitoring Cache Fusion Performance](https://docs.oracle.com/en/database/oracle/oracle-database/18/racad/monitoring-performance.html)

‎docs/architecture/resource-x-last-current-carrier/02-last-current-lineage-certificate.md‎

Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
# 02：最后 current 血缘证书
2+
3+
last-current carrier 的关键不是多记录一个版本号，而是证明一条不可拼接的因果链：
4+
5+
```text
6+
某个节点确实是最后 X owner
7+
↓
8+
它在关闭写权限的同一次转换中冻结了这份 image
9+
↓
10+
image、source identity 和 authority transition 属于同一快照
11+
↓
12+
此后没有新的 current owner、formation 或 authority generation 取代它
13+
```
14+
15+
只有整条链成立，PI 才是“last-current carrier 候选”；它依然不是 X authority。
16+
17+
## 1. 证据强度阶梯
18+
19+
不同观测的证明力不能混用：
20+
21+
```mermaid
22+
flowchart BT
23+
T[topology: node appears in PI set]
24+
W[watermark: observed progress boundary]
25+
P[provenance: who last advanced an observation]
26+
L[exact transition lineage]
27+
I[exact retained image identity]
28+
A[master revalidation + authority grant]
29+
30+
T --> W --> P --> L --> I --> A
31+
32+
T -. insufficient for grant .-> NO[no write authority]
33+
W -. insufficient for grant .-> NO
34+
P -. insufficient for grant .-> NO
35+
```
36+
37+
| 证据 | 可以证明 | 不能证明 |
38+
|---|---|---|
39+
| PI holder set | 哪些节点可能保存某个 PI | 哪个 PI 最新、内容是什么 |
40+
| watermark | 某个观察值未低于已知边界 | 该值对应哪份 image、谁仍拥有它 |
41+
| historical provenance | 某次观察由哪个 source 推进 | source 当前仍保留同一份字节 |
42+
| transition lineage | image 与某次 X→N+PI 转换同源 | 当前 master 尚未被新轮次替代 |
43+
| retained image identity | proof 指向同一冻结 image | 可以绕过 master 直接写 |
44+
| current master grant | authority 在当前轮次被唯一提交 | requester 已完成本地安装 |
45+
46+
因此，topology、watermark 和历史 provenance 都只能做**辅助复核**；它们不能互相拼凑成
47+
last-current authority。
48+
49+
## 2. 证书的语义内容
50+
51+
公开架构只规定语义，不冻结具体 C struct、字节偏移或消息布局。一个 last-current lineage
52+
certificate 至少要把以下事实绑定为一个不可分割对象：
53+
54+
| 语义域 | 必须回答的问题 |
55+
|---|---|
56+
| resource identity | 这是哪个数据库块/逻辑资源？ |
57+
| source identity | 哪个节点、哪次启动/连接上下文冻结了它？ |
58+
| formation identity | 它属于哪一轮集群成员关系？ |
59+
| master/authority lineage | 哪次 authority transition 把最后 X 关闭并产生 N+PI？ |
60+
| local image generation | source 本地缓存对象在冻结前后是否为同一代？ |
61+
| page version boundary | image 对应哪个页面版本、SCN/LSN 边界？ |
62+
| content identity | proof 与 image 内容是否可用 checksum/摘要精确 join？ |
63+
| transition identity | duplicate/retry 是否仍指向同一次 X→N+PI？ |
64+
65+
这里的 generation 都属于各自域。不得把 page SCN、ship boundary、BufferDesc generation、
66+
master generation 等不同量塞入同一个字段后假定它们可比较。
67+
68+
```mermaid
69+
classDiagram
70+
class LastCurrentCertificate {
71+
+ResourceIdentity resource
72+
+SourceIdentity source
73+
+FormationIdentity formation
74+
+AuthorityLineage transition
75+
+LocalImageGeneration image_generation
76+
+PageVersionBoundary page_version
77+
+ContentIdentity content_digest
78+
}
79+
80+
class RetainedImage {
81+
+ResourceIdentity resource
82+
+LocalImageGeneration image_generation
83+
+PageVersionBoundary page_version
84+
+ContentIdentity content_digest
85+
+Bytes immutable_bytes
86+
}
87+
88+
LastCurrentCertificate "1" --> "1" RetainedImage : exact join
89+
```
90+
91+
## 3. 证书必须在转换点产生
92+
93+
如果系统在看到 `N+PI` 后才回头组合历史记录，会遇到经典的 time-of-check/time-of-use
94+
问题：source 可能已经转移过多次，buffer slot 可能被重用，watermark 也可能由另一条路径推进。
95+
96+
正确的线性化点是：最后 X owner 仍拥有关闭写权限所需的本地与全局上下文时，在同一转换
97+
critical section 内冻结证书和 image identity，然后才发布 X→N+PI。
98+
99+
```mermaid
100+
sequenceDiagram
101+
participant H as Last X holder
102+
participant B as Local buffer authority
103+
participant M as Resource master state
104+
participant R as Retained-pair owner
105+
106+
H->>B: lock exact resource/image generation
107+
H->>M: validate current X lineage
108+
H->>R: freeze certificate + image identity
109+
R-->>H: retained pair armed
110+
H->>B: close ordinary writes
111+
H->>M: publish X -> N+PI transition
112+
H->>B: release local critical section
113+
```
114+
115+
顺序约束：
116+
117+
1. arm 失败时，不能先丢失最后 X 或释放 image；
118+
2. certificate 与 image identity 必须在写关闭前后做同代复核；
119+
3. X→N+PI 发布后，任何修改都必须通过新的 authority acquisition；
120+
4. duplicate 只能重放同一 immutable pair，不能重新采样一份“看起来相同”的页面。
121+
122+
## 4. 如何证明它是“最后一次”
123+
124+
“source 曾经是 X holder”不够。master 必须能证明这次 transition 在当前 resource lineage 上没有
125+
后继 current owner：
126+
127+
```mermaid
128+
stateDiagram-v2
129+
[*] --> X_CURRENT
130+
X_CURRENT --> PAIR_ARMED: freeze exact certificate + image
131+
PAIR_ARMED --> N_PI: commit X -> N+PI
132+
N_PI --> SUPERSEDED: another current/X generation committed
133+
N_PI --> CANDIDATE: no successor current, exact lineage current
134+
CANDIDATE --> GRANTABLE: master full revalidation
135+
136+
SUPERSEDED --> [*]: old pair can only retire
137+
CANDIDATE --> [*]: drift/mismatch => fail closed
138+
```
139+
140+
需要同时成立：
141+
142+
- transition 是该 resource 当前 authority lineage 的末端；
143+
- source identity、formation 和 master session 仍然匹配；
144+
- source 节点仍被当前成员关系承认；
145+
- 该 source 的 PI membership 仍存在；
146+
- 没有 X/S holder 或更晚的 transition 与之冲突；
147+
- retained image 的本地 generation 和内容 identity 未发生漂移。
148+
149+
任何一项无法证明，都不能退化成“选择 watermark 最大的 PI”。
150+
151+
## 5. ABA 与重用防护
152+
153+
相同 BufferTag、相同节点甚至相同页面 SCN 都可能在不同 acquisition 中再次出现。证书必须区分：
154+
155+
```mermaid
156+
flowchart LR
157+
A1[resource R / source A / generation 10] --> N1[N+PI pair P1]
158+
N1 --> X2[new X owner / generation 11]
159+
X2 --> N2[resource R / source A / generation 12 / pair P2]
160+
161+
P1[P1 bytes] -. same tag, stale lineage .-> REJECT[reject]
162+
N2 --> ACCEPT[P2 current candidate]
163+
```
164+
165+
- tag 相同不代表 transition 相同；
166+
- source node 相同不代表 incarnation 相同；
167+
- page SCN 相同不代表 BufferDesc generation 相同；
168+
- retry request 相同不代表 master session 未变化；
169+
- checksum 相同只能证明内容相同，不能证明 authority 相同。
170+
171+
## 6. Lineage diagnostic gate
172+
173+
在启用该 fast path 前，应先有确定性诊断证明当前 `N+PI` 问题确实来自“最后 X holder 已完成
174+
X→N+PI，但 current-holder 生命周期没有留下可直接路由的 holder”。诊断应区分三类结果：
175+
176+
| 诊断结果 | 行为 |
177+
|---|---|
178+
| exact immediate lineage | 允许进入 retained-pair 路径 |
179+
| lineage 被后继 current 取代 | 丢弃旧 pair，路由到新 holder |
180+
| lineage 缺失或无法判定 | fail closed；修复 holder lifecycle 或进入 recovery |
181+
182+
这道 gate 防止把一个 current-holder 记账缺陷隐藏成“PI promotion”。如果根因是 holder 本应仍在，
183+
优先修复 holder 生命周期，而不是扩大 fast path。

0 commit comments

Comments
 (0)