数据库迁移实战指南基于 agents24 插件市场的零停机迁移与跨数据库模式库【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南以 agents24Multi-harness agentic plugin marketplace中framework-migration插件的database-migration技能及其参考资料 details.md 为主体系统讲解两类高阶数据库迁移模式零停机Zero-Downtime迁移的 Blue-Green 部署策略以及跨数据库PostgreSQL ↔ MySQL迁移的方言适配方案。读完本文你将掌握如何用多阶段渐进式 SQL 变更实现无感知上线如何在迁移脚本中按数据库方言动态生成类型正确的 DDL以及如何与 ORM 迁移、Schema 变换、数据变换、回滚策略等配套模式组合使用。一、模式库定位database-migration 技能的知识结构在 agents24 仓库中database-migration是一个技能Skill文件位于 plugins/framework-migration/skills/database-migration/SKILL.md。其frontmatter声明了用途在 ORMSequelize、TypeORM、Prisma之间执行数据库迁移支持 Schema 变换、数据迁移、跨数据库搬移内置回滚流程与零停机部署策略覆盖数据库版本升级与数据模型重构技能正文描述了七类典型使用场景ORM 间迁移、Schema 变换、数据库间数据搬移、回滚流程实现、零停机部署、数据库版本升级、数据模型重构。而本文所依托的 details.md 正是该技能引用的补充模式与模板库——SKILL.md 末尾明确写着More detailed templates and worked examples live inreferences/details.md.也就是说SKILL.md 提供的是基础骨架各 ORM 的迁移文件写法、Schema 变换四步法、事务回滚、检查点回滚而 details.md 提供的是进阶模式零停机迁移与跨数据库迁移。二者叠加才构成完整的实战能力。二、零停机迁移Blue-Green 部署策略details.md 核心模式一数据库 Schema 变更最危险的地方在于一次ALTER TABLE可能让正在运行的老版本代码直接崩溃。details.md 给出的核心思路是永远不要一步到位而是通过 5 个阶段让新旧并存→逐步切换→彻底清理。Phase 1向后兼容地新增列先只做加法不做减法。新增一列email_new此时新旧两版代码都还能正常工作——老代码继续读写email新代码可以开始准备读写email_new// Phase 1: Make changes backward compatible module.exports { up: async (queryInterface, Sequelize) { // Add new column (both old and new code can work) await queryInterface.addColumn(users, email_new, { type: Sequelize.STRING, }); }, };工程要点这一步绝对不能删除或重命名任何现有列、不能收紧allowNull约束。凡是会破坏旧代码的 DDL 都要推迟到新代码完全接管流量之后。Phase 2部署双写代码此阶段只改应用代码不再执行 DDL。新代码同时写入email与email_new两个字段保证新增列持续有数据。由于没有数据库变更这一步的发布风险与一次普通发版相当。Phase 3回填Backfill存量数据用一条幂等的批量 UPDATE 把历史数据补齐。details.md 特别用WHERE email_new IS NULL保证脚本可重复执行// Phase 3: Backfill data module.exports { up: async (queryInterface) { await queryInterface.sequelize.query( UPDATE users SET email_new email WHERE email_new IS NULL ); }, };实践提示对于超大表回填往往需要分批如按主键范围、每批 10005000 行而不是单条巨型 UPDATE避免长事务锁表。这与 code-migrate.md 中 SQL→NoSQL 迁移脚本使用batch_size 1000分批读取的思路一致。Phase 4切换读取路径再发一次纯代码变更所有读操作改为读取email_new同时保留对email的写入双写。此时即使线上仍有少量老实例它们读旧列也不受影响形成双保险窗口期。Phase 5清理旧列确认email_new数据完整、读取稳定后最后才执行删除旧列的 DDL// Phase 5: Remove old column module.exports { up: async (queryInterface) { await queryInterface.removeColumn(users, email); }, };这五个阶段完整覆盖了兼容→双写→回填→切换→清理是零停机列迁移的通用模板也适用于列改名参见 SKILL.md 中full_name三步法与列类型变更参见 SKILL.md 中age_new四步法。事实上 SKILL.md 里的列改名零停机三步法和改列类型四步法正是本模式的简化变体先建新列 → 复制/变换数据 → 切代码 → 删旧列。三、跨数据库迁移PostgreSQL → MySQL 方言适配details.md 核心模式二当需要把数据从一种数据库搬到另一种时最大的坑是类型系统差异。details.md 提供了一个标准解法在迁移脚本内通过queryInterface.sequelize.getDialect()获取当前方言按方言分别建表。同一逻辑、不同方言的建表// Handle differences module.exports { up: async (queryInterface, Sequelize) { const dialectName queryInterface.sequelize.getDialect(); if (dialectName mysql) { await queryInterface.createTable(users, { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true, }, data: { type: Sequelize.JSON, // MySQL JSON type }, }); } else if (dialectName postgres) { await queryInterface.createTable(users, { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true, }, data: { type: Sequelize.JSONB, // PostgreSQL JSONB type }, }); } }, };模式拆解关注点MySQL 分支PostgreSQL 分支说明主键自增Sequelize.INTEGERautoIncrement同左两种方言都原生支持脚本可完全一致JSON 类型Sequelize.JSONSequelize.JSONBMySQL 的 JSON 与 PostgreSQL 的 JSONB 语义、索引能力不同必须分别声明方言探测getDialect()返回mysqlgetDialect()返回postgres迁移工具会基于同一份脚本在目标库上执行补充要点JSONB在 PostgreSQL 中是二进制存储、支持 GIN 索引与更丰富的查询操作符MySQL 的JSON是二进制序列化存储但表达式索引支持有限。若迁移目标是从 PostgreSQL 到 MySQL且原表大量使用jsonb_path_ops等特性还需在应用层同步调整查询写法——这一层适配工作与 details.md 展示的类型适配互为表里。与其他跨库模式的关系details.md 的方言分支只是建表层的适配。更完整的跨库搬移还需要数据搬移与验证这在同插件的 code-migrate.md 第 6 节Database MigrationSQL to NoSQL中有更全面的展示先analyze_schema()分析表结构与关系再设计目标结构embedded / references最后按batch_size分批读取、类型转换、批量写入并附_migrated_at元数据与verify_migration()校验。也就是说details.md 解决目标表怎么建code-migrate.md 解决数据怎么搬、怎么验证。四、配套基础模式ORM 迁移与 Schema 变换SKILL.md 支撑details.md 的两个进阶模式建立在一组基础模式之上它们都定义在 SKILL.md 中用于承接零停机与跨库场景的日常部分。三大 ORM 的迁移文件范式Sequelize每个迁移导出up/down两个异步函数用queryInterface操作 Schema。命令为npx sequelize-cli db:migrate回滚为npx sequelize-cli db:migrate:undo。TypeORM实现MigrationInterface接口用QueryRunner与Table描述列isPrimary、isGenerated、generationStrategy: increment。执行npm run typeorm migration:run回滚npm run typeorm migration:revert。Prisma直接在schema.prisma声明模型如id Int id default(autoincrement())用npx prisma migrate dev --name create_users生成迁移、npx prisma migrate deploy应用到生产。三类 Schema 变换模板加列带默认值addColumn(users, status, { defaultValue: active, allowNull: false })保证存量行立即有合法值。零停机列改名加新列 →UPDATE users SET full_name name复制数据 → 切代码 → 删旧列。改列类型四步法addColumn建age_new→CAST(age AS INTEGER)变换 →removeColumn删旧 →renameColumn改名down中再用changeColumn还原。这三类变换与 details.md 的 Blue-Green 五阶段本质上是同一套哲学先加后删、分步切换建议组合阅读。五、回滚策略事务与检查点SKILL.md 支撑零停机迁移必须配备回滚手段SKILL.md 提供了两种模板事务型迁移用queryInterface.sequelize.transaction()包裹 DDL 与数据更新任一步失败即transaction.rollback()并抛出异常保证迁移原子性。检查点型回滚先CREATE TABLE users_backup AS SELECT * FROM users建快照迁移后执行校验如SELECT COUNT(*) FROM users WHERE new_field IS NULL必须为 0校验失败则从备份表整体还原再抛错。在更高层面legacy-modernize.md 把回滚上升到系统级定义触发条件P0 功能不可用、响应时间上升 50%、数据完整性问题、错误率上升 5%并按 Blue-Green / Canary / Feature Flag 分别给出回滚步骤——例如 Blue-Green 回滚就是把负载均衡切回 100% 到蓝色环境。这与 details.md 的 Phase 2/4纯代码切换思路天然契合正因为每次切换都是可逆的代码变更回滚也只是反向切换一次。六、在 agents24 插件体系中的落地方式本文模式库服务于framework-migration插件该插件在 agents24 中由以下部分组成可按需组合Agentlegacy-modernizer.md负责存量系统渐进现代化重点覆盖存储过程 → ORM的数据层改造输出含迁移计划、兼容层、各阶段回滚流程architect-review.md对 Schema 与数据架构做审查。Commandcode-migrate.md 提供了从迁移评估→计划→执行→测试→回滚→监控的完整编排其中第 6 节专门给出 SQL→NoSQL 迁移器与批量数据搬移脚本legacy-modernize.md 则以 13 步、5 阶段、4 个用户审批检查点的流程管理整个现代化过程。Skilldatabase-migration 及其 details.md 正是数据层迁移的模式库SKILL.md 负责基础模板details.md 负责零停机与跨库等高阶模板。典型应用链路是由legacy-modernizerAgent 评估存量 Schema 与数据耦合 → 按 SKILL.md 的 ORM 模板生成基础迁移 → 对高风险变更套用 details.md 的 Blue-Green 五阶段 → 跨库搬移时套用方言分支建表 code-migrate.md 的分批搬移脚本 → 全程以事务或检查点回滚兜底。七、总结三张可复用的决策清单任何列级变更先问自己能不能拆成 5 步兼容加列 → 双写代码 → 回填 → 切读 → 删旧列。答案是否说明存在一步到位的风险。跨库迁移先问类型差异在哪用getDialect()分支处理 JSON/JSONB、时间精度、自增语法等差异再谈数据搬移与校验。每一次切换都要可逆DDL 用事务或检查点备份兜底纯代码切换保留反向切换路径两者结合才构成完整的零停机闭环。以上内容全部可在仓库中验证details.md 给出了两个核心模式的可运行代码SKILL.md 提供基础模板与命令code-migrate.md 与 legacy-modernize.md 提供编排与回滚的完整工作流。读者可直接将这些模板复制到自己的 Sequelize/TypeORM/Prisma 项目中按注释中的命令执行迁移与回滚。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 数据库迁移实战指南：基于 agents24 插件市场的零停机迁移与跨数据库模式库
数据库迁移实战指南基于 agents24 插件市场的零停机迁移与跨数据库模式库【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南以 agents24Multi-harness agentic plugin marketplace中framework-migration插件的database-migration技能及其参考资料 details.md 为主体系统讲解两类高阶数据库迁移模式零停机Zero-Downtime迁移的 Blue-Green 部署策略以及跨数据库PostgreSQL ↔ MySQL迁移的方言适配方案。读完本文你将掌握如何用多阶段渐进式 SQL 变更实现无感知上线如何在迁移脚本中按数据库方言动态生成类型正确的 DDL以及如何与 ORM 迁移、Schema 变换、数据变换、回滚策略等配套模式组合使用。一、模式库定位database-migration 技能的知识结构在 agents24 仓库中database-migration是一个技能Skill文件位于 plugins/framework-migration/skills/database-migration/SKILL.md。其frontmatter声明了用途在 ORMSequelize、TypeORM、Prisma之间执行数据库迁移支持 Schema 变换、数据迁移、跨数据库搬移内置回滚流程与零停机部署策略覆盖数据库版本升级与数据模型重构技能正文描述了七类典型使用场景ORM 间迁移、Schema 变换、数据库间数据搬移、回滚流程实现、零停机部署、数据库版本升级、数据模型重构。而本文所依托的 details.md 正是该技能引用的补充模式与模板库——SKILL.md 末尾明确写着More detailed templates and worked examples live inreferences/details.md.也就是说SKILL.md 提供的是基础骨架各 ORM 的迁移文件写法、Schema 变换四步法、事务回滚、检查点回滚而 details.md 提供的是进阶模式零停机迁移与跨数据库迁移。二者叠加才构成完整的实战能力。二、零停机迁移Blue-Green 部署策略details.md 核心模式一数据库 Schema 变更最危险的地方在于一次ALTER TABLE可能让正在运行的老版本代码直接崩溃。details.md 给出的核心思路是永远不要一步到位而是通过 5 个阶段让新旧并存→逐步切换→彻底清理。Phase 1向后兼容地新增列先只做加法不做减法。新增一列email_new此时新旧两版代码都还能正常工作——老代码继续读写email新代码可以开始准备读写email_new// Phase 1: Make changes backward compatible module.exports { up: async (queryInterface, Sequelize) { // Add new column (both old and new code can work) await queryInterface.addColumn(users, email_new, { type: Sequelize.STRING, }); }, };工程要点这一步绝对不能删除或重命名任何现有列、不能收紧allowNull约束。凡是会破坏旧代码的 DDL 都要推迟到新代码完全接管流量之后。Phase 2部署双写代码此阶段只改应用代码不再执行 DDL。新代码同时写入email与email_new两个字段保证新增列持续有数据。由于没有数据库变更这一步的发布风险与一次普通发版相当。Phase 3回填Backfill存量数据用一条幂等的批量 UPDATE 把历史数据补齐。details.md 特别用WHERE email_new IS NULL保证脚本可重复执行// Phase 3: Backfill data module.exports { up: async (queryInterface) { await queryInterface.sequelize.query( UPDATE users SET email_new email WHERE email_new IS NULL ); }, };实践提示对于超大表回填往往需要分批如按主键范围、每批 10005000 行而不是单条巨型 UPDATE避免长事务锁表。这与 code-migrate.md 中 SQL→NoSQL 迁移脚本使用batch_size 1000分批读取的思路一致。Phase 4切换读取路径再发一次纯代码变更所有读操作改为读取email_new同时保留对email的写入双写。此时即使线上仍有少量老实例它们读旧列也不受影响形成双保险窗口期。Phase 5清理旧列确认email_new数据完整、读取稳定后最后才执行删除旧列的 DDL// Phase 5: Remove old column module.exports { up: async (queryInterface) { await queryInterface.removeColumn(users, email); }, };这五个阶段完整覆盖了兼容→双写→回填→切换→清理是零停机列迁移的通用模板也适用于列改名参见 SKILL.md 中full_name三步法与列类型变更参见 SKILL.md 中age_new四步法。事实上 SKILL.md 里的列改名零停机三步法和改列类型四步法正是本模式的简化变体先建新列 → 复制/变换数据 → 切代码 → 删旧列。三、跨数据库迁移PostgreSQL → MySQL 方言适配details.md 核心模式二当需要把数据从一种数据库搬到另一种时最大的坑是类型系统差异。details.md 提供了一个标准解法在迁移脚本内通过queryInterface.sequelize.getDialect()获取当前方言按方言分别建表。同一逻辑、不同方言的建表// Handle differences module.exports { up: async (queryInterface, Sequelize) { const dialectName queryInterface.sequelize.getDialect(); if (dialectName mysql) { await queryInterface.createTable(users, { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true, }, data: { type: Sequelize.JSON, // MySQL JSON type }, }); } else if (dialectName postgres) { await queryInterface.createTable(users, { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true, }, data: { type: Sequelize.JSONB, // PostgreSQL JSONB type }, }); } }, };模式拆解关注点MySQL 分支PostgreSQL 分支说明主键自增Sequelize.INTEGERautoIncrement同左两种方言都原生支持脚本可完全一致JSON 类型Sequelize.JSONSequelize.JSONBMySQL 的 JSON 与 PostgreSQL 的 JSONB 语义、索引能力不同必须分别声明方言探测getDialect()返回mysqlgetDialect()返回postgres迁移工具会基于同一份脚本在目标库上执行补充要点JSONB在 PostgreSQL 中是二进制存储、支持 GIN 索引与更丰富的查询操作符MySQL 的JSON是二进制序列化存储但表达式索引支持有限。若迁移目标是从 PostgreSQL 到 MySQL且原表大量使用jsonb_path_ops等特性还需在应用层同步调整查询写法——这一层适配工作与 details.md 展示的类型适配互为表里。与其他跨库模式的关系details.md 的方言分支只是建表层的适配。更完整的跨库搬移还需要数据搬移与验证这在同插件的 code-migrate.md 第 6 节Database MigrationSQL to NoSQL中有更全面的展示先analyze_schema()分析表结构与关系再设计目标结构embedded / references最后按batch_size分批读取、类型转换、批量写入并附_migrated_at元数据与verify_migration()校验。也就是说details.md 解决目标表怎么建code-migrate.md 解决数据怎么搬、怎么验证。四、配套基础模式ORM 迁移与 Schema 变换SKILL.md 支撑details.md 的两个进阶模式建立在一组基础模式之上它们都定义在 SKILL.md 中用于承接零停机与跨库场景的日常部分。三大 ORM 的迁移文件范式Sequelize每个迁移导出up/down两个异步函数用queryInterface操作 Schema。命令为npx sequelize-cli db:migrate回滚为npx sequelize-cli db:migrate:undo。TypeORM实现MigrationInterface接口用QueryRunner与Table描述列isPrimary、isGenerated、generationStrategy: increment。执行npm run typeorm migration:run回滚npm run typeorm migration:revert。Prisma直接在schema.prisma声明模型如id Int id default(autoincrement())用npx prisma migrate dev --name create_users生成迁移、npx prisma migrate deploy应用到生产。三类 Schema 变换模板加列带默认值addColumn(users, status, { defaultValue: active, allowNull: false })保证存量行立即有合法值。零停机列改名加新列 →UPDATE users SET full_name name复制数据 → 切代码 → 删旧列。改列类型四步法addColumn建age_new→CAST(age AS INTEGER)变换 →removeColumn删旧 →renameColumn改名down中再用changeColumn还原。这三类变换与 details.md 的 Blue-Green 五阶段本质上是同一套哲学先加后删、分步切换建议组合阅读。五、回滚策略事务与检查点SKILL.md 支撑零停机迁移必须配备回滚手段SKILL.md 提供了两种模板事务型迁移用queryInterface.sequelize.transaction()包裹 DDL 与数据更新任一步失败即transaction.rollback()并抛出异常保证迁移原子性。检查点型回滚先CREATE TABLE users_backup AS SELECT * FROM users建快照迁移后执行校验如SELECT COUNT(*) FROM users WHERE new_field IS NULL必须为 0校验失败则从备份表整体还原再抛错。在更高层面legacy-modernize.md 把回滚上升到系统级定义触发条件P0 功能不可用、响应时间上升 50%、数据完整性问题、错误率上升 5%并按 Blue-Green / Canary / Feature Flag 分别给出回滚步骤——例如 Blue-Green 回滚就是把负载均衡切回 100% 到蓝色环境。这与 details.md 的 Phase 2/4纯代码切换思路天然契合正因为每次切换都是可逆的代码变更回滚也只是反向切换一次。六、在 agents24 插件体系中的落地方式本文模式库服务于framework-migration插件该插件在 agents24 中由以下部分组成可按需组合Agentlegacy-modernizer.md负责存量系统渐进现代化重点覆盖存储过程 → ORM的数据层改造输出含迁移计划、兼容层、各阶段回滚流程architect-review.md对 Schema 与数据架构做审查。Commandcode-migrate.md 提供了从迁移评估→计划→执行→测试→回滚→监控的完整编排其中第 6 节专门给出 SQL→NoSQL 迁移器与批量数据搬移脚本legacy-modernize.md 则以 13 步、5 阶段、4 个用户审批检查点的流程管理整个现代化过程。Skilldatabase-migration 及其 details.md 正是数据层迁移的模式库SKILL.md 负责基础模板details.md 负责零停机与跨库等高阶模板。典型应用链路是由legacy-modernizerAgent 评估存量 Schema 与数据耦合 → 按 SKILL.md 的 ORM 模板生成基础迁移 → 对高风险变更套用 details.md 的 Blue-Green 五阶段 → 跨库搬移时套用方言分支建表 code-migrate.md 的分批搬移脚本 → 全程以事务或检查点回滚兜底。七、总结三张可复用的决策清单任何列级变更先问自己能不能拆成 5 步兼容加列 → 双写代码 → 回填 → 切读 → 删旧列。答案是否说明存在一步到位的风险。跨库迁移先问类型差异在哪用getDialect()分支处理 JSON/JSONB、时间精度、自增语法等差异再谈数据搬移与校验。每一次切换都要可逆DDL 用事务或检查点备份兜底纯代码切换保留反向切换路径两者结合才构成完整的零停机闭环。以上内容全部可在仓库中验证details.md 给出了两个核心模式的可运行代码SKILL.md 提供基础模板与命令code-migrate.md 与 legacy-modernize.md 提供编排与回滚的完整工作流。读者可直接将这些模板复制到自己的 Sequelize/TypeORM/Prisma 项目中按注释中的命令执行迁移与回滚。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考