tikv学习3pd

在 TiDB 集群中，**PD（Placement Driver）** 提交和更新应用数据的核心流程涉及 **元数据管理**、**调度决策生成** 和 **协调执行** 三个关键环节。以下是详细说明：

---

### **1. 元数据管理：PD 的核心存储**
PD 维护集群的全局元数据，包括以下内容：
- **Region 分布信息**：每个 Region 的副本位置（Peer）、Leader 信息、版本号等。
- **Store 状态**：TiKV 节点的标签（Labels）、容量、负载状态等。
- **调度策略**：副本数量、均衡规则、优先级配置等。

#### **元数据存储机制**
- PD 使用 **etcd** 作为底层分布式键值存储，确保元数据的 **高可用** 和 **强一致性**。
- 所有元数据变更（如 Region 分裂、Store 上下线）会通过 **Raft 共识算法** 提交到 etcd 集群。

#### **示例流程：Region 分裂后的元数据更新**
1. 当某个 Region 大小超过阈值（默认 96MB），TiKV 触发 **Region 分裂**。
2. TiKV 生成新的 Region ID 和元数据，并通过 **PD 的 gRPC 接口** 上报分裂请求。
3. PD 验证请求后，将新的 Region 信息写入 etcd，并更新内存中的 Region 路由表。
4. 其他 TiKV 节点和 TiDB 通过 PD 获取最新的 Region 分布信息。

---

### **2. 调度决策的生成与提交**
PD 持续监控集群状态，基于预设策略生成调度任务（Operator），并通过协调 TiKV 节点执行这些任务。

#### **调度决策的生成**
- **输入**：集群负载、Region 分布、Store 状态、用户定义的规则（如 `placement-rule`）。
- **策略类型**：
- **负载均衡**：将热点 Region 迁移到低负载节点。
- **副本修复**：补充缺失的副本或替换故障节点。
- **手动干预**：通过 `pd-ctl` 强制触发特定操作。

#### **调度任务的提交与执行**
1. **生成 Operator**：
PD 根据策略生成一个 **Operator**（如 `TransferLeader` 或 `AddPeer`），包含具体的操作步骤。
```go
// 示例：迁移 Leader 的 Operator
op := operator.NewOperator("transfer-leader", regionID, operator.TransferLeader{FromStore: oldLeader, ToStore: newLeader})
```
2. **提交到调度队列**：
Operator 被放入 PD 的 **调度队列**，等待下发到目标 TiKV 节点。
3. **下发指令到 TiKV**：
PD 通过 **gRPC** 将操作指令发送给相关 TiKV 节点。例如：
- 发送 `AddPeer` 指令到目标 TiKV，要求其新增一个副本。
- 发送 `TransferLeader` 指令到当前 Leader，要求其转移 Leader 角色。
4. **TiKV 执行操作**：
TiKV 接收到指令后，通过 **Raft 协议** 在集群内达成一致，完成操作。例如：
- `AddPeer`：新副本加入 Raft Group，开始同步数据。
- `RemovePeer`：副本从 Raft Group 中移除，数据被清理。
5. **状态反馈与确认**：
TiKV 将操作结果反馈给 PD，PD 更新元数据并标记 Operator 完成。

---

### **3. 数据一致性与容错机制**
为确保调度操作的安全性和一致性，PD 依赖以下机制：

#### **Raft 协议保障数据复制**
- 所有 Region 的变更（如写入、副本迁移）通过 **Raft 日志** 在副本间同步。
- PD 不直接修改数据，而是通过下发指令触发 TiKV 的 Raft 状态机变更。

#### **Operator 的原子性**
- 每个 Operator 包含多个步骤（如 `AddPeer` → `TransferLeader` → `RemovePeer`），PD 确保这些步骤要么 **全部成功**，要么 **回滚**。
- 若某步骤失败（如目标 TiKV 宕机），PD 会重新生成调度策略。

#### **心跳机制与状态监控**
- TiKV 定期向 PD 发送 **心跳信息**，包含 Region 的元数据和负载状态。
- PD 通过心跳检测异常节点，并触发副本修复或 Leader 转移。

---

### **4. 示例场景：扩容新节点后的数据迁移**
假设集群扩容一个 TiKV 节点（Store 4），PD 的完整流程如下：

1. **Store 注册**：
新 TiKV 节点启动后，向 PD 注册并上报标签（如 `zone=z1, host=h4`）。
2. **负载检测**：
PD 发现现有节点负载不均衡（如 Store 1 的磁盘使用率超过 80%）。
3. **生成调度任务**：
PD 生成多个 `MovePeer` Operator，将部分 Region 的副本从 Store 1 迁移到 Store 4。
4. **下发指令**：
PD 通过 gRPC 通知 Store 1 和 Store 4 执行副本迁移。
5. **Raft 变更**：
- Store 1 作为 Leader，向 Raft Group 提交 `AddPeer` 请求，添加 Store 4 为 Follower。
- 数据同步完成后，Store 4 成为合法副本，Store 1 触发 `RemovePeer` 移除自身副本（如需缩容）。
6. **元数据更新**：
PD 更新 Region 的副本分布信息，并同步到 etcd。

---

### **5. 关键配置与工具**
#### **PD 相关配置**
- `schedule.max-merge-region-size`：控制 Region 合并的阈值。
- `replication.max-replicas`：定义集群的副本数量。
- `label-property`：指定故障域标签（如 `zone`）。

#### **运维工具**
- **pd-ctl**：命令行工具，用于手动触发调度或查询状态。
```bash
# 强制迁移 Region 100 的 Leader 到 Store 4
pd-ctl operator add transfer-leader 100 4
```
- **TiDB Dashboard**：可视化界面，监控调度操作和集群状态。

---

### **总结**
PD 提交和更新应用数据的过程本质上是 **通过协调 TiKV 节点完成元数据变更和调度操作**，其核心步骤为：
1. **元数据管理**：通过 etcd 持久化集群状态。
2. **调度决策**：生成 Operator 并下发到 TiKV。
3. **执行与反馈**：TiKV 通过 Raft 协议完成变更，PD 确认结果并更新元数据。

这一流程确保了 TiDB 集群的 **高可用性**、**数据均衡性** 和 **故障自愈能力**，是分布式数据库高效运行的关键。