服务端面试题手册

Vercel Serverless Functions 适合把轻量后端逻辑放在前端项目旁边，例如表单提交、Webhook、登录回调、BFF 聚合接口、简单数据库读写。它不用维护服务器，随部署一起发布，流量低时几乎没有空转成本，流量上来时平台自动扩缩容。追问Serverless 和 Edge Functions 有什么区别？Serverless 更接近普通 Node.js 后端，生态兼容更好；Edge 更靠近用户、延迟低，但运行时 API 更受限。冷启动会不会影响线上接口？低频接口可能遇到冷启动。可以通过减少依赖体积、拆分函数、选择区域和缓存结果降低影响。数据库连接为什么容易出问题？Serverless 会并发创建函数实例，如果每个实例都新建连接，数据库连接数很快被打满。常见做法是连接池代理或 serverless 友好数据库。哪些任务不该放进去？视频处理、批量爬取、长轮询、定时大批量同步和复杂报表生成不合适，应放到队列或 worker。

Vercel 定价的关键不是先看月费，而是看项目是否商业化、团队人数和资源用量。Hobby 适合个人项目、学习 Demo、开源展示站；Pro 适合客户项目、SaaS 官网、内容站和需要预览协作的团队；Enterprise 解决合规、SLA、组织权限、专属支持和复杂安全要求。追问Hobby 计划可以放商业项目吗？不建议。只要涉及客户交付、公司官网、付费产品或团队协作，就应该按 Pro 或 Enterprise 评估。Pro 最容易超的是哪几项？常见是带宽、构建分钟、函数执行时长和图片优化次数。营销活动页或媒体站尤其要关注带宽。什么时候需要 Enterprise？需要 SAML/SSO、审计、SLA、合规采购、专属支持或更细组织权限时，Enterprise 才有明显价值。如何控制成本？静态资源尽量走 CDN 缓存，接口避免每次都走 Serverless；检查构建缓存、图片尺寸、ISR revalidate 和无效预览部署。

Vercel 的错误排查可以按三类看：构建错误看 Build Logs，接口和 Serverless Function 问题看 Runtime Logs，线上体验和性能问题看 Analytics、Speed Insights 或第三方监控。高效做法不是等报错后翻日志，而是在部署、运行时、告警和错误追踪之间建立完整链路。追问Build Logs 和 Function Logs 有什么区别？Build Logs 记录部署生成过程，适合查依赖、构建命令、类型错误和环境变量缺失。Function Logs 记录线上函数执行，适合查接口报错、超时和数据库连接。为什么本地正常，Vercel 上失败？最常见是 Node.js 版本不同、环境变量没配、大小写路径在本地不敏感但线上敏感。也可能是 Vercel 运行环境访问不到内网数据库。日志里应该打印哪些信息？打印请求 ID、接口名、耗时、状态、关键业务 ID 和错误 message。不要打印完整请求体、密钥、cookie、手机号等敏感数据。函数超时怎么排查？先看外部 API 慢、数据库查询慢，还是代码做了重计算。Vercel Functions 不适合长任务，必要时拆到队列或 worker。写段代码try { return Response.json(await loadData()); }catch (err) { console.error('loadData failed', { message: err.message }); return Response.json({ error: 'Internal error' }, { status: 500 }); }

Vercel、Netlify 和 AWS Amplify 都能部署前端应用，但解决的问题不完全一样。Vercel 更适合 Next.js 和重视预览体验的团队；Netlify 更适合静态站点、多框架项目和表单类需求；AWS Amplify 更适合已经在 AWS 生态里、需要认证、存储、数据库一起管理的全栈项目。追问Vercel 一定比 Netlify 快吗？不一定。Next.js 项目在 Vercel 上通常更省心；普通静态站点放 Netlify 也可以很快。性能更多来自框架、缓存、图片处理和访问分布。为什么说 Vercel 有平台锁定风险？如果大量使用 Edge Middleware、ISR、图片优化和项目配置，迁移时要逐项找替代。锁定不是不能用，而是要知道哪些是平台能力。AWS Amplify 为什么成本难预测？它背后可能同时使用构建、存储、数据库、认证、流量、日志等多个 AWS 服务，流量变化后账单更难估算。小团队怎么选？Next.js 先选 Vercel；官网、博客、文档选 Netlify；除非团队熟悉 AWS 或后端明确要用 AWS，否则不建议一开始上 Amplify。迁移平台注意什么？先列出环境变量、函数、边缘逻辑、图片优化、表单、认证和 DNS 依赖，灰度验证后再切全量流量。

Vercel 做多环境部署，核心不是多建几个分支，而是把 Production、Preview、Development 的触发方式、环境变量和数据资源隔离清楚。main 对应生产，Pull Request 和功能分支对应 Preview，本地通过 vercel dev 对应 Development。这样团队能在合并前拿到真实预览地址，又不会让测试请求误连生产数据库。追问为什么不能只用一个 .env 文件？一个文件短期省事，长期容易把测试密钥、生产数据库和本地回调混在一起。支付、登录、推送这类功能尤其危险。NODE_ENV 和 VERCEL_ENV 有什么区别？NODE_ENV 更偏构建模式，Preview 也常是 production。VERCEL_ENV 才表示 production、preview 或 development，更适合环境路由。Preview 环境需要独立数据库吗？只看静态页面可以不要；涉及登录、写入、回调或迁移时建议隔离。最低成本是测试库加命名空间，更稳是每个 PR 临时 schema。多环境最常见的坑是什么？变量改完不重新部署、Preview 误用生产 API、回调地址只配生产域名。排查时先看 Deployment Environment。写段代码const apiBase = { production: process.env.API_URL, preview: process.env.PREVIEW_API_URL, development: 'http://localhost:3001' }[process.env.VERCEL_ENV || 'development'];

MCP 的错误处理和重试机制，关键不是“失败就再试一次”，而是先判断失败能不能重试。参数校验失败、权限不足、工具不存在这类错误重试没有意义；网络抖动、上游 5xx、限流、临时超时才适合重试。把错误分类、超时、退避、熔断和降级放在一起设计，MCP Server 才不会在上游变慢时把自己也拖垮。追问哪些 MCP 错误不应该重试？400 参数错误、401/403 权限错误、工具名不存在、schema 不匹配都不该重试。应该快速返回，并提示调用方修正输入或重新授权。限流错误应该怎么处理？如果上游返回 Retry-After，优先按它等待；没有这个头时再用指数退避。还要给每个用户或会话设置并发上限。熔断和重试是什么关系？重试解决偶发失败，熔断处理持续失败。上游连续超时或 5xx 达到阈值后，应短时间直接失败或走降级。错误日志怎么写才方便排查？每次工具调用都生成 requestId，并在 MCP 响应、应用日志、上游请求日志里贯穿它。敏感参数要脱敏。降级策略有哪些边界？降级只适合可接受旧数据或部分结果的场景。涉及写入、支付、权限变更或不可逆操作时不要自动降级。写段代码async function retry(fn, max = 3) { for (let i = 0; i < max; i++) { try { return await fn(); } catch (e) { if (!e.retryable || i === max - 1) throw e; await new Promise(r => setTimeout(r, Math.min(1000 * 2 ** i, 8000))); } }}

MCP 的持久化和缓存不能只理解成“把数据存起来”。先区分哪些数据必须长期保留，哪些只是为了减少重复计算：工具定义、资源索引、用户会话、授权状态通常需要持久化；工具调用结果、资源快照、schema 解析结果更适合缓存。分清这条线，才不会把缓存当数据库，也不会把数据库拖成临时变量仓库。追问MCP 哪些数据一定要持久化？工具清单、资源元数据、授权状态和会话恢复信息最好持久化，因为它们影响协议行为和用户体验。单次工具调用中间结果不一定落库，除非要审计或断点续跑。Redis 缓存和数据库版本怎么配合？关键记录带 version 或 updatedAt，缓存 key 或 value 里也保存这个版本。读取时发现版本不一致就丢弃缓存，这比单纯依赖 TTL 更可靠。持久化会带来哪些安全边界？不要把 access token、用户输入的敏感资源和工具返回原文无脑落库。确实要保存时，应加密、设置保留周期，并在日志里只记录 request id。缓存最常见的坑是什么？权限变化后缓存没失效，可能导致用户还能看到旧资源；失败结果缓存太久，也会让故障恢复后仍然返回错误。单机和多实例有什么取舍？单机可以用 SQLite 加内存缓存；多实例必须把会话和缓存外置到 Redis 或数据库，否则请求打到不同实例时会状态丢失。写段代码async function getToolSchema(name: string) { const key = `mcp:schema:${name}`; const cached = await redis.get(key); if (cached) return JSON.parse(cached); const schema = await store.loadToolSchema(name); await redis.set(key, JSON.stringify(schema), { EX: 300 }); return schema;}

Zookeeper 是主从协同架构，但角色边界很清楚：Leader 负责写请求排序、事务提案和提交协调；Follower 负责本地读、转发写请求、参与选举和投票；Observer 只同步数据和服务读请求，不参与选举，也不计入写入多数派。设计重点不是所有节点都可写，而是用少量投票节点保证一致性，再用 Observer 扩展读能力。追问写请求怎么流转？客户端连到 Follower 时，写请求会被转发给 Leader，由 Leader 生成事务提案并广播。超过半数 Follower ACK 后才提交。Observer 为什么能提升读性能？Observer 不参加投票，增加它不会提高多数派门槛，也不会拖慢 Leader 等待 ACK 的路径。它适合承接跨机房或大规模客户端读流量。为什么常用奇数个投票节点？3 个节点能容忍 1 个故障，5 个能容忍 2 个。4 个投票节点也只能容忍 1 个故障，却多了同步和运维成本。配置容易踩什么坑？每台机器的 myid 必须和 server.X 对应。Observer 需要在节点配置里声明 peerType=observer，并在集群配置中标成 observer。跨机房部署合适吗？投票节点不建议跨高延迟机房，网络抖动会放大成选举和会话超时。远端读流量可考虑 Observer。

Zookeeper 的 Leader 选举不是谁先启动谁当 Leader，而是看哪个节点最适合承接已提交历史。Fast Leader Election 会在 LOOKING 状态下交换投票，每张票通常包含 epoch、zxid 和 sid：先比较选举轮次，再看 zxid 谁更新，zxid 相同才比较 sid。某个候选者拿到超过半数投票后成为 Leader。追问Leader 选举什么时候触发？集群首次启动、Leader 宕机、网络分区导致多数 Follower 失联时，节点都会进入 LOOKING。短暂 GC、磁盘卡顿也可能让 Follower 误判超时。zxid 和 sid 谁更重要？zxid 更重要，因为它代表节点看到的事务进度。只有 zxid 一样时才比较 sid，sid 大只是为了打破平票。为什么必须超过半数才能当选？多数派机制保证任意两个成功多数集合一定有交集，新 Leader 能接触到上一任已提交事务信息。选举期间客户端会怎样？写请求通常会失败、阻塞或连接断开，需要客户端重试。业务侧要设置合理 sessionTimeout 和重试退避。排查选举问题看什么？先确认 myid 和 zoo.cfg 的 server.X 是否对应，再检查 2888/3888 端口。日志里的 LEADING、FOLLOWING、Cannot open channel 很关键。

Zookeeper 的一致性主要靠 ZAB 协议保证。所有写请求最终交给 Leader 排序，Leader 分配全局递增的 zxid，再把提案广播给 Follower；超过半数节点 ACK 后，事务才提交。代价是写入要等多数派，延迟不会像单机缓存那样低；好处是 Leader 宕机后，新 Leader 能根据 zxid 找到较完整的提交历史，避免已提交数据丢失或未提交数据乱入。追问ZAB 和普通主从复制最大区别是什么？普通主从复制常见问题是主节点确认太早，故障时从节点未必拥有同一批数据。ZAB 要求事务拿到多数派 ACK 再提交。zxid 为什么能决定数据新旧？zxid 是事务全局序号，高位通常关联 Leader epoch，低位表示任期内事务递增。选主和同步时比较 zxid 判断谁更新。读请求为什么不一定强一致？Follower 和 Observer 异步接收提交消息，可能比 Leader 慢。必须读最新时可以先执行 sync()，但有协调成本。Leader 崩溃时怎么避免事务丢失？新 Leader 会和其他节点对齐事务日志：落后的补发 DIFF，差太多的发 SNAP，未提交尾巴会 TRUNC 回滚。怎么判断一致性问题来自哪里？先确认节点角色和存活，再看日志里的 zxid、leader election、syncLimit 超时。很多读旧值只是连到了落后 Follower。

Zookeeper 性能优化先分清读多、写多还是连接多。读多可以加 Observer 或让客户端分散到 Follower；写多瓶颈通常在 Leader、事务日志 fsync 和过半确认；连接多、Watcher 多、znode 大，会把内存和网络打满。有效优化不是把参数调大，而是减少无意义写入、控制节点大小、把事务日志放到稳定低延迟磁盘。追问加节点一定能提升性能吗？不一定。Follower 或 Observer 能分担读请求，但写请求仍要 Leader 发起并等待过半确认，投票节点越多，写入链路可能越长。dataDir 和 dataLogDir 为什么分开？事务日志每次写入都很敏感，最好放低延迟 SSD 或独立盘；快照体积大但频率低，可以放普通数据盘。Watcher 多会带来什么问题？Watcher 会占服务端内存，事件触发时还会产生通知风暴。客户端重连后无脑重复注册，会导致 watch_count 持续上涨。单个 znode 为什么不建议放大数据？Zookeeper 是协调元数据系统，不是文件存储。大节点会放大网络传输、序列化、快照和事务日志成本。性能压测看哪些边界？至少分读密集、写密集、混合读写、重连风暴和 Watcher 触发场景。每次只改一个参数，记录 P95/P99、磁盘 await、GC pause。写段配置tickTime=2000initLimit=10syncLimit=5maxClientCnxns=100dataLogDir=/data/zookeeper/txnlogautopurge.purgeInterval=1

Zookeeper、Etcd 和 Consul 都能做分布式协调，但出发点不一样。Zookeeper 更像协调原语库，擅长临时节点、顺序节点、Watcher、分布式锁和老牌 Java/大数据生态；Etcd 是强一致 KV，Raft、revision、租约和 Watch 更贴近 Kubernetes 控制面；Consul 把服务发现、健康检查、多数据中心和 KV 打包在一起，适合微服务治理。追问Consul 是 AP 还是 CP？不能简单说 Consul 全部是 AP。服务发现依赖 Gossip，读到的信息可能短暂滞后；Server 集群和 KV 一致读依赖 Raft，更接近 CP。Zookeeper 和 Etcd 的 Watch 有什么差别？Zookeeper 的 Watch 是一次性通知，触发后需要重新注册。Etcd Watch 基于 revision，可以从指定版本继续消费事件，但要处理 compaction 后版本过旧的问题。为什么 Kubernetes 选 Etcd？Etcd 的 Raft KV、revision、租约和 gRPC API 更符合 Kubernetes 的对象存储与控制循环模型。Zookeeper 数据模型更偏传统中间件生态。老系统要不要迁到 Etcd？如果只是为了技术更新，通常不值得。临时节点、顺序节点、ACL、Watcher 语义都要重做，只有控制面重构时才值得评估。三者性能怎么比较才靠谱？按读写比例、值大小、Watcher 数量、磁盘 fsync 和网络延迟压测。不要只看单机 benchmark。

Zookeeper 出问题时不要先调参数，先判断是客户端、网络、磁盘还是集群选举问题。连接超时通常看 sessionTimeout、端口连通性和服务端负载；脑裂要看是否真的出现多个可写 Leader，多数情况下是网络分区或监控误判；数据不一致多半是读到了落后的 Follower，需要用 sync() 或改读 Leader。追问连接超时一定是服务端问题吗？不一定。先用 nc 验证 2181 端口，再看客户端 DNS、负载均衡、防火墙和连接池是否耗尽。服务端 latency_max 很高时，还要查磁盘 I/O、GC 暂停和 outstanding 请求堆积。Zookeeper 会不会真的脑裂？Zookeeper 依赖过半机制，正常配置下不会允许两个 Leader 同时提交事务。危险点通常是偶数节点、跨机房高延迟部署、错误 myid/server 配置或监控误判。数据不一致时 sync() 为什么有用？Follower 读可能落后于 Leader，sync(path) 会让当前连接先同步到较新的事务点。代价是多一次网络往返，强一致读路径不要滥用。Watcher 泄漏怎么判断？看 echo wchs | nc zk1 2181 和客户端注册逻辑。很多泄漏来自异常重试时重复注册，修复时要让 Watcher 与业务对象生命周期绑定。故障恢复最怕什么？最怕只恢复快照不恢复事务日志，或不同节点混用不同版本数据目录。恢复前先停集群、备份现状，再按 zxid 最新且完整的快照和日志恢复。写段命令echo ruok | nc zk1 2181echo stat | nc zk1 2181echo mntr | nc zk1 2181 | egrep 'latency|connections|outstanding|synced'

Zookeeper 运维的重点不是“进程活着就行”，而是确认多数派健康、写入延迟可控、客户端连接没有失控。日常先看四类指标：集群角色和节点存活、请求延迟、连接与 Watcher 数量、磁盘和 JVM 状态。stat 能看 leader/follower，mntr 适合接 Prometheus exporter，cons 能排查连接来源，wchs 可以判断 Watcher 是否异常膨胀。追问线上最应该优先盯哪个指标？优先看 zk_avg_latency、zk_max_latency 和 zk_outstanding_requests。节点存活重要，但很多事故在节点没挂前，延迟和排队已经先报警了。Watcher 数量突然升高说明什么？通常说明客户端重复注册、服务实例目录过大，或某个配置监听没有去重。短期定位来源连接，长期要改客户端代码。Zookeeper 磁盘满了会怎样？常见表现是写入失败、延迟飙升、Leader 不稳定，严重时节点无法启动。要开启 autopurge，并监控 dataDir 和 dataLogDir。滚动重启为什么不能一口气重启多台？Zookeeper 需要多数派可用，5 节点同时停 3 台就失去法定人数。稳妥做法是一台一台重启并确认状态。写段命令echo stat | nc zk1 2181echo mntr | nc zk1 2181 | egrep 'latency|outstanding|watch_count'echo cons | nc zk1 2181 | wc -l

Zookeeper 要稳，先别把它当数据库用，而要当成“小而关键的协调层”。生产集群通常选 3 或 5 个投票节点：3 节点能容忍 1 台故障，5 节点能容忍 2 台故障；节点数不是越多越好，写入要多数派确认，7 台以上会增加选举和同步成本。部署时尽量跨机架或可用区，但不要把网络延迟拉得太大。追问为什么生产集群常用 3 或 5 个节点？Zookeeper 依赖多数派，4 个节点仍然只能容忍 1 台故障，因为多数派需要 3 票。偶数节点增加机器和同步成本，却不提升容错收益。dataDir 和 dataLogDir 为什么建议分开？事务日志是写请求关键路径，磁盘抖动会直接放大写延迟。快照文件更偏后台持久化，和日志分盘更稳。Zookeeper 适合存业务大数据吗？不适合，它适合配置、状态、锁节点、服务实例这类小数据。大对象会增加网络复制、快照体积和恢复时间。Watcher 最容易踩什么坑？原生 Watcher 触发一次就失效，收到事件后要重新注册。回调里不要做重活，应投递异步任务。分布式锁一定要自己实现吗？不建议，Curator 的 InterProcessMutex 已处理大量边界。业务侧更应该关注超时时间、finally 释放锁和锁粒度。写段配置tickTime=2000initLimit=10syncLimit=5dataDir=/data/zookeeper/datadataLogDir=/data/zookeeper/logsautopurge.purgeInterval=1

VPN 变慢不要先怪节点，先把问题切开看：本地网络、VPN 协议、服务器距离、加密开销、MTU 分片和运营商干扰，任何一环都可能拖慢速度。最稳的排查顺序是先关掉 VPN 测下载、上传、延迟和丢包，再打开 VPN 测同一组数据。追问怎么判断是 VPN 慢，还是本地网络慢？关掉 VPN 测速，再打开 VPN 测同一地区、同一时间段的速度和延迟。裸连也慢，多半是 Wi-Fi、路由器或宽带问题。WireGuard 为什么通常比 OpenVPN 快？WireGuard 协议更轻，代码路径短，常用 ChaCha20，加密开销更低。OpenVPN TCP 容易出现重传叠加，网络一抖就卡。MTU 为什么会影响速度？VPN 会额外加包头，原本能通过的包可能变大后被分片。常见做法是把 MTU 从 1500 降到 1420 或 1400，但不要盲目降太多。Split Tunneling 什么时候有用？只有部分应用需要 VPN 时，分流能降低延迟和带宽压力。边界是安全策略要清楚，敏感请求不要被错误拆到不同路径。写段命令speedtest-cli --simpleping -c 50 your-vpn-server.comiperf3 -c your-vpn-server.com -t 30

MariaDB 和 MySQL 同源，但现在已经不能简单当成同一个数据库的两个名字。MariaDB 最初由 MySQL 原始作者创建，目标是保持开源和兼容，同时加入更多存储引擎、优化器能力和集群方案；MySQL 由 Oracle 维护，生态稳定，云厂商支持广，MySQL 8.0 在窗口函数、CTE、JSON、权限模型等方面也补齐了很多能力。追问MariaDB 能直接替换 MySQL 吗？低版本和常规 SQL 场景通常迁移成本不高，客户端协议、基础语法和常用工具大多兼容。真正要小心的是高版本差异、系统表、复制、JSON 行为和认证插件。两者功能主要差在哪里？MariaDB 提供 Aria、ColumnStore、Spider、MyRocks 等更多引擎选择，也有自己的 Galera 集群路线。MySQL 8.0 的数据字典、JSON、窗口函数、CTE 和权限体系更统一。性能上 MariaDB 一定更快吗？不一定。读写性能受版本、引擎、索引、SQL、参数和硬件影响很大，同一条 SQL 在两个优化器里的执行计划可能不同。生产环境怎么选？如果团队重度使用 MySQL 8.0、依赖云厂商托管能力，继续用 MySQL 更稳。如果看重开源路线、特定引擎或 MariaDB 生态，MariaDB 合适。写段 SQLSELECT VERSION();SHOW VARIABLES LIKE 'version_comment';EXPLAIN SELECT * FROM orders WHERE user_id = 1001;

MariaDB 的存储引擎不是越多越好，而是要按事务、读写比例、数据规模和运维成本来选。默认优先 InnoDB，因为它支持事务、行级锁、崩溃恢复和外键，适合绝大多数 OLTP 系统。Aria 更像 MyISAM 的加强版，适合临时表、读多写少或不需要完整事务的场景；ColumnStore 面向分析查询；Spider 用来做分片和跨节点访问；MyRocks 适合写入密集、压缩率敏感的业务。追问为什么多数业务表建议用 InnoDB？InnoDB 的优势不只是事务，还包括崩溃恢复、MVCC、行级锁和成熟生态。订单、账户、库存这类需要一致性的表，不应为了读性能换成非事务引擎。Aria 和 MyISAM 有什么区别？MyISAM 读性能不错，但表级锁明显，不支持事务，崩溃恢复弱。Aria 是 MariaDB 对这类场景的改进选择，但仍不能替代 InnoDB 做核心交易表。ColumnStore 适合放业务明细表吗？不太适合。ColumnStore 优势是列式压缩和批量分析，适合报表和历史数据查询；频繁按主键更新、单行查询很多时会难受。更换存储引擎有什么坑？ALTER TABLE 切引擎可能锁表、耗时长，还可能遇到索引长度、外键或数据类型兼容问题。大表建议在线变更或分批迁移。写段 SQLSHOW ENGINES;CREATE TABLE event_log (id BIGINT PRIMARY KEY, created_at DATETIME, payload TEXT) ENGINE=InnoDB;

MariaDB 主从复制的核心是：主库写 binlog，从库通过 IO 线程拉取日志，再由 SQL 线程重放。最基础的是异步复制，性能好、延迟低，但主库宕机时可能丢最后几笔事务；半同步复制会等至少一个从库确认收到日志，可靠性更好，但写入延迟会上升；GTID 复制用全局事务 ID 标记事务，主从切换和故障恢复更稳。追问最小可用的主从复制怎么配置？主库要开启 serverid、logbin 和 ROW 格式 binlog，从库设置不同 server_id，并通过 CHANGE MASTER TO 指向主库。脚本要注意版本差异，新版本会逐步转向 replica 相关命令。异步、半同步和 GTID 有什么区别？异步最快但可能丢数据；半同步至少确认日志到一个从库，适合更重视数据安全的业务；GTID 是事务定位方式，让补复制、换主库更清楚。复制延迟一般从哪里排查？先看 SecondsBehindMaster、RelayLogFile、ExecMasterLog_Pos，再结合慢 SQL、从库 IO、磁盘写入和大事务判断。主从切换最容易出什么问题？从库还没追平就提升为主库，会导致新主缺数据；应用仍写旧主，会形成双写。切换前要确认 relay log 执行完和应用连接串更新完成。写段 SQLCHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;START SLAVE;SHOW SLAVE STATUS\G

MariaDB 备份不要只理解成把数据导出一份，真正要设计的是恢复能力。小库、低频变更、临时迁移，用 mysqldump 足够；线上核心库、数据量较大或恢复时间敏感，优先用 Mariabackup 做物理备份，再配合 binlog 做时间点恢复。备份策略一般按 RPO 和 RTO 倒推：能接受丢 5 分钟数据，就至少保留连续 binlog；要求 30 分钟内恢复，就不能只靠几十 GB 的 SQL 文件慢慢导入。追问mysqldump 和 Mariabackup 怎么选？mysqldump 是逻辑备份，优点是可读、可跨版本、适合单库单表恢复，缺点是大库导出和导入都慢。Mariabackup 是物理备份，恢复速度更接近文件拷贝，适合生产全量备份。如何恢复到指定时间点？常见做法是每天一次全量备份，持续保留 binlog，并记录全量备份完成时的 binlog 文件和 position。恢复时先还原全量，再用 mysqlbinlog 回放到指定时间点。备份脚本最容易踩什么坑？第一是只备份不校验，事故时才发现压缩包损坏。第二是把密码写在脚本里且权限过宽，建议用专门备份账号和最小权限。恢复前后要检查什么？恢复前确认目标目录为空、磁盘空间足够、服务已停止。恢复后要做表检查、核心 SQL 抽样和业务只读验证。写段命令mariabackup --backup --target-dir=/backup/full --user=backup --password=xxxmariabackup --prepare --target-dir=/backup/fullmysqlbinlog --stop-datetime="2026-05-30 10:18:00" mysql-bin.000123 | mysql -u root -p