If you’re a DBA who has spent years with MySQL or PostgreSQL, trying out a new database usually brings mixed feelings. Curiosity, yes — but also hesitation.
I went through the same phase with TiDB.
Before installing it, the questions in my mind were very simple:
- Is this going to be complicated?
- Will it feel completely alien?
- What should I even check after it starts?
This blog is written exactly for that stage — when you’re new to TiDB and want to understand it calmly, without rushing or overengineering things.
In our previous blog, “A DBA’s First Look at TiDB’s Distributed Architecture and Unique Features”, we explored what TiDB is and why DBAs should care about it.
The next natural question for any DBA is:
“How do I install TiDB, and what should I verify first after connecting?”
This blog answers that question, without assuming any prior knowledge of TiDB or distributed systems.
Understanding TiDB Installation Options
Before installing TiDB,One important thing to clear upfront: TiDB is not installed like MySQL.
MySQL is a single server process.
TiDB is a database cluster, even when you run it on your laptop.
For learning purposes, TiDB provides something called TiDB Playground.
Think of it as “a safe sandbox where all TiDB components run together so you can understand how the system behaves”.
TiDB Playground (Learning Mode – Used in This Blog)
TiDB Playground:
- Runs all TiDB components on a single machine
- Starts automatically with one command
- Is designed only for learning, testing, and demos
- Is not production-ready
Think of it like running MySQL on your laptop to learn — not to host production traffic.
TiDB Cluster (Production Mode)
In production:
- TiDB, TiKV, and PD run on separate servers
- Data is distributed across multiple machines
- High availability is guaranteed
This blog intentionally avoids production setup to keep learning simple.
TiDB Cloud
A fully managed TiDB service where:
- PingCAP manages infrastructure
- DBAs focus only on schema and queries
Why TiUP Exists (And Why You Don’t Need to Worry About It)
TiDB uses a tool called TiUP for installation and lifecycle management.
When I first heard about it, my concern was:
“Is this another complex orchestration tool?”
In reality, TiUP exists to make a DBA’s life easier, not harder.
TiUP:
- Downloads the correct TiDB components
- Ensures compatible versions
- Starts and stops the cluster cleanly
You don’t manage binaries manually.
You don’t worry about version mismatches.
From a DBA perspective, TiUP is there so you can focus on understanding TiDB, not fighting the setup.
Installing TiDB
Let’s start with the installation.
To install TiUP, I used the official PingCAP mirror. This is important because some older blogs still point to outdated URLs.
Run this as a normal user:
$ curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
$ source ~/.bashrc
What this does:
- Installs TiUP under your home directory
- Updates your shell environment
- Does not touch system files
No sudo is required, and that’s intentional.
Starting TiDB for the First Time
Once TiUP is installed, starting TiDB is just one command:
$ tiup playground
This is where pause and think:
“That’s it?”
Yes — but a lot happens behind the scenes.
What Actually Starts When TiDB Playground Runs
This is the most important part to understand.
When you run tiup playground, you’re not starting a single database process. You’re starting multiple components, each with a clear responsibility.
TiDB Server (SQL Layer)
This is what your application connects to.
- Accepts SQL queries
- Uses MySQL protocol
- Does not store data
- Stateless by design
From a MySQL DBA’s perspective, this is similar to mysqld — but without storage responsibilities.
TiKV (Storage Layer)
This is where your actual data lives.
- Stores data in a distributed way
- Uses key-value storage internally
- Handles replication and durability
- Replaces InnoDB’s role
As a DBA, you should think of TiKV as:
“The engine that safely stores data across nodes, even if one fails.”
PD (Placement Driver)
PD is the brain of the cluster.
It:
- Knows where data is stored
- Balances data across nodes
- Assigns timestamps for transactions
There’s nothing like this in MySQL, and you usually don’t interact with PD directly — but it’s critical to TiDB’s stability.
TiFlash (Analytical Engine)
TiFlash stores data in columnar format.
Why this matters:
- Row storage (TiKV) is great for transactions
- Column storage (TiFlash) is great for analytics
TiDB can use both on the same data, without ETL pipelines.
Monitoring (Prometheus & Grafana)
One thing I genuinely liked:
monitoring starts automatically.
You don’t have to install exporters or dashboards manually.
For DBAs, this is a big win.
Connecting to TiDB (This Will Feel Familiar)
TiDB listens on port 4000 by default.
You connect using a normal MySQL client:
$ mysql -h 127.0.0.1 -P 4000 -u root
Once connected, you’ll see something like:
Server version: MySQL 8.0 compatible (TiDB)
This is the moment most DBAs relax — because SQL behaves exactly as expected.
The First Things need to check
After connecting, I didn’t create tables immediately.
First, I wanted to understand the cluster itself.
Checking Which Components Are Running
> SELECT * FROM information_schema.cluster_info;
This query shows:
- TiDB server
- PD
- TiKV
- TiFlash
- Their addresses and versions
When you see all of them listed and running, it confirms:
“This is not a single database instance — this is a functioning cluster.”
Understanding How Data Is Distributed (Regions)
SELECT * FROM information_schema.tikv_region_status LIMIT 10;
This output shows Regions.
A Region is:
- A small chunk of data
- Automatically managed
- Replicated for fault tolerance
Instead of DBAs manually creating shards, TiDB splits and moves Regions automatically.
This is one of the core reasons TiDB scales better than MySQL.
Verifying SQL Behavior (Compatibility Check)
SELECT @@sql_mode;
SELECT @@character_set_server;
You’ll typically see:
- Strict SQL modes
utf8mb4character set
This matters because:
- It prevents silent data issues
- It ensures predictable behavior during migration
Validate Transaction Behavior (ACID Check)
Create a test database and table:
CREATE DATABASE testdb;
USE testdb;
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
amount DECIMAL(10,2),
created_at DATETIME
);
Test a transaction rollback:
START TRANSACTION;
INSERT INTO orders VALUES (1, 100.00, NOW());
ROLLBACK;
SELECT * FROM orders;
Result:
Empty set
This confirms strong transactional consistency, even in a distributed system.
Important TiDB Parameters Looked At (Without Tuning)
I didn’t change any parameters.
I only wanted to understand what kind of controls exist.
SHOW VARIABLES LIKE 'tidb%';
A few worth knowing:
tidb_enable_async_commit
Helps reduce commit latency in distributed transactions.tidb_enable_1pc
Optimizes transactions that touch a single Region.tidb_distsql_scan_concurrency
Controls how many parallel tasks are used during scans.
At this stage, the most important thing is:
Understand what these settings are for — not to tune them.
Final Thoughts
Installing TiDB is easier than most DBAs expect.
The real change is not SQL syntax — it’s thinking in terms of clusters instead of single servers.
By installing TiDB, validating cluster components, and understanding initial settings, DBAs can confidently begin their journey into distributed SQL.