Zabbix监控库从MySQL迁移TiDB：踩坑总结与实操指南

如果你管过一套上了规模的Zabbix，多半能理解这种焦虑：监控大盘画面看起来还正常，可背后那台MySQL单机库已经在崩溃边缘试探。我们这次就是被逼到这一步，才下决心把Zabbix监控库从MySQL整体迁到了TiDB。整个过程有惊无险，中间踩了不少坑，也整理出了一套可以拿去直接用的实操方法。这篇文章把完整过程记录下来，从方案选型、兼容性摸底、schema导入、参数调整，到数据迁移、切换验证、问题排查，涉及的关键细节都会展开说，适合正在纠结监控库扩容的运维同行，也适合打算把老MySQL库迁到TiDB的团队参考。

1. 为什么最后选了TiDB

1.1 监控库撑不住的三个典型症状

先说我们的实际规模。接手的这套Zabbix监控平台，覆盖了多个机房，受监控主机数量在1500台上下，活跃监控项累计接近40万，采集频率大部分是30秒一次，少部分网络设备是10秒一次。这样跑下来，每24小时落库的history明细数据大约有1000万条，加上trends趋势数据和告警记录，一个季度就能把磁盘空间撑到让DBA皱眉的程度。

症状是逐步出现的。最开始只是MySQL的慢查询日志里出现一些扫描行数千万的history查询，随后是磁盘IO经常跑到90%以上，接着是前端画面偶尔要转好几秒才出图。到了后半年，情况变得更典型：history_uint这张核心大表到了500GB级别，备份时间从最初的几小时被拉长到十几个小时；每次做数据清理，DELETE语句会把主库卡到应用超时；Zabbix Server日志里间歇性出现“history sync process”落盘迟缓的告警。真正的痛点不是单条SQL多慢，而是整个单机MySQL在写入、备份、清理三个环节同时到极限，任何一个环节处理不当都会连锁拖垮监控的实时性。

这时候很多团队的第一反应是继续压榨MySQL，比如换SSD、调buffer pool、加读写分离。但这些方案解决不了本质问题：监控数据是典型的持续高并发写入加周期大海量删除，单机架构在容量和写入吞吐上都有天花板，继续堆硬件只是把问题往后推迟两三个月。

1.2 为什么不继续压榨MySQL，也不选PostgreSQL

既然是Zabbix官方既支持MySQL又支持PostgreSQL，换库的选项似乎很宽，但真正对比下来，可选的路并没有想象中那么多。

继续留MySQL做分库分表是最先被排除的。Zabbix的schema里表与表之间有大量跨表JOIN，前端页面的图型查询动不动就带着四五张表关联，如果按主机维度分库，跨库查询基本没法写；按时间段分表又需要大改Zabbix源码。为了一个开源监控系统去改内核逻辑，后续每次升级都是灾难。

换PostgreSQL也认真评估过。Zabbix对PostgreSQL的支持是完整的，迁移本身也有官方升级路径，但问题出在迁移难度上。监控库里存着好几年的历史数据，MySQL到PostgreSQL不仅字段类型需要转换，部分函数和SQL模式行为也不一致，前端SQL虽然Zabbix内部有抽象，但rownum这类MySQL方言痕迹依然存在。更现实的阻力是团队对PostgreSQL的运维经验明显不如MySQL丰富，出问题的时候排查效率会低不少。

最后摆上桌面的是TiDB。它最吸引人的一点是：连接协议和SQL语法与MySQL高度兼容，应用侧几乎不用改连接方式，很多MySQL写法直接就能跑。与此同时，它又是分布式架构，写入能力可以通过加节点横向扩展，数据存储有多个副本，坏了节点不丢数据。对Zabbix这种以写入为主、单机MySQL已经撑不住的场景来说，TiDB的定位几乎是量身定做。

1.3 TiDB到底哪一点打动了我们

真正打动的其实就两条：兼容和扩容。

先说兼容。TiDB的兼容不是说表面接个MySQL客户端那么简单，而是绝大多数SQL语法、数据类型、事务语义都能无缝对接。Zabbix Server用的是C代码里的MySQL客户端库，PHP前端走的是mysqli扩展，这两条路都能直接连TiDB，端口默认4000，几乎不需要改连接字符串以外的内容。MySQL原生客户端工具、mysqldump导出的SQL文件，在TiDB上都能正常执行。也就是说，我们不需要改Zabbix任何代码。

再说扩容。TiDB的计算节点（TiDB Server）和存储节点（TiKV）是分开的，监控数据量上来了，往集群里加几台TiKV节点就能把存储和写入吞吐撑起来，不需要做任何分库分表逻辑改造。对运维团队来说，这是一条清晰的线性扩容路径，比在MySQL上反复迁移数据实在得多。

当然，选择TiDB不等于没有代价。分布式事务的提交代价比单机MySQL要高，小事务、低并发的场景下延迟反而可能不如MySQL；另外TiDB对部分MySQL特性的支持仍有差异，比如存储过程、触发器、FULLTEXT索引这些，替换前必须逐项排查。把兼容性边界摸清楚，是这次替换能否成功的前置条件。

2. 替换前必须摸清的兼容性底牌

2.1 先搞懂Zabbix到底在数据库里干了什么

动手迁移之前，我先花了一个下午把Zabbix的数据库访问机制重新理了一遍。很多人容易忽略这一步，直接拿schema去TiDB里导入，报错之后再一点一点打补丁，效率很低。

Zabbix对数据库的使用可以分成三层。第一层是配置数据，包括hosts、items、triggers、actions、users、settings这些表，数据量不大，但被Zabbix Server在启动时整体加载到内存里，前端页面也经常查，对事务一致性有要求，写入频率低。第二层是历史数据，包括history、history_uint、history_str、history_log、history_text这五张明细表，以及trends、trends_uint两张趋势表，承担了全库99%的写入量和查询压力，特点是只增不减、按时间查询。第三层是运行数据，比如alerts、auditlog、events、sessions，量级介于前两层之间，前端操作和告警处理都要用到。

这里有一个容易被忽视的关键机制：Zabbix从5.0版本开始默认启用数据库分区，主要针对history和trends系列表，创建方式是Range分区，按clock字段的月份做边界。分区的好处是清理过期数据不再走DELETE，而是对过期分区执行DROP PARTITION，瞬间完成。理解这一点非常关键，因为TiDB支持Range分区，也就是说Zabbix引以为傲的快速清理机制在TiDB上可以保留，不必退化为大量DELETE。

另一个机制是housekeeper。Zabbix Server内置的housekeeper进程负责清理过期事件和审计日志，对分区表走分区删除路径，对非分区表走DELETE。如果迁移后分区功能失效，housekeeper就会用DELETE去啃几百万行的历史表，在TiDB上这会直接触发大事务限制，是我们必须避免的情况。

2.2 一份不完全的TiDB不兼容点清单

Zabbix的schema文件本身比较干净，不涉及存储过程和触发器，但替换前我还是把TiDB和MySQL的差异点列了个清单，照着一条条核对，省得到时候临时抓瞎。

这张表看着简单，实际每条后面都有故事。比如LOCK TABLES，TiDB官方文档里明确说不支持这条语句，但为了兼容MySQL生态，提供了一个叫“noop function”的开关，开启后遇到LOCK TABLES会直接忽略而不是报错。Zabbix前端虽然日常不执行LOCK TABLES，但我们不能保证所有升级脚本和二次开发代码都不碰它，所以提前把开关打开，可以少操很多心。外键也是一样，Zabbix官方schema在6.0版本并不创建外键，如果你们团队自己加过外键，迁移前一定要先去掉，否则TiDB虽然能导入，但外键实际上不会生效，容易造成数据完整性假象。

2.3 快速搭一套能“试错”的TiDB环境

摸清兼容性边界之后，我没有直接在生产环境动手，而是先在测试环境搭了一套TiDB，用来反复试导入和验证功能。这里强烈建议任何打算做替换的团队都走这一步，因为TiDB集群部署本身虽然不难，但有许多参数和逻辑需要在真实环境下观察效果。

测试环境可以用单机方式快速部署。当时的做法是用官方运维工具先起一套本地独立的TiDB，命令行大致如下：

tiup playground v6.5.0 --db 1 --pd 1 --kv 1

这个命令会拉起一个单节点的TiDB测试集群，包含一个TiDB Server、一个PD、一个TiKV，监听4000端口。用MySQL客户端连上去就能操作：

mysql -h 127.0.0.1 -P 4000 -u root

如果是生产环境，建议用统一的集群部署方式，准备好拓扑文件后执行：

tiup cluster deploy zabbix-tidb /opt/tidb/topo.yaml tiup cluster start zabbix-tidb

生产环境的topo.yaml至少要规划3个TiKV节点起步，PD也是3个才能保证容灾，TiDB计算节点视并发量放2到4个。这里不展开完整拓扑写法，重点是要在测试环境先把下面这些动作全部做一遍：创建zabbix库和用户、导入schema.sql、手动执行几条Zabbix前端典型查询、模拟一次分区创建和删除。全套跑通之后，再谈生产切换才靠谱。

创建数据库和用户的SQL在TiDB上写法基本一致：

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'%' IDENTIFIED BY 'your_password_here'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'%';

3. schema导入与参数适配实录

3.1 直接导入schema的第一波报错

测试环境准备好之后，我从Zabbix服务器上拿到了数据库初始化SQL文件，Zabbix 6.0版本的安装包路径一般是/usr/share/zabbix-sql-scripts/mysql/，里面有个压缩的SQL文件，解压出来就是完整schema。

导入命令看着很简单，但真实执行时第一波报错就来了。命令本身是这样的：

gunzip -c server.sql.gz > server.sql mysql -h 127.0.0.1 -P 4000 -u zabbix -p zabbix < server.sql

导入过程中最先碰到的是ERROR 1105 (HY000): unsupported statement。定位发现是schema文件开头的部分MySQL版本注释写法TiDB不认识，报错语句是MySQL 5.01版本注释块里的分区定义语法。这里要说明一下，Zabbix生成SQL文件时会把分区创建语句包在/*!50100 PARTITION BY RANGE ... */这种版本注释里，MySQL自己执行时能识别，TiDB在部分版本下解析这类注释也可能有问题。

解决方式不复杂，我写了个小脚本把server.sql里所有/*!50100 ... */版本注释的包裹去掉，让分区语句变成普通的CREATE TABLE语句的一部分，再执行就没有这个问题了。这个处理在MySQL上也不影响，因为去掉注释后语法本质相同。

随后遇到的第二个报错是字符集相关。TiDB默认的character_set_server和collation_server可能与Zabbix期望的不完全一致，导致建表时出现无法识别的排序规则。解决办法是在TiDB侧把全局变量设成与MySQL一致的组合：

SET GLOBAL character_set_server = 'utf8mb4'; SET GLOBAL collation_server = 'utf8mb4_bin';

设置完之后再重新导入。还有一个容易忽略的地方，TiDB默认SQL模式下NO_ZERO_DATE、NO_ZERO_IN_DATE的开关状态与MySQL常见配置有差异，如果历史数据里有零日期，导入时会报错，建议导入前确认当前会话SQL模式，必要时显式SET一下。

3.2 分区表：Zabbix和TiDB都能接受的方式

分区表的处理是整个适配里最容易出错也最重要的一环。Zabbix 6.0的schema文件里默认给history和trends表预建了一批分区，大约覆盖到当前时间之后几个月，后续运行中由Zabbix Server自动补充新分区。TiDB对Range分区是支持的，创建语法和MySQL几乎一样，这就保证了Zabbix那套自动维护逻辑能继续跑。

但我在测试中发现一个细节：TiDB执行ALTER TABLE ... ADD PARTITION时，分区定义里的VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01 00:00:00'))这个写法是兼容的，而Zabbix server在运行时会周期性检查未来分区是否存在，不足就自动补。所以只要初始分区创建成功，后续自动补充分区基本不用人工干预。

我在测试环境手动确认了分区操作的兼容性，下面两个语句TiDB都能正常执行：

ALTER TABLE history ADD PARTITION (PARTITION p2023_03 VALUES LESS THAN (UNIX_TIMESTAMP('2023-04-01 00:00:00'))); ALTER TABLE history DROP PARTITION p2023_01;

实际运维中强烈建议在迁移完成后检查一次实际表结构，确认history和trends系列表都按分区存在。检查方法很直接：

SELECT TABLE_NAME, PARTITION_NAME FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA='zabbix' AND TABLE_NAME='history';

如果发现分区没建上或者Zabbix Server没有按预期自动补充分区，就需要用计划任务兜底，定期执行补分区SQL。这种情况在版本差异大的时候可能出现，提前做好监控告警，避免分区断档之后housekeeper退化走DELETE引发大事务。

3.3 TiDB与Zabbix两侧的关键参数调整

schema导入跑通之后，不要急着接生产流量，先把两侧参数调到位。TiDB侧有几个参数与Zabbix这种写入密集场景直接相关。

第一个是事务大小限制。TiDB默认的txn-total-size-limit是100MB，意思是单个事务里所有写入和修改的数据总量有限制，超过直接报错。Zabbix虽然用分区表规避了大量DELETE，但导入历史数据和部分维护操作仍可能出现大事务。在配置文件config.toml里我把这个参数调到了2GB：

[performance] txn-total-size-limit = 2147483648

注意这个参数是实例参数，需要修改TiDB Server的配置文件并滚动重启才生效。调大不等于可以乱用，任何超过1GB的事务在分布式数据库里都会引发明显的性能抖动，SRE意识还是要有的。

第二个是noop函数开关。前面提到LOCK TABLES在TiDB默认会报错，打开开关之后会被忽略，对于Zabbix这种不需要依赖MySQL表锁语义的场景，直接开启是安全的：

SET GLOBAL tidb_enable_noop_functions = ON;

第三个是连接数。Zabbix Server和各监控节点走的是短连接池，PHP前端也有连接，TiDB默认最大连接数是4000，实际使用中我们没遇到瓶颈，但压测时曾观察到过too many connections，需要确认Zabbix Server侧线程池配置不要设太高。

Zabbix Server侧要改的就是数据库连接指向。编辑zabbix_server.conf：

DBHost=10.0.1.11 DBPort=4000 DBName=zabbix DBUser=zabbix DBPassword=your_password_here

前端配置文件zabbix.conf.php对应改成：

$DB['SERVER'] = '10.0.1.11'; $DB['PORT'] = '4000'; $DB['DATABASE'] = 'zabbix'; $DB['USER'] = 'zabbix'; $DB['PASSWORD'] = 'your_password_here';

改完之后先不要直接重启，测试环境里启动一次，观察日志里有没有连接报错和初始化失败。Zabbix Server对数据库版本号有基本底线要求，TiDB返回的版本号通常形如5.7.25-TiDB-v6.5.0，前端和server端满足校验需求。

4. 历史数据迁移与切换流程

4.1 迁移策略：配置表全量迁，历史明细不迁

数据迁移往往是最让人头疼的环节，监控库里几百GB的history明细表，如果全量往TiDB灌，既慢又容易触发各种问题。我们当时做了一个务实的选择：配置数据表全量迁移，trends趋势表迁移，history和history_*明细表不迁移，让监控系统从切换时刻开始重新积累。

这个策略背后的逻辑是体验驱动的。Zabbix前端在展示长时间范围图形时，优先使用trends表的数据，trends表每个监控项每小时只有一条记录，体量比history小了两到三个数量级。例如一个监控项一天产生2880条history明细（30秒一次），但trends只有24条。全库40万监控项的trends数据，一个季度大概也就是几千万条，mysqldump导出和TiDB导入都能在可接受的时间内完成。history明细数据虽然丢了，但它只影响短时间曲线的回查，不影响整体监控能力。监控系统的核心价值是当前状态和近期趋势，而不是几个月前的每一笔采集点。

当然，如果业务有硬性要求保留全部历史明细，可以在切换完成后用TiDB的同步工具做增量补录，但那是另一个话题，代价会高很多。对大部分团队来说，配置表加trends的迁移方案性价比最高。

4.2 mysqldump导出与TiDB导入的实操命令

迁移用的工具还是最稳妥的mysqldump，导出的文件TiDB基本能直接吃。具体分两步走，先导结构，再导数据，方便出问题定位。

导结构的时候注意几个参数，--single-transaction是为了保证InnoDB一致性快照，--no-data只导出表结构，避免误把大量历史明细带出来：

mysqldump \ --single-transaction \ --quick \ --skip-lock-tables \ --default-character-set=utf8mb4 \ --no-data \ -h mysql-old -u root -p zabbix > zabbix_schema_only.sql

导入TiDB：

mysql -h 127.0.0.1 -P 4000 -u zabbix -p zabbix < zabbix_schema_only.sql

这里有个隐藏细节，导出时如果MySQL实例上跑的是8.0版本，mysqldump默认会在文件里带上SET @@SESSION.SQL_LOG_BIN=0这类Binlog相关语句。TiDB执行这类语句一般会报错，处理办法是导出时加上--set-gtid-purged=OFF并去掉不必要的会话设置。如果实在还有报错，用sed把对应行处理掉即可。

接着导出配置表和trends表数据。这里用到了--tables参数指定表名，明确哪些表要导，哪些表不导：

mysqldump \ --single-transaction \ --quick \ --skip-lock-tables \ --default-character-set=utf8mb4 \ --set-gtid-purged=OFF \ -h mysql-old -u root -p zabbix \ --tables hosts groups items applications triggers functions \ trends trends_uint alerts events users settings \ > zabbix_config_data.sql

导入的时候如果SQL文件比较大，建议在目标库执行时把输出重定向到日志文件，方便查看进度和报错：

mysql -h 127.0.0.1 -P 4000 -u zabbix -p zabbix < zabbix_config_data.sql > import.log 2>&1

导入完成后做一轮行数校验，这一步绝对不能省。抽样核对hosts、items、trends表的总行数和最新时间点，确保数据没有丢：

SELECT COUNT(*) FROM items; SELECT COUNT(*) FROM trends WHERE clock > UNIX_TIMESTAMP('2023-01-01'); SELECT COUNT(*) FROM hosts;

4.3 切换步骤与回滚预案

切换当天是按这个顺序推进的，全部操作用了大概两个小时。

先停掉Zabbix Server的采集服务，避免切换期间产生增量数据写进旧库。停服这个动作放在晚间业务低峰进行，给历史数据迁移预留足够窗口。然后执行上面说的mysqldump导出，导出完成后导入TiDB，导入完成后校验。校验通过之后，把zabbix_server.conf和zabbix.conf.php的连接信息从旧MySQL改成TiDB地址，启动Zabbix Server。观察Server日志没有数据库连接错误后，前端页面刷新确认主机状态和图形数据正常。

回滚预案我是这样准备的：旧MySQL实例不关机、不停服务，保持原样运行至少一周。因为切换时只是改了Zabbix连接指向，新旧两个库的schema保持一致，万一TiDB侧出现严重问题，把配置文件改回旧MySQL地址，再补一遍切换期间产生的trends数据，就能快速恢复。实际执行中这套预案虽然没有用到，但给了团队足够的心理安全感。

切换完成后还有一个容易被忽略的动作：在TiDB上先跑一遍ANALYZE TABLE，把统计数据刷新出来。因为新导入的库统计信息是空的，TiDB优化器在生成执行计划时可能会选错索引，导致前端页面某些查询突然变慢。执行下面这条命令能让优化器更快进入正常状态：

ANALYZE TABLE hosts, items, trends, history, history_uint;

5. 切换后的功能验证与性能观察

5.1 功能验证清单：从登录到告警一条条过

切换完成后的前24小时是最关键的观察期。我列了一张验证清单，安排团队成员按顺序逐项跑通，确保不是“数据库能连”就算成功。

前端登录和页面加载是第一步。打开Zabbix前端页面，用管理员账号登录，确认仪表盘、主机列表、监控项列表都能正常加载。这一步能快速发现PHP连接层和字符集是否正常。

第二步是检查实时监控数据是否在继续写入。在TiDB侧执行下面的查询，看最新数据时间是否在持续刷新：

SELECT MAX(clock) FROM history_uint WHERE clock > UNIX_TIMESTAMP(NOW() - INTERVAL 5 MINUTE);

如果最大时间一直停在切换时刻，说明采集写入链路有问题，需要立即看Zabbix Server的进程日志。

第三步是图形页面的验证。随机挑几台重要主机，打开不同时间范围的图形，分别覆盖1小时、24小时和7天，确认短时间图形走history表、长时间图形走trends表的数据都能正常绘制，没有断线或白屏。

第四步是告警链路验证。手动维护一台测试主机，触发一个已知的条件，确认触发器状态变化、事件产生、告警通知发送的完整链路都正常。这一步能暴露Zabbix Server事件写入对TiDB事务模式是否敏感。

第五步是housekeeper工作状态验证。查看Zabbix Server日志中housekeeper相关的输出，确认它在处理历史表时走的是分区DROP路径，没有出现大量DELETE。

5.2 性能对比和查询优化手段

切换后两周的观察数据积累下来，性能表现基本达到了预期。写入层面最直观的变化是磁盘IO不再像以前那样频繁打满，因为数据分散在多个TiKV节点上，MySQL单机时代的顺序写放大问题消失了。具体数据上，Zabbix Server的history sync进程处理积压的耗时从高峰期的十几分钟降到了一两分钟以内。

查询层面则出现了新的挑战。分布式数据库在多节点并行扫描上有优势，但优化器的执行计划对统计信息依赖很强。切换初期，前端某些图形查询反而比MySQL慢，定位之后发现是TiDB没有对history_uint表按时间列做有效的分区裁剪，导致查询扫了多个分区。解决办法是确保查询条件里带上clock字段，并且保证统计信息是最新的。对于Zabbix固定的几种查询模式，可以给history_uint、trends_uint表按clock列建立索引，让优化器有更多选择。

如果遇到TiDB侧明显慢的SQL，先从慢查询记录里捞出来看执行计划。TiDB自带慢查询系统表非常方便：

SELECT * FROM information_schema.slow_query WHERE process_time > 3 ORDER BY process_time DESC LIMIT 10;

拿到慢SQL后，用EXPLAIN分析是否走了分区裁剪和正确索引。大多数前端慢查询只要把时间范围条件写清楚，执行计划就会变得正常。

5.3 长期运行必须注意的TiDB运维点

稳定运行之后，维护任务就切换到了TiDB的日常运营。以下几点是我实际运维中最有体会的。

备份方案需要换。原来MySQL逻辑备份那套在TiDB上效率不高，TiDB更推荐用自带的备份工具，比如br命令行工具做全量加增量备份，速度快且对集群影响小。备份策略可以沿用每日全量加每日增量，恢复演练建议每季度做一次。

GC机制需要理解。TiDB删除数据后空间不会立刻释放，而是交给GC机制异步清理，物理空间回收有一定的滞后。切换初期我们观察过磁盘使用率，发现过DROP分区后空间没有马上减少的情况，这是正常现象，不用恐慌，等几个GC周期后就会逐步回收。

TiDB自身的监控不能缺。官方提供了配套的Grafana监控面板，挂载在集群侧，包含TiDB Server、TiKV、PD三层的核心指标。日常重点看TiKV的磁盘使用、CPU、Raft日志状态，还有TiDB Server的SQL执行延迟和连接数水位。一套健康的TiDB集群，TiKV各项指标应该保持平稳，不会出现某节点异常突出的情况。

升级Zabbix版本时要格外谨慎。TiDB对ALTER TABLE中的部分列变更操作支持有限，Zabbix官方升级脚本里如果涉及MODIFY COLUMN类型变更，可能需要在TiDB测试环境先演练一遍，把不支持的操作手工转换过去。

6. 高频问题排查与不为人知的坑

6.1 高频问题速查表

把这一路遇到的问题汇总成一张速查表，后续再有人做类似替换，可以直接按图索骥。

6.2 几条用时间换来的运维经验

最后说几条不常被写进文档里的经验，都是我实际踩过坑之后总结出来的。

第一，正式切换前，一定要在TiDB测试环境里完整跑一遍Zabbix升级路径。我们当时因为测试环境没有跑过升级脚本，后来在TiDB上做小版本升级时卡了好几个小时。有些升级脚本里包含了存储过程创建语句，MySQL能跑、TiDB直接报错，这种问题提前演练就能暴露。

第二，不要把MySQL的备份恢复习惯直接搬过来。刚开始我们本着熟悉的心态，准备用mysqldump做TiDB日常备份，测了一次恢复，数据量一大恢复时间就长得让人难以接受。换成官方备份工具之后，同样的数据量恢复时间缩短了一个数量级。分布式数据库要用配套的备份工具，这是经验之谈。

第三，监控TiDB本身的告警和监控Zabbix一样重要。我们搭了一套独立的轻量监控来盯TiDB集群状态，重点观察PD节点的健康、TiKV节点间心跳延迟、TiDB Server的活跃连接数和慢查询数。TiDB一旦出现节点故障，会自动做Leader切换，但如果你不知道，看到监控曲线抖动就会慌。提前知道节点故障是正常的自愈机制，运维心态会稳很多。

第四，切换后前两周不要做任何大动作。我们当时忍住没动Zabbix升级，也没调TiDB的大参数，只做了统计信息刷新和慢查询优化，整个系统两周平稳后才开始正常迭代。这给团队留出了适应分布式数据库特性的缓冲期，代价最小。

这次替换让我印象最深的一点是，TiDB不是银弹，但它确实在“兼容MySQL生态”和“分布式扩展能力”之间找到了一个对运维团队很友好的平衡点。Zabbix跑在TiDB上不是官方标准架构，需要自己踩过坑才会熟练，但一旦摸清了这些边界，整套方案完全可以在生产环境稳定跑下去。