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

  1. Check PD reachability: `curl http://<pd>:2379/pd/api/v1/version` and confirm the --pd address is correct.
  2. Retry the command once PD connectivity is restored; this is a transient infrastructure failure.
  3. 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

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


AI-assisted analysis of tikv/tikv@78aedc1c81 (2026-09-03). Data as JSON: /api/errors/dc13d4fd61db289a. Report an issue: GitHub.