TiDB 和 HBase 副本机制及其故障转移流程

--- ### **一、TiDB 与 HBase 的副本机制对比** #### **1. TiDB 的副本机制（基于 Raft 协议）** - **核心原理**： - TiDB 的存储层 TiKV 采用 **Raft 共识算法**，每个数据 Region 默认维护 **3 个副本**，分布在不同的物理节点上。 - 写入时，数据通过 Raft Leader 同步到 Follower 副本，多数派（N/2 + 1）确认后提交，保证强一致性。 - 副本角色：Leader（处理读写）、Follower（同步数据）、Learner（只读异步副本）。 - **特点**： - **自动故障转移**：Leader 故障时，剩余副本通过 Raft 选举新 Leader。 - **数据强一致**：所有读请求默认由 Leader 处理，确保线性一致性。 #### **2. HBase 的副本机制** - **传统模式（HBase 1.x 及之前）**： - **单 Region 副本**：每个 Region 在集群中仅有一个副本，数据存储依赖 **HDFS 的多副本机制**（默认 3 副本）。 - **读写路径**：读写仅通过 RegionServer 的主副本，HDFS 副本仅用于数据持久化，不直接参与 HBase 读写逻辑。 - **Region Replication（HBase 2.0+）**： - **多 Region 副本**：允许为每个 Region 配置多个副本（需手动开启），副本分布在不同的 RegionServer 上。 - **读优化**：读请求可分发到任意副本，但写入仍通过主副本同步到其他副本（异步或同步可配）。 - **特点**： - **依赖 HDFS 副本**：数据持久化由 HDFS 保证，但 Region 副本是逻辑层面的多活。 - **最终一致性**：若启用多 Region 副本，从副本可能短暂落后主副本。 #### **3. 核心差异** | **特性** | **TiDB** | **HBase（传统模式）** | **HBase（Region Replication）** | |------------------|-----------------------------------|----------------------------------|---------------------------------------| | **副本协议** | Raft 共识算法（强一致） | 单副本 + HDFS 多副本（最终一致） | 主从异步复制（可配一致性） | | **副本角色** | Leader/Follower 明确分工 | 单主副本，无角色区分 | 主副本（读写） + 从副本（只读） | | **故障恢复** | 自动选举新 Leader，秒级切换 | 依赖 HMaster 重新分配 Region | 主副本故障后需手动或半自动切换 | | **数据一致性** | 强一致（线性一致性） | 依赖 HDFS 副本，Region 单点读写 | 主副本强一致，从副本最终一致 | --- ### **二、HBase 的 Region 副本数量** #### **1. 默认副本数** - **HBase 传统模式**： 每个 Region **仅有 1 个逻辑副本**，但数据在 HDFS 上默认存储 **3 个物理副本**（通过 HDFS 的 `dfs.replication` 参数配置）。 - **Region Replication 模式（HBase 2.0+）**： 需手动配置 `hbase.region.replica.replication.enabled` 和 `hbase.region.replica.count`，默认仍为 **1 个 Region 副本**。 #### **2. 副本作用域** - **HDFS 副本**：保障数据持久化和存储层容灾，对 HBase 透明。 - **Region 副本**：提升读可用性和负载均衡，需显式启用。 --- ### **三、HBase RegionServer 故障转移与恢复流程** 当 HBase RegionServer 挂掉时，恢复流程如下： #### **1. 故障检测** - **HMaster 监控**：通过 ZooKeeper 的会话心跳检测 RegionServer 状态，若超时（默认 3 分钟），判定为宕机。 #### **2. Region 重新分配** - **HMaster 介入**： 1. 将故障 RegionServer 上的所有 Region 标记为不可用。 2. 根据 Region 的元数据（hbase:meta 表），将这些 Region 重新分配到其他健康的 RegionServer 上。 3. 新分配的 RegionServer 从 HDFS 加载对应 Region 的数据文件（HFile）和日志（WAL）。 #### **3. 数据恢复** - **HFile 恢复**： 由于数据持久化在 HDFS，新的 RegionServer 可直接从 HDFS 读取 HFile 文件，重建 Region 内存状态。 - **WAL 恢复**： 若故障前有未持久化的写入操作（存储在 WAL 中），HMaster 会拆分原 RegionServer 的 WAL 文件，并由新 RegionServer 回放日志到对应 Region，确保数据完整性。 #### **4. 客户端重试** - 客户端通过重试机制（如指数退避）自动切换到新的 RegionServer。 #### **5. 关键配置参数** - **故障检测时间**：`zookeeper.session.timeout`（默认 180 秒）。 - **WAL 处理**：`hbase.master.hfilecleaner.ttl`（控制 WAL 保留时间）。 --- ### **四、TiDB 与 HBase 故障转移对比** | **特性** | **TiDB** | **HBase** | |------------------|-----------------------------------|-----------------------------------| | **故障检测** | 秒级 Raft 心跳检测 | 依赖 ZooKeeper 会话超时（分钟级） | | **恢复速度** | 自动秒级切换，无需人工干预 | 需 HMaster 介入，分钟级恢复 | | **数据一致性** | 强一致，无数据丢失 | 依赖 WAL 回放，可能少量数据丢失 | | **副本参与度** | 多副本实时参与读写 | 单副本读写，HDFS 副本仅持久化 | --- ### **五、总结** - **TiDB**：基于 Raft 的多副本机制，天然支持高可用和强一致，适合对一致性要求高的场景。 - **HBase**：传统模式依赖 HDFS 副本保障数据安全，故障恢复较慢；Region Replication 模式可提升读可用性，但需手动配置且一致性较弱。 - **故障转移**：TiDB 的自动切换更高效，HBase 需依赖外部组件（如 ZooKeeper 和 HMaster）且恢复时间较长。