Bug: Cannot Use Container Name for TIKV Deployment

Author: nottisaCreated Sep 4, 2024Updated Sep 16, 2026

Labelsexternal-issuetopic:deploymenttopic:scale

Describe the bug

You cannot use the container name of your containers for your TIKV and PD containers on a single node deployment. This really only affects single-node environments like mine which are built to scale using TiKV, but are still running on a single node.

Steps to reproduce

Create a network for our cluster:

bash

docker network create --subnet=172.18.0.0/16 tikv-cluster

Create TIKV and PD containers referencing the container names instead of IPs:

bash

docker run --name=tikv1 \
	--volume=/etc/localtime:/etc/localtime:ro \
	--volume=/tmp/tikv-cluster:/data \
	--network=tikv-cluster \
	-p 20160:20160 \
	--restart=always \
	--detach=true \
	pingcap/tikv:latest \
	--addr=0.0.0.0:20160 --advertise-addr=tikv1:20160 --data-dir=/data/tikv1 --pd=pd1:2379

docker run --name=pd1 \
	--volume=/tmp/tikv-cluster:/data \
	--volume=/etc/localtime:/etc/localtime:ro \
	--network=tikv-cluster \
	-p 2379:2379 \
	-p 2380:2380 \
	--restart=always \
	--detach=true \
	pingcap/pd:latest \
	--name=pd1 --data-dir=/data/pd1 --client-urls=http://0.0.0.0:2379 --advertise-client-urls=http://pd1:2379 --peer-urls=http://0.0.0.0:2380 --advertise-peer-urls=http://pd1:2380 --initial-cluster=pd1=http://pd1:2380

We actually can verify the connection of our TiKV cluster by using pd-ctl:

pd-ctl store -u http://localhost:2379

Now we make a Surreal instance. Beta.1 gives the best logging, but this can be replicated on v1.5.3, and v1.5.4

bash

docker run --name=surreal \
	--network=tikv-cluster \
	-p 2000:2000 \
	--restart=no \
	--detach=true \
	surrealdb/surrealdb:v2.0.0-beta.1 \
	start tikv://pd1:2379 -A --user root --pass AwDZdTEcvB9LpS7rHhYQWe2zmsnGgk8XjJbUMtfyR64NqFC5Pa --bind 0.0.0.0:2000

If we view our Docker logs for our surreal container (docker logs surreal) we should see something like so:

2024-09-03T23:46:47.316302Z  INFO surreal::env: Running 2.0.0-beta.1 for linux on x86_64
2024-09-03T23:46:47.316499Z  INFO surrealdb::core::kvs::tr: Connecting to kvs store at tikv://pd1:2379
2024-09-03T23:46:47.317010Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.318356Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.321014Z  INFO tikv_client::pd::cluster: All PD endpoints are consistent: ["pd1:2379"]    
2024-09-03T23:46:47.321464Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.322489Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.324892Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.326301Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://pd1:2379"    
2024-09-03T23:46:47.328326Z  INFO surrealdb::core::kvs::tr: Connected to kvs store at tikv://pd1:2379
2024-09-03T23:46:47.330472Z  INFO tikv_client::pd::client: connect to tikv endpoint: "tikv1:20160"    
2024-09-03T23:46:47.330618Z  INFO tikv_client::common::security: connect to rpc server at endpoint: "http://tikv1:20160"    
2024-09-03T23:46:50.392249Z ERROR surrealdb::core::kvs::ds: error=There was a problem with a datastore transaction: gRPC error: transport error
2024-09-03T23:46:50.392290Z ERROR surrealdb::core::kvs::ds: error=There was a problem with a datastore transaction: gRPC error: transport error
2024-09-03T23:46:50.392484Z ERROR surreal::cli: There was a problem with the database: There was a problem with a datastore transaction: gRPC error: transport error

We can see that it connects to our placement driver properly as notated by "Connected to kvs store at tikv://pd1:2379" and the grabbing of our storage node "connect to tikv endpoint: 'tikv1:20160'", but seems to be unable to connect to our TiKV instance.

Expected behaviour

We should expect it to respect the container names which it seems to do when it connects to our placement driver, but when it connects to our TiKV instance it fails.

SurrealDB version

v2.0.0-beta.1, v1.5.4, v1.5.3

Contact Details

No response

Is there an existing issue for this?

I have searched the existing issues

Code of Conduct

I agree to follow this project's Code of Conduct

Source: surrealdb/surrealdb

View original on GitHub View discussion on GitHub