| title | TiDB FAQ |
|---|---|
| category | faq |
TiDB is a distributed SQL database that features in horizontal scalability, high availability and consistent distributed transactions. It also enables you to use MySQL’s SQL syntax and protocol to manage and retrieve data.
TiDB works as the SQL layer and TiKV works as the Key-Value layer. TiDB is mainly responsible for parsing SQL, specifying query plan, and generating executor while TiKV is to store the actual data and works as the storage engine.
TiDB provides TiKV the SQL enablement and turns TiKV into a NewSQL database. TiDB and TiKV work together to be as scalable as a NoSQL database while maintains the ACID transactions of a relational database.
Inspired by Google F1 and Spanner, TiDB and TiKV adopt a highly-layered architecture. This architecture supports pluggable storage drivers and engines, which powers you to customize your database solutions based on your own business requirements. Meanwhile, this architecture makes it easy to debug, update, tune, and maintain. You won’t have to go through the entire system just to find and fix a bug in one module.
Placement Driver (PD) works as the cluster manager of TiDB. It manages the TiKV metadata and makes decisions for data placement and load balancing. PD periodically checks replication constraints to balance load and data automatically.
Yes, it is. When all the required services are started, you can use TiDB as easily as a MySQL server. You can replace MySQL with TiDB to power your applications without changing a single line of code in most cases. You can also manage TiDB using the popular MySQL management tools.
TiDB is at your service if your applications require any of the following:
- Horizontal scalability
- High availability
- Strong consistency
- Support for distributed ACID transactions
TiDB is not a good choice if the number of the rows in your database table is less than 100GB and there is no requirement for high availability, strong consistency and cross-datacenter replication.
TiDB follows MySQL user authentication mechanism. You can create user accounts and authorize them.
-
You can use MySQL grammar to create user accounts. For example, you can create a user account by using the following statement:
CREATE USER 'test'@'localhost' identified by '123';The user name of this account is "test"; the password is “123" and this user can login from localhost only.
You can use the
Set Passwordstatement to set and change the password. For example, to set the password for the default "root" account, you can use the following statement:SET PASSWORD FOR 'root'@'%' = '123'; -
You can also use MySQL grammar to authorize this user. For example, you can grant the read privilege to the "test" user by using the following statement:
GRANT SELECT ON \*.\* TO 'test'@'localhost';
As your business grows, your database might face the following three bottlenecks:
-
Lack of storage resources which means that the disk space is not enough.
-
Lack of computing resources such as high CPU occupancy.
-
Not enough throughputs.
You can scale TiDB as your business grows.
-
If the disk space is not enough, you can increase the capacity simply by adding more TiKV nodes. When the new node is started, PD will migrate the data from other nodes to the new node automatically.
-
If the computing resources are not enough, check the CPU consumption situation first before adding more TiDB nodes or TiKV nodes. When a TiDB node is added, you can configure it in the Load Balancer.
-
If the throughputs are not enough, you can add both TiDB nodes and TiKV nodes.
TiDB is self-healing. All of the three components, TiDB, TiKV and PD, can tolerate failures of some of their instances. With its strong consistency guarantee, whether it’s data machine failures or even downtime of an entire data center, your data can be recovered automatically.
Strong consistency means all replicas return the same value when queried for the attribute of an object. TiDB uses the Raft consensus algorithm to ensure consistency among multiple replicas. TiDB allows a collection of machines to work as a coherent group that can survive the failures of some of its members.
Yes. The transaction model in TiDB is inspired by Google’s Percolator, a paper published in 2006. It’s mainly a two-phase commit protocol with some practical optimizations. This model relies on a timestamp allocator to assign monotone increasing timestamp for each transaction, so the conflicts can be detected. PD works as the timestamp allocator in a TiDB cluster.
Yes. ACID semantics are guaranteed in TiDB:
-
Atomicity: Each transaction in TiDB is "all or nothing": if one part of the transaction fails, then the entire transaction fails, and the database state is left unchanged. TiDB guarantees atomicity in each and every situation, including power failures, errors, and crashes.
-
Consistency: TiDB ensures that any transaction brings the database from one valid state to another. Any data written to the TiDB database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof.
-
Isolation: TiDB provides snapshot isolation (SI), snapshot isolation with lock (SQL statement: SELECT ... FOR UPDATE), and externally consistent reads and writes in distributed transactions.
-
Durability: TiDB allows a collection of machines to work as a coherent group that can survive the failures of some of its members. So in TiDB, once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors.
The lease parameter (--lease=60) is set from the command line when starting a TiDB server. The value of the lease parameter impacts the Database Schema Changes (DDL) speed of the current session. In the testing environments, you can set the value to 1s for to speed up the testing cycle. But in the production environments, it is recommended to set the value to minutes (for example, 60) to ensure the DDL safety.
Any language that has MySQL client or driver.
TiDB is compatible with MySQL protocol. TiDB sever speaks MySQL protocol and follows MySQL’s SQL grammar. The MySQL protocol layer and the TiDB SQL layer within the TiDB server work together to translate MySQL requests to TiDB SQL plan.
TiDB maps relational databases to Key-Value databases. It maps the relational table to Key-Value pairs and it also translate SQL statements to Key-Value operations.
Yes. TiDB follows MySQL’s SQL grammar. You can use TiDB just as using MySQL.
No. TiDB supports MySQL syntax and protocol, but it is a new open source database that is developed and maintained by PingCAP, Inc.
TiDB scores in horizontal scalability while still maintains the traditional relation database features. You can easily increase the capacity or balance the load by adding more machines.
TiDB is as scalable as NoSQL databases but features in the usability and functionality of traditional SQL databases, such as SQL syntax and consistent distributed transactions.
Yes. Your applications can be migrated to TiDB without changing a single line of code in most cases. You can use checker to check whether the Schema in MySQL is compatible with TiDB.
Yes. Besides TiKV, TiDB supports many popular standalone storage engines, such as GolevelDB, RocksDB and BoltDB. If the storage engine is a KV engine that supports transactions and it provides a client that meets the interface requirement of TiDB, then it can connect to TiDB.
Manually clone TiDB to the GOPATH directory and run the make command. TiDB uses Makefile to manage the dependencies.
If you are a developer and familiar with Go, you can run make parser; ln -s _vendor/src vendor in the root directory of TiDB and then run commands like go run, go test and go install. However, this is not recommended.
No. You can clone the TiDB repository to your $GOPATH/src/github.com/pingcap/tidb and run the make command manually. TiDB is a project rather than a library. Its package management is very complex and the parser is generated using the parser.y file, so TiDB uses Makefile.
However, if you are very familiar with Go, you can try the make parser; ln -s _vendor/src vendor command at the TiDB root directory. After that, the go run, go test, go install commands might work. But this approach is not recommended.
You need to set the --config parameter in TiKV/PD to make the toml configuration effective. TiKV/PD does not read the configuration by default.
For TiKV, the default value of the --data-dir parameter is /tmp/tikv/store. In some virtual machines, restarting the operating system results in removing all the data under the /tmp directory. It is recommended to set the TiKV data directory explicitly by setting the --data-dir parameter.
This is because the address in the startup parameter has been registered in the PD cluster by other TiKVs. This error occurs when there is no data folder under the directory that TiKV --store specifies, but you use the previous parameter to restart the TiKV.
To solve this problem, use the store delete function to delete the previous store and then restart TiKV.
This is because the cluster ID stored in local TiKV is different from the cluster ID specified by PD. When a new PD cluster is deployed, PD generates random cluster IDs. TiKV gets the cluster ID from PD and stores the cluster ID locally when it is initialized. The next time when TiKV is started, it checks the local cluster ID with the cluster ID in PD. If the cluster IDs don't match, the cluster ID mismatch message is displayed and TiKV exits.
If you previously deploy a PD cluster, but then you remove the PD data and deploy a new PD cluster, this error occurs because TiKV uses the old data to connect to the new PD cluster.
Most of the APIs of PD are available only when the TiKV cluster is initialized. This message is displayed if PD is accessed when PD is started while TiKV is not started when a new cluster is deployed. If this message is displayed, start the TiKV cluster. When TiKV is initialized, PD is accessible.
This is because the --initial-cluster in the PD startup parameter contains a memeber that doesn't belong to this cluster. To solve this problem, check the corresponding cluster of each member, remove the wrong memeber, and then restart PD.
If you want to update PD's startup parameters, such as --client-url, --advertise-client-url or --name, you just need to restart PD with the updated parameters.
However, if you want to update --peer-url or --advertise-peer-url, pay attention to the following situations:
- The previous startup parameter has
--advertise-peer-urland you just want to update--peer-url: restart PD with the updated parameter. - The previous startup parameter doesn't have
--advertise-peer-url: update the PD information with etcdctl and then restart PD with the updated parameter.
By default, TiDB/PD/TiKV outputs the logs to standard error. If a file is specified using --log--file during the startup, the log is output to the file and rotated daily.