先把一句可能得罪人的话放在最前面：给 Bytebase 这类数据库变更平台挑服务器，绝大多数人的第一反应就是错的。采购单打开，按照"企业级应用"的默认印象挑一台十六核三十二 G 的机器，理由是平台要跑 SQL 审核、要连一堆数据库实例、要存好多年的变更历史，听着就该配好一点。但真正把资源曲线拉出来看会发现，控制台进程本身常年是空闲的，元数据库跑的是一堆小而碎的查询，真正把 CPU、磁盘、IOPS 打满的时刻，是某一天晚上十点，某个研发点下"执行"按钮的那一瞬间——而那一瞬间被打到的，根本不是跑平台的这台机器，是被改的那个目标库所在的那一台。买错了地方，钱就白花了。
所以这一篇我们不按"软件安装教程"的写法走，而是按"资源账"的写法走：平台侧到底吃多少、目标库侧到底吃多少、在线改表工具的四笔代价分别记在谁头上、变更窗口怎么排才不会和备份跑批撞车。下面这几条是全文的结论，后面每一节都会展开讲推导过程，你可以先扫一眼，看看哪一条和你们现在的做法不一样。
第一，平台侧是典型的"小规格长周期"负载：控制台加一个元数据库，CPU 常年空闲，压力集中在元数据库的小查询与审核瞬间的 SQL 解析，按企业级应用买大机基本是浪费。
第二，真正的资源账在"变更执行那一瞬间被打到的那一端"：影子表、binlog 暴涨、触发器带来的主库写放大、切换瞬间的元数据锁，这四笔全部发生在目标库那台机器上，与平台机器的规格几乎无关。
第三，在线改表的磁盘账要按"再来一份全表数据"来算，不是按"跑一个小工具"来算；偏偏很多人只看工具进程的内存占用，忘了它要在磁盘上复制出一张同样大的表。
第四，变更窗口是一条排期题而不是一个时间点：备份窗口、报表跑批、大促、主从延迟敏感期，这四条时间线任意两条撞上，都会把一个本来可控的变更变成事故。
第五，回滚脚本不是把 SQL 反着写一遍，它必须提前演练过，而且必须假设"变更之后业务已经往新结构里写了数据"这个最难的情况。
很多团队在评估要不要上数据库变更平台时，脑子里的问题是"我们现在 DBA 拿着 SQL 直接上生产库执行，出过事吗？好像也没出过事，那为什么要多一套系统"。这个问题本身就问偏了。直接上库执行这个动作在单次维度上确实可以很顺利，一个熟练的 DBA 敲完语句、看一眼 rows affected、提交，全程三十秒。真正的问题从来不在单次执行，而在于：三个月之后没人记得那天改了什么、为什么改、谁批准的；表结构在不同环境之间漂移，测试库和生产库的某个字段类型已经不一样了，没人知道是从哪次变更开始不一样的；新人写了一条没有 where 的更新语句，因为没有第二个人看过，直接跑在了生产上。
Bytebase 这一类的数据库变更协作平台，解决的正是"单次执行"之外的那一段：脚本先入库，成为一份可版本化的文本；提交时先过一遍规则驱动的静态审核，把明显不该出现的写法在合并之前拦下来；然后按环境串成的流水线，从开发到测试再到生产，同一份脚本被不同的数据量和不同的负载验证三次；执行过程和结果被记进元数据库，形成一条可审计的变更流水。它是一次开源的数据库 DevOps 实践，服务端用 Go 编写，前端用 Vue 编写，自托管时以服务形式常驻，并且需要一个元数据库来存放实例、项目、变更单、审核结果这些元数据；生产部署通常建议使用外部数据库，至于具体支持哪些数据库作为元数据库、连接串该怎么配，一律以官方部署文档和你所部署版本的说明为准，不要照抄任何博客里的旧配置。
把这段边界划清楚很重要，因为它直接决定了后面的资源配置思路：平台管的是"变更单的生命周期"，不是"SQL 的执行引擎"。执行这件事，最终还是落到目标数据库实例上去做的，平台负责的是把执行这一步变得可控、可追溯、可回滚。既然执行发生在别处，那么"给平台配服务器"这个问题的答案，天然就应该是"配两笔账"——一笔给平台自己，一笔给执行现场。
Bytebase 的概念模型不复杂，但它决定了你后面所有权限、流水线和资源边界怎么划。这套模型可以拆成七件套：Instance（实例）、Database（库）、Project（项目）、Environment（环境）、Issue（变更单）、SQL Review（SQL 审核）、Rollout（变更执行）。下面按"被管对象—组织方式—变更生命周期"三层来拆，理解了这三层，你在填第一个实例的时候就不会把测试库和生产库挂到同一个环境里。
Instance 指的是一个被 Bytebase 纳管的数据库实例地址，Database 是这个实例上具体的库。这一层最容易产生的误解，是以为"把实例加进平台"意味着数据要搬到平台上去——完全不是，Bytebase 只保存连接信息、元数据和对这个库的操作记录，业务数据一行都不离开你自己的数据库服务器。这个误解在资源规划上很致命，因为有人会据此认为"平台机器要装下所有库的数据"，然后去买一台带几十 T 存储的机器，而实际上平台机器只需要装下元数据库那一小份数据。实例可以来自不同的机房、不同的云、不同的版本，平台对它们一视同仁，这也意味着一次变更的资源消耗完全取决于你这次改的是哪个实例，而不是平台有多强。
Project 是人和库的归属单位，Environment 是这条流水线上的层级，比如开发、测试、生产。这两个概念经常被当成"权限分组"来用，那就太浪费了。它们真正的价值在于：同一份 schema 变更脚本，可以在开发环境用几乎没数据的小库先跑一遍验证语法和依赖，在测试环境用接近真实结构的中等数据量跑一遍验证执行耗时与锁行为，最后才进生产。也就是说，流水线的作用不是"审批更规范"，而是"同一份脚本先被验证三次"，这三次验证分别暴露不同类型的错误——语法错误在第一环就死了，耗时问题在第二环暴露，只有真正和数据量、和线上负载相关的风险才会留到生产环节，而那时你已经对它心里有数了。
Issue 是变更单，一次变更的最小单位；SQL Review 是提交阶段做的规则驱动静态审核，直接对 SQL 文本做检查，比如有没有写注释、有没有用不该用的写法；Rollout 是真正把语句发到目标实例上执行的那一步。这三者分开的意义在于，审核和执行可以有不同的触发时机与不同的失败后果：审核失败只是变更单合不进去，代价是研发多改一次；执行失败则会真的在目标库上留下痕迹，代价是可能要回滚。社区版内置多少条审核规则、具体规则名叫什么，不同版本之间差异很大，本文一律写"以你部署版本的规则集为准"，不会列出具体条数或规则编号，你在自己的控制台里能看到的规则列表才是唯一可信的来源。另外 Bytebase 会把每次变更与结果记进元数据，形成可审计的变更流水，这条流水本身就是"审计"这件事的答案。
把平台自己的账单独算一遍。控制台进程是一个 Go 写的常驻服务，日常干的事情是响应页面请求、轮询变更单状态、调度审核与执行任务；元数据库存的是实例信息、项目配置、变更单、审核结果、迁移历史这类结构化的小记录。这两者合起来的负载曲线非常典型：CPU 常年趴在低位，内存占用平稳且可预测，磁盘增长缓慢且与业务数据量无关——你的业务表从五千万行涨到五亿行，元数据库的体积几乎不变，因为它存的是"变更了什么"，不是"表里有什么"。
那么压力峰值出现在哪？两处。第一处是元数据库上的小查询，尤其是变更历史 pages、变更单列表、实例列表这类带筛选和分页的查询，在团队规模变大、变更单积累到一定量之后会变慢，这是元数据库需要被认真对待的主要原因，而不是因为它"装不下"。第二处是 SQL 审核的瞬间——变更单提交时，平台要对提交的 SQL 文本做解析并按规则集逐条检查，这是一次短时的 CPU 尖峰，持续时间是秒级，不会形成长时间占用。理解这两处峰值的形状很关键：它们都是"短时、可预测、可容忍排队"的，不像在线请求那样有尾延迟要求，所以给平台侧配资源的原则是"够用且有余量"，而不是"越大越好"。
接下来是那个高频问题：元数据库该给它独立盘还是共享盘。我们的倾向是独立盘，理由是元数据库虽然小，但它的写入是随机小 IO，而且它的响应延迟会直接传导到控制台的每一次点击和每一个变更单的状态流转上；如果和其他 IO 密集型的邻居共享一块盘，邻居一次批量写入造成的 IO 抖动，会让你以为"平台卡了"，实际上是盘在抖。当然这不是绝对结论：如果团队规模很小、并发变更单很少、变更历史也不长，共享盘完全可以跑，前提是这个盘有明确的 IOPS 兜底而不是完全无保障的超售型存储。判断标准只有一个——看变更单列表页在业务高峰期的打开速度，那才是你自己的答案。
还有一条容易被忽略的：平台机器要和它管理的目标数据库实例之间保持稳定的网络连通与足够的带宽余量。审核和执行指令、执行结果的回传都要走这条链路，链路不稳的表现不是"平台挂了"，而是"变更单卡在执行中不知道到底执行了没有"，这种半吊子状态比失败更难处理。所以在租用的时候，平台机器放在哪个机房、到各地数据库实例的网络质量如何，是选型时必须问清楚的一项，具体带宽与线路以官网实时信息或咨询确认为准。
Bytebase 可以对接 gh-ost、pt-online-schema-change 这一类在线改表工具来避免长时间锁表，具体到哪个版本支持哪个工具，以官方文档为准，这里不做断言。我们重点讲这一类工具的共同工作原理，以及由此推导出的四笔代价——这才是配置服务器时真正要算的账。原理本身并不神秘：新建一张影子表，按新结构建好；把老表已有的数据分批拷到影子表；拷贝期间业务对老表的写入，通过触发器或者解析 binlog 的方式同步到影子表；拷贝追平之后，在一个很短的时间窗口内把两张表的名字互换，完成切换。整个过程不长时间锁表，代价则分散在下面四处。
影子表是实打实的一张完整表，包含数据和索引。也就是说，改一张占用 S 空间的表，改表期间磁盘上要同时存在老表和影子表，峰值占用接近两份。很多人算磁盘的时候只算了"工具进程占多少内存"，然后发现磁盘使用率在改表进行到一半时突然告警——因为影子表是按批次一点点长大的，告警往往出现在改表开始之后很久，那时再想中断，前面拷贝的活就白干了。这里还有个细节：影子表在建索引的过程中还会产生额外的临时空间需求，所以我更倾向于把影子表这一笔记成 S 乘以一个大于 1 的系数，而不是简单记成 S。
在线改表期间，业务照常写入，这些写入会正常进 binlog；而同步机制无论是触发器还是解析 binlog，都会让同一份数据变更在日志层面留下额外痕迹。结果是改表期间的 binlog 增长速度明显高于平时，如果改表持续时间长，累积量会相当可观。这一笔的估算方式是"变更预计时长 × 主库写入速率 × 放大系数"，三个变量里，变更时长由你的限速参数和表大小共同决定，写入速率是业务固有属性，放大系数则取决于同步机制——因此它必须是一个你自己实测出来的数，而不是抄来的数。真正危险的不是 binlog 占空间，而是它占的是和数据盘同一块盘，把数据盘写满会直接让实例不可用。
如果采用的是触发器模式，那么业务对老表的一次写入，会额外触发一次对影子表的写入，等于主库上的写操作被放大。这一笔的特点是它不占空间，但吃 IOPS 和 CPU，而且是实时的、无法延后处理的。在写入本来就高的业务时段开改表，主库的写延迟会整体抬升，表现出来就是业务侧"莫名变慢"，而慢的原因要到改表任务里去找。这也是为什么改表窗口要避开业务写入高峰——不是怕改表失败，是怕改表成功的代价是业务慢了一个小时。
最后的表名互换需要拿元数据锁，虽然窗口很短，但它是一把真锁：如果切换那一刻正好有长事务或大查询占着这张表，切换就会等待，而等待期间后续的查询会被堵住，形成一次短时的连接堆积。这一笔的规避办法不是加机器，而是排窗——选一个长事务少、慢查询少的时段，并且在切换前检查有没有持有锁的长事务。另外要提醒一句：MySQL 从 8.0 开始部分 DDL 支持 instant、inplace 这类优化路径，但一条语句到底能走哪条路径，取决于数据库版本、存储引擎和具体操作类型，文中只能写"以目标实例实测为准"，任何"某个操作一定不锁表"的断言都不成立，请先在与生产同版本的实例上实测，再决定要不要走在线改表。
上面四笔是定性描述，真正下单时要能算出数。这里给一套可以照着套的推导，注意其中每一个系数都是假设符号，需要你用自己的压测数据替换，本文不给出任何具体数值结论。设目标表现有数据与索引占用为 S，变更期间业务对这张表的写入速率为 W，预计变更持续时长为 T。第一步，影子表占用 ≈ S × α，α 是大于 1 的系数，多出来的部分是影子表建索引过程中产生的临时空间与页级碎片，α 取多少要在同版本实例上实测一次才知道。第二步，binlog 增量 ≈ W × T × β，β 是同步机制带来的日志放大系数，采用触发器模式和解析 binlog 模式的 β 并不相同，同样只能实测。第三步，峰值写放大：触发器模式下业务的一次写入会在主库上额外产生一次对影子表的写入，因此改表期间主库需要的写 IOPS ≈ 平时峰值写 IOPS × γ，γ 同样由实测得出，它决定的是"业务会不会变慢"而不是"改表会不会失败"。第四步，把前两步相加再加上安全余量，得到这次变更需要的空闲磁盘；把第三步的结果与分批拷贝本身消耗的 IO 相加，得到这次变更需要的 IOPS 余量。第五步，回过头校验 T：T 由表大小和你的限速参数共同决定，限速调低会拉长 T，T 变长又会让 binlog 增量变大，这两个变量是互相拉扯的，所以最终取值一定是在"改表快一点但主库更累"和"主库轻松一点但 binlog 攒更多"之间做一次取舍，而不是套一个固定参数了事。
把上面四笔代价和日常会遇到的其他变更动作放在一起，就得到下面这张对照表。这张表的用法不是"照着配"，而是"在提交变更单之前，先找到你要做的动作属于哪一行，然后去确认那一行的最后一列你有没有预留"。六个行覆盖的是数据库变更流水线里最常见的六类动作，包括最后那行"回滚"——它经常被漏掉，但它恰恰是最需要在资源上提前留余量的一类。
| 变更动作 | 主要消耗的资源 | 在哪里发生 | 什么情况下会出事 | 租服务器时要预留什么 |
|---|---|---|---|---|
| 普通 DDL（元数据变更，如改默认值、改注释） | 几乎不耗磁盘与 CPU，吃的是短暂的元数据锁 | 目标实例本地，与平台机器无关 | 撞上长事务或大查询时，等待元数据锁会堵住后续连接 | 目标库所在机器预留连接数余量与慢查询排查能力，无需为平台加配 |
| 在线改表（影子表 + 增量同步） | 磁盘（再来一份全表）、binlog 空间、主库写 IOPS | 目标实例所在机器，影子表与老表同盘 | 磁盘余量不足、binlog 撑满数据盘、写入高峰触发主库写放大 | 按"峰值表大小 × 2 + binlog 增量"预留空闲磁盘，并单独确认 IOPS 上限 |
| 大表加索引 | 排序所需的临时空间、大量顺序与随机 IO、CPU | 目标实例本地，临时目录所在盘压力最大 | 临时空间落在小盘上、索引体积超过预留、与跑批抢 IO | 数据盘与临时目录都要有余量，磁盘类型优先看 IOPS 而不是只看容量 |
| 批量数据订正（DML） | binlog 暴增、主从复制延迟、锁范围随批次大小变化 | 主库写、从库追，延迟在从库侧体现 | 单批过大造成长事务、从库延迟拉大影响读业务、订正逻辑写错无法撤销 | 预留 binlog 空间与从库追齐的余量，并要求订正脚本分批可中断 |
| 跨库 / 跨实例变更 | 网络链路、平台到各实例的并发连接、多实例之间的时序 | 平台机器与各实例之间的链路上 | 部分实例成功部分失败，留下难清理的中间状态 | 平台机器到各实例的网络质量与带宽余量要提前确认，变更单要能分实例重试 |
| 回滚 | 与第二、三行同量级的资源，且发生在最慌乱的时刻 | 目标实例本地，常与业务在线流量同时进行 | 回滚脚本未演练、数据是变更之后新写入的、回滚时磁盘已无余量 | 回滚必须预留在原变更之外的独立磁盘与 IO 余量，不能与原变更共用同一份空间预算 |
排变更窗口这件事，很多人是这么做的：找一个业务低峰的时间点，写进变更单，执行。问题是"业务低峰"这四个字掩盖了四条互相独立的时间线，它们各自的低峰并不重合。第一条是备份窗口，全量备份或快照期间磁盘 IO 被大量占用，此时叠加在线改表的分批拷贝，两股 IO 撞在一起，改表时长会被拉长，而改表时长一拉长，binlog 累积就更多，形成正反馈。第二条是报表跑批，跑批的特点是大范围扫描和长时间占用连接，它和改表抢的是同一批 IO 与同一批连接。
第三条是大促与运营活动，这一条不用多解释，但要注意它的影响范围比峰值时段更长：活动前的预热、活动后的对账，都会让数据库处于非典型状态。第四条最容易被漏掉——主从延迟敏感期。很多业务在读从库，从库延迟一旦拉大，读到的就是旧数据，用户看到的是"刚下的单查不到"，这种问题的排查成本极高，因为从应用侧看一切正常。在线改表和批量订正都会带来从库延迟，所以它们的窗口必须避开那些对读一致性最敏感的业务时段，而不只是避开写入高峰。
给出一套可套用的排窗方法，而不是具体时刻：第一步，把上述四条时间线各自画出来，标出各自的"绝对不可碰"区间；第二步，取这四条的交集之外，作为候选窗口；第三步，在候选窗口里再剔除长事务与慢查询高发的时段，这一步要靠你自己的监控数据，不要靠印象；第四步，给候选窗口设一个硬性上限——改表预计时长超过窗口剩余时长就必须拆批或改期，不允许"跑不完就让它继续跑到早上"。第四步是这套方法里最容易被跳过、也最救命的一条，因为绝大多数改表事故不是"改错了"，而是"改得太久，把后面的备份和早高峰一起拖下水了"。
还有一条工程约束必须写进流程：变更单必须配回滚脚本，且这份回滚脚本必须是演练过的。演练的意思是它至少在与生产同结构的环境里完整跑通过一次，而不是"我看着 SQL 觉得没问题"。这一条会在后面单独展开，这里先把它作为窗口排期的准入条件提出来——没有演练过的回滚脚本，等于没有回滚方案，那么这次变更就不具备进入候选窗口的资格。
SQL Review 是规则驱动的静态审核，在变更单提交时按规则集检查 SQL 文本，例如是否缺注释、是否使用了不该用的写法。社区版内置多少条规则、具体规则名是什么，不同版本差异很大，这里一律写"以你部署版本的规则集为准"，不做条数与编号的罗列。落地这件事的难度不在技术，而在节奏：规则开得太松，审核形同虚设；开得太严，团队会绕过平台。
绕过的路径比想象中多。研发发现变更单每次都被卡，而卡住的理由又是"缺注释"这类他认为不影响正确性的规则，他的选择不会是去补注释，而是申请一个可以直接上库的例外账号，或者把语句拆成几条绕过检查的版本，或者干脆让 DBA 私下执行。一旦这样的口子开了，平台就退化成一个只记录部分变更的残缺账本——这比没有平台更糟，因为它给了管理者一种"变更都被管起来了"的错觉，而实际上最危险的那部分变更恰恰在账本外面。
所以我们的建议是分三段推进，而不是一步到位。第一段，规则全部设为提示级，只产出报告不阻断，目的是让团队看到自己的 SQL 到底踩了多少条规则，同时收集误报——这个阶段通常会发现某些规则在你们的业务写法下误报率很高，那就先关掉它们。第二段，把"确认无争议且误报率低"的那一批规则升级为阻断级，典型的是那些一旦放过就会造成数据不可恢复后果的写法；其余规则继续保持提示。第三段，才考虑把覆盖面扩大到风格类规则，此时团队已经习惯了审核的存在，阻力会小很多。整个过程中有一条不能妥协：凡是会造成不可逆数据损失的规则，从第一天起就该是阻断级，这类规则没有"渐进适应"的余地。
另外，审核规则集本身也应该被版本化管理。它和 schema 脚本的性质是一样的——是一份会演进的团队约定，某天有人提议加一条规则，就应该像改代码一样走评审，而不是管理员在控制台上顺手勾一下。把规则集当成配置随手改，团队很快就会失去对审核结果的信任，因为他们不知道昨天能过的语句为什么今天过不了。
Bytebase 支持 GitOps 模式：把 schema 变更脚本放在 Git 仓库里，平台监听仓库变化并自动生成或推进变更单。这个模式看起来只是"换个地方放脚本"，实际上它改变了责任边界，而且是往好的方向改变。在传统的提交模式里，研发需要主动打开控制台、填变更单、贴 SQL，这一步是纯人工的，忙起来就会忘，忘了的结果就是"先上库，后补单"，变更流水就此失真。而在 GitOps 模式里，研发的工作流没有变——他本来就要把代码推到仓库，现在只是把 schema 脚本也一起推上去，变更单的创建由平台自动完成，人的主动性不再是流水真实性的前提。
但边界变化带来新的责任划分，需要提前讲清楚。第一，评审的位置前移了：原来是变更单在平台里被评审，现在 SQL 的评审发生在 Git 的合并请求里，因此谁有合并权限、合并前需要几个人通过，这套代码评审规则必须覆盖到 schema 目录，否则会出现"代码有人审、建表语句没人审"的缺口。第二，目录结构与命名约定变成硬约束：平台要靠文件路径判断这条脚本属于哪个库、按什么顺序执行，约定一旦混乱，自动生成的变更单就会指错库。第三，自动推进意味着执行时机的决定权部分交给了推送动作——这就要求分支策略与环境的对应关系（哪个分支对应哪个环境）被明确写下来，并且和前面讲的变更窗口机制结合起来，不能出现"推到主分支就在生产上立刻执行、撞上备份窗口也照跑"的情况。
换句话说，GitOps 解决的是"变更从哪来、是否完整"的问题，它没有解决"什么时候执行、资源够不够"的问题。后者依然要靠环境流水线、变更窗口和回滚方案来兜底。把这两件事分开看，你就不会误以为上了 GitOps 就万事大吉。
最常见的回滚误解，是把变更语句反着写一遍：加了列就 drop column，改了类型就改回去。在结构层面这当然是对的，但真实的回滚场景远比这复杂，因为从变更执行完成到你决定回滚之间，业务一直在往新结构里写数据。如果你把列 drop 掉，那段时间内写入的数据就真的没了——这时候回滚造成的破坏可能比不回滚更大。所以回滚方案的设计起点，不是"怎么把结构变回去"，而是"结构变回去之后，这段时间内产生的数据怎么办"，这个问题的答案通常有三种：一并保留（把新增列保留为可空）、一并清理（明确知道这些数据可丢弃）、或者需要先做数据搬迁再改结构。
第二种误解是把回滚当成一条即时生效的语句。事实上回滚很可能同样是一次在线改表，同样需要影子表、同样吃磁盘、同样会在切换时拿元数据锁，而且它发生在所有人都很紧张、业务流量还没摘掉的时刻。这也是前面那张表把"回滚"单列成一行的原因：它的资源需求和一次正向改表是同量级的，你必须为它预留独立于原变更之外的空间，不能把两份预算算成一份——很多团队在改表时把磁盘吃到百分之八十，等到要回滚时发现空间不够，只能先做一轮危险的清理。
第三，回滚脚本必须可演练，演练环境要与生产结构一致、数据量至少能暴露出耗时问题。演练要回答三个具体问题：回滚需要多长时间（决定你能不能在当前窗口内做完）、中途能不能中断重来（决定它有没有二次风险）、回滚完成后数据与结构是否一致（决定它是不是真的结束了）。这三问里有任何一问答不出来，这次变更就不该进入执行阶段。把它作为一条硬性的准入条件写进流程，比事后复盘时说"下次一定先演练"有用得多。
结合前面的资源账，我们把租用建议收敛到两个落点，这两个落点对应的是两笔不同的账，不要混在一起谈。第一个落点给平台侧：控制台与元数据库是一套小规格长周期负载，选型上优先关注稳定性和盘的 IO 保障，而不是核心数与内存容量；建议给它一块独立的数据盘，避免与其他 IO 密集型业务共享时产生抖动，具体机型的 CPU、内存、磁盘组合按需选择即可，不必一上来就上大规格。第二个落点给目标库与在线改表现场：这才是真正要花钱的地方，选型时优先看磁盘容量余量、磁盘的 IOPS 能力、以及 binlog 与数据是否可以考虑分层放置，容量上的判断标准建议直接用前面那套估算框架算出来的峰值，再加一层安全余量，而不是按"当前使用率"反推。
另外提醒一项容易在下单时被忽略的确认项：平台机器到你各数据库实例之间的网络质量与带宽余量。跨实例变更和执行结果回传都依赖这条链路，链路不稳不会让平台报错，只会让变更单停在一个"不知道执行了没有"的中间状态，这种状态的处置成本比一次失败高得多。所以如果你管理的实例分布在多个机房或多个地区，平台机器的放置位置需要在下单前就想清楚，而不是等变更单卡住了再去调。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
在正式把变更流水线切到生产之前，建议按下面这份清单逐项验一遍，验不过的项不要靠"应该没问题"放行。第一项，元数据库的独立性与备份：确认元数据库用的是外部数据库、有独立的数据盘、并且被纳入备份范围——元数据库一旦丢失，你失去的不是数据，而是全部变更历史与审计记录。第二项，磁盘峰值演算：挑一张你们最大的表，按估算框架算出影子表加 binlog 增量加安全余量的峰值，然后在目标机器上真的造一个同样大小的文件验证能否容纳，别只看监控图上的剩余百分比。第三项，IOPS 实测：在目标盘上跑一次与改表类似的顺序加随机混合写入，看延迟是否可接受，很多存储标称容量够但 IOPS 在持续写入下会掉。
第四项，在线改表工具与目标实例的兼容性实测：在与生产同版本的实例上跑一次完整的改表，确认工具能正常工作、切换顺利、触发器模式下的写放大在你的业务写入速率下可接受。第五项，回滚演练：按前面那三问完整跑一遍回滚，记录耗时。第六项，变更窗口的四条时间线已经画出来并写进流程文档，且窗口剩余时长大于预计改表时长这一条有明确的把关人。第七项，审核规则集已经过第一段提示期的收集与裁剪，误报率高的规则已经关掉，不可逆风险的规则已经设为阻断。第八项，平台到各实例的网络连通与延迟在工作时段复测过一次，而不是只在部署当天测过一次。
数据库变更场景的负载形状很特别：平时几乎不用资源，变更的那一两个小时把磁盘、IOPS、网络同时打到峰值，而且是计划内的、可预测的峰值。这种形状对租用方案的要求不是"整体性能强"，而是"峰值来的时候顶得住、峰谷的时候不浪费"，因此下单前要确认的东西和常规业务不太一样。第一，确认磁盘的容量余量能不能按峰值表大小的两倍再加安全余量来配，以及后续能不能在线扩容——改表做到一半发现盘不够，是最难收场的一种意外。第二，确认磁盘的 IOPS 在持续写入下的表现，不要只看峰值 IOPS 指标，持续写入时的稳定值才是改表期间真正拿到的东西。
第三，确认备份窗口与快照策略不会和你的变更窗口抢 IO，最好能把两者错开并写进同一份排期表。第四，确认平台机器到各数据库实例所在机房的网络质量与带宽余量，如果有跨地区管理的实例，这一点需要单独确认。第五，确认是否需要考虑主从或多副本的部署形态，因为在线改表和批量订正都会带来复制延迟，从库的规格与网络同样要纳入预算，不能只算主库。第六，确认扩容与变更的响应方式——当你的大表继续增长、下一次改表的峰值超过这次的预算时，加盘或换机型的流程要多久，这件事提前问清楚，比事后临时找人有用。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。上述清单中的机型、磁盘类型、带宽与机房选择，都需要在下单前与业务方逐项对齐，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
