TiDB

Prerequisites

• An Azure subscription with permission to create virtual machines
• An SSH key pair
• A MySQL-compatible client on your workstation if you want to connect remotely (mysql, MySQL Workbench, DBeaver, or any MySQL driver)

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for TiDB by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size (Standard_D4s_v5 is recommended, see Sizing). Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) only. Then select Review + create and Create.

First-boot initialisation generates your per-VM database password, bootstraps the cluster with that password already set, and starts all five services. Allow two to three minutes after the VM is running before the database accepts queries. TiDB creates its entire system-table catalogue on the first bootstrap.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:tidb-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name tidb \
  --image sac1647283583153:tidb-ubuntu-24-04:default:latest \
  --size Standard_D4s_v5 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

A welcome banner prints the most useful commands.

Step 4 - Confirm the cluster is running

Five services make up the deployment. Check that all five report active.

systemctl is-active tidb-pd tidb-ngm tidb-prometheus tidb-tikv tidb

Expected output:

active active active active active

Check which ports are listening. Only the SQL port is bound on all interfaces. Everything else is cluster-internal and bound to loopback.

ss -tlnp 2>/dev/null | grep -E '4000|2379|20160|20180|10080|12020|9090' | awk '{print $1, $4}' | sort -u

Ask PD directly whether the storage layer is serving. A TiKV store must be Up. This is the check that matters, because the SQL layer accepts connections even when storage is unavailable.

curl -s http://127.0.0.1:2379/pd/api/v1/stores | jq -r '.stores[] | "store \(.store.id) \(.store.address) \(.store.state_name)"'

Step 5 - Retrieve your per-VM database password

Upstream TiDB creates its root account with no password at all. This image never ships that default. It contains no bootstrapped cluster, and on first boot it generates a password unique to your VM and applies it during the first cluster bootstrap. An empty-password root never exists as a completed state.

The credentials file is readable only by root. Check its permissions, then read it:

sudo ls -l /root/tidb-credentials.txt

sudo cat /root/tidb-credentials.txt

Store the password in your password manager. It is generated per VM, so no two deployments of this image share a credential.

Step 6 - Connect over the MySQL protocol

TiDB speaks the MySQL wire protocol, so the standard mysql client works. Run it on the VM:

mysql -h 127.0.0.1 -P 4000 -uroot -p'<TIDB_ROOT_PASSWORD>' -e 'SELECT VERSION() AS server_version'

The version string shows both the MySQL protocol level and the TiDB release:

+--------------------+ | server_version | +--------------------+ | 8.0.11-TiDB-v8.5.7 | +--------------------+

Step 7 - Run SQL

Create a database and a table, insert rows, and read them back. Every write travels through the SQL layer into TiKV.

mysql -h 127.0.0.1 -P 4000 -uroot -p'<TIDB_ROOT_PASSWORD>' -t -e " CREATE DATABASE IF NOT EXISTS quickstart; DROP TABLE IF EXISTS quickstart.orders; CREATE TABLE quickstart.orders ( id INT PRIMARY KEY AUTO_INCREMENT, region VARCHAR(24), amount DECIMAL(10,2) ); INSERT INTO quickstart.orders (region, amount) VALUES ('emea', 120.50), ('apac', 340.00), ('amer', 75.25), ('emea', 210.75); SELECT * FROM quickstart.orders; SELECT region, COUNT(*) AS orders, ROUND(SUM(amount),2) AS revenue FROM quickstart.orders GROUP BY region ORDER BY revenue DESC;"

To confirm the data is persisted rather than held in memory, restart the stack and read the same rows back:

sudo systemctl restart tidb-tikv tidb for i in $(seq 1 60); do mysql -h 127.0.0.1 -P 4000 -uroot -p'<TIDB_ROOT_PASSWORD>' -N -e 'SELECT 1' >/dev/null 2>&1 && break sleep 2 done mysql -h 127.0.0.1 -P 4000 -uroot -p'<TIDB_ROOT_PASSWORD>' -t -e 'SELECT COUNT(*) AS rows_after_restart FROM quickstart.orders'

The rows come back from TiKV after the storage layer has been stopped and started, so they were on disk rather than held in memory.

Step 8 - Inspect the cluster

Query PD for its view of the cluster, including each store's capacity:

curl -s http://127.0.0.1:2379/pd/api/v1/stores | jq -r '.stores[] | "store \(.store.id) \(.store.address) \(.store.state_name) capacity=\(.status.capacity)"'

Step 9 - Open TiDB Dashboard over an SSH tunnel

TiDB Dashboard is a full web console for the cluster. It covers instance topology, SQL statement analysis, slow queries, Top SQL and a key-space visualiser. PD serves it.

On this image PD is bound to loopback only, because the PD client port also exposes unauthenticated cluster-administration APIs alongside the Dashboard. Reach the Dashboard through an SSH tunnel rather than opening the port:

ssh -L 2379:127.0.0.1:2379 azureuser@<vm-public-ip>

With the tunnel open, browse to http://127.0.0.1:2379/dashboard. Sign in with username root and the password from Step 5. The Dashboard authenticates against the TiDB SQL account, so rotating root secures the Dashboard too.

The Overview page shows queries per second, latency percentiles and CPU usage, drawn from the bundled Prometheus.

Cluster Info lists the component instances and their versions.

SQL Statements aggregates the queries the cluster has executed, with latency and execution counts. It is the fastest way to find the statement worth optimising.

Grafana and Alertmanager are not included in this image. The Dashboard's own charts are backed by the bundled Prometheus, which is why the Monitor and Alert links on the Overview page are inactive.

Step 10 - Connect remotely

The Azure network security group created with this image opens SSH (22) only, so the TiDB SQL port is not reachable from outside the VM by default. You have two options.

SSH tunnel (recommended). This needs no firewall change, and the database is never exposed to the network:

ssh -L 4000:127.0.0.1:4000 azureuser@<vm-public-ip> mysql -h 127.0.0.1 -P 4000 -uroot -p

Open the port. If an application needs direct access, add an inbound rule for TCP 4000 in your NSG, scoped to the source addresses that need it. Do not open the port to the internet.

Sizing

TiDB is a distributed system, and by default each of its three components sizes its memory as a percentage of total RAM. TiKV's block cache alone defaults to 45%, and the SQL layer's memory limit defaults to 80% of the same RAM. This image sets every one of those ceilings explicitly and recomputes them from the machine's own RAM at each service start, so the same image behaves correctly across VM sizes.

Standard_D4s_v5 (4 vCPU / 16 GiB) is the recommended size. Choose a D-series size rather than a cheaper burstable B-series size of the same capacity. TiKV runs continuous RocksDB background compaction, which is a sustained baseline CPU load.

A burstable SKU drains its CPU credits under sustained load and then throttles to a low baseline. Compaction then falls behind and write stalls appear, which looks like a database fault but is really a sizing fault. D-series SKUs have no credit model.

For context, PingCAP's own development and test guidance is well above this for each component separately (TiDB 8 cores / 16 GiB, TiKV 8 cores / 32 GiB, PD 4 cores / 8 GiB). Standard_D4s_v5 is a single-box development and evaluation size, not a claim of production capacity. Scale up for heavier workloads, and scale out to a multi-node cluster for anything that needs fault tolerance.

Maintenance

The database and its data disk survive reboots, and all five services start automatically. Check the TiDB service status:

systemctl status tidb --no-pager | head -5

Data lives on the dedicated data disk mounted at /var/lib/tidb. Confirm the mount:

df -h /var/lib/tidb | tail -1

Take regular backups. A single replica means there is no redundancy inside the cluster, so an Azure disk snapshot of the data disk, or a logical dump, is your only protection against data loss. For example:

mysqldump -h 127.0.0.1 -P 4000 -uroot -p'<TIDB_ROOT_PASSWORD>' --databases quickstart > /tmp/quickstart-backup.sql

unattended-upgrades applies Ubuntu security updates automatically.

Support

SecureAnyCloud publishes and maintains this image with 24/7 support. For questions about TiDB itself, see the PingCAP documentation. For image or deployment issues, contact SecureAnyCloud support.

Deploy on Azure

Launch TiDB on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com