数据库教程FGMT80：国产数据库-TDSQL数据库工程师培训实战教程（腾讯金融级分布式数据库）

## 前言与本套风哥教程内容大纲介绍

风哥教程本文面向希望系统掌握国产分布式数据库 TDSQL（TDSQL for MySQL，腾讯金融级分布式数据库）的数据库工程师、主机工程师与运维人员。本套风哥教程以"先建立原理认知，再动手落地集群"为主线，理论部分讲清楚 TDSQL 的产品定位、架构组件、实例模型与核心技术原理，实战部分从操作系统环境准备开始，一步步完成分布式集群安装、周边组件部署、赤兔管理平台接入、日常监控巡检、数据库登录使用以及集群启停，全程给出可直接照做的配置与命令。

本套风哥教程的实验环境统一按 64GB 内存、8 颗 CPU 的服务器规格规划，所有安装目录统一使用 /fgedudb（替代传统安装根目录），数据库实例名、数据库名、用户名统一使用 fgedudb / fgedudb / fgedu，集群主机名统一为 fgedu-net-cn1 与 fgedu-net-cn2，便于读者在自己的实验环境中直接替换复用。

风哥教程本文的内容大纲如下：

第一部分 TDSQL 数据库基础知识：数据库系统分类；TDSQL 数据库介绍；TDSQL 数据库产品优势；TDSQL 数据库应用场景与业务；TDSQL 数据库架构组件；TDSQL 数据库实例架构；TDSQL 数据库分布式技术原理。

第二部分 TDSQL 分布式集群安装配置：TDSQL 分布式集群项目环境规划；TDSQL For Linux 操作系统环境准备；TDSQL 分布式数据库集群安装；TDSQL 其它组件模块安装（HDFS 冷备、LVS 负载均衡、Kafka、ES 日志分析平台）。

第三部分 TDSQL 分布式数据库管理入门：TDSQL 管理平台赤兔介绍与自动化巡检；TDSQL 日常管理与监控指南；TDSQL 数据库登录与使用入门；TDSQL 分布式集群启动与停止。

需要说明的是，本套风哥教程属于工程实战导向的技术文档，所有参数、命令与配置均围绕教学实验环境给出，读者在生产环境落地前应结合实际容量规划、网络规划与安全规范二次校验。

---

## 第一部分　TDSQL 数据库基础知识（理论）

### 1.1 数据库系统分类

在进入 TDSQL 之前，风哥先把数据库系统的分类脉络梳理清楚，因为只有理解分类坐标，才能准确判断 TDSQL 在整个数据库版图中的位置。

按数据模型划分，数据库可分为关系型数据库（RDBMS，如 Oracle、MySQL、PostgreSQL、SQL Server）与非关系型数据库（NoSQL，如键值型 Redis、文档型 MongoDB、宽列型 HBase、图数据库）。关系型数据库以二维表组织数据，依靠 SQL 声明式查询与事务 ACID 保证，长期承载核心交易系统；NoSQL 则为特定场景做了取舍，牺牲部分事务能力换取高吞吐与灵活模型。

按部署形态划分，可分为集中式数据库与分布式数据库。集中式数据库把全部数据放在单台或共享存储之上，依靠纵向扩容（加 CPU、加内存、加磁盘）提升能力，架构简单、事务处理成熟，但容量与吞吐存在单机天花板。分布式数据库把数据水平拆分到多台普通 x86 服务器上，依靠横向扩容获得线性增长，同时通过中间件或原生分布式内核对外提供统一的数据库视图。

按是否原生分布式划分，分布式数据库又可分为两类：一类是"中间件分库分表"路线，即在传统 MySQL 之上加一层代理做路由、聚合与分布式事务，应用看到的是逻辑库；另一类是"原生分布式内核"路线，从内核层面改造存储与事务协议。TDSQL MySQL 版属于前者与后者结合的工程形态：底层引擎兼容 MySQL（TXSQL 内核），上层由 SQL 引擎（Proxy）承担路由、聚合与分布式事务协调，底层 SET 单元采用一主多备强同步复制。

按应用负载划分，又可分为 OLTP（联机事务处理，面向高并发短事务，如交易、记账）与 OLAP（联机分析处理，面向大批量复杂查询，如报表、风控分析）。金融核心系统对一致性与可用性的要求远高于对分析能力的要求，这正是 TDSQL 的主战场。

风哥再补充一个选型视角，帮助读者判断什么场景该上 TDSQL、什么场景不必上。集中式数据库（包括传统主备、共享存储集群）在数据量小于单机容量、并发可控、团队没有分布式运维经验时仍然是更稳妥的选择，因为它事务模型简单、排错路径短。当业务出现以下任一信号时，才需要考虑分布式：单库数据量逼近单机存储与内存上限、写入吞吐超过单主节点处理能力、业务高峰需要横向加机器而不是纵向堆硬件、多地域部署要求就近接入与容灾。TDSQL 属于"为 OLTP 交易场景设计的分布式"，它并不擅长大规模实时分析，复杂报表类需求应交给独立的 OLAP 平台，而不是压在交易集群上。

还要区分 TDSQL 与"应用层分库分表"的差别。应用层分库分表需要业务代码自己计算路由、自己处理跨库事务、自己做结果归并，侵入性强、迁移成本高；TDSQL 把路由、聚合、分布式事务、主备切换下沉到 Proxy 与内核，应用仍然写标准 SQL，这是它工程价值的核心。理解这一点，读者才能明白后续为什么所有连接都走 Proxy、为什么建表必须声明 s-hardkey。

### 1.2 TDSQL 数据库介绍

TDSQL（Tencent Distributed SQL）是腾讯打造的金融级分布式数据库产品，其 MySQL 版（TDSQL for MySQL）以兼容 MySQL 协议为基础，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时配套智能 DBA、自动化运营、监控告警等设施，为客户提供完整的分布式数据库解决方案。腾讯内部约 90% 的金融、计费、交易类业务核心系统承载在 TDSQL 之上，外部已服务大量政企与金融机构，覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、政务等领域。

从工程师视角看，TDSQL 的本质是一套"高可用主备组（SET）+ 无状态 SQL 引擎（Proxy）+ 决策调度集群（Tschedule）+ 配置协调（TzooKeeper）+ 运维支撑（OSS、赤兔、监控）"的分布式体系。应用侧只需要连接 Proxy 提供的接入地址，无需感知底层数据落在哪个分片、主备是否发生切换，这是它对业务透明的关键。

### 1.3 TDSQL 数据库产品优势

风哥把 TDSQL 的产品优势归纳为六个可验证的技术点，而不是营销话术。

第一，强一致性。TDSQL 采用自研的异步多线程强同步复制（MAR，Multi-thread Asynchronous Replication），主机必须收到至少一个备机日志落盘的 ACK 应答后才向应用返回事务成功，杜绝异步复制在主库宕机时丢交易的风险，满足金融级"一笔账不能少"的要求。

第二，高可用性。每个物理分片采用一主多备架构，主备分布在跨机架、跨机房的服务器上，配合 Agent 心跳与 Scheduler 决策，主节点故障可自动切换到可用备节点；同时支持两地三中心，同城强同步、异地异步灾备。

第三，水平扩展。通过 s-hardkey 分片把逻辑表打散到多个 SET，容量与吞吐随节点数线性增长，扩容以增加分片的方式完成，不需要停机改造业务。

第四，高性能。MAR 把串行同步线程异步化，引入线程池，主机在等待备机 ACK 期间不阻塞其他会话；Proxy 层做读写分离，读请求分发到备节点，写请求路由到主节点。

第五，企业级安全。Proxy 层负责鉴权、SQL 审计、风险操作阻断，配合账号体系、SSL 传输、访问白名单与操作日志，满足金融合规要求。

第六，易运维。赤兔管理平台把集群的资源管理、实例管理、备份恢复、监控告警、性能分析、自动化巡检统一到 Web 界面，降低分布式集群的运维门槛。

### 1.4 TDSQL 数据库应用场景与业务

TDSQL 的典型落地场景有四类。其一是银行核心与信用卡交易系统，对 RPO（数据丢失量）要求为零、RTO（恢复时间）要求秒级，强同步与自动切换是刚需。其二是保险、证券、支付清结算系统，交易量大、账务要求严格，依赖分布式事务保证跨分片记账一致。其三是计费与第三方支付，账单流水可按用户 ID 或商户 ID 分片，高并发写入下仍需保证账实相符。其四是政务与物联网平台，要求自主可控、可水平扩展、支持私有化部署。

从业务建模角度，这类系统的共同特征是：以一个天然的业务主键（用户 ID、订单号、商户号）作为 s-hardkey，绝大多数请求都携带该主键，能够精准路由到单个分片；少量不带 s-hardkey 的查询由 Proxy 广播到全分片后聚合。这一特征直接决定了后续建表时 s-hardkey 的选择原则。

风哥也要讲清楚不适用的边界，避免盲目上分布式。以下三类需求不适合直接压在 TDSQL 交易集群：一是以大表全扫描、多维实时聚合为主的分析报表，这类应交给独立 OLAP 引擎；二是分片键难以确定、大量查询都不带主键的弱结构化业务，广播会让分布式优势变成负担；三是数据量与并发都很小、团队缺乏分布式运维能力的内部系统，集中式库更经济。判断是否落地，先看业务主键是否清晰、访问模式是否以点查为主、增长是否真的超出单机容量，三条同时成立再考虑分片。

### 1.5 TDSQL 数据库架构组件

一套独立的 TDSQL 分布式系统由十余个组件构成，风哥按"数据链路"与"管理链路"两条线拆开讲。

数据链路组件：

- 数据库节点组（SET）：由兼容 MySQL 的 TXSQL 引擎、监控信息采集模块（Agent，Tagent）组成。一个 SET 是一个逻辑主备组，包含一个主节点（Master）、若干备节点（Slave_n）、若干异地备份节点（Watcher_m），主备之间走 MAR 强同步。物理分片与 SET 对应，一个 SET 上可以存放一个或多个逻辑分表。

- 接入网关集群（TProxy / SQL-Engine）：无状态、不存数据，负责客户端长短连接管理、SQL 语法语义解析、分片路由、读写分离、分布式事务协调、结果聚合与鉴权审计。Proxy 与数据库引擎数量对应，前端再挂负载均衡对外提供统一入口。

管理链路组件：

- 决策调度集群（Tschedule）：集群的管理调度中心，由调度作业集群（Scheduler）、程序协调与配置集群（TzooKeeper）、运维支撑系统（OSS）组成。Scheduler 负责自动调度备份、监控采集、报表生成、主备切换、扩缩容等作业；TzooKeeper 提供配置维护、选举决策、路由同步，统一下发调度所有 DDL，部署数量需大于等于三台；OSS 是综合业务运营管理平台，融合网络管理、系统管理与监控服务。

- GTM（MetaCluster，元数据/全局事务管理器）：提供全局唯一且严格递增的事务时间戳，为两阶段提交的 Prepare、Commit 阶段提供全局时钟与事务协调，TM 模块内置于计算层以提升并发效率。

- 赤兔管理平台（chitu）：集群可视化 Web 控制台，提供物理资源管理、调度决策系统、备份恢复系统、可用区管理、实例管理、性能分析与监控告警。

- Monitor：监控采集模块，从 TzooKeeper 定期采集实例动态信息。

- Kafka：基于 TzooKeeper 协调的消息集群，作为 Proxy 日志持久化存储位置与数据同步锁依赖通道。

- Agent：部署在每个 DB 节点上，负责监控数据库存活状态，把健康状态上报 TzooKeeper，再由 Scheduler 感知并触发切换流程。

- HDFS：用于实时冷备与备份数据落地。

三个核心模块——决策调度集群（Tschedule）、数据库节点组（SET）、接入网关集群（TProxy）——之间的交互全部通过配置集群（TzooKeeper）完成，这是理解 TDSQL 通信机制的关键。

### 1.6 TDSQL 数据库实例架构

TDSQL 支持集中式实例与分布式实例混合部署。集中式实例对应单 SET 一主多备，不做水平拆分，适合中小业务；分布式实例由多个 SET 组成，逻辑统一、物理分散，应用看到的是一张完整的逻辑表，物理上被拆成多张物理表分布在不同 SET 上。

实例的高可用部署模型为：每个物理分片（SET）一主多备，主备跨机架、跨机房部署；同城站点之间强同步，异地灾备站点异步复制。两地三中心典型采用 2:2:2 部署：生产站点与同城站点强同步保证 RPO 为零，主节点故障时自动切换到同城可用备节点；异地站点逻辑主节点异步复制生产数据并自带本地备节点，异地管理节点使用独立集群，当生产同城可用域整体异常时快速切换到异地。

Proxy 是无状态的，没有主备之分，可以同时与业务系统通信，节点数通常大于等于 2，前端必须部署负载均衡（如 LVS）保证多 Proxy 之间的负载均衡与故障摘除。

### 1.7 TDSQL 数据库分布式技术原理

#### 1.7.1 MAR 强同步复制原理

MySQL 原生半同步复制存在两个工程问题：一是等待 Slave ACK 超时后退化为异步，存在丢数据窗口；二是等待 ACK 的工作线程阻塞，吞吐受限。TXSQL 对其做了改造：Master 等待 Slave ACK 超时或失败时直接向客户端返回失败，不退化为异步；采用组提交方式，增加 rpl_slave_ack_thread 线程循环取出 io thread 收到的 binlog 名与位点信息，只处理最后一个；采用线程池加业务线程异步化，Master 等待 ACK 期间把会话挂起，线程切换去处理其他会话。Master 节点因此开启两组线程：接收备机 ACK 应答线程（Dump ACK Thread）与唤醒挂起客户端连接线程（User ACK Thread）。只有备机日志落盘 ACK 返回后，主节点工作线程才唤起保存的会话，执行后半段提交并把结果返回客户端。

#### 1.7.2 分片路由原理

数据切分需要先选定分表键 s-hardkey，再按 HAs-h（默认）、Range 或 List 算法把数据分散到不同物理分片。应用建表时通过 s-hardkey=字段 指定分片键。Proxy 收到 SQL 后：若 SQL 携带 s-hardkey，按算法计算目标分片，只路由到对应 SET；若 SQL 未携带 s-hardkey，则广播到所有分片，各分片查询自身内容后回传 Proxy，Proxy 按 SQL 语义做结果聚合再答复应用。需要注意，物理分片与逻辑分表不是一一对应，一个物理分片上可以存放一个到多个逻辑分表。

#### 1.7.3 分布式事务两阶段提交原理

跨分片的事务采用两阶段提交（2PC）。第一阶段 Prepare：Proxy（TM）向涉及的所有分片发送 prepare，各分片执行写操作并写 redo、锁资源，返回 prepared 状态；第二阶段 Commit：全部 Prepare 成功后统一发送 commit，任一分片失败则全部 XA rollback。异常处理分四类：Prepare 超时或失败，触发所有实例 XA rollback 并向客户端报错；Commit log 写失败，触发 XA rollback；Commit log 写超时，Proxy 返回超时，客户端继续等待后超时；Commit 超时或失败，向客户端返回 disconnect，并向各实例发送断开连接请求。

#### 1.7.4 读写分离与故障切换原理

写请求路由到主节点，读请求按权重分发到备节点，由 Proxy 透明完成。Agent 持续探测主备心跳并上报 TzooKeeper，Scheduler 感知主节点异常后基于多数派选举决策，把可写角色切换到健康备节点，同时更新 TzooKeeper 中的路由信息，Proxy 随即按新路由转发，整个过程对应用透明。

#### 1.7.5 分片算法选型与分片设计约束

分片算法直接决定数据分布是否均衡、查询能否命中单分片，风哥把三种常见算法的适用边界讲清楚。HAs-h 分片对分片键做哈希取模，数据分布均匀、热点少，适合用户 ID、账号号段这类取值离散、查询以点查为主的场景，也是 TDSQL 的默认算法；缺点是范围查询（如某号段区间）会被打散到全分片，无法走连续扫描。Range 分片按分片键值区间切分，适合订单时间、流水号这类天然有序、经常做范围扫描的场景，缺点是新写入容易集中到最新区间形成热点，需要配合预拆分与热点打散。List 分片按枚举值显式映射，适合按地区、机构、渠道这类有限类别划分的业务，路由确定但类别扩展时要手工调整。

分片设计有三条硬约束必须在建模阶段就想清楚。第一，分片键必须同时进入主键与所有唯一键，否则跨分片无法保证唯一性，建表会被 Proxy 拒绝。第二，高频查询条件尽量携带分片键，不带分片键的 SQL 会被广播到所有分片，分片越多放大越严重，成为集群瓶颈。第三，避免选择更新频繁或会产生热点的字段做分片键，例如按自增 ID 尾部做哈希会导致新用户集中。

关于全局自增：分片环境下每个分片各自的 AUTO_INCREMENT 会重复，不能直接作为全局唯一主键。TDSQL 提供全局自增序列（Sequence），由 Scheduler 统一发号，应用取号后写入，保证全局唯一且趋势递增；本套风哥教程在 2.7 节给出取号示例。

关于跨分片 JOIN：携带分片键、两表落在同一分片的 JOIN 可以下推到分片本地执行；跨分片的 JOIN 需要 Proxy 把两侧结果拉回做归并，代价高且对大表不友好。工程上的常见做法是让经常关联的表使用相同分片键并落在同一分片（共表/同组分片），避免大表跨片关联。聚合查询（SUM、COUNT、GROUP BY）由 Proxy 在各分片并行计算后二次聚合，结果正确但延迟高于单分片。

关于两阶段提交的性能代价：2PC 相比本地事务多了一次 Prepare 往返与一次协调日志写入，跨分片事务的延迟通常高于单分片事务，且持锁时间更长。因此风哥的建议是，业务设计上尽量让一次事务只涉及一个分片，把跨分片 2PC 留给真正必须原子的场景（如跨账户转账），不要为了方便把无关写操作塞进同一事务。

---

## 第二部分　TDSQL 分布式集群安装配置与管理实战

### 2.1 TDSQL 分布式集群项目环境规划

#### 2.1.1 硬件与系统规格

本套风哥教程实验环境统一采用 64GB 内存、8 颗 CPU 的 x86 服务器，操作系统选用 RHEL 9.3（兼容麒麟等国产 Linux，命令差异风哥会在对应位置说明）。按 64GB 内存、8CPU 的规格，单节点可同时承载管理组件与一个 SET 实例，教学实验采用 fgedu-net-cn1、fgedu-net-cn2 双机部署，生产环境则建议管理组件、Proxy、SET 分别独立成组。

单机资源分配基线（64GB / 8CPU）：

| 项目 | 规划值 |

| --- | --- |

| 物理内存 | 64GB |

| CPU | 8 核 |

| SET 实例 innodb_buffer_pool_size | 24576M（约 24GB，取内存 40% 左右） |

| Proxy 进程内存上限 | 8192M |

| TzooKeeper / Scheduler / Agent | 各 2048M |

| 连接数上限 max_connections | 4096 |

| 磁盘 | /fgedudb 数据盘 ≥ 500GB，预留冷备空间 |

#### 2.1.2 角色与主机规划

教学双机角色划分如下，所有进程的安装根目录统一为 /fgedudb：

| 主机名 | 角色 | 说明 |

| --- | --- | --- |

| fgedu-net-cn1 | TzooKeeper、Scheduler、Manager、Proxy、SET-Master、Agent、Monitor | 主节点机，承载决策调度、接入网关与分片主节点 |

| fgedu-net-cn2 | TzooKeeper、Scheduler、Manager、Proxy、SET-Slave、Agent、Monitor | 备节点机，承载决策调度、接入网关与分片备节点 |

说明：生产环境 TzooKeeper 需大于等于三台以满足多数派选举，Scheduler/Manager 无状态集群部署建议奇数台；本实验为双机教学，TzooKeeper 以双节点演示，读者在生产落地时必须补齐第三台。Kafka、HDFS、ES、LVS 在本实验中作为周边组件分别部署在 fgedu-net-cn1、fgedu-net-cn2 上，后文给出配置。

风哥 itpux-com

#### 2.1.3 网络与端口规划

| 组件 | 监听端口示例 | 用途 |

| --- | --- | --- |

| TzooKeeper | 2181、2888、3888 | 配置协调、选举、路由同步 |

| Scheduler | 3306、8080 | 调度作业与决策接口 |

| Proxy | 15001 | 业务 SQL 接入端口（MySQL 协议） |

| SET-Master | 3306 | 分片主实例 |

| SET-Slave | 3306 | 分片备实例 |

| Agent | 32000 | 节点心跳上报 |

| Kafka | 9092 | 日志与同步锁通道 |

| HDFS NameNode | 8020、9870 | 冷备数据落地 |

| ES | 9200 | 日志分析平台 |

| 赤兔控制台 | 80/443 | Web 管理入口 |

#### 2.1.4 账号与目录规划

- 操作系统用户：tdsql（属组 tdsql），所有组件以该用户运行，禁止使用 root 跑数据库进程。

- 安装根目录：/fgedudb（本套风哥教程统一替代传统安装根目录）。

- 数据库实例名：fgedudb；数据库名：fgedudb；数据库账号：fgedu（密码按实验规范自行设置，下文以变量 DB_PASS 表示）。

- 目录结构：

```

/fgedudb/

├── zookeeper/          # 配置协调集群

├── scheduler/          # 决策调度与作业集群

├── manager/            # 管理模块

├── proxy/              # SQL 引擎/接入网关

├── set/fgedudb/        # 分片实例数据目录

│   ├── data/

│   ├── log/

│   └── binlog/

├── agent/              # 节点采集代理

├── kafka/              # 消息组件

├── hdfs/               # 冷备组件

└── es/                 # 日志分析组件

```

#### 2.1.5 容量估算与硬件选型依据

64GB 内存、8CPU 是教学与中小规模验证的规格，风哥给出一套可复用的估算方法，读者在生产落地时据此放大。内存侧：InnoDB 缓冲池通常取物理内存的 50%～60%，本实验取 24576M（约 24GB），剩余留给操作系统页缓存、连接会话、Proxy 与管理组件；buffer pool instance 数量建议与 CPU 核数对齐或取 8，减少内部锁竞争。CPU 侧：8 核对应单分片约数千 QPS 的短事务能力，生产按目标 TPS 除以单核经验值横向加分片，而不是给单分片堆更多核。磁盘侧：按"单表预估行数 × 单行平均长度 × 副本数 × 1.3 冗余系数"估算数据容量，再叠加 binlog 与备份空间，数据盘建议预留不低于总量的 30% 空闲；交易库优先选用 NVMe SSD，随机写延迟直接决定事务提交表现。

网络侧：强同步复制要求备机 ACK 走独立链路，主备之间建议万兆网卡并做 bonding，避免复制流量与业务流量争抢；本实验双机同网段，生产应把管理网、复制网、业务网分离。LVS VIP 192.168.10.100 由两台 Director 共享，业务只感知 VIP，不感知后端 Proxy 变化。容量估算完成后再回到 2.1.1 的规格表逐项核对，避免边装边改参数。

### 2.2 TDSQL For Linux 操作系统环境准备

风哥强调：分布式集群 80% 的安装问题出在操作系统基线，本节必须在 fgedu-net-cn1、fgedu-net-cn2 两台机器上分别执行。

#### 2.2.1 主机名与 hosts 解析

两台机器分别设置主机名：

```

# 在 fgedu-net-cn1 上执行

hostnamectl set-hostname fgedu-net-cn1

# 在 fgedu-net-cn2 上执行

hostnamectl set-hostname fgedu-net-cn2

```

编辑 /etc/hosts，保证双机互相可解析（两台机器内容一致）：

```

cat >> /etc/hosts <<'EOF'

192.168.10.11   fgedu-net-cn1

192.168.10.12   fgedu-net-cn2

EOF

```

验证双向解析：

```

ping -c 2 fgedu-net-cn1

ping -c 2 fgedu-net-cn2

```

#### 2.2.2 创建运行用户与目录

```

groupadd tdsql

useradd -g tdsql -m -s /bin/bas-h tdsql

mkdir -p /fgedudb/{zookeeper,scheduler,manager,proxy,set/fgedudb/{data,log,binlog},agent,kafka,hdfs,es}

chown -R tdsql:tdsql /fgedudb

chmod -R 750 /fgedudb

```

#### 2.2.3 关闭防火墙与 SELinux（实验环境）

生产环境应按最小化开放端口，实验环境先关闭便于排障：

```

systemctl stop firewalld

systemctl disable firewalld

setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

```

#### 2.2.4 时间同步

分布式集群对时钟一致性要求极高，两机配置 chronyd 同步同一时间源：

```

dnf install -y chrony

sed -i 's/^pool .*/server ntp.aliyun.com iburst/' /etc/chrony.conf

systemctl enable --now chronyd

chronyc sources -v

```

验证两机时间差应小于 50ms：

```

chronyc tracking

```

风哥教程 113257174

#### 2.2.5 内核参数调整

编辑 /etc/sysctl.conf（两台机器一致），针对 64GB 内存、8CPU 的规格调整：

```

cat >> /etc/sysctl.conf <<'EOF'

# 网络与连接

net.core.somaxconn = 65535

net.core.netdev_max_backlog = 65535

net.ipv4.tcp_max_syn_backlog = 65535

net.ipv4.ip_local_port_range = 1024 65535

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_keepalive_time = 600

# 内存与文件句柄

vm.swappiness = 1

vm.overcommit_memory = 1

fs.file-max = 1048576

# 透明大页关闭（数据库场景）

EOF

echo never > /sys/kernel/mm/transparent_hugepage/enabled

echo never > /sys/kernel/mm/transparent_hugepage/defrag

sysctl -p

```

#### 2.2.6 资源限制 ulimit

编辑 /etc/security/limits.conf：

```

cat >> /etc/security/limits.conf <<'EOF'

tdsql soft nofile 65535

tdsql hard nofile 65535

tdsql soft nproc  65535

tdsql hard nproc  65535

tdsql soft memlock unlimited

tdsql hard memlock unlimited

EOF

```

#### 2.2.7 依赖包安装

```

dnf install -y gcc gcc-c++ make cmake ncurses-devel libaio libaio-devel \

numactl net-tools lsof psmisc perl-Data-Dumper perl-DBD-MySQL \

java-1.8.0-openjdk java-1.8.0-openjdk-devel

```

TDSQL 部分组件（Kafka、TzooKeeper、HDFS、ES）依赖 JDK，统一使用 1.8：

```

java -version

```

#### 2.2.8 磁盘挂载与文件系统

实验数据盘挂载到 /fgedudb，建议使用 XFS：

```

# 以 /dev/sdb 为例，按实际盘符替换

mkfs.xfs /dev/sdb

mkdir -p /fgedudb

mount /dev/sdb /fgedudb

UUID=$(blkid /dev/sdb | awk '{print $2}' | cut -d'"' -f2)

echo "UUID=$UUID /fgedudb xfs defaults,noatime,nodiratime 0 0" >> /etc/fstab

mount -a

df -h /fgedudb

```

至此两台机器的操作系统基线完成，风哥建议在两台机器上分别执行 `ulimit -n`、`sysctl vm.swappiness`、`chronyc tracking` 做一次基线核对，再进入安装环节。

#### 2.2.9 基线常见问题排查清单

安装阶段八成报错都能在基线层定位，风哥把高频问题列成对照表，读者遇到异常先按此自查。

主机名与解析：`hostnamectl` 设置后若新开终端仍显示旧名，检查是否登录会话未刷新；`/etc/hosts` 必须两台机器内容一致，且不要让 `/etc/resolv.conf` 的 DNS 覆盖本地解析，可用 `getent hosts fgedu-net-cn2` 验证，比 ping 更可靠。

时间漂移：强同步对时钟敏感，两机时间差超过数百毫秒会导致复制位点判断异常。用 `chronyc tracking` 查看 System time 偏移量，若持续偏大，检查上游 NTP 是否可达、防火墙是否放行 UDP 123。

透明大页与 swap：THP 未关闭会出现 InnoDB 周期性卡顿，确认 `cat /sys/kernel/mm/transparent_hugepage/enabled` 显示 never；`vm.swappiness=1` 之外，生产建议直接禁用 swap 或保留极小值，避免数据库被换出。

文件句柄：`ulimit -n` 必须在以 tdsql 用户登录的会话里查看，只改 limits.conf 而不重新登录不生效；连接数上到几千时句柄不足会报 Too many open files。

权限与属主：所有 /fgedudb 下的目录必须属主为 tdsql:tdsql，数据库进程以 tdsql 启动，root 启动会导致数据文件属主错乱、后续无法切换用户运行。

依赖缺失：JDK 版本必须为 1.8，过高版本会让 TzooKeeper、Kafka 启动报 UnsupportedClassVersion；libaio 缺失会让 InnoDB 无法使用 O_DIRECT 直接 IO。

网上搜索风哥教程可以学习全套数据库教程

### 2.3 TDSQL 分布式数据库集群安装

安装顺序遵循依赖关系：先装配置协调 TzooKeeper，再装决策调度 Scheduler/Manager，然后初始化 SET 分片实例，最后装 Proxy 与 Agent，并在赤兔或命令行完成注册。

#### 2.3.1 安装并启动 TzooKeeper

把官方发行包解压到 /fgedudb/zookeeper（两台机器一致）：

```

tar -zxf tdsql-zookeeper-3.8.4.tar.gz -C /fgedudb/zookeeper --strip-components=1

chown -R tdsql:tdsql /fgedudb

```

fgedu-net-cn1 上写配置 /fgedudb/zookeeper/conf/zoo.cfg：

```

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/fgedudb/zookeeper/data

clientPort=2181

server.1=fgedu-net-cn1:2888:3888

server.2=fgedu-net-cn2:2888:3888

```

fgedu-net-cn2 上同样写 zoo.cfg，然后分别写入 myid：

```

# fgedu-net-cn1

echo 1 > /fgedudb/zookeeper/data/myid

# fgedu-net-cn2

echo 2 > /fgedudb/zookeeper/data/myid

```

两台机器分别启动：

```

su - tdsql -c "/fgedudb/zookeeper/bin/zkServer.s-h start"

su - tdsql -c "/fgedudb/zookeeper/bin/zkServer.s-h status"

```

验证：

```

/fgedudb/zookeeper/bin/zkCli.s-h -server fgedu-net-cn1:2181 ls /

```

能看到根节点列表即说明协调集群正常。注意生产环境必须为三台，双机在脑裂场景下无法形成多数派，这是教学演示的简化。

风哥数据库教程 itpux-com

#### 2.3.2 安装 Scheduler 与 Manager

解压调度与管理模块：

```

tar -zxf tdsql-scheduler.tar.gz -C /fgedudb/scheduler --strip-components=1

tar -zxf tdsql-manager.tar.gz -C /fgedudb/manager --strip-components=1

chown -R tdsql:tdsql /fgedudb/scheduler /fgedudb/manager

```

编辑 /fgedudb/scheduler/conf/scheduler.ini，关键项按 64GB/8CPU 规格填写：

```

[common]

zk_list = fgedu-net-cn1:2181,fgedu-net-cn2:2181

data_dir = /fgedudb/scheduler/data

log_dir = /fgedudb/scheduler/log

worker_cpu = 8

mem_limit = 2048M

[schedule]

port = 3306

http_port = 8080

backup_window = 02:00-04:00

```

启动 Scheduler（两台机器均启动，无状态互备）：

```

su - tdsql -c "/fgedudb/scheduler/bin/scheduler start"

su - tdsql -c "/fgedudb/scheduler/bin/scheduler status"

```

Manager 配置 /fgedudb/manager/conf/manager.ini：

```

[common]

zk_list = fgedu-net-cn1:2181,fgedu-net-cn2:2181

meta_db = fgedudb

meta_user = fgedu

meta_pass = DB_PASS

log_dir = /fgedudb/manager/log

```

启动 Manager：

```

su - tdsql -c "/fgedudb/manager/bin/manager start"

```

#### 2.3.3 初始化 SET 分片实例（fgedudb）

fgedu-net-cn1 作为 Master，fgedu-net-cn2 作为 Slave。先在 Master 上初始化实例目录 /fgedudb/set/fgedudb/data，配置文件 /fgedudb/set/fgedudb/etc/my.cnf，按 64GB 内存、8CPU 规格给出关键参数：

```

[mysqld]

basedir = /fgedudb/set/fgedudb

datadir = /fgedudb/set/fgedudb/data

log_bin = /fgedudb/set/fgedudb/binlog/fgedudb-bin

server_id = 101

port = 3306

socket = /fgedudb/set/fgedudb/data/mysql.sock

# 内存规格（64GB 内存，buffer pool 取约 24GB）

innodb_buffer_pool_size = 24576M

innodb_buffer_pool_instances = 8

innodb_log_buffer_size = 64M

innodb_flus-h_log_at_trx_commit = 1

innodb_flus-h_method = O_DIRECT

innodb_io_capacity = 2000

innodb_io_capacity_max = 4000

# 连接与并发（8CPU）

max_connections = 4096

table_open_cache = 4096

thread_cache_size = 128

# 强同步复制（MAR）

rpl_semi_sync_master_enabled = 1

rpl_semi_sync_slave_enabled = 1

rpl_semi_sync_master_timeout = 10000

rpl_semi_sync_master_wait_for_slave_count = 1

# 字符集

character_set_server = utf8mb4

collation_server = utf8mb4_general_ci

```

初始化数据目录：

```

su - tdsql

cd /fgedudb/set/fgedudb

./bin/mysqld --initialize-insecure --defaults-file=/fgedudb/set/fgedudb/etc/my.cnf --user=tdsql

```

启动 Master 实例：

```

./bin/mysqld_safe --defaults-file=/fgedudb/set/fgedudb/etc/my.cnf --user=tdsql &

```

登录并创建实例账号 fgedu、复制账号：

```

./bin/mysql -S /fgedudb/set/fgedudb/data/mysql.sock

```

```

ALTER USER 'root'@'localhost' IDENTIFIED BY 'DB_PASS';

CREATE USER 'fgedu'@'%' IDENTIFIED BY 'DB_PASS';

GRANT ALL PRIVILEGES ON *.* TO 'fgedu'@'%';

CREATE USER 'repl'@'%' IDENTIFIED BY 'DB_PASS';

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

CREATE DATABASE fgedudb DEFAULT CHARACTER SET utf8mb4;

FLUs-h PRIVILEGES;

s-hOW MASTER STATUS;

```

记录 Master 的 binlog 文件名与位点。fgedu-net-cn2 上初始化 Slave，my.cnf 中 server_id 改为 102、relay_log 指向本机目录，然后配置复制：

```

CHANGE MASTER TO

  MASTER_HOST='fgedu-net-cn1',

  MASTER_PORT=3306,

  MASTER_USER='repl',

  MASTER_PASSWORD='DB_PASS',

  MASTER_LOG_FILE='fgedudb-bin.000001',

  MASTER_LOG_POS=157,

  MASTER_CONNECT_RETRY=10;

START SLAVE;

s-hOW SLAVE STATUS\G

```

确认 `Slave_IO_Running=Yes`、`Slave_SQL_Running=Yes`，且强同步状态 `Rpl_semi_sync_master_status=ON`。

#### 2.3.4 安装 Agent 并注册节点

Agent 部署在每个 DB 节点，负责心跳上报。解压并配置 /fgedudb/agent/conf/agent.ini：

```

[common]

zk_list = fgedu-net-cn1:2181,fgedu-net-cn2:2181

db_host = 127.0.0.1

db_port = 3306

agent_port = 32000

log_dir = /fgedudb/agent/log

```

启动 Agent：

```

su - tdsql -c "/fgedudb/agent/bin/agent start"

```

在 Scheduler 中注册 SET 与节点（命令行演示，生产推荐在赤兔界面操作）：

```

/fgedudb/scheduler/bin/setctl create --set=fgedudb --s-hard=0 \

  --master=fgedu-net-cn1:3306 --slave=fgedu-net-cn2:3306 \

  --user=fgedu --pass=DB_PASS

```

#### 2.3.5 安装并配置 Proxy

Proxy 无状态，两台机器各装一份。解压到 /fgedudb/proxy，配置 /fgedudb/proxy/conf/proxy.ini：

```

[common]

zk_list = fgedu-net-cn1:2181,fgedu-net-cn2:2181

listen_port = 15001

log_dir = /fgedudb/proxy/log

mem_limit = 8192M

worker_threads = 16

[route]

default_set = fgedudb

s-hard_key = user_id

```

启动 Proxy：

```

su - tdsql -c "/fgedudb/proxy/bin/proxy start"

su - tdsql -c "/fgedudb/proxy/bin/proxy status"

```

验证 Proxy 已从 TzooKeeper 拉到路由：

```

/fgedudb/proxy/bin/proxyctl --host=fgedu-net-cn1 --port=15001 route list

```

#### 2.3.6 安装校验清单与常见故障

集群各层启动后，风哥建议按下面的顺序逐层校验，确认一层通了再装下一层，不要全部启动后再排错。

协调层校验：`zkServer.s-h status` 查看角色（leader/follower），`zkCli.s-h ls /` 能列出根节点；双机教学环境允许一个 leader 一个 follower，生产三节点必须有且仅有一个 leader。

调度层校验：`schedulerctl status` 显示 RUNNING，`manager` 进程存在；Scheduler 能连上 TzooKeeper 后会在 /tdsql 节点下注册自己。

实例层校验：Master 启动后用 `mysql -S /fgedudb/set/fgedudb/data/mysql.sock` 登录，执行 `s-hOW MASTER STATUS;` 看 binlog；Slave 配置复制后 `s-hOW SLAVE STATUS\G` 确认 `Slave_IO_Running`、`Slave_SQL_Running` 均为 Yes，`Rpl_semi_sync_master_status` 为 ON。

接入层校验：`route list` 返回的路由表必须包含 fgedudb 的 Master/Slave 地址；用 `mysql -h VIP -P 15001` 能登录并执行 `SELECT 1;`。

常见故障按现象定位。端口占用：启动报 Address already in use，用 `ss -lntp | grep 端口` 找占用进程，3306 常被系统自带 mariadb 或旧实例占用，先停掉或改端口。权限问题：数据目录属主不是 tdsql 会报 Permission denied，重新 `chown -R tdsql:tdsql /fgedudb`。myid 错误：TzooKeeper 报 myid 不一致或拒绝连接，检查 data/myid 与 zoo.cfg 中 server.N 的编号是否一一对应。强同步插件未加载：`Rpl_semi_sync_master_status` 一直 OFF，检查 my.cnf 中半同步参数是否生效、插件是否安装，必要时 `INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';`。复制中断：`Slave_IO_Running` 为 No，看 Last_IO_Error，多为账号密码、网络、server_id 冲突或位点错位。

上51CTO搜索风哥可以学习全套数据库教程

### 2.4 TDSQL 其它组件模块安装

#### 2.4.1 HDFS 集群配置（实时冷备）

TDSQL 的实时冷备与备份落地依赖 HDFS。实验采用 fgedu-net-cn1 作 NameNode、fgedu-net-cn2 作 DataNode，安装目录 /fgedudb/hdfs。

解压并设置 JAVA_HOME：

```

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk

tar -zxf hadoop-3.3.6.tar.gz -C /fgedudb/hdfs --strip-components=1

chown -R tdsql:tdsql /fgedudb/hdfs

```

编辑 /fgedudb/hdfs/etc/hadoop/core-site.xml：

```

<configuration>

  <property>

    <name>fs.defaultFS</name>

    <value>hdfs://fgedu-net-cn1:8020</value>

  </property>

  <property>

    <name>hadoop.tmp.dir</name>

    <value>/fgedudb/hdfs/tmp</value>

  </property>

</configuration>

```

编辑 hdfs-site.xml：

```

<configuration>

  <property>

    <name>dfs.replication</name>

    <value>2</value>

  </property>

  <property>

    <name>dfs.namenode.name.dir</name>

    <value>/fgedudb/hdfs/namenode</value>

  </property>

  <property>

    <name>dfs.datanode.data.dir</name>

    <value>/fgedudb/hdfs/datanode</value>

  </property>

</configuration>

```

格式化并启动（仅S首在 NameNode 执行）：

```

su - tdsql

/fgedudb/hdfs/bin/hdfs namenode -format

/fgedudb/hdfs/sbin/start-dfs.s-h

jps

```

在 NameNode 看到 NameNode、DataNode 进程，Web 端口 9870 可访问即正常。Scheduler 的备份作业通过 OSS 把备份包写入 HDFS 指定目录：

```

/fgedudb/hdfs/bin/hdfs dfs -mkdir -p /tdsql/backup/fgedudb

/fgedudb/hdfs/bin/hdfs dfs -ls /tdsql/backup

```

#### 2.4.2 LVS 负载均衡配置（Proxy 前端）

Proxy 无状态且多节点部署，前端用 LVS DR 模式做负载均衡与故障摘除。实验在 fgedu-net-cn1 上安装 ipvsadm，fgedu-net-cn1、fgedu-net-cn2 同时作为 Real Server（本机 Proxy）。

调度器（fgedu-net-cn1）配置：

```

dnf install -y ipvsadm

modprobe ip_vs

ipvsadm -C

ipvsadm -A -t 192.168.10.100:15001 -s wrr

ipvsadm -a -t 192.168.10.100:15001 -r fgedu-net-cn1:15001 -g -w 1

ipvsadm -a -t 192.168.10.100:15001 -r fgedu-net-cn2:15001 -g -w 1

ipvsadm -Ln

```

两台 Real Server 抑制 ARP 并绑定 VIP 到 lo：

```

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ip addr add 192.168.10.100/32 dev lo

```

业务侧统一连接 VIP 192.168.10.100:15001，任一 Proxy 故障由 LVS 自动摘除。

#### 2.4.3 Kafka 与消费者（日志持久化与同步锁通道）

Kafka 基于 TzooKeeper 协调，作为 Proxy 日志持久化位置与数据同步锁依赖通道。解压到 /fgedudb/kafka，编辑 config/server.properties：

```

broker.id=1

listeners=PLAINTEXT://fgedu-net-cn1:9092

zookeeper.connect=fgedu-net-cn1:2181,fgedu-net-cn2:2181

log.dirs=/fgedudb/kafka/logs

num.partitions=3

default.replication.factor=2

```

fgedu-net-cn2 上 broker.id=2、listeners 指向本机。启动：

```

su - tdsql

/fgedudb/kafka/bin/kafka-server-start.s-h -daemon /fgedudb/kafka/config/server.properties

```

创建 Proxy 日志主题并启动消费者验证：

```

/fgedudb/kafka/bin/kafka-topics.s-h --create --bootstrap-server fgedu-net-cn1:9092 \

  --replication-factor 2 --partitions 3 --topic proxy-log

/fgedudb/kafka/bin/kafka-console-consumer.s-h --bootstrap-server fgedu-net-cn1:9092 \

  --topic proxy-log --from-beginning

```

#### 2.4.4 ES 日志分析平台

Elasticsearch 用于集群日志集中检索。解压到 /fgedudb/es，编辑 config/elasticsearch.yml：

```

cluster.name: tdsql-log

node.name: es-node-1

path.data: /fgedudb/es/data

path.logs: /fgedudb/es/logs

network.host: 0.0.0.0

http.port: 9200

discovery.seed_hosts: ["fgedu-net-cn1", "fgedu-net-cn2"]

cluster.initial_master_nodes: ["es-node-1", "es-node-2"]

```

按 64GB 内存规格设置 JVM 堆（不超过物理内存一半且不超过 31GB），编辑 config/jvm.options：

```

-Xms16g

-Xmx16g

```

启动：

```

su - tdsql

/fgedudb/es/bin/elasticsearch -d -p /fgedudb/es/es.pid

curl http://fgedu-net-cn1:9200

```

返回集群状态 JSON 即正常。Proxy、Agent、Scheduler 的日志通过 Filebeat 采集后写入 ES，在赤兔或 Kibana 中检索。

#### 2.4.5 周边组件验证要点

周边组件不是集群主体，但任一异常都会让备份或日志链路静默失败，风哥给出逐项验证命令。

HDFS：`hdfs dfsadmin -report` 查看 DataNode 存活与容量，`hdfs dfs -ls /tdsql/backup/fgedudb` 确认备份目录可写；NameNode 未格式化前不要启动 DataNode，二次格式化会导致集群版本不一致。

LVS：`ipvsadm -Ln` 查看 VIP 192.168.10.100 与后端两台 Proxy 的转发规则，`ip addr s-how` 确认 VIP 只在一台 Director 上（DR 模式）；客户端 `telnet 192.168.10.100 15001` 应能连通，摘除一台 Proxy 后业务仍可用。

Kafka：`kafka-topics.s-h --list --bootstrap-server fgedu-net-cn1:9092` 列出主题，`kafka-console-consumer.s-h` 能读到消息即生产消费正常；注意 broker.id 不能重复、advertised.listeners 要配成客户端可达地址，否则外部连不上。

ES：`curl http://fgedu-net-cn1:9200/_cluster/health?pretty` 看 status 为 green 或 yellow；JVM 堆超过 31GB 会压缩失效，64GB 机器固定取 16g 稳妥。

风哥 itpux-com

### 2.5 TDSQL 管理平台赤兔介绍与自动化巡检

#### 2.5.1 赤兔平台定位

赤兔（chitu）是 TDSQL 集群的可视化管理控制台，通过 OSS 接收用户请求，以 HTTP POST 调用后端流程，把结果封装返回给前端。赤兔提供物理资源管理、调度决策系统、备份恢复系统、可用区管理、实例管理、性能分析与监控告警等全部运维功能。浏览器访问 [http://fgedu-net-cn1（默认](http://fgedu-net-cn1%EF%BC%88%E9%BB%98%E8%AE%A4) Web 端口），使用管理员账号登录后，左侧导航分为资源管理、实例管理、备份恢复、监控告警、性能分析、巡检报告几个区域。

#### 2.5.2 接入集群

S首登录后在"资源管理"中添加 TzooKeeper 地址 fgedu-net-cn1:2181,fgedu-net-cn2:2181，赤兔自动从协调集群拉取 Scheduler、SET、Proxy 的注册信息。在"实例管理"中应能看到 fgedudb 实例及其 Master（fgedu-net-cn1:3306）、Slave（fgedu-net-cn2:3306）角色，状态显示为"正常"。

#### 2.5.3 自动化巡检

赤兔内置巡检任务，由 Scheduler 按时间窗口自动执行，检查项覆盖：主备复制状态、强同步 ACK 是否正常、binlog 位点差、磁盘容量、内存与连接数、Agent 心跳、Proxy 路由一致性、备份是否成功。命令行方式手动触发一次巡检：

```

/fgedudb/scheduler/bin/schedulerctl inspect --set=fgedudb --report=/fgedudb/scheduler/report/fgedudb_inspect.html

```

巡检报告在赤兔"巡检报告"页面查看，重点关注以下判定：

- `Slave_IO_Running` 与 `Slave_SQL_Running` 是否均为 Yes；

- `Seconds_Behind_Master` 是否持续大于 0；

- `Rpl_semi_sync_master_status` 是否为 ON；

- 主备 binlog 位点差是否在阈值内；

- /fgedudb 数据盘使用率是否超过 80%；

- Proxy 到各 SET 的路由是否与 TzooKeeper 一致。

定时巡检可在赤兔"调度作业"中配置每日 03:00 自动执行，报告归档到 HDFS /tdsql/backup/fgedudb/report。

网上搜索风哥教程可以学习全套数据库教程

### 2.6 TDSQL 日常管理与监控指南

#### 2.6.1 监控指标体系

Monitor 模块从 TzooKeeper 定期采集实例动态，赤兔监控大盘展示四类指标：

- 实例层：QPS、TPS、连接数、慢查询数、缓冲池命中率、行锁等待；

- 复制层：强同步状态、备机延迟、ACK 队列长度；

- 资源层：CPU、内存、磁盘、网络；

- 链路层：Proxy 转发量、广播查询比例、错误率。

命令行查看实例实时状态：

```

/fgedudb/scheduler/bin/setctl s-how --set=fgedudb

/fgedudb/proxy/bin/proxyctl --host=fgedu-net-cn1 --port=15001 stats

```

#### 2.6.2 告警规则配置

在赤兔"监控告警"中按 64GB/8CPU 规格设置阈值：CPU 使用率 > 85% 持续 5 分钟告警；内存使用率 > 80%；数据盘 > 80%；备机延迟 > 10s；强同步状态 OFF；连接数 > 3500（上限 4096 的 85%）。告警通道接入企业微信或短信 webhook。

#### 2.6.3 慢查询分析与性能诊断

慢查询是分布式集群最常见的性能来源，风哥给出固定排查路径。先在实例层开启慢日志并设定阈值：

```

SET GLOBAL slow_query_log = ON;

SET GLOBAL long_query_time = 1;

```

登录对应分片查看慢日志，或在赤兔"性能分析"页面按耗时排序。分析时先判断这条 SQL 是否携带 s-hardkey：不带分片键的广播查询会被放大到全分片，分片越多代价越高，这类问题优先在业务侧补全查询条件，而不是调大缓冲池。其次看执行计划，`EXPLAIN` 是否走索引、是否出现全表扫描；跨分片 JOIN 与大结果集聚合要评估是否应改为同分片设计。

Proxy 层用 `proxyctl stats` 观察广播查询比例，该比例长期偏高说明分片键使用习惯差。资源层关注缓冲池命中率（低于 99% 需评估加内存）、行锁等待与 QPS 峰值；复制层关注 ACK 队列长度，队列堆积说明备机跟不上，强同步会拖慢主库提交。性能压测建议先在单分片用 `sysbench` 打满基线，再逐步加并发观察横向扩展是否线性，避免一上来就压全集群导致无法定位瓶颈。

#### 2.6.4 备份与恢复

Scheduler 在时间窗口内自动触发物理备份写入 HDFS。手动执行一次全量备份：

```

/fgedudb/scheduler/bin/backupctl --set=fgedudb --type=full \

  --hdfs-path=hdfs://fgedu-net-cn1:8020/tdsql/backup/fgedudb

```

查看备份列表：

```

/fgedudb/hdfs/bin/hdfs dfs -ls /tdsql/backup/fgedudb

```

恢复时在赤兔"备份恢复"中选择备份包，指定目标节点执行，恢复过程由 Scheduler 编排，先停写、再落盘、再追 binlog。

上51CTO搜索风哥可以学习全套数据库教程

### 2.7 TDSQL 数据库登录与使用入门

#### 2.7.1 通过 Proxy 登录

业务应用不直连 SET，统一连接 LVS VIP 或 Proxy：

```

mysql -h 192.168.10.100 -P 15001 -u fgedu -p'DB_PASS' fgedudb

```

验证连接与路由：

```

SELECT @@proxy_route;

s-hOW DATABASES;

```

#### 2.7.2 创建分片表

以 user_id 作为 s-hardkey，在 fgedudb 库中创建逻辑分片表：

```

USE fgedudb;

CREATE TABLE t_account (

  user_id    BIGINT NOT NULL,

  user_name  VARCHAR(64) NOT NULL,

  balance    DECIMAL(18,2) NOT NULL DEFAULT 0,

  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,

  PRIMARY KEY (user_id, user_name),

  UNIQUE KEY uk_user_name (user_name, user_id)

) s-hARDKEY=user_id;

```

注意：分片键必须包含在主键与唯一键中，否则 Proxy 无法保证跨分片唯一性约束。

#### 2.7.3 写入与分片路由

```

INSERT INTO t_account(user_id, user_name, balance) VALUES

(1001,'zhang',1000.00),

(1002,'li',2000.00),

(1003,'wang',3000.00);

```

携带 s-hardkey 的查询只路由到单个分片：

```

SELECT * FROM t_account WHERE user_id = 1001;

```

不带 s-hardkey 的查询由 Proxy 广播全分片后聚合：

```

SELECT user_name, balance FROM t_account WHERE balance > 1500;

```

#### 2.7.4 分布式事务（两阶段提交）

跨分片转账由 Proxy 协调 2PC：

```

START TRANSACTION;

UPDATE t_account SET balance = balance - 500 WHERE user_id = 1002;

UPDATE t_account SET balance = balance + 500 WHERE user_id = 1003;

COMMIT;

```

若任一分片 Prepare 失败，Proxy 触发所有分片 XA rollback，事务整体回滚，不会出现单边扣账。

#### 2.7.5 读写分离验证

写操作走主节点，读操作按权重走备节点：

```

/* 写：路由到 Master */

UPDATE t_account SET balance = balance + 100 WHERE user_id = 1001;

/* 读：可路由到 Slave */

SELECT * FROM t_account WHERE user_id = 1001;

```

#### 2.7.6 全局自增、跨分片聚合与 DDL 下发

全局自增序列用于生成不重复的业务主键，先创建序列再取号：

```

CREATE SEQUENCE seq_account START WITH 1 INCREMENT BY 1;

SELECT NEXTVAL(seq_account);

```

应用先 `NEXTVAL` 拿到全局号，再把该号连同分片键写入，避免各分片自增重复。

跨分片聚合由 Proxy 在各分片并行计算后二次归并，例如统计全表账户余额总量：

```

SELECT COUNT(*) AS cnt, SUM(balance) AS total_bal

FROM t_account;

```

这类语句不带分片键会广播到全部分片，结果正确但延迟随分片数上升，风控报表类需求应错峰执行。带分片键的聚合只打单分片：

```

SELECT COUNT(*) FROM t_account WHERE user_id = 1001;

```

DDL 下发由 Proxy 统一编排到所有分片，应用无需逐片执行：

```

ALTER TABLE t_account ADD COLUMN phone VARCHAR(20) AFTER user_name;

CREATE INDEX idx_balance ON t_account(balance);

```

注意 DDL 期间会短暂加锁，生产变更应在低峰窗口通过赤兔"变更工单"灰度下发，并先在测试分片验证。删除表同样由 Proxy 广播到全部分片。

风哥数据库教程 itpux-com

### 2.8 TDSQL 分布式集群启动与停止

#### 2.8.1 启动顺序

启动遵循依赖反向：先 TzooKeeper，再 Scheduler/Manager，再 SET 实例，再 Agent，再 Proxy，最后周边组件。

```

# 1. TzooKeeper（两台）

su - tdsql -c "/fgedudb/zookeeper/bin/zkServer.s-h start"

# 2. Scheduler / Manager（两台）

su - tdsql -c "/fgedudb/scheduler/bin/scheduler start"

su - tdsql -c "/fgedudb/manager/bin/manager start"

# 3. SET 实例：先 Master（fgedu-net-cn1），后 Slave（fgedu-net-cn2）

su - tdsql -c "/fgedudb/set/fgedudb/bin/mysqld_safe --defaults-file=/fgedudb/set/fgedudb/etc/my.cnf --user=tdsql &"

# 4. Agent（两台）

su - tdsql -c "/fgedudb/agent/bin/agent start"

# 5. Proxy（两台）

su - tdsql -c "/fgedudb/proxy/bin/proxy start"

# 6. 周边组件：HDFS、Kafka、ES

su - tdsql -c "/fgedudb/hdfs/sbin/start-dfs.s-h"

su - tdsql -c "/fgedudb/kafka/bin/kafka-server-start.s-h -daemon /fgedudb/kafka/config/server.properties"

su - tdsql -c "/fgedudb/es/bin/elasticsearch -d -p /fgedudb/es/es.pid"

```

启动后依次校验：

```

/fgedudb/zookeeper/bin/zkServer.s-h status

/fgedudb/scheduler/bin/schedulerctl status

/fgedudb/scheduler/bin/setctl s-how --set=fgedudb

/fgedudb/proxy/bin/proxyctl --host=fgedu-net-cn1 --port=15001 route list

mysql -h 192.168.10.100 -P 15001 -u fgedu -p'DB_PASS' -e "SELECT 1;"

```

风哥教程 113257174

#### 2.8.2 停止顺序

停止与启动相反：先 Proxy，再 Agent，再 SET，再 Scheduler/Manager，最后 TzooKeeper 与周边组件。

```

# 1. Proxy

su - tdsql -c "/fgedudb/proxy/bin/proxy stop"

# 2. Agent

su - tdsql -c "/fgedudb/agent/bin/agent stop"

# 3. SET：先停 Slave，再停 Master

mysql -S /fgedudb/set/fgedudb/data/mysql.sock -u fgedu -p'DB_PASS' -e "s-hUTDOWN;"

# 4. Manager / Scheduler

su - tdsql -c "/fgedudb/manager/bin/manager stop"

su - tdsql -c "/fgedudb/scheduler/bin/scheduler stop"

# 5. 周边组件

su - tdsql -c "/fgedudb/es/bin/elasticsearch stop"

su - tdsql -c "/fgedudb/kafka/bin/kafka-server-stop.s-h"

su - tdsql -c "/fgedudb/hdfs/sbin/stop-dfs.s-h"

# 6. TzooKeeper（最后）

su - tdsql -c "/fgedudb/zookeeper/bin/zkServer.s-h stop"

```

#### 2.8.3 主备切换演练

在赤兔"实例管理"中对 fgedudb 执行手动切换，或命令行：

```

/fgedudb/scheduler/bin/setctl switchover --set=fgedudb --target=fgedu-net-cn2:3306

```

切换后检查：Master 角色变为 fgedu-net-cn2，强同步恢复 ON，Proxy 路由更新，业务连接无中断。演练后切回，记录 RTO 与位点一致性。

手动切换与故障自动切换要分别演练。手动 switchover 是计划内操作，先确认备机追平主库、强同步 ACK 正常，再优雅地把写角色移交，过程中短暂拒绝新写但不丢数据；故障切换是主节点宕机后的应急动作，Scheduler 基于多数派判定主不可用后把健康备提升为新主，此时要重点核对 RTO（从故障发生到业务恢复的时间）与 RPO（数据丢失量）。强同步保证已提交事务一定落到备机，正常故障切换 RPO 为 0；只有在强同步退避或备机未 ACK 的极端情况下才可能丢少量未提交数据，因此风哥反复强调切换前必须确认 `Rpl_semi_sync_master_status` 为 ON、`Seconds_Behind_Master` 接近 0。

演练记录应包含：切换前主备位点、切换触发命令、新主角色确认时间、Proxy 路由刷新时间、业务连接是否报错、切回过程。建议把手动切换、宕机切换、网络分区三类场景各跑一遍，形成可复用的应急手册，而不是只做一次成功演示。

---

## 风哥针对本文总结

风哥针对本文总结如下：本套风哥教程从数据库系统分类讲起，明确了 TDSQL 在集中式与分布式、OLTP 与 OLAP 坐标中的位置；理论部分拆解了 TDSQL 的六大产品优势、四类落地场景、数据链路与管理链路组件、一主多备的实例架构，以及 MAR 强同步、s-hardkey 分片路由、两阶段提交、读写分离与自动故障切换四项核心技术原理。实战部分以 64GB 内存、8CPU 的双机 fgedu-net-cn1、fgedu-net-cn2 为基线，完成了操作系统基线准备、TzooKeeper/Scheduler/Manager/SET/Proxy/Agent 的集群安装、HDFS 冷备、LVS DR、Kafka、ES 日志平台的周边部署，以及赤兔巡检、监控告警、备份恢复、分片表与分布式事务使用、集群启停与主备切换演练。

风哥提醒读者重点把握三条主线：其一，强同步是金融级一致性的底线，任何时候都要确认 Rpl_semi_sync_master_status 为 ON、备机 ACK 正常；其二，s-hardkey 决定路由效率，建表时必须把分片键纳入主键与唯一键，业务 SQL 尽量携带分片键以避免广播；其三，启动与停止必须遵循依赖顺序，先协调层后数据层、先主后备。生产落地时还需把双机教学环境补齐为三节点 TzooKeeper、奇数台 Scheduler、独立 Proxy 组与两地三中心容灾，并按真实容量重新核算 buffer pool、连接数与磁盘阈值。

风哥教程本文所有命令均以 /fgedudb 为安装根目录、以 fgedudb/fgedudb/fgedu 为实例、库与账号，读者可直接替换到自有实验环境。分布式数据库的工程能力来自反复的安装、切换、备份与故障演练，建议读者按本套风哥教程的步骤完整跑通一遍集群生命周期，再结合真实业务模型做分片设计与性能压测。

---