oceanbase
OceanBase Deployment and Operations with obd
Use this entry point to identify the target, execution mode, and owning skill. Do not turn an explanation, configuration review, or diagnostic request into a deployment.
Mandatory Package Acquisition Order
Apply this rule before any online lookup or request for every package carried by the OceanBase public repositories, including OBD, database and proxy components, companion libraries, clients, test tools, and diagnostic tools. Select the effective artifact source first; only then select a download mechanism.
For each exact package candidate, use these effective artifact sources in order: (1) the actual package directories under https://mirrors.oceanbase.com, then (2) the actual package directories under https://mirrors.aliyun.com/oceanbase. The first actual OceanBase package request must target source 1. Keep the same source through three meaningful acquisition attempts before moving to source 2; after both sources are exhausted, move from the target-OS suffix to EL8 and then EL7 when that package family publishes EL suffixes. A generic connectivity test cannot replace or precede the first source-1 request.
A package-manager .repo file is only repository configuration, not a package source or package download. Count the effective base URL or final candidate URL that serves the package bytes, not the host that served the .repo file. Before using a repository definition or counting a package-manager attempt, resolve and record that effective URL and confirm that it belongs to the current source. Operating-system dependency repositories such as Rocky BaseOS/AppStream are a separate channel: changing one neither counts as an OceanBase source attempt nor changes this order, and must not be hidden in the same opaque command as OceanBase acquisition.
Within the current source, use applicable controller-local mechanisms such as a version-supported OBD/tool path, direct curl or wget, or the operating-system package manager. obd mirror imports or indexes an artifact that is already local; never use it as a network downloader. Read the detailed fixed package-source workflow before the first package network request.
OBD bootstrap: the controller package is ob-deploy; Community and Commercial OceanBase deployments use the same OBD package from the public community tree. When OBD is absent and no verified controller-local RPM already exists, start under https://mirrors.oceanbase.com/community/, default to downloading the exact RPM on the selected controller with curl or wget, and install that local RPM with the operating-system package manager. A request to execute an OBD-dependent deployment authorizes this proved first installation and the package manager's ordinary non-interactive acceptance option such as -y; do not ask for separate permission to run the install command. This exception does not authorize OBD replacement, upgrade, downgrade, an unproved package candidate, or broad repository changes. Do not add a persistent OceanBase .repo merely as the default way to bootstrap OBD. Use a repository definition only when its effective package URL is proved to follow the current source order.
Other packages: default online mode lets the installed OBD/repository or owning tool workflow resolve and fetch the proved winners. When direct controller-local download or an approved relay succeeds, follow the artifact's actual consumer path: import OBD component RPMs with obd mirror clone and isolate the complete local closure; use the version-proved local registration or installation path for clients, test tools, diagnostic tools, images, and non-RPM artifacts; install operating-system dependencies only on the machine that consumes them. Do not turn every downloaded package into a package-manager installation on every cluster node.
Default Controller, SSH, and Existing-State Discovery
For every configuration-file or maximum-utilization autodeploy cluster deployment, keep the controller on a cluster deployment host unless the user explicitly selected a separate controller. Probe the user-supplied target hosts in their original order before choosing or installing OBD. Reuse the target host that owns the intended registered deployment, or an otherwise unambiguous existing target-host controller. Only after every target host is reachable and confirmed to have no OBD executable, package ownership, or controller metadata, install OBD on the first target host with non-interactive package-manager acceptance and without asking the user to choose or approve the install command. Never default to installing or running OBD on the automation runner.
Use the user's supplied SSH login user for every deployment machine; if no login user is specified, use root. If no authentication material is supplied, use passwordless SSH. After login, keep that login-session user as the identity for all subsequent work: inspect and prepare hosts, install and run OBD, own controller metadata and files, and connect from the controller to the same login user on every other node. Do not derive or switch to a second OBD execution user. If controller-to-node passwordless authentication fails but the runner already has verified access to the exact target, directly append the controller login user's public key to that same login user's authorized_keys, preserve existing entries and permissions, and verify BatchMode access without another prompt. Use narrowly scoped privilege escalation only for commands that require it; it must not change the OBD/controller owner. Never copy a private key, replace authorized_keys, alter passwords or sshd_config, bypass a host-key mismatch, or use a tunnel. Ask for access only when no already-approved path can modify the exact target or its identity remains ambiguous.
Do not ask the user whether a cluster is already deployed. Determine that through read-only inspection of candidate-controller registrations and, on every target host, relevant package/service state, processes, listeners, deployment paths, and database identity when reachable. A missing registration or stopped process alone does not prove absence. Ask only when access failed or the completed inspection leaves a genuine identity or ownership ambiguity. Follow the detailed controller, SSH, and cluster discovery contract.
Default New-Deployment Directory
For a new deployment, when the user does not specify deployment or storage paths, select the default separately on every target under the established login-session user. Use the persistent mounted filesystem with the greatest usable free capacity for which that user can actually read, write, and traverse a safe parent directory, then create a new deployment-specific base beneath it. Place the component home, data, redo, log, and other deployment-owned subdirectories beneath that base as the installed schema permits. Do not default to the user's home while a larger writable persistent filesystem exists, and do not assume a path such as /data/1 without inspecting the host. Explicit user paths override this default; existing registered paths are immutable unless the user requests a supported path-migration workflow. Follow the detailed default deployment-directory selection.
Default New-Cluster Sizing
For a new OceanBase cluster deployment, when the user does not specify resource values, a resource cap, or a non-maximum sizing profile, default to the maximum-utilization workflow without asking the user to choose a size. Explicit user values or caps take precedence. This default maximizes only the resolved target hosts; it does not add hosts, components, tenants, or topology that the user did not request.
For a new distributed deployment with multiple user-supplied Observer hosts and no explicit zone mapping, assign each distinct host to a distinct new zone in deterministic host order. Do not ask the user to choose the default placement. Preserve an explicit zone mapping, do not infer extra hosts or replicas, and do not claim that logical zones sharing one physical failure domain provide high availability.
Deployment Package Closure
Before the first package lookup or acquisition for any retained workflow, read the shared deployment package closure. This includes controller installation or maintenance, deployment, component changes, upgrade, reinstall, obd test, and obdiag tool provisioning. Build the complete package set from the final requested workflow, including selected *-libs, client-library, test-tool, diagnostic-tool, and rollback dependencies; do not stop after downloading the obvious primary artifact. In online mode prove every closure entry is resolvable; in local-package/offline mode place and verify the complete closure on the selected remote controller before package selection. Child Skills can be invoked directly and therefore repeat this link at their own acquisition entry points.
Default Database Bootstrap Password
For a new OceanBase cluster deployment, do not ask the user to choose the initial database root/sys password unless the user has already specified one. When no override was supplied, leave the bootstrap-password field absent and use the installed OBD workflow's proved random-password generation path; do not generate the value in the agent or substitute an empty value. Keep the generated value protected and verify authentication without printing it. Read the cluster workflow's database bootstrap-password default before rendering deployment YAML.
Route the Request
| Skill | Use when |
|---|---|
| cluster-management | Deploy or operate OceanBase Community Edition clusters; manage configuration, lifecycle, upgrades, component changes, monitoring, Config Server, and network access. |
| obd-administration | Install or update the OBD controller; manage mirrors/repositories, provision the exact dynamic tool required by a retained workflow, inspect trace evidence, and handle the tested runtime settings. |
| tenant-management | Create, inspect, optimize, back up, restore, drop, or manage physical primary/standby tenants. |
| testing-and-benchmark | Run Sysbench, TPC-H, TPC-C, or mysqltest through obd test. |
| obdiag-diagnostics | Install-gated diagnostic collection, analysis, checks, scenes, or RCA through obd obdiag. |
Current Skill-Version Boundary
Before routing any request, check whether its operation appears in current Skill-version unsupported capabilities. For a listed capability, report UNSUPPORTED — the current Skill version does not support this workflow before proposing or executing commands. This is a Skill-coverage verdict, not a claim that the installed OBD product can never support the capability. Do not recover a deleted workflow from repository history or route it through a generic component or tool command.
Resolve Product and Capability First
Before proposing an executable command or configuration, read product and capability resolution. Resolve the installed Community Edition component keys, plugins, repositories, and artifact set before selecting syntax or rendering a configuration.
Do not:
- treat a source-tree feature as proof that the installed OBD package exposes it;
- infer compatibility only because every requested package exists in a repository.
Preserve the User's Execution Mode
- Explain, plan, review, or audit: stay read-only. Inspect only the supplied files and already available local evidence unless the user expands the scope.
- Diagnose: begin with the smallest relevant read-only evidence set. High-overhead collection or tool installation is a separate action.
- Implement: display the resolved targets, mutations, impact, and acceptance plan before execution. Obtain authorization at the point required by the risk class.
Read the shared operation contract before any live controller/host/deployment query, SSH/SQL/API/network access, download, write, or other externally visible action. A child skill can be selected directly, so every child in the routing table must also link this contract and retain its essential safety boundary.
Define Completion and Failure Handling
Command exit, task acceptance, process state, control-plane state, and data-plane usability are different results.
- Read completion criteria before declaring an operation complete.
- On failure, timeout, interruption, or a mixed state, read failure recovery and evidence before retrying or cleaning anything.
- Before any cleanup, removal, reset, prune, drop, or deletion, read cleanup and ownership boundaries and enumerate the exact removed and retained objects.
Never use destroy, --force, metadata deletion, repository cleanup, tenant drop, or another broad mutation as a generic repair.
Sensitive Values
Do not place passwords, passkeys, access keys, tokens, private keys, or credential-bearing URIs in reusable examples, chat output, process arguments when a protected input exists, or reports. Redact secrets without discarding the non-sensitive evidence needed to reproduce a failure.