如何通过 Bytebase MCP Server 跨多个数据库批量执行 sheet、plan 与 rollout 变更流程【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase当你需要把同一条 DDL/DML比如给多个环境的库执行CREATE TABLE或ALTER TABLE按 Bytebase 的评审流程下发时MCP Server 提供了一个手动批处理流程先创建 sheetSQL 载体再创建一个包含多个spec的 plan然后创建 issue 与 rollout。Bytebase 的propose_database_change工具只支持单库目标官方 skill 文档明确写了For batch changes across multiple databases才使用这条手动路径所以下面的步骤是批量场景的默认操作方式。整条流程通过 MCP 工具get_skill、search_api、call_api完成主流程为get_skill(database-change) → search_api(operationId) → call_api(...)。skill 原文在 database-changeskill 的加载与占位符约定见 AGENTS.md。准备确认模式、权限与目标库开始前需要满足以下条件MCP 访问模式允许写入。/mcp端点受工作区 MCP 访问策略管控DISABLED模式直接拒绝连接READ_ONLY模式只放行只读方法。创建 sheet、plan、issue、rollout 都属于写操作所以工作区的 MCP 策略需要允许写入的 Read-write 模式。MCP 会话同时受每个用户自身权限上限约束策略层面的拒绝会记入审计日志见 server.go 的鉴权中间件与 mcp-capability-ladder 的能力分层。具备四个权限bb.sheets.create创建 sheet、bb.plans.create、bb.issues.create、bb.rollouts.createskill 文档列出后三者bb.sheets.create来自 tool_change.go 中变更工具的权限说明。知道目标库的精确 canonical 名称。先用ListDatabases之类的读操作查库并原样保留返回的nameworkspace 实例形如instances/prod/databases/mainproject 实例形如projects/my-project/instances/prod/databases/main不要把后者缩写成instances/{instance-id}/databases/{database-name}。另外注意sheet 的 SQL 内容必须 base64 编码。Step 1创建 sheetbase64 SQL每调用一次call_api前先search_api获取 schema这是 skill 文档要求的固定顺序search_api(operationIdSheetService/CreateSheet)call_api(operationIdSheetService/CreateSheet, body{ parent: projects/{project-id}, sheet: { content: Q1JFQVRFIFRBQkxFIHVzZXJzIChpZCBJTlQgUFJJTUFSWSBLRVkpOw } })其中{project-id}是目标项目 IDcontent是 SQL 的 base64 编码。skill 文档给出的这段示例解码后是CREATE TABLE users (id INT PRIMARY KEY);——文档示例你自己的 SQL 需要重新做 base64 编码。响应 JSON 中的name字段形如projects/{project-id}/sheets/{sheet-id}就是后续 plan 要引用的 sheet 资源名记下来。Step 2创建包含多个目标的 planplan 的关键结构是顶层扁平的specs数组不包在 steps 里每个 spec 有一个唯一id、一个changeDatabaseConfig.targets数组即使只有一个目标也要写成数组和一个sheet引用。先取 schema再按批量方式下发。以下示例把同一个 sheet 挂到 dev 和 prod 两个库上skill 文档的批量示例search_api(operationIdPlanService/CreatePlan)call_api(operationIdPlanService/CreatePlan, body{ parent: projects/{project-id}, plan: { title: Add users table to all databases, specs: [ { id: spec-dev, changeDatabaseConfig: { targets: [instances/dev-pg/databases/mydb], sheet: projects/{project-id}/sheets/{sheet-id} } }, { id: spec-prod, changeDatabaseConfig: { targets: [instances/prod-pg/databases/mydb], sheet: projects/{project-id}/sheets/{sheet-id} } } ] } }){sheet-id}替换为 Step 1 返回的 sheet 资源名targets中的库名替换为ListDatabases返回的精确 canonical 名称。要点一个 sheet 可以被多个 spec 复用批量场景就是给同一份 SQL 挂多个 spec每个 spec 指向一个或多个目标库。目标库按 rollout policy 执行可以是串行也可以是并行。如果目标库组织在 database group 里可以直接用组作为 targettargets: [projects/{project-id}/databaseGroups/{group-name}]。变更类型不需要显式指定后端从 sheet 内容自动判断是 imperativeDDL/DML还是 SDL声明式 schemaplan spec 里没有type字段。Step 3创建 issuesearch_api(operationIdIssueService/CreateIssue)call_api(operationIdIssueService/CreateIssue, body{ parent: projects/{project-id}, issue: { title: Add users table, type: DATABASE_CHANGE, plan: projects/{project-id}/plans/{plan-id} } }){plan-id}来自 Step 2 响应中的 plan 资源名。issue 必须通过plan字段关联到刚创建的 plan类型固定为DATABASE_CHANGE。Step 4创建 rolloutsearch_api(operationIdRolloutService/CreateRollout)call_api(operationIdRolloutService/CreateRollout, body{ parent: projects/{project-id}, rollout: { plan: projects/{project-id}/plans/{plan-id} } })rollout 引用 plan 而非 issue。响应里的 rollout 资源名即本批次变更的执行入口可以在 Bytebase 控制台打开该 rollout 跟踪各 spec 的任务执行。结果判断与常见错误每步call_api的成功标准一致响应 Status 为 200 OK且 JSON 响应体里带新创建资源的nameHTTP 400 时响应中会有Error字段。四步的name相互引用sheet → plan → issue → rollout前一步的名字就是后一步 body 里的字段值。skill 文档给出了批量流程的常见错误对照表排查时按此定位错误原因修复database not found数据库引用不对重新列出数据库并原样保留其 canonicalnamesheet not foundsheet 不存在先执行 Step 1 创建 sheetmissing enginesheet 缺少 engine 字段给 sheet 补上engine字段plan not foundplan 不存在先创建 plan 再创建 issueinvalid base64SQL 未编码对 SQL 内容做 base64 编码targets must be array把 target 写成了字符串包成数组[...]还有一个边界issue 是否需要人工审批由项目的审批策略决定MCP 会话本身不能批准自己的变更审批类方法对 MCP 一律拒绝。rollout 创建后如果 issue 仍卡在待审批需要由人在 Bytebase 控制台完成审批。限制propose_database_change工具tool_change.go只支持单库目标文档注释明确把批量场景导向get_skill(database-change)即本文这条手动路径。/mcp端点的 JSON-RPC 请求体上限为 4 MiBserver.go 中的maxMCPRequestBodyBytes。单条 statement 超限时传输层直接返回 413且会导致当前会话连接失败之后该连接上的调用都会失败。批量 SQL 很大时注意单库分批或用更小的 statement。文中{project-id}、{instance-id}、{database-name}、{sheet-id}、{plan-id}等占位符按 AGENTS.md 的约定统一使用{project-id}项目标识、{instance-id}实例标识、{database-name}库名、{sheet-id}sheet 标识、{plan-id}plan 标识全部替换为真实资源名后命令即可执行。【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何通过 Bytebase MCP Server 跨多个数据库批量执行 sheet、plan 与 rollout 变更流程
如何通过 Bytebase MCP Server 跨多个数据库批量执行 sheet、plan 与 rollout 变更流程【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase当你需要把同一条 DDL/DML比如给多个环境的库执行CREATE TABLE或ALTER TABLE按 Bytebase 的评审流程下发时MCP Server 提供了一个手动批处理流程先创建 sheetSQL 载体再创建一个包含多个spec的 plan然后创建 issue 与 rollout。Bytebase 的propose_database_change工具只支持单库目标官方 skill 文档明确写了For batch changes across multiple databases才使用这条手动路径所以下面的步骤是批量场景的默认操作方式。整条流程通过 MCP 工具get_skill、search_api、call_api完成主流程为get_skill(database-change) → search_api(operationId) → call_api(...)。skill 原文在 database-changeskill 的加载与占位符约定见 AGENTS.md。准备确认模式、权限与目标库开始前需要满足以下条件MCP 访问模式允许写入。/mcp端点受工作区 MCP 访问策略管控DISABLED模式直接拒绝连接READ_ONLY模式只放行只读方法。创建 sheet、plan、issue、rollout 都属于写操作所以工作区的 MCP 策略需要允许写入的 Read-write 模式。MCP 会话同时受每个用户自身权限上限约束策略层面的拒绝会记入审计日志见 server.go 的鉴权中间件与 mcp-capability-ladder 的能力分层。具备四个权限bb.sheets.create创建 sheet、bb.plans.create、bb.issues.create、bb.rollouts.createskill 文档列出后三者bb.sheets.create来自 tool_change.go 中变更工具的权限说明。知道目标库的精确 canonical 名称。先用ListDatabases之类的读操作查库并原样保留返回的nameworkspace 实例形如instances/prod/databases/mainproject 实例形如projects/my-project/instances/prod/databases/main不要把后者缩写成instances/{instance-id}/databases/{database-name}。另外注意sheet 的 SQL 内容必须 base64 编码。Step 1创建 sheetbase64 SQL每调用一次call_api前先search_api获取 schema这是 skill 文档要求的固定顺序search_api(operationIdSheetService/CreateSheet)call_api(operationIdSheetService/CreateSheet, body{ parent: projects/{project-id}, sheet: { content: Q1JFQVRFIFRBQkxFIHVzZXJzIChpZCBJTlQgUFJJTUFSWSBLRVkpOw } })其中{project-id}是目标项目 IDcontent是 SQL 的 base64 编码。skill 文档给出的这段示例解码后是CREATE TABLE users (id INT PRIMARY KEY);——文档示例你自己的 SQL 需要重新做 base64 编码。响应 JSON 中的name字段形如projects/{project-id}/sheets/{sheet-id}就是后续 plan 要引用的 sheet 资源名记下来。Step 2创建包含多个目标的 planplan 的关键结构是顶层扁平的specs数组不包在 steps 里每个 spec 有一个唯一id、一个changeDatabaseConfig.targets数组即使只有一个目标也要写成数组和一个sheet引用。先取 schema再按批量方式下发。以下示例把同一个 sheet 挂到 dev 和 prod 两个库上skill 文档的批量示例search_api(operationIdPlanService/CreatePlan)call_api(operationIdPlanService/CreatePlan, body{ parent: projects/{project-id}, plan: { title: Add users table to all databases, specs: [ { id: spec-dev, changeDatabaseConfig: { targets: [instances/dev-pg/databases/mydb], sheet: projects/{project-id}/sheets/{sheet-id} } }, { id: spec-prod, changeDatabaseConfig: { targets: [instances/prod-pg/databases/mydb], sheet: projects/{project-id}/sheets/{sheet-id} } } ] } }){sheet-id}替换为 Step 1 返回的 sheet 资源名targets中的库名替换为ListDatabases返回的精确 canonical 名称。要点一个 sheet 可以被多个 spec 复用批量场景就是给同一份 SQL 挂多个 spec每个 spec 指向一个或多个目标库。目标库按 rollout policy 执行可以是串行也可以是并行。如果目标库组织在 database group 里可以直接用组作为 targettargets: [projects/{project-id}/databaseGroups/{group-name}]。变更类型不需要显式指定后端从 sheet 内容自动判断是 imperativeDDL/DML还是 SDL声明式 schemaplan spec 里没有type字段。Step 3创建 issuesearch_api(operationIdIssueService/CreateIssue)call_api(operationIdIssueService/CreateIssue, body{ parent: projects/{project-id}, issue: { title: Add users table, type: DATABASE_CHANGE, plan: projects/{project-id}/plans/{plan-id} } }){plan-id}来自 Step 2 响应中的 plan 资源名。issue 必须通过plan字段关联到刚创建的 plan类型固定为DATABASE_CHANGE。Step 4创建 rolloutsearch_api(operationIdRolloutService/CreateRollout)call_api(operationIdRolloutService/CreateRollout, body{ parent: projects/{project-id}, rollout: { plan: projects/{project-id}/plans/{plan-id} } })rollout 引用 plan 而非 issue。响应里的 rollout 资源名即本批次变更的执行入口可以在 Bytebase 控制台打开该 rollout 跟踪各 spec 的任务执行。结果判断与常见错误每步call_api的成功标准一致响应 Status 为 200 OK且 JSON 响应体里带新创建资源的nameHTTP 400 时响应中会有Error字段。四步的name相互引用sheet → plan → issue → rollout前一步的名字就是后一步 body 里的字段值。skill 文档给出了批量流程的常见错误对照表排查时按此定位错误原因修复database not found数据库引用不对重新列出数据库并原样保留其 canonicalnamesheet not foundsheet 不存在先执行 Step 1 创建 sheetmissing enginesheet 缺少 engine 字段给 sheet 补上engine字段plan not foundplan 不存在先创建 plan 再创建 issueinvalid base64SQL 未编码对 SQL 内容做 base64 编码targets must be array把 target 写成了字符串包成数组[...]还有一个边界issue 是否需要人工审批由项目的审批策略决定MCP 会话本身不能批准自己的变更审批类方法对 MCP 一律拒绝。rollout 创建后如果 issue 仍卡在待审批需要由人在 Bytebase 控制台完成审批。限制propose_database_change工具tool_change.go只支持单库目标文档注释明确把批量场景导向get_skill(database-change)即本文这条手动路径。/mcp端点的 JSON-RPC 请求体上限为 4 MiBserver.go 中的maxMCPRequestBodyBytes。单条 statement 超限时传输层直接返回 413且会导致当前会话连接失败之后该连接上的调用都会失败。批量 SQL 很大时注意单库分批或用更小的 statement。文中{project-id}、{instance-id}、{database-name}、{sheet-id}、{plan-id}等占位符按 AGENTS.md 的约定统一使用{project-id}项目标识、{instance-id}实例标识、{database-name}库名、{sheet-id}sheet 标识、{plan-id}plan 标识全部替换为真实资源名后命令即可执行。【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考