# Example of Minimal Deployment Topology for Production

__*TiDB Topology*__
__*zz-BGL*__

![`smart`](TiDBClusterDeploymentTopologyExercise_aa_007_20220914.png)

---------------------------------------------------------------------------
Note: Similar to what is shown in this figure, we also provide each students ten instance in the lab.

`TiDB` instances count: 2
`Placement Driver` instances count: 3
`TiKV` instances count: 3
`TiFlash` instances count: 1
Monitoring & Grafana instance count: 1


`TiDB` server: Responsible for accepting client connections, executing SQL parse and optimization, and finally generating distributed execution plans. The `TiDB` layer itself is stateless. In practice, multiple `TiDB` instances can be launched. Through load balancing components (such as `LVS`, `HAProxy`, or `F5`), a unified access address is provided to the outside world, and client connections can be evenly distributed across multiple `TiDB` instances to achieve load balancing. `TiDB` server itself does not store data, but only parses SQL and forwards the actual data read request to the underlying storage node `TiKV` (or `TiFlash`).

PD (Placement Driver) server: Metadata management module for the entire `TiDB` cluster. It stores the real-time data distribution of each `TiKV` node and the overall topology of the cluster, provides the TiDB Dashboard management interface, and assigns transaction IDs to distributed transaction. PD not only stores metadata, but also issues data scheduling commands to specific `TiKV` nodes based on the real-time data distribution status reported by the `TiKV` nodes. In addition, the PD itself is made up of at least 3 nodes and has high availability capabilities. It is recommended to deploy an odd number of PD nodes.

Storage nodes:

- `TiKV` server: Responsible for storing data. From the outside, `TiKV` is a distributed key-value storage engine that provides transaction. The basic unit for storing data is Region. Each Region is responsible for storing data for a Key Range (the left and right open range from StartKey to EndKey), and each `TiKV` node is responsible for multiple Region. `TiKV`'s API provides native support for distributed transaction at the KV key-value pair level. By default, the isolation level of SI (Snapshot Isolation) is provided, which is the core of `TiDB`'s support for distributed transactions at the SQL level. After the SQL layer of `TiDB` completes the SQL parse, the SQL execution plan is converted into an actual call to the `TiKV` API. So, the data is all stored in `TiKV`. Additionally, data in `TiKV` is automatically maintained in multiple replica (three by default), which naturally supports high availability and automatic failover.

- `TiFlash` server: `TiFlash` is a special class of storage nodes. Unlike normal `TiKV` nodes, data is stored in a columnar format inside `TiFlash`, and the main function is to accelerate analytical scenario. `TiFlash` node is optional if you don't need the columnar storage.


`Monitoring & Grafana`:

- `Prometheus`: As a time series database, `Prometheus` has a multi-dimensional data model and flexible query language. As one of the most popular open source projects, `Prometheus` has been adopted by many companies and organizations and has a very active community. PingCAP is one of the active developers and adopters of Prometheus for monitoring and alerting in `TiDB`, `TiKV` and `PD`.

- `Grafana`: `Grafana` is an open source project for analyzing and visualizing metrics. `TiDB` uses Grafana to display the performance metrics.