Appearance
第3章 数据库部署与验收（Vastbase 主线）
对应简历：技能第6条「熟练掌握 MySQL、Vastbase（OpenGauss，PostgreSQL 系）数据库集群部署与验收，熟悉 Redis、RocketMQ、Nacos 等中间件部署」；项目一 P1-3「负责 Vastbase G100 一主一备集群部署、license 导入与参数调优（最大连接数 / 线程池），完成数据库环境验收」；项目二 P2-4「配套云数据库 MySQL 主备等云服务开通配置」。 实施版口径：Vastbase 是主角——部署、调优、验收全流程扩写放开讲（真实生产经历）；MySQL 按"部署备援"保留安装与主从搭建；慢查询/索引压缩为两节。产品层深挖（openGauss 家族、选型三段论）见华为篇第 4 章；Redis 部署在第 4 章中间件交付。 使用提醒：Vastbase 的命令链是实施岗面试的"手上功夫"证明，3.2–3.4 的实操模板要求能默写。本章末附口径红线（3.13），面试前再读一遍。
3.1 实施工程师的数据库职责总述 【必背】
标准回答：先说结论：实施工程师对数据库的职责是"装得起来、调得对、验得过、交得清楚"，和 DBA 的"持续优化、故障救火"是两个视角。展开四件事：第一装得起来——按客户信创要求和配套表选型数据库，在国产化环境完成集群部署，我在银行项目部署的是 Vastbase G100 一主一备，跑在麒麟 V10 加鲲鹏 ARM 上，安装包就是 kylin_v10sp1-aarch64_kunpeng 专用包；第二调得对——部署完按业务预估做参数调优，我实际调过 max_connections 从 100 到 10000、开线程池，每个参数都讲得出为什么；第三验得过——输出验收清单逐项验证：服务状态、主备角色、切换演练、连接测试，银行项目数据库环境验收是我负责过的，平台的"一次通过客户验收"里有我这一块；第四交得清楚——部署步骤、参数说明、日常巡检命令、备份口径写进部署手册交给客户。选型类问题我的角色口径要先亮出来："数据库选型是华为配套体系加银行信创合规定的，我负责按配套表落地实施"——这句先说，既不越位又能顺势展示落地能力。这个总述答完，面试官基本就清楚我对数据库的边界在哪，后面的追问都会落在我的主场。
追问链：
- 追问1：为什么不选 MySQL 而选 Vastbase？ → 答：先亮角色再讲理解："选型是华为和银行按配套体系定的，我负责落地"，然后给三条配套理由：金融信创目录合规要求必须国产数据库；Vastbase 是 openGauss 内核的商业发行版，对鲲鹏 ARM 原生适配（我拿的就是专用包）；与华为 BCS 区块链平台的配套认证体系。它是 PG 系语法，vsql 和 DataStudio 工具链与 PG 兼容。选型三段论的完整展开见华为篇第 4 章 4.9——面试深挖"选型逻辑"时按那个框架答。
- 迭问2：数据库部署完你怎么确认"能交给客户了"？ → 答：跑我的验收清单五项：高可用组件健康（systemctl status has dcs）、集群主备角色正确（hasctl list）、模拟故障切换验证（停主库看备库升主）、应用连接测试（vsql 命令行加 DataStudio 图形界面双验证）、参数生效核对。每项截图留档进验收材料——"验得过"的标志不是我觉得没问题，而是每一项有证据。这套清单详见 3.4。
- 迭问3：调研和方案阶段，数据库部分你要提前跟客户确认什么？ → 答：五件事必须前置：选型与版本（配套表定，客户信创目录确认）；资源规格（CPU/内存/磁盘按业务量估，数据库节点建议独立数据盘和日志盘）；网络（数据库网段、应用访问路径、防火墙端口）；高可用要求（一主一备起步，切换容忍度是多少）；备份口径（客户有没有集中备份平台纳管）。这五件在规划期对齐，安装期就是照表施工——数据库是所有组件里"前置功课收益最大"的一个，返工成本也最高。
3.2 Vastbase 一主一备部署全流程 【必背】
标准回答：这是我在银行项目亲手做的真实部署，全流程六步我能背出来。第一步环境准备：两节点上传安装包和自动化部署包，配置 install.conf 写安装目录和 IP——关键细节是安装目录建议以 /home/vastbase 为前缀，因为自动化脚本用 vastbase 用户执行，装到其他目录会因为没有读写权限而失败，这个坑我踩过并写进了指南。第二步双节点同时执行安装：两节点同时跑 sh vbcluster_install.sh install.conf，执行时间误差不能超过 10 秒——这是集群初始化握手的要求，我们实际操作是两个人对好时间同时回车。第三步配置高可用组件自启：systemctl enable has dcs——HAS 是高可用组件负责监控和自动切换，DCS 是分布式配置存储，角色类似 etcd 的一致性底座。第四步 license 管理：首次部署自带 3 个月免费期，到期前上传新 license、改 vastbase.yml 里的 license 路径、再滚动重启 has——先重启一个节点、确认就绪后再另一个，两台同时重启 DCS 会失去多数派，有双主风险，这个顺序是硬纪律。第五步参数调优（3.3 展开）。第六步验收（3.4 展开）。这套流程后来完整沉淀进《智能合约引擎安装部署指南》，成为公司同类项目的标准章节——面试官问"国产数据库你实际用过吗"，我的回答不是"了解"，是"装过、调过、验过、写成过文档"。
追问链：
- 迭问1：为什么两节点执行误差不能超过 10 秒？ → 答：因为集群初始化时两个节点要互相握手协商主备角色，时间窗内双方都在等对方注册；误差太大，先执行的一方会初始化超时或单边成主，后到的加入流程就乱了。所以操作上是两人协同同时执行——这种"多节点动作要同步"的约束在分布式系统部署里很常见，K8s 集群初始化也有类似的时间敏感环节，我在第 6 章会呼应。
- 迭问2：HAS 和 DCS 到底是什么，和 MySQL 体系怎么对应？ → 答：HAS 相当于数据库的高可用管理进程，负责监控数据库状态、发起自动主备切换——角色类似 MySQL 生态的 MHA/Orchestrator 加上云数据库的 HA 管理；DCS 是分布式配置存储，存集群元数据和一致性仲裁——角色类似 etcd，选主决策靠它达成多数派。用"我熟悉的组件"做对应记忆是我快速上手国产化软件栈的方法，这个对应表华为篇第 4 章 4.8.1 有完整版。
- 迭问3：部署踩过什么真实的坑？ → 答：两个。第一安装目录权限：自动化脚本用 vastbase 用户跑，目录不在它可控范围就直接失败——解决是提前规划目录属主，这条我写进指南的"前提条件"。第二 license 更换的重启方式：必须滚动重启 has，先 A 后 B，同时重启有双主风险——这是厂商支持和实际验证得出的操作规范，也标红进了文档。坑不可怕，踩过变成文档条目，下一个项目就不再是坑。
- 迭问4（深挖）：license 到期会发生什么？ → 答：到期前厂商和监控系统都有提醒窗口，我的做法是把 license 有效期做进巡检项，到期前一个月申请替换，避免临期被动。替换动作本身就是"上传新文件、改配置路径、滚动重启 has"三步，关键是滚动顺序和做在业务低峰。这块我按实际操作口径答，license 机制内部的实现细节不属于我深入过的层面，如实说。
实操模板（部署命令链，可背）：
bash
# 1) 两节点同时执行（误差 <10s，两人协同回车）
sh vbcluster_install.sh install.conf
# 2) 高可用组件开机自启
systemctl enable has dcs
# 3) 安装目录前提：属 vastbase 用户（install.conf 建议以 /home/vastbase 为前缀）
# 4) license 更换
vi /etc/vastbase/has/etc/vastbase.yml # 修改 licence 路径
systemctl restart has # 先节点A，就绪后再节点B（滚动，防双主）3.3 Vastbase 参数调优与 license 管理 【必背】
标准回答：参数调优我讲"为什么调、怎么调、怎么验"三段。为什么调：数币平台是多组件并发访问数据库的场景，默认参数面向通用小负载，连接数上限默认 100 根本不够用，不调上线第一天就可能撞墙。怎么调：用 hasctl -c /home/vastbase/has/etc/vastbase.yml edit-config 进配置编辑，改两组参数——max_connections 从 100 调到 10000，支撑平台各组件的连接规模；enable_thread_pool = on 开线程池，配套 numa_distribute_mode = 'all' 和 thread_pool_attr = '128,1,(allbind)'。这里有个值得主动讲的原理：openGauss 是线程池模型，连接由线程池复用处理，调万级连接的开销远小于 MySQL 那种每连接一线程的模型——这是 openGauss 内核的设计红利，也是我敢把连接数调到 10000 的底气。怎么验：:wq 保存后滚动重启 has（先一个节点就绪后再另一个），起来后登录验证参数生效、业务连接压一轮确认。license 管理一并说：自带 3 个月免费期，正式替换走"上传、改路径、滚动重启"三步，有效期进巡检项提前一个月动作。调参的纪律就一条：每个参数都讲得出业务理由，调完有验证动作——不解释理由的调参在客户评审那儿过不去。
追问链：
- 迭问1：max_connections 调 10000 不会有问题吗？MySQL 为什么不敢这么调？ → 答：关键在进程模型差异。openGauss 线程池模式下，连接和执行线程解耦，万个连接由池里有限的工作线程复用服务，内存和调度开销可控；MySQL 每连接一线程，一万连接就是一万个线程的栈内存和调度压力，直接把机器拖垮。所以同一个数值在两个体系里含义完全不同——能讲出这个差异，就证明我不是抄参数而是理解了机制，这也是华为篇第 4 章线程池参数那节的核心点。
- 迭问2：thread_pool_attr = '128,1,(allbind)' 什么含义？ → 答：按线程池属性的结构：128 是工作线程数，1 是每个线程可并发处理的会话数，(allbind) 表示绑定全部 CPU 核。它和 numa_distribute_mode 配合做 NUMA 感知的线程分配，减少跨 NUMA 访问内存的开销——鲲鹏是多路多核平台，NUMA 意识是这类机器调优的基本功（NUMA 概念见第 8 章 8.10 的鲲鹏服务器特点）。参数级更深的语义我理解到这层，如实给边界。
- 迭问3：调完参数怎么验证生效？ → 答：三步：重启后
show max_connections;级别的查询确认运行时值；看 has 集群状态确认两节点都正常；再用应用侧压一轮并发连接验证实际可用。我的习惯是验证结果截图进验收材料——"调了"和"调对且证明了"在交付里是两回事。
实操模板（调优命令链，可背）：
bash
/home/vastbase/has/bin/hasctl -c /home/vastbase/has/etc/vastbase.yml edit-config
# max_connections = 10000
# enable_thread_pool = on
# numa_distribute_mode = 'all'
# thread_pool_attr = '128,1,(allbind)'
# :wq 保存 → 滚动重启 has（先A就绪再B）
su - vastbase -c "vsql -c 'show max_connections;'" # 验证3.4 Vastbase 环境验收：清单与主备切换验证 【必背】
标准回答：数据库环境验收是简历 P1-3 的原文职责，我的验收清单固定五项，每项有明确通过标准。第一项组件健康：systemctl status dcs 和 systemctl status has 都是 active，这是集群的地基。第二项集群角色：hasctl -c /home/vastbase/has/etc/vastbase.yml list 输出里主备角色正确——一台 Primary 一台 Standby，角色错乱一切免谈。第三项数据库可用：su - vastbase -c "vsql -r" 命令行能登录，建测试用户、授权、查询走通；再用 DataStudio 图形工具远程连接验证——命令行和图形工具双验证，因为客户侧运维习惯不一样，两种入口都必须好使。第四项故障切换演练：模拟主库故障（停主节点数据库），观察 HAS 自动切换、备库升主；再验证应用连接恢复——银行环境的验收这个环节客户是看着做的，切不过去就是一票否决。第五项参数与基线核对：调优参数生效值、自启动配置、时间同步、备份口径逐项对表。这套"查状态、造故障、验入口"的三段式验证方法和我在 K8s 上做控制面故障切换演练是同一套方法论——面试里我会主动把两个项目的验证方法对应起来讲，证明方法论可迁移，不是碰巧做成一次。
追问链：
- 迭问1：切换演练具体怎么做的？停主库会不会有风险？ → 答：做法是窗口期内停主节点的数据库进程，盯 hasctl list 看 Standby 升 Primary，然后从应用侧发连接验证恢复，最后把原主拉起来确认它以备机身份重新加入。风险控制三点：演练安排在测试验证阶段或客户批准的窗口，不影响真实业务数据；演练前确认数据已同步、无大事务在途；演练步骤提前写成方案给客户确认。做演练不是逞能，是给客户"故障时刻的行为预演"——验收时客户最买账的就是这个环节。
- 迭问2：应用怎么做到切换无感？ → 答：靠连接入口的解耦：应用连接串指向数据库的浮动地址/服务入口而不是某个物理节点 IP，主备切换后入口自动指向新主，应用重连即恢复。这和我用 Nginx+Keepalived 做 apiserver 的 VIP 漂移、云上 CLB 摘除故障节点是同一个设计思想——"入口虚拟化加故障自动切换"，我在第 4、6 章都会回到这个模式，面试里把它串成一条线讲非常加分。
- 迭问3：切换后数据一致性怎么确认？ → 答：三层确认：切换前记录主库的写入位点或关键表的行数；切换后在新主上核对同一批数据（行数、抽查最近写入的记录）；应用侧做一轮读写验证。同步型复制下这基本是走形式，但形式必须走——验收材料里"切换后数据一致"这一行要有证据支撑，这是金融客户的底线要求，也是我敢在客户面前做演练的底气。
- 迭问3（深挖）：验收报告里数据库部分写什么？ → 答：四块：环境信息（版本、架构、节点、参数配置）；验证项与结果（五项清单逐条，附命令输出截图）；遗留事项与建议（比如 license 到期日提醒、备份策略待与客户备份系统对接）；签字确认栏。这套结构是我从银行项目验收材料里沉淀的，第 15 章 15.11 有验收报告的完整模板结构——数据库作为其中一个章节嵌进去。
实操模板（云数据库交付 checklist，可背）：
text
□ 1 规格确认：版本/规格/存储与方案一致（选型理由写入方案）
□ 2 网络：VPC 内网 + 安全组仅放行应用网段→3306
□ 3 账号：应用账号最小权限、管理账号分离、密码符合客户策略
□ 4 高可用与备份：主备同步状态、每日全备+binlog 保留 7 天、恢复到时间点验证过
□ 5 连接交付：连接串（集群入口而非物理节点）+说明写入运维文档
□ 6 验收：连接/权限/备份可恢复/延迟指标四项核对并留证实操模板（验收命令链，可背）：
bash
# 验收四查
systemctl status dcs && systemctl status has # 1 组件健康
/home/vastbase/has/bin/hasctl -c /home/vastbase/has/etc/vastbase.yml list # 2 主备角色
su - vastbase -c "vsql -r" # 3 命令行登录
# DataStudio 远程连接 → 图形入口验证
su - vastbase -c "vsql -c 'show max_connections;'" # 4 参数核对
# 切换演练：停主库进程 → hasctl list 看升主 → 应用连接验证 → 原主恢复入集群3.5 Vastbase 日常运维与备份口径 【理解】
标准回答：日常运维三件事我按巡检、会话、备份讲。巡检三看：systemctl is-active has dcs 组件健康、hasctl list 主备角色、会话与长事务——select * from pg_stat_activity 是 PG 系的 processlist 等价物，能看到每个会话的状态和 SQL；要终结会话用 pg_terminate_backend(pid) 对应 MySQL 的 kill。巡检还要专门抓 idle in transaction 状态的长会话——它阻碍 vacuum 回收，是 PG 系特有的危害点，这个细节体现真用过。与 MySQL 的运维差异我总结五条：客户端 vsql 对应 mysql、元命令 \l 列库 \du 列用户、工具 DataStudio 对应 Navicat；复制机制 openGauss 主推物理 WAL 日志流复制，MySQL 是逻辑 binlog；线程池模型对比每连接一线程；默认隔离级别 PG 系 RC、MySQL RR，迁移应用要注意快照读行为差异；迁移工作量主要在开发侧（函数语法、序列替代自增等）。备份口径我的诚实分层：客户环境有集中备份平台统一纳管，我的职责边界是集群部署验收；但工具族对应关系我讲得清——gs_dump 对应 mysqldump（逻辑导出）、gs_basebackup 对应 XtraBackup（物理全备）、WAL 归档对应 binlog（PITR 按时间点恢复），"物理备份加 WAL 归档"和"XtraBackup 加 binlog"完全同构——同构的知识迁移是我学国产化栈最快的原因。
追问链：
- 迭问1：vsql 里怎么查"processlist 等价物"？ → 答：
select * from pg_stat_activity看会话状态、等待事件、执行 SQL；终结用pg_terminate_backend(pid)。再加一条巡检要点：抓 state 为 idle in transaction 且时间长的会话优先清理。这两条是我背熟的日常组合，答的时候顺带对比 MySQL 的 show processlist 和 kill，展示双体系能力。 - 迭问2：备份策略客户侧怎么定的？ → 答：金融客户有集中备份平台，数据库纳入平台统一策略（全备周期、保留期都是平台定的），我的职责是确保部署侧配合：归档参数、备份账号权限、恢复演练配合。这个口径在面试里很重要——不冒充做过完整 PITR 演练，但讲得清机制和对应关系，边界诚实反而加分。
- 迭问3：Vastbase 的验收和 MySQL 的验收，动作上有什么不同？ → 答：框架相同（3.10 的八项通用清单），差异在工具和专项：Vastbase 多了 has/dcs 组件健康、hasctl 角色查询、license 有效期核对，工具用 vsql 加 DataStudio；MySQL 是 show slave status 双 Yes 加延迟指标，工具用 mysql 客户端加 Navicat 类。切换演练两边都要做——Vastbase 靠 HAS 自动切换、MySQL 自建场景要确认半同步和提升从库的手顺。同一张验收清单模板换"专项检查"一列就能在两个库之间复用，这也是我把清单模板化的原因。
关联话术："数据库话题我按三层讲：Vastbase 部署验收是生产实操随便挖；MySQL 是课程实验加云上运维（移动云 MySQL 8.0 主备是我配置交付的）；原理层两套体系同构对比着讲。面试官问'国产数据库你实际用过吗'——我答'装过、调过、验收过、写成过标准文档'，这四个动词就是我的差异化。"
实操模板（Vastbase 日常巡检命令组，可背）：
bash
systemctl is-active has dcs # 1 组件健康
/home/vastbase/has/bin/hasctl -c /home/vastbase/has/etc/vastbase.yml list # 2 主备角色
su - vastbase -c "vsql -c \"select state,count(*) from pg_stat_activity group by state;\"" # 3 会话分布
su - vastbase -c "vsql -c \"select pid,now()-state_change from pg_stat_activity where state='idle in transaction' and now()-state_change>'30 min';\"" # 4 长事务
# 5 license 有效期、磁盘空间纳入巡检表，异常截图留档对照速查（Vastbase vs MySQL：实施视角五件事）：
| 事项 | Vastbase/openGauss | MySQL |
|---|---|---|
| 部署形态 | 厂商自动化脚本双节点同时执行（误差<10s） | mysqld --initialize 或包管理安装 |
| 高可用组件 | has + dcs（systemd 托管） | 主从复制（自建）或云侧托管 |
| 角色与状态 | hasctl list | show slave status\G |
| 会话管理 | pg_stat_activity / pg_terminate_backend | show processlist / kill |
| 验收核心 | 组件健康+角色+切换演练+双工具连接 | 双 Yes+延迟趋零+切换演练 |
3.6 MySQL 部署备援：安装与初始化 【理解】
标准回答：MySQL 是我的第二数据库技能，按"部署备援"口径讲——非信创项目或客户指定 MySQL 时我能独立交付。安装三种方式按定制度排：yum/rpm 最快但路径不可定制，CentOS 上要先卸 mariadb-libs 防依赖冲突；二进制 tar 包解压即用、目录自定、升级回滚方便，是我喜欢用的方式；源码编译只在特殊需求时用。初始化流程：5.7/8.0 用 mysqld --initialize 生成数据目录和随机临时密码（在错误日志里 grep "temporary password"），或者 --initialize-insecure 生成空密码；启动后 alter user 改密、跑安全初始化（删匿名账号、禁远程 root）。配置文件核心项清单：datadir、socket、character_set_server=utf8mb4、server_id（主从必须不同）、log_bin 开 binlog——后两项是主从和按时间恢复的地基。启动不了我的三步排查：先看错误日志（八成问题它直接告诉你）；mysqld --defaults-file 前台手工启动看真实报错；查 datadir 属主必须是 mysql:mysql 加磁盘空间。红线一条：绝不能一怒之下重新 initialize——那等于删库。这套我在课程实验里把每种启动失败都人为制造过一遍，自建场景心里有谱。
追问链：
- 迭问1：忘记 root 密码怎么办？ → 答：四步：my.cnf 加 skip-grant-tables → 重启 → 免密登录改密码 → 去参数再正常重启。注意两点：跳授权状态任何人都能连，必须本机或维护窗口做；改完立刻恢复配置。这是八股高频题，答的时候带上安全意识就是加分项。
- 迭问2：8.0 和 5.7 部署层面有什么差异？ → 答：三条最相关：默认字符集 8.0 就是 utf8mb4（5.7 默认 latin1 必须显式改）；8.0 必须 create user 和 grant 分开（5.7 可一条龙，8.0 已废弃）；8.0 默认认证插件 caching_sha2_password，老客户端连不上，兼容方案建用户时显式 mysql_native_password——这个坑我真实遇到过，新库老应用报认证错误，一条命令解决。
- 迭问3：my.cnf 的核心参数清单报一下？ → 答：按交付模板我固定写这几项：datadir 与 socket 路径、character_set_server=utf8mb4、server_id（主从必须不同）、log_bin 开 binlog 加 binlog_format=row、max_connections 按业务并发、slow_query_log=ON 加 long_query_time=1（不开慢日志等于放弃排障入口）、双一配置按安全等级定（金融场景 sync_binlog=1 加 innodb_flush_log_at_trx_commit=1）、innodb_buffer_pool_size 专用库给内存的 50% 到 70%。每个参数配一句"为什么"写进手册注释，客户评审和后续接手的人都能看懂取舍。
实操模板（MySQL 部署初始化命令链，可背）：
bash
# 二进制包部署核心流程
tar -xzf mysql-8.0.x-linux-glibc2.28-$(uname -m).tar.gz -C /usr/local/
useradd -r mysql && mkdir -p /data/mysql && chown -R mysql:mysql /data/mysql
mysqld --initialize --user=mysql --datadir=/data/mysql # 临时密码在 error log
grep 'temporary password' /data/mysql/error.log
systemctl enable --now mysqld # unit 按 /usr/local 管理
# 首次登录后: alter user 改密 + 安全初始化(删匿名账号/禁远程root)关联话术："项目二我用的是移动云 MySQL 8.0 主备实例——我的职责是规格规划、安全组放行、账号权限、连接信息交付给应用；自建安装维护在课程实验里完整做过。云上交付加自建能力两层都有，答的时候诚实分层，每层都站得住。"
3.7 MySQL 主从搭建与验收 【必背】
标准回答：主从复制用三线程模型讲：主库 dump 线程推 binlog，从库 IO 线程收进中继日志 relay log，从库 SQL 线程重放。搭建步骤可默写：主库建复制账号 grant replication slave、开 log_bin 设 server_id；从库导入全备后 change master to 指定主库地址、账号、binlog 位点（GTID 模式用 master_auto_position=1 自动对齐，不用手工记位点，搭从库简单得多）；start slave 然后 show slave status\G 验收——Slave_IO_Running 和 Slave_SQL_Running 双 Yes、Seconds_Behind_Master 趋零，这"三件套"就是我的验收标准，任何一个 No 就看 Last_IO_Error/Last_SQL_Error 的具体报错。一致性等级主动讲：默认异步，主库宕机可能丢最新事务；半同步要求至少一个从库 ACK 收到 binlog 才返回成功，大幅缩小丢失窗口。这套知识我会主动做一次迁移："银行 Vastbase 一主一备原理同一层——也是日志传送加重放，只是传物理 WAL 流、MySQL 是逻辑 binlog，我两套都实际部署过"——这句迁移是我数据库话题的差异化答法。
追问链：
- 迭问1：给运行两年的库搭从库要停主库吗？ → 答：不用。低峰在主库 mysqldump 加 --single-transaction（InnoDB 一致性快照不锁表）和 --source-data=2（位点写进备份文件），全备导入新从库，按位点 change master（GTID 直接 auto position），start slave 追增量。全程主库正常服务——这个方案的意义是"扩从库不需要停业务窗口"，实施场景很实用。
- 迭问2：SQL 线程 No 最常见原因？ → 答：回放冲突——从库被直连写入过，主库日志重放撞上"记录已存在"。处理以主库为准修从库数据再重启 SQL 线程；根治是制度加技术双防：从库设 read_only 加 super_read_only、只发只读账号、"从库绝不直写"写进规范。技术修复之外必须有制度修复——这是经典故障教我的。
- 迭问3：从库延迟怎么发现、怎么处理？ → 答：发现靠 Seconds_Behind_Master 巡检和告警。原因分主库侧（大事务、慢 SQL）和从库侧（单 SQL 线程串行回放是天生瓶颈、从库配置差、备份大查询抢资源）。处理：拆大事务优化慢 SQL；开并行复制（8.0 writeset 方案更彻底）；从库同规格、备份报表分流。读写分离下延迟的直接症状"下单后立刻查不到"要会讲：工程方案写后读走主库。
- 迭问4：GTID 和传统位点怎么选？ → 答：我优先 GTID：每个事务全局唯一编号，change master 用 master_auto_position=1 自动对齐，不用手工记"文件名加位点"，搭从库和故障切换都简单得多、也更不容易错；传统位点的适用是老版本或特殊复制拓扑不支持 GTID 的场景。实操差异说一句：位点方式要把备份里记录的 binlog 文件名和 pos 抄进 change master，抄错一位从库就起不来；GTID 一条 auto position 完事——用过的人才知道哪个坑多。
实操模板（主从搭建，可默写）：
sql
-- 主库
grant replication slave on *.* to 'repl'@'10.0.x.%' identified by 'xxx';
-- my.cnf: log_bin=on server_id=1
-- 从库导入全备后:
change master to
master_host='主库IP', master_user='repl', master_password='xxx',
master_log_file='binlog.000005', master_log_pos=1234; -- GTID 则 master_auto_position=1
start slave;
show slave status\G -- 双Yes + 延迟0 = 验收通过3.8 备份策略与恢复演练 【必背】
标准回答：备份我按"策略三层 + 演练一层"讲，这套方法论跨数据库通用。策略层：全量——小库每日 mysqldump（--single-transaction 不锁表、--master-data=2 记位点），大库每日或每周 XtraBackup 物理备（拷数据文件加持续抓 redo，恢复快）；增量——binlog 是普适增量，保留 3 到 7 天，重要系统 7 到 15 天，大库再叠 XtraBackup 增量；实施细节四条——备份放从库跑、凌晨低峰、crontab 调度配日志留痕配失败告警（脚本见第 2 章 2.12）、find -mtime 滚动清理防备份盘自爆。经典对比题必须会：23:00 开始 23:30 结束的备份，mysqldump 理论只能恢复到 23:00 的快照点（之后靠 binlog 补），XtraBackup 能恢复到 23:30（含备份期间的 redo）。演练层是我特别强调的：定期把全备导入测试库、mysqlbinlog 按位点截取增量重放、核对数据——没演练过的备份等于没有备份，因为你不知道它能不能恢复、要多久。误操作恢复三步也背下来：测试库恢复最近全备 → 解析 binlog 跳过误操作语句截取增量 → 误伤表数据导出回灌生产。这套方法在 Vastbase 侧同构适用（3.5 讲过对应关系），在 K8s 侧我还用它管 etcd 快照——同一套"备份+演练+规范"三件套贯穿我所有交付。
追问链：
- 迭问1：8 点全备、9 点误 drop 一张小表、有 binlog，怎么恢复？ → 答：四步：测试库恢复 8 点全备；mysqlbinlog 解析 8 到 9 点日志按表名过滤、跳过那条 drop；增量在测试库重放，得到 9 点误删前一刻的表状态；导出该表回灌生产。两个关键点：恢复动作全在测试库做、生产只接受最终回灌；回灌前锁定该表操作窗口评估冲突。小表全程半小时级——这个题是备份八股的必考题，我把步骤背成了顺口溜。
- 迭问2：物理备份和逻辑备份怎么选？ → 答：逻辑备份（mysqldump）跨版本跨平台、可精确到单库单表、文本可读，但量大时恢复慢（本质是重放 SQL）；物理备份（XtraBackup）拷文件快、恢复快、支持增量，但绑定版本和平台。我的三档策略：30G 内每日逻辑全量加 binlog；30 到 200G 每日物理全量加 binlog；200G 以上每周全量加每日增量加 binlog，备份移从库。选择逻辑是"按数据量决定备份方式、按业务决定保留期"，不是背参数。
- 迭问3（深挖）：RPO/RTO 怎么讲？ → 答：RPO 最多丢多少数据，由刷盘策略（双一配置）和备份频率决定；RTO 多久能恢复，由数据量、备份方式和演练熟练度决定——所以定期演练本质是在压缩 RTO。用 RPO/RTO 语言讲备份，把操作题提升到架构题高度，这套度量语言我在割接方案的风险评估里也用（第 15 章 15.12）。
- 迭问4：备份文件存在哪、怎么管理？ → 答：三层管理：本机目录按日期组织（full/binlog 分目录、find -mtime 滚动清理）；第二层同步到独立存储——备份和数据库放同一台机器等于没备份，我同步到监控节点或专用备份盘；第三层重要系统异机/异地留存。备份的管理动作还有三个：每次备份后校验文件大小和完整性（gzip -t 或恢复演练抽查）、备份日志留痕（成功失败都有记录）、备份目录的磁盘容量纳入监控——备份把备份盘写满导致新备份失败，是备份体系最隐蔽的故障。
实操模板：
bash
# mysqldump 全量（不锁表+记位点）
mysqldump -uroot -p'xxx' -A -R --triggers --single-transaction \
--master-data=2 --flush-logs | gzip > /data/backup/full_$(date +%F).sql.gz
# 恢复链路: 全备导入 → 按位点截取 binlog 重放
mysqlbinlog --start-position=记录位点 binlog.000006 | mysql -uroot -p3.9 慢查询定位链路（压缩节一） 【理解】
标准回答：慢查询优化链路四步，这是实施联调期配合开发排障的固定动作。第一步开慢日志：slow_query_log=ON、long_query_time=1 秒（按业务定）、log_queries_not_using_indexes=ON 把没走索引的查询也记下来，日志落在 slow.log。第二步聚合分析找 TOP SQL：mysqldumpslow 或 pt-query-digest 按"执行总耗时、执行次数"排序——次数多但单次快的也要关注，总量同样吃人。第三步 explain 看执行计划，四个重点字段：type 访问类型从好到坏 system、const、ref、range、index、all，出现 all 全表扫描就是重点优化对象，生产底线 range；key 实际使用的索引；rows 预估扫描行数；Extra 里 Using filesort（额外排序）和 Using temporary（临时表）都是坏信号，Using index 是覆盖索引的好信号。第四步优化三板斧：建或改索引（where、order by、join on 的列，联合索引按最左前缀设计）、改写 SQL（避免 select *、拆大查询、减少回表）、架构层（加缓存或读写分离）。预防机制是 SQL 上线前过 explain 加审核——联调阶段我把"没走索引的查询"当评审项拦在上线前，比上线后救火划算得多；云上环境则靠数据库审计服务先暴露异常 SQL，再用慢日志确认、explain 定位。
追问链：
- 迭问1：数据库 CPU 爆满第一反应？ → 答：
show full processlist看会话构成：大量同一条 SQL 在跑就是慢 SQL 拖的，逐条 kill 止血再优化；连接堆积查连接池。应急顺序永远是"先 kill 保服务、再优化根治"——顺序说清楚，面试官就知道你处理过生产。 - 迭问2：SQL 昨天快今天突然慢？ → 答：三种高频原因：统计信息过旧优化器选错索引（analyze table 刷新）；数据量跨过临界点计划成本结构变了；缓存层失效查询直打库。排查动作：跑 explain 和它快的时候的执行计划对比，type 和 key 变没变——计划变了查统计信息，没变查数据量和缓存，两条路一分开就清楚了。
3.10 索引与失效场景（压缩节二） 【理解】
标准回答：索引核心概念三条。第一结构：InnoDB 索引是 B+ 树——非叶子节点只存键做路由，叶子节点存数据且之间有双向指针，等值和范围查询都高效；树非常"矮胖"，千万级数据三四层 IO 就能定位，这是它胜过二叉树和哈希的根本原因（哈希等值 O(1) 但不支持范围和排序，二叉树千万数据高几十层每层一次磁盘 IO 不可接受——B+ 树是"为磁盘 IO 而生"的选型）。第二回表与覆盖索引：二级索引叶子只存"索引列值 + 主键值"，查完要拿主键回聚簇索引再查一次取整行——这就是回表，多一次树的 IO；查询的列全部包含在索引里就免回表，explain 的 Extra 显示 Using index，这是索引设计的优化目标。第三失效场景高频五个必须会报：对索引列做函数或运算、隐式类型转换（字符串列传数字）、like 左模糊、or 连接了无索引列、违反联合索引最左前缀——再加两个进阶：结果集占比太大优化器放弃索引、统计信息过旧选错计划。建索引规范：每表必须有显式主键（InnoDB 没有会生成不可控的隐藏 row_id）；where、order by、join on 的列建索引；联合索引区分度高的等值列放最左；长字符串用前缀索引；生产大表加索引避开高峰用 online DDL。这些规范的落地场景就是联调期的 SQL 评审——失效场景里我主答隐式转换、左模糊、最左前缀三个高频形态，各配一个改法，有场景有解法这题就立住了。
追问链：
- 迭问1：联合索引 (a,b,c) 哪些查询能用上？ → 答：按最左前缀连续匹配的原则判断：where a=1 完整用上第一列；a=1 and b=2 用上两列；b=1 用不上——缺了最左列 a，索引树是先按 a 排序再按 b 排的，跳过 a 无法定位；a=1 and c=2 只能用 a，c 在索引里够不着（中间断了不连续）。这条规则决定了联合索引的列顺序设计：最常用作等值过滤、区分度最高的列放最左——我在联调阶段给开发做 SQL 评审时就按这条建议重排过一个索引的列序。
- 迭问2：表加了索引还是慢？ → 答：查三个方向：条件列是否符合最左前缀；是否踩了失效写法（函数运算、隐式转换、左模糊）；基数问题——列区分度太低（如性别列）优化器算出走索引不如全表扫，索引建了也不选。再加统计信息过旧导致选错计划，analyze table 修复。加索引不是万能药，要确认它"被用上了"才算数——explain 的 key 字段说了算。
3.11 数据库交付验收通用清单 【必背】
标准回答：把前面几节收口成一张我实际用的"数据库交付验收通用清单"，MySQL 和 Vastbase 都适用，这就是我"验得过"的操作化表达，八项：一环境核对——版本、架构、节点规格与方案一致，server_id/参数与配置表一致；二服务与自启——服务 active 且 enable，重启机器后自动拉起（这条经常被漏，我验收必做重启验证）；三账号与权限——应用账号最小权限、管理账号分离、密码策略合规；四数据层验证——建库建表、插入查询走通、字符集正确；五高可用验证——主从/主备状态正确、复制无延迟，切换演练通过（客户在场或留录像）；六连接入口——命令行和图形工具双验证、应用侧连接串测试通过、防火墙端口白名单已放行；七参数核对——调优参数生效值截图、慢日志等基础参数确认开启；八交付物——部署手册数据库章节、验收记录、备份口径说明齐备。八项每项有证据（命令输出截图），装订进验收材料。我讲这张清单的思路是：验收不是"做完了"，是"每一项可证明"——银行项目平台一次通过验收，数据库这块靠的就是这套清单化动作。第 15 章 15.7 的验收阶段还有全平台层面的展开。
追问链：
- 迭问1：为什么"重启验证"必须做？ → 答：因为"服务现在是 active"和"重启后还能 active"是两回事——没 enable 的服务、写错的 fstab 挂载、没持久化的防火墙规则，全都是"活着但重启就现形"的隐患。客户环境断电重启一次，数据库没起来，就是实施事故。我的规矩：验收前所有节点做一次计划内重启验证，全绿才算过——这条在银行环境是我主动提出加进验收方案的，客户很认可。
- 迭问2：验收时客户数据库管理员问倒你怎么办？ → 答：如实分级："这个参数的机制我理解到 XX 层，更深的我会后和原厂确认后给您书面答复。"然后把问题记进验收纪要的"待确认项"，48 小时内书面闭环——实施岗不怕被问倒，怕的是不懂装懂损失信任。这套应对话术在第 15 章 15.7 验收节还有完整版。
3.12 云数据库交付要点（移动云 MySQL 主备） 【理解】
标准回答：云上数据库交付是"自建部署"的另一面——不装机，但规划、配置、验收的功课一样不少，这是项目二 P2-4 我真实负责的部分。我的交付要点五步：第一步规格规划——按业务并发和数据量选型：8 核 16G、300G SSD 的主备规格，依据是应用连接数预估加数据增长预测，选型理由要能写进方案（和自建做硬件规划是同一个思维，只是单位从"台机器"变成"个规格"）；第二步网络与安全——VPC 内网访问、安全组只放行应用网段到 3306、账号按应用分建最小权限；第三步高可用与备份配置——主备同步模式、自动备份策略（每日全备加 binlog 保留 7 天）在控制台确认，恢复到时间点能力做一次验证；第四步交付连接信息——连接串（主库读写、只读实例如有单独给）、账号密码按客户规范移交，配套写入运维文档；第五步验收——用 3.11 的通用清单裁剪云版本：连接验证、账号权限、备份可恢复性、主备切换（云侧托管但要在控制台确认同步状态和延迟指标）。云数据库交付的最大心得：云把安装运维托管了，但"怎么选、怎么配、怎么验"的责任还在实施工程师——规格选小了业务高峰顶不住，安全组开大了过不了客户安全评审，这些决策一个都省不掉。自建加云上两种经历叠加，我对数据库部署的理解才是完整的——这也是简历"ARM 国产化与 x86 云环境双实践"在数据库上的体现。
追问链：
- 迭问1：云数据库和自己搭，客户环境怎么建议？ → 答：按三点判断：客户有没有云平台准入（金融信创环境多是自建国产库，互联网环境云托管更普遍）；运维力量——没有专职 DBA 的团队，云托管的高可用、备份、监控开箱即用价值很大；合规要求——数据不出客户机房的硬约束下只能自建。我的口径是"两边都交付过，帮客户按约束选，不预设立场"——银行项目自建 Vastbase、移动云用云 MySQL，就是两种约束下的两个合理答案。
- 迭问2：云上主备的切换你验证过吗？ → 答：验证的是"云侧高可用的表现"而不是切换操作本身——控制台确认主备同步状态与复制延迟指标、在维护窗口申请过主备切换看到应用重连恢复。切换机制是云托管的黑盒，我的职责是把"入口怎么配"（应用连接串指向集群入口而非物理节点）和"切换后怎么验"（连接恢复、数据一致抽查）做扎实——云时代实施工程师的价值从"会操作"转向"会设计会验证"。
3.13 本章口径红线（面试前再读一遍）
- 角色口径：数据库选型是华为配套体系与银行信创要求定的，我负责按配套表落地实施与验收——先亮角色再讲能力，不越位。
- 数字口径：Vastbase 一主一备、max_connections 100→10000、线程池开启、双节点安装误差小于 10 秒、license 滚动重启（先 A 就绪再 B）——全部一手操作，大胆讲。
- 边界诚实：Vastbase 备份由客户集中备份平台纳管，我的边界是集群部署验收；MySQL 自建按"课程实验 + 云上运维"双口径讲，不冒充生产 DBA。
- 产品层深挖跳转：openGauss 家族、选型三段论、线程池参数逐个讲 → 华为篇第 4 章；本答实施层。
- 一句话人设：国产数据库我"装过、调过、验收过、写成过标准文档"——四个动词就是差异化。
3.14 本章案例
- 【真实项目】（银行）Vastbase G100 一主一备部署、调优与验收（STAR，约 300 字）：背景是数币平台需要国产数据库承载合约数据，信创要求 PG 系国产库且必须适配鲲鹏 ARM 与麒麟 V10。任务是我负责部署一主一备集群、完成调优并通过客户验收。行动：两节点配置 install.conf（安装目录以 /home/vastbase 为前缀避开权限坑），协同同时执行安装脚本（误差小于 10 秒保证握手），配置 has/dcs 开机自启；调优 max_connections 100 到 10000、开线程池并配 NUMA 参数，滚动重启生效；license 到期前完成正式替换并按先 A 后 B 滚动重启 has 避免双主；验收跑五项清单——组件健康、hasctl list 主备角色、vsql 加 DataStudio 双连接验证、停主库切换演练、参数核对，全部截图留档。结果：数据库环境一次通过验收，支撑试点业务运行，完整步骤与两个踩坑记录沉淀进《智能合约引擎安装部署指南》成为公司标准。
- 【课程项目】MySQL 主从加备份恢复演练：搭一主一从验证双 Yes 和延迟归零；mysqldump 全量加 flush-logs 切 binlog 增量；模拟误删表做恢复演练——测试库导全备、mysqlbinlog 截位点跳过 drop、回灌。价值是把 3.7/3.8 的命令链跑成肌肉记忆，面试口径"自建实验加云上运维结合"。
- 【经典故障】主从不同步（SQL 线程报错）：从库 SQL 线程停，Last_SQL_Error 指向"记录已存在"——追溯是从库被开发直连写入过。处理以主库为准修从库数据重启线程；根治设 read_only 加 super_read_only、只留只读账号、"从库绝不直写"写进规范。教学点：技术修复之外必须有制度修复，同样的故障第二次出现说明第一次没修完。
章末自测清单（快问快答）
- Vastbase 基于什么内核？ → openGauss（华为基于 PostgreSQL 演化），PG 系语法。
- 双节点安装脚本执行要求？ → 同时执行，误差不超过 10 秒。
- HAS 和 DCS 各是什么？ → HAS 高可用组件（监控切换），DCS 分布式配置存储（类似 etcd 的仲裁底座）。
- 两个调优参数及值？ → max_connections 100→10000、enable_thread_pool=on。
- 为什么 openGauss 敢调万级连接？ → 线程池模型连接与执行线程解耦；MySQL 每连接一线程不敢。
- license 更换的关键动作？ → 改 vastbase.yml 路径后滚动重启 has（先 A 就绪再 B，防双主）。
- Vastbase 验收五项？ → 组件健康、主备角色、双工具连接验证、切换演练、参数核对。
- pg_stat_activity 对应 MySQL 什么？ → show processlist；终结会话 pg_terminate_backend 对应 kill。
- Vastbase 安装目录为什么要 /home/vastbase 前缀？ → 自动化脚本用 vastbase 用户执行，其他目录无读写权限会失败。
- 主从复制三线程？ → 主库 dump、从库 IO（收 relay log）、从库 SQL（重放）。
- 主从验收三件套？ → 双 Yes 加 Seconds_Behind_Master 趋零。
- mysqldump 两个关键参数？ → --single-transaction 不锁表、--master-data=2 记位点。
- 23:00-23:30 备份，两种工具各恢复到几点？ → mysqldump 到 23:00（快照点）、XtraBackup 到 23:30（含期间 redo）。
- explain 里最差的 type 和底线？ → all（全表扫描）；生产底线 range。
- 索引失效报三个高频？ → 隐式类型转换、like 左模糊、违反最左前缀。
- 交付验收为什么必须做重启验证？ → 查"活着但重启现形"的隐患（未 enable、fstab、防火墙未持久化）。
- 云数据库交付五步？ → 规格规划→网络与安全→高可用与备份配置→连接信息交付→验收核对。
- 调研期数据库要前置确认的五件事？ → 选型版本、资源规格、网络端口、高可用要求、备份口径。
- 切换演练后数据一致性怎么确认？ → 切前记位点/行数、新主核对同批数据、应用读写验证——形式必须走，证据要留档。