My idea is: for example, there are two TiKV nodes, 5.1 and 5.2. One write request writes 123 to 5.1, and another write request writes 456 to 5.2. Then, the request to read 123 will always read from 5.1. I want to extend the replica of 5.1 to achieve load balancing. Additionally, if this is possible, can we specify a read replica (for example, if 5.1 has an extended replica on machine 5.5, can we specify that every read request for 123 goes to 5.5)?
I didn’t quite understand what you meant.
The TiDB cluster is load-balanced by default. For example, in a cluster with three servers 5.1, 5.2, and 5.3, with three replicas, when you write 123, the leader replica will be written to 5.1, and the follower replicas will be automatically written to 5.2 and 5.3. By default, reads are performed from the leader replica, and the leader is dynamically switched, so it is not necessarily always on 5.1.
Are you saying that after writing 123, 5.1kv itself stored 123, and then 5.1 also created a leader replica to store 123? Or does 5.1 only have the leader? What I mean is whether there are two storage instances on 5.1 or just one. In my context, two means 5.1 itself plus the leader, and one storage means just the leader.
In version 5.1, 123 is stored. In versions 5.2 and 5.3, 123 is also stored asynchronously. When retrieving data, if 5.1 is the leader, it is retrieved from 5.1; if 5.2 is the leader, it is retrieved from 5.2.
Is this understanding correct?
Okay. I have this scenario where I use a LIKE query. I’m not very familiar with TiDB. For example, in MySQL, using double % can cause a full table scan, and if there are writes at the same time, it might cause a deadlock. Will this happen in TiDB?
Are you looking to implement read-write separation?
Currently, TiDB does not have complete read-write separation technology. It only has large labels, but followers will only read when the system is slow.
If you are using read-write separation, reading from the leader won’t have any impact. If you are talking about a full table scan, reading from any replica will have an impact.
Partitioning the table will distribute the fields you want to scatter. However, it won’t solve the issue of a full table scan with LIKE. If the left side is not %, then it can use the index.
|
username: TiDBer_2CPYnSMQ
|
username: 
|
username: 
|
username: 
|
username: