兼职铲屎官看到这条标题的时候，我心里其实会心一笑：把“MySQL主从复制”和“SG-Nav 分层思维链 H-CoT / 在线分层 3D 场景图 / 目标导航”放在一起，看起来像是从两份完全不同资料里各截了一段，拼成了一条让人摸不着头脑的题目。但做架构做久了就会发现，这类“混搭”反而是真实工作里的常态——一个平台既要稳住数据底座的高可用，又要支撑机器人这类智能体的实时决策，两套东西在表面上天差地别，底层却共用一套很朴素的思想：系统必须能在单点失效时继续工作。
因此这篇不打算按单线程资料写。我按标题给的两条线索，各拆成可复现的实战内容。前半段围绕 MySQL 主从复制，从 binlog 到故障切换，把高可用架构真正落地的步骤、参数和演坑讲清楚；后半段聊聊 SG-Nav 代表的场景理解和目标导航方案，它看起来属于机器人方向，但“在线分层 3D 场景图 + H-CoT 分层思维链”这套设计，恰恰和数据库复制里的分层、追踪、恢复逻辑高度同构。
如果你只关心数据库高可用，可以直接看 2、3、5 三节；如果想理解我为什么把两个领域放进同一篇文章，那最好从头读完。
1. 标题里的两个“高可用”：一个在数据链路，一个在任务推理
先说数据库侧。MySQL 里做一主一从，已经是很多团队接触的第一套高可用方案。只要把写入集中在主库，把读流量或者是灾备流量交给从库，主库一旦故障，至少还有一个完整的数据副本可以顶上。听起来简单，真正压垮系统的往往不是复制本身，而是三个问题：切换需要多久、切换之后会不会丢数据、旧主恢复后如何防止双写脑裂。
机器人侧的问题也很像。SG-Nav 这类系统要完成“目标导航”——不是给机器人一个坐标点，而是告诉它“去厨房找一个杯子”或“找到走廊尽头的白板”。它不能靠单一、静态、只有几何信息的栅格地图硬搜，因为目标对象的准确位置本来就未知。更靠谱的做法是在线维护一张分层的 3D 场景图，既有房间级拓扑，也有物体节点和空间关系；再配合 H-CoT 分层思维链，让机器人像人一样分步推理：先判断目标最可能出现在哪个功能区，再走到那个区域，接着在小范围内修正目标位置。找不到就更新图里的置信度，重新规划。
两个场景的因果链条完全不一样，但核心模型一致：把一个大系统拆成可观测、可追踪、可回滚的状态副本，并且在状态不一致时有一套仲裁和恢复机制。数据库里这套机制叫 binlog、GTID、主从角色切换；机器人系统里叫场景图节点更新、子目标生成、失败重规划。一个是处理“数据”，一个是处理“空间语义”，架构语言却是通用的。
这也是我写这篇内容的原因：与其把资料当成独立两篇来背，不如把它们放在同一个实战框架里对照，效果比单向罗列好得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MySQL 主从复制落地：以 binlog 为线索把两个实例串起来
2.1 从一个干净的 Docker 环境开始
我常用 Docker 搭 MySQL 主从实验环境，原因只有一个：清理方便。生产环境后来大多数都会落到云上，但本地验证思路时 docker compose 是最省时间的方案。以下是一个最小可跑的主从结构。
先建一个自定义网络，保证两个容器可以用服务名互访：
bash复制docker network create mysql-ha
主库容器：
bash复制docker run -d \
--name mysql-master \
--network mysql-ha \
-p 3306:3306 \
-e MYSQL_ROOT_PASSWORD=rootpass \
-e MYSQL_DATABASE=appdb \
mysql:8.0 \
--server-id=1 \
--log-bin=mysql-bin \
--binlog-format=ROW \
--gtid-mode=ON \
--enforce-gtid-consistency=ON \
--binlog-expire-logs-seconds=604800
从库容器：
bash复制docker run -d \
--name mysql-slave \
--network mysql-ha \
-p 3307:3306 \
-e MYSQL_ROOT_PASSWORD=rootpass \
mysql:8.0 \
--server-id=2 \
--gtid-mode=ON \
--enforce-gtid-consistency=ON \
--skip-log-bin
这里几个参数值得单独解释，因为多数安装问题不是“没装好”，而是这些参数没对齐：
server-id：主从拓扑里每个节点必须唯一。我用 1 和 2 很简单，但