tikv/tikv · error
get_region_info should success
Error message
get_region_info should success
What it means
After locating the region, split_region asks PD for current region info (get_region_info) at the region's start key. If the RPC to PD fails (network error, PD unavailable), expect panics with 'get_region_info should success'.
Source
Thrown at cmd/tikv-ctl/src/main.rs:898
let pd = pd.unwrap_or_else(|| {
exit_with_clap_error(
ErrorKind::MissingRequiredArgument,
"--pd is required for this command",
);
});
let cfg = PdConfig::new(vec![pd]);
cfg.validate().unwrap();
RpcClient::new(&cfg, None, mgr).unwrap_or_else(|e| perror_and_exit("RpcClient::new", e))
}
fn split_region(pd_client: &RpcClient, mgr: Arc<SecurityManager>, region_id: u64, key: Vec<u8>) {
let region = block_on(pd_client.get_region_by_id(region_id))
.expect("get_region_by_id should success")
.expect("must have the region");
let leader = pd_client
.get_region_info(region.get_start_key())
.expect("get_region_info should success")
.leader
.expect("region must have leader");
let store = pd_client
.get_store(leader.get_store_id())
.expect("get_store should success");
let tikv_client = {
let cb = ChannelBuilder::new(Arc::new(Environment::new(1)));
let channel = mgr.connect(cb, store.get_address());
TikvClient::new(channel)
};
let mut req = SplitRegionRequest::default();
req.mut_context().set_region_id(region_id);
req.mut_context()
.set_region_epoch(region.get_region_epoch().clone());
req.set_split_key(key);View on GitHub (pinned to 78aedc1c81)
Solutions
- Check PD reachability: `curl http://<pd>:2379/pd/api/v1/version` and confirm the --pd address is correct.
- Retry the command once PD connectivity is restored; this is a transient infrastructure failure.
- If TLS is enabled, pass the correct CA/cert/key args to tikv-ctl so the gRPC channel can be established.
Example fix
// before
let leader = pd_client
.get_region_info(region.get_start_key())
.expect("get_region_info should success")
.leader
.expect("region must have leader");
// after
let region_info = match block_on(pd_client.get_region_info(region.get_start_key())) {
Ok(info) => info,
Err(e) => { eprintln!("get_region_info failed: {:?}", e); return; }
}; Defensive patterns
Strategy: retry
Validate before calling
// check PD health before running the command curl -fsS http://<pd-host>:2379/pd/api/v1/version || echo "PD unreachable"
Try / catch
// wrap the PD call; this is an io/grpc error, retry transient failures
match pd_client.get_region_info(region.get_start_key()) {
Ok(info) => info,
Err(e) => { backoff_retry(|| pd_client.get_region_info(...)); return; }
} Prevention
- Confirm PD endpoints and ports are reachable from the control host
- Keep CA/cert/key flags consistent with the cluster's TLS config
- Avoid running tikv-ctl during PD maintenance windows
When it happens
Trigger: PD is down or unreachable from tikv-ctl; network partition between the control host and PD; TLS/security manager misconfiguration blocking the gRPC call.
Common situations: Running tikv-ctl during PD maintenance or cluster outage; firewall blocking the PD client port; wrong security certificates for a TLS-enabled cluster.
Related errors
- encountering two different values but they are not in write
- failed to load all stores: {:?}
- get_store should success
- split_region should success
- fail to request PD {} err {:?}
AI-assisted analysis of tikv/tikv@78aedc1c81 (2026-09-03).
Data as JSON: /api/errors/dc13d4fd61db289a.
Report an issue: GitHub.