阿里云 DTS 作业管理器

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install alibabacloud-dts-job-manager
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 alibabacloud-dts-job-manager。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

阿里云 DTS 作业管理器可帮助你在阿里云数据传输服务 (DTS) 中创建、检查、查询价格并管理单向数据库同步作业。它支持 RDS MySQL、PolarDB MySQL 和 PolarDB-X 2.0 之间的同步；RDS PostgreSQL 与 PolarDB PostgreSQL 之间的同步；以及 ApsaraDB for MongoDB 副本集之间的同步。
作为用于云数据库操作的 Openclaw Skills 之一，它会引导你完成作业创建流程：从解析端点和选择实例规格，到审核方案、测试连接、确认购买以及执行预检查。它还可以列出作业、报告状态和进度、检查已同步对象、查询实例规格价格，并执行经批准的启动、暂停或重命名操作。它不管理迁移、订阅、校验、跨账号或双向作业。

应用场景

创建受支持的单向同步作业，用于数据传输或跨地域灾难恢复。
查找某个地域中的同步作业，或通过 ID 或准确名称查询作业。
检查作业状态、进度、增量延迟、预检查结果或已同步对象。
查询用户所选 DTS 实例规格的单价和计费单位。
在审核目标并取得所需授权后，启动、暂停或重命名已定位的作业。
在编制同步方案前，将云数据库实例名称解析为 ID。

工作原理

检查 dtscli 运行环境和会话能力，确保此技能已为当前代理做好准备，并在进行任何云 API 调用前验证技能身份。
将请求匹配到受支持的只读查询、价格查询、作业创建流程或生命周期操作。不会更改不受支持的作业类型。
创建作业时，加载受支持的场景，解析源端和目标端点，并获取用户对实例规格、同步阶段及目标端已有对象处理策略的选择。
编制公开 JSON 方案并初始化创建尝试。审核方案；如有需要，通过指定的凭据流程收集凭据，并测试连接。
展示已审核的方案、连接测试结果、报价和计费影响。在执行前，取得用户对未更改购买方案的明确批准。
按照返回的下一步操作，检查预检查和作业状态，并报告结果。对于生命周期变更，先定位并审核作业，再执行明确获授权的操作。
谨慎解读结构化 JSON 输出和操作结果。对不明确的结果进行核实，不要重试可能已经完成的管理操作。

配置指南

按照当前操作系统的说明安装 dtscli，并确保它位于 PATH 中。支持 macOS、Linux 和 Windows。
按照文档说明的设置和凭据流程配置阿里云身份验证及数据库访问。切勿在聊天中提供机密信息、令牌或授权码。
在会话中首次使用时，检查运行时版本和所需能力，然后为当前宿主代理确保技能已就绪。将宿主提供的稳定小写代理标识符代入 。
dtscli version --json
dtscli skills ensure --agent
如果命令报告缺少阿里云 CLI 或 DTS 插件，请安装所需依赖，并按照工作流指引继续执行同一命令：
dtscli job deps install --yes
如果找不到 dtscli，请查阅针对相应平台的安装说明。不要替换为其他 DTS 接口，也不要直接调用 aliyun。进行云 API 调用前，验证技能的软件包身份，并遵循文档说明的请求身份验证流程。管理操作和购买都需要明确确认，除非当前用户消息已经授权执行完全相同且未更改的操作或方案。

数据架构

创建工作流使用公开 JSON 方案，并通过 create init、review、test 和 execute 跟踪尝试。端点专属字段取决于数据库系列。
方案字段 用途和限制
scenario 为源端和目标端选择的受支持同步链路模板。
job_name 用户为新作业提供的名称。创建时不会搜索重复名称。
source, destination 端点配置，包括地域和已解析的实例 ID。PostgreSQL 和 MongoDB 必须填写 database 字段；MySQL 系列则省略该字段。
stages 用户选择的结构迁移和全量迁移组合。增量同步始终启用；仅选择增量同步时，两个字段均设为 false。
objects 要同步的数据库对象，以源命名空间和对象表示。对于 MongoDB，将身份验证数据库保留在端点的 database 字段中，并将要同步的数据库放在 objects 中。
existing_destination_policy 目标对象已存在时，用户为预检查选择的处理方式。忽略选项仅适用于该预检查；它不会清空或重建目标端。
instance_class 用户选择的 DTS 实例规格；工作流会获取该规格的报价。
destination_storage_engine 仅在目标端为 PolarDB MySQL 时填写，并使用用户选择的存储引擎。
CLI 会将 JSON 结果输出到标准输出，并将进度输出到标准错误。创建响应包含 attempt_id、next_step、outcome 和资源影响信息等工作流状态；作业查询会返回作业详情，并可包含结构化的 db_list 映射和计数。价格按实例规格报价，本地缓存有效期为 24 小时。切勿将凭据、配置档或私有身份验证数据放入公开方案。

高级特性

支持通过场景驱动的方式，在文档记录的 RDS、PolarDB、PolarDB-X 2.0 和 MongoDB 副本集链路中创建作业。
分别解析源端和目标端实例名称，并要求精确匹配结果唯一后才使用实例 ID。
提供按规格查询报价的功能，并显示币种、计费单位以及实时查询或缓存信息。
使用经过审核的创建尝试、连接测试、确认哈希、预检查和明确的购买批准。
通过专用流程收集凭据，避免数据库凭据进入对话或公开方案。
支持作业列表、状态和进度检查、预检查查询、已同步对象报告，以及经批准的启动、暂停和重命名操作。
针对购买结果不明确的情况采取安全措施，避免盲目重试，并将写入操作限制在用户请求的操作和受支持的 API 操作范围内。
为受支持的 OpenAPI 命令传递会话范围内的请求标识符和技能版本，以便识别此技能发出的云请求。

name: alibabacloud-dts-job-manager description: Create, query, and manage database synchronization jobs in Alibaba Cloud Data Transmission Service (DTS), covering synchronization link creation, job status and progress visibility, job renaming, starting, suspending, or resuming jobs, and instance class and hourly price lookup. Use when the user mentions DTS, a DTS job/instance/link, data synchronization, or database synchronization; asks what synchronization jobs exist, how far a job has progressed, or what its incremental latency is; asks how much a synchronization costs, what the small instance class costs, or what unit it is billed by; needs full or incremental synchronization for a data migration or cross-region disaster recovery; or says “sync data from one database to another.” Supports database synchronization among RDS MySQL, PolarDB MySQL, and PolarDB-X 2.0; between RDS PostgreSQL and PolarDB PostgreSQL; and between ApsaraDB for MongoDB replica sets.

Alibaba Cloud DTS Job Manager

Core scope

Create and manage only same-account, one-way cloud-database synchronization jobs whose source and destination databases belong to the supported synchronization links. Apply the source and destination database configuration for database instances or clusters, access methods, and regions; apply DbList and Reserve for synchronized objects and parameters.

Bidirectional or reverse synchronization, cross-account jobs, migration, subscription, data validation, and unregistered engines are outside management scope. Read-only queries may report these jobs, but stop before any write.

Runtime

Every operation runs through dtscli, which must be on PATH. macOS, Linux, and Windows are supported. When the shell reports dtscli: command not found, read platform installation and command execution to select the installer, paths, and shell syntax for the actual host. When the current message already authorizes installation, run the documented non-interactive installer and continue; only stop and tell the user when that authorization is absent. Never fall back to another way of calling DTS.

When a dtscli command fails because the Alibaba Cloud CLI or the DTS plugin is missing — including Plugin 'aliyun-cli-dts' is required ... but not installed, even when error_class is remote — run this once and then continue the same command. Do not ask the user to authorize it, and do not add --update:

dtscli job deps install --yes

That install is not a plan change. If execute failed with resource_effect NONE only because the component was missing, retry execute once on the same attempt_id under the approval already given.

Do not add --update, and do not run aliyun yourself: this includes plugin installation, version queries, and API calls for products such as DDS, MongoDB, or DTS. Do not replace the aliyun binary. Stop the current task only when a command's JSON output carries an error_class whose message contains ERROR: unchecked version: preserve and report that error, and run no further dtscli job command or any aliyun command. A successful dtscli doctor check that merely mentions those words is not that error; continue. When reporting the CLI version, quote the version field from dtscli job deps install. Do not run aliyun version. Do not upgrade the Alibaba Cloud CLI and do not read the same data through another interface. See setup.

In the current user session, run dtscli version --json only the first time this Skill is used. Confirm that capabilities contains skills.ensure, then run:

dtscli skills ensure --agent

Later steps and sub-agents in the same session run business commands directly. Continue when ready=true, including action=busy. Stop and reload Skill files when reload_required=true. When ready=false without reload, read automatic Skills updates. --agent names the current host's stable lowercase identifier and must match [a-z][a-z0-9_-]{0,31}. Common hosts: codex, claude, cursor, zcode, qoder, qoderwork, qwencode, qwenworkcn, opencode, kimi, or pi.

Results are written as JSON on standard output and progress on standard error. On failure, the exit code is non-zero. Standard output may contain a generic error with error_class, or retain the command-specific status or execution summary. Interpret the JSON under the relevant workflow; do not determine success from the exit code or one field alone.

Request identity

Before any cloud API invocation, read this skill's package identity manifest. Use only its top-level non-empty string name as {skill-name} and only its top-level non-empty string version as {skill-version}. The name must match this Skill's frontmatter name and the skill directory name. If missing, invalid, or inconsistent, STOP. NEVER invent, guess, or reuse a name or version from another skill. On a skill switch or return, reread that skill's package identity manifest. Read request identity before constructing the request identifier.

Before this skill's first cloud API invocation in a conversation, generate a fresh random 32-character lowercase hexadecimal session ID. Reuse that session ID for this skill throughout the conversation; each skill MUST use a distinct session ID. NEVER copy one from documentation, examples, another skill, or a previous conversation, and NEVER send the literal {session-id} placeholder.

Attach --user-agent only to dtscli commands that call an OpenAPI and accept it: dtscli job instances, job price, job get, job list, job precheck, job start, job pause, job rename, job create test, and job create execute. Do not attach it to any other command, including version, skills ensure, skills install, upgrade, doctor, job auth login, job auth status, job deps install, job credentials collect, and the locally completed job create scenarios, job create init, and job create review. Exact user-agent with skill version propagation across CLI/SDK/Terraform:

--user-agent "AlibabaCloud-Agent-Skills/alibabacloud-dts-job-manager/{session-id} skill-version/{skill-version}"

Core Security Requirements

Never accept or handle a secret, credential, token, or authorization code in chat. Follow setup for authentication and database credentials and connection tests for database credentials.
Before every management operation, show the redacted target, key parameters, action, and billing or lifecycle impact, then obtain explicit confirmation. A change to the plan, parameters, or action requires new confirmation.
When the same user message names the instances, databases or tables, and job name, and explicitly approves purchasing that unchanged plan, run dtscli job create execute --attempt-id --yes once. Do not copy confirmation_sha256 to the user. A changed plan requires a new confirmation.
When the same user message names the job region and the job name (or job ID) and explicitly approves suspending, starting, or renaming that unchanged target, show the review and run that one operation once without asking again. That authorization covers only that job and that operation: a change to the target, direction, or operation requires new confirmation, and it never carries over to another job or another operation.
Do not retry a management operation before verifying the previous outcome. When a purchase result is ambiguous, stop, ask the user to check the console, and never retry execute.
Execute only a call that matches the user's request and appears in the API allowlist.

Create

Sub-agents run only dtscli. The path below does not require reading references first; read the matching document from the table at the end only when the user must choose the class, stage combination, or existing-destination policy, or after a command fails or a required field is missing. Never read credential files.

Creation does not query existing jobs for a duplicate name. Use the job name the user supplied and create a new job. Do not wait for delay_seconds to become 0.

The instance class, the stage combination, and the existing-destination-object policy are the user's decisions and must not be filled in from a template: keep a valid choice the user already made, and when a choice is missing or invalid, obtain it under the three rules below before compiling the plan. After the required choices exist, follow the numbered sequence below exactly. Do not skip or reorder a step except when next_step requires credential collection followed by another review.

Class: when the user has not chosen one, first run dtscli job price with no --instance-class, show every reviewed class with its complete quotation and RPS reference, and require the user to select one. Do not query only one class in that case. Preserve a valid class the user already gave, and do not query every class after that. Once a class is selected, query it once with --instance-class after loading the scenario and resolving both endpoints but before create init. Never preselect from RPS or price. When the user says this machine has no saved database username or password, do not ask for either in the conversation; after review returns credentials_required, run dtscli job credentials collect --attempt-id once, adding --language zh when the page should be Chinese.
Stage combination: follow creation choice elicitation, show the available combinations, and require the user to select one; keep a valid combination the user already chose. Incremental synchronization is always on and cannot be disabled.
Existing-destination-object policy: follow the existing destination object policy and let the user choose between failing the precheck when destination objects exist and ignoring that precheck. Ignoring applies to that one precheck only; it never clears or rebuilds the destination, and a full-load primary-key conflict keeps the destination row. Any other precheck failure must stop.
Load the scenario template. If the scenario is unknown, run the same command without --name and pick only a returned name. When both sides are RDS PostgreSQL, the scenario is rds-postgresql-to-rds-postgresql; resolve both instance names with --type RDS --engine POSTGRESQL --page-size 20 (src then dest). Do not use the PolarDB PostgreSQL flags for an RDS PostgreSQL instance.
dtscli job create scenarios --name

Resolve the source and destination endpoints in order, then query the quotation. When the user gave only an instance name, run the source job instances query once under resolve an instance ID from a name; run the destination query only after one exact source match. Skip the query for an endpoint that already has a complete instance ID. Stop immediately when either endpoint has zero or several matches or is unusable; do not continue to the other endpoint, quotation, or plan compilation. After both endpoints are known, run dtscli job price --instance-class once, with no region or link argument.

Write public JSON. Do not include usernames, passwords, engine, instance_type, or the profile. Angle brackets mark placeholders to replace with the user's actual choices. PostgreSQL and MongoDB endpoints need database; for MongoDB that field is the authentication database, such as admin, and synchronized objects belong in objects. Never put the authentication database into objects, and never use the database being synchronized as database. PolarDB MySQL destinations need destination_storage_engine.

{
"scenario": "",
"job_name": "",
"source": {
"region": "",
"instance_id": "",
"database": "
"
},
"destination": {
"region": "",
"instance_id": "",
"database": "
"
},
"stages": { "structure": true, "full": true },
"objects": [{ "source": "", "objects": [{ "source": "" }] }],
"existing_destination_policy": "",
"instance_class": "",
"destination_storage_engine": "
"
}

Fill stages with the combination the user selected; the example is the standard structure-plus-full combination, and an incremental-only combination sets both to false. existing_destination_policy and instance_class must carry the user's selected values: do not submit the placeholders and do not substitute a default for the user's choice. Omit both database fields for the MySQL family; that family rejects them. For PostgreSQL set them to the databases that hold the synchronized objects. Different instances may use the same database name. For MongoDB set them to the authentication database, such as admin, and keep the synchronized database in objects. Omit destination_storage_engine unless the destination is PolarDB MySQL; then set the engine the user named.

Compile the plan:
dtscli job create init --input

Follow the returned next_step: review reports credentials and the plan summary, then test reports connectivity and issues the confirmation hash. When outcome is credentials_required, run dtscli job credentials collect --attempt-id once, return to review, then run test. Do not rebuild the public input and do not skip review; test accepts only an attempt that has been reviewed. The credential page is English by default; add --language zh for Chinese. Neither the page address nor credential values enter the conversation.

After test returns ready_for_confirmation, show the complete plan from review, this run's connection_test, the class and quotation obtained in step 2, and the billing impact, and obtain explicit confirmation. An explicit approval in the current user message to purchase that unchanged plan satisfies this confirmation; do not ask again. Choosing the class, stage combination, or existing-destination policy, or authorizing installation, is not purchase approval. When the user asks to confirm the creation plan first, ask, and run execute only after that approval. Re-query the same class only when that quotation's cache lifetime has expired. Once the user has approved the unchanged plan, run execute once. Do not stop after the connection test:

dtscli job create execute --attempt-id --yes

Do not copy confirmation_sha256. When outcome is indeterminate, or failed with resource_effect UNKNOWN, stop and never retry execute; if a job ID is present, run dtscli job get --job-id --region , otherwise ask the user to check the console. When outcome is failed with resource_effect NONE (nothing was created) or INSTANCE_PURCHASED (the instance exists and is billing), determine the cause. If the only cause is a missing Alibaba Cloud CLI or DTS plugin, install it as described under Runtime and execute once more on the same attempt_id without asking again. For any other cause, obtain the user's confirmation again, and then execute once more on the same attempt_id: the purchased instance is reused for configuration and start, and a second instance is never bought.

After a successful create, follow next_step for the precheck, then job get. Do not wait for delay 0; a CHECKING precheck is not a failure — query it again as described in job status · precheck. A Chinese final answer must name the exact job name, the source instance name, and the destination instance name. For PostgreSQL, also write both database values; do not mention only the schema and table. For MongoDB, write the synchronized database, not only the authentication database. For the MySQL family, write both product names and both 「同步」 and 「创建」.

job price quotes by class only and does not accept --region; the price does not vary with link or region.

Query

When the user asks to list synchronization jobs in a region, follow list jobs and run dtscli job list --region --page 1 --page-size 10. When the user requires the final answer in Chinese, it must contain 地域 ，第
页，每页
条。本页 条，总数 条。 If jobs exist, write 「任务 ID、实例 ID、名称、状态」 in that order and list every job on this page; if none exist, write 「没有同步任务」. If more pages exist, report how many jobs remain. If the user already limited the request to this page and said not to ask about another page, stop after that report; otherwise let the user decide whether to continue.

If a job ID is known, run dtscli job get --job-id --region . When only a name is known, run dtscli job list --region --job-name and compare complete names case-sensitively on this page. Stop when there are zero or multiple exact matches. After one match, run job get or dtscli job precheck --job-id --region . Add --with-db-list when the user asks for the synchronized objects, and report the structured db_list mapping and counts. Interpret the raw status. Report an unknown value as-is and stop before any write.

When configuring a job and only an instance name is known, use dtscli job instances to resolve the instance ID; do not treat it as job list. First confirm that the capabilities from this session's dtscli version --json include job.instances. When they do not and the current user message already authorizes installing or upgrading the runtime dependencies, run dtscli upgrade once, rerun dtscli version --json, and continue once the capability appears; do not ask the user about it. Stop and tell the user to upgrade dtscli only when the capability is still missing after the upgrade or that authorization is absent. Pass the user-given instance name as --instance-id. Search the source and destination separately: use --usage-type src to resolve the source and --usage-type dest to resolve the destination. The same product can appear on either side, so do not follow the examples into one fixed side. Use these flags exactly; do not guess another --type, --engine, or --page-size:

dtscli job instances --region --type RDS --engine MYSQL --usage-type --instance-id --page 1 --page-size 100
dtscli job instances --region --type RDS --engine POSTGRESQL --usage-type --instance-id --page 1 --page-size 20
dtscli job instances --region --type POLARDB --engine POLARDB --usage-type --instance-id --page 1 --page-size 30
dtscli job instances --region --type POLARDB --engine POLARDB_PG --usage-type --instance-id --page 1 --page-size 30
dtscli job instances --region --type POLARDBX20 --engine POLARDBX20 --usage-type --instance-id --page 1 --page-size 100
dtscli job instances --region --type MONGODB --engine MONGODB --usage-type --instance-id --page 1 --page-size 100

Product --type --engine --page-size

RDS MySQL RDS MYSQL 100

RDS PostgreSQL RDS POSTGRESQL 20

PolarDB MySQL POLARDB POLARDB 30

PolarDB PostgreSQL POLARDB POLARDB_PG 30
PolarDB-X 2.0 POLARDBX20 POLARDBX20 100

MongoDB replica set MONGODB MONGODB 100

Further match rules are in resolve an instance ID from a name. In user-facing text, use product names, instance names, and the resolved instance IDs; never show API enums such as --type or --engine. After a unique exact name match, write instance_id into the plan; stop when there are zero or several matches.

Stop when resolving an instance name returns zero or several matches, when the instance is unusable, or when either side does not satisfy the link requirements. Never pick the first row, reuse an older instance ID, or continue with a different instance.

Price

A request that only asks for a price is read-only: run dtscli job price --instance-class and report the unit price, the currency, and the billing unit, say whether the quote came from this run's live query or from a local cache (valid for 24 hours), and note that the purchase page and the final order remain official. Do not compile a plan, collect credentials, test connectivity, or run any create, start, pause, or rename for it. job price quotes by class only and accepts no --region, source, destination, or link parameter; do not pick a class the user did not choose, do not recommend other classes, and do not re-query for a fresher price. See instance classes and pricing.

Lifecycle

After locating the job, run job get and show the review before the first dtscli job start, dtscli job pause, or dtscli job rename. For a rename, that job get must happen before the first rename; a later job get that only reads the new name back does not replace it. Run the operation once when the same message already approved that job and that operation; otherwise obtain explicit confirmation first. A create-flow purchase approval does not authorize pause or rename, and one lifecycle authorization never carries over to another job or operation.

Task-based reference loading

Read these only after a command fails, a field is missing, a user choice is needed for the class, stage combination, or existing-destination policy, or the user asks for pricing or link details. Do not load every creation reference at once.

User intent Read

Validate installation, profile, authentication, or service access Setup
Ask only for a price, a class quotation, or a billing unit, or compare classes Instance classes and pricing; read setup first when installation or authentication needs validating
Create a job: scenario or field error Supported synchronization links, job creation
Create a job: stage combination or existing-destination policy Job creation, Reserve
Create a job: endpoint, object, or Reserve error Read the source and destination database configuration, DbList, Reserve, and database credentials and connection tests only as needed
Resolve an instance ID from a name to configure a job Source and destination database configuration · resolve an instance ID from a name
List jobs, interpret status, or view precheck results Job status
Rename or manage lifecycle Job lifecycle, with job status for current-state verification

Call a DTS API Read the API allowlist before calling it

Access denied, or which RAM actions this Skill requires RAM permissions

UberFix Branch Finder

阿里云 DTS-AI 文档解析器