Docker与Kafka环境下MySQL脚本部署及K8s编排方案咨询

核心实现思路 #

你提出的「启动阶段执行SQL、完成后再开始消费Kafka消息」的逻辑本身是成立的，不需要额外做消息暂存——Kafka自身的消息留存机制天然会把未消费的消息持久化在Broker端，只要消费端不提交分区订阅、不主动拉取消息，消息不会丢失也不会被跳过，落地的时候注意几个关键点即可：

• 不要自己手写SQL脚本执行逻辑，直接用成熟的数据库版本迁移工具托管所有.sql脚本，比如Flyway、Liquibase。这类工具自带版本校验、幂等执行、执行日志留痕、全局迁移锁的能力，能避免重复执行脚本、多节点同时执行冲突、执行出错无回滚记录这类低级问题。所有脚本必须遵循向后兼容原则：加字段必须带默认值、禁止直接在生产环境大表上跑锁表DDL、禁止直接删除在用的字段/索引。
• 消费端加两层启动护栏：第一层是初始化开关，数据库迁移未完成时，Kafka消费者的auto.startup配置强制设为false，不触发消费者组注册、不做分区分配，从根源上避免拉到消息后无法处理的问题；第二层是业务侧校验，哪怕开关漏放，业务逻辑入口也要先校验当前数据库schema版本是否匹配，不匹配直接触发消费重试，不要直接执行SQL抛非预期错误。
• SQL执行完成后不要瞬间拉满消费并发：先以10%的消费并发预热2-3分钟，确认数据库读写正常、消息处理逻辑无报错之后，再逐步把并发拉到满配，避免积压的海量消息瞬间打满数据库连接池，把刚完成变更的库打挂。
• Kafka侧的消息留存时间至少配置为72小时，覆盖「SQL脚本最长执行时长+应用滚动发布时长+故障回滚缓冲时长」，避免极端场景下留存到期丢消息。

Kubernetes编排场景的常见阻碍与对应解法 #

你预判的K8s编排阻碍确实是这套方案落地最容易踩坑的地方，核心问题都出在K8s的Pod生命周期管理、多副本调度、探针机制和单实例启动逻辑的冲突上，具体问题和对应解法如下：

• 问题1：多副本同时启动，重复执行SQL脚本引发锁库
  K8s Deployment默认滚动更新时会并行拉起多个新副本，如果把SQL执行逻辑嵌在每个业务容器的启动流程里，会出现多个实例同时连库执行DDL的情况，轻则脚本报错启动失败，重则长时间锁库影响全链路业务。
  解法：优先把SQL迁移逻辑从业务容器里拆出来，两种实现选一个即可：
  1. 配置为Pod的Init Container：Init Container会在业务容器启动之前执行，执行成功退出后业务容器才会被拉起，配合迁移工具自带的数据库全局锁，哪怕多副本同时拉起，也只会有一个实例抢到锁执行脚本，其余实例会等待锁释放后校验版本直接正常退出，不会重复执行。
  2. 配置为独立的前置Job：在应用Deployment更新前先运行迁移Job，Job执行成功返回状态码0之后，再触发应用的滚动更新，完全把数据库变更流程和业务容器生命周期解耦。
• 问题2：探针配置不当，反复杀掉正在执行SQL的实例引发启动死循环
  如果把SQL执行逻辑放在业务容器内，默认K8s的存活探针会在容器启动后按配置周期开始检测，如果SQL执行时长超过探针的初始延迟时间，K8s会判定容器不健康直接杀掉重启，陷入「启动→执行脚本→探针检测失败被杀→重启」的死循环。
  解法：如果坚持把SQL执行放在业务容器内，必须给容器配置独立的startupProbe（启动探针），把启动探针的超时时间设置为比SQL脚本最长预估执行时间长30%，启动探针检测成功之前，存活探针、就绪探针都不会生效，不会出现误杀的情况。如果用前面提到的Init Container/前置Job方案，这个问题天然不存在——因为SQL执行完之前业务容器根本不会启动。
• 问题3：滚动更新期间新旧版本消费者并存，引发schema不兼容报错
  K8s滚动更新过程中会存在一段时间新旧版本Pod同时运行的状态，如果本次发布的SQL包含不兼容变更（比如删字段、改字段类型），还没被下线的旧版本Pod写库时会直接抛schema错误。
  解法：所有数据库变更必须拆成多阶段发布，禁止单次发布做不兼容变更：第一阶段先执行兼容类变更（加字段、加索引、调整字段长度），发布新版本应用，等所有旧版本Pod完全下线、全量流量切到新版本稳定运行至少24小时之后，第二阶段再执行清理类的不兼容变更（删除废弃字段、删除冗余索引）。
• 问题4：提前触发消费者组重平衡，拉长故障恢复时间
  如果消费者在数据库迁移完成前就注册到消费者组，会触发分区重平衡，重平衡完成后拉到消息却无法正常处理，会反复触发消费失败、再重平衡的风暴，拉长消费恢复的时间。
  解法：就是前面提到的关闭消费者自动启动配置，等数据库迁移完成、所有业务依赖初始化完毕之后，再手动调用消费者的start方法触发注册和分区分配，从根源上避免无效重平衡。

实操补充建议 #

• 生产环境大表的DDL变更不要直接用原生MySQL DDL语句，封装成pt-online-schema-change或者gh-ost的执行任务放到迁移脚本里，避免长时间锁表阻塞业务读写。
• 给消费端配置启动阶段限流：刚启动的前5分钟把消费速率控制在日常峰值的30%，观察数据库CPU、连接数、慢查询指标正常后再逐步放开限流，避免流量突增打垮数据库。
• 所有SQL脚本在上线前必须在预发环境执行至少一次，记录脚本执行时长，给K8s探针、超时配置留足冗余。

内容的提问来源于stack exchange，提问作者sergiopf