You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While for other apis, we do not support rate limit:
AskSplit
AskBatchSplit
ReportSplit
ReportBatchSplit
GetClusterConfig
PutClusterConfig
ScatterRegion
GetGCSafePoint
SyncRegions
UpdateGCSafePoint
UpdateServiceGCSafePoint
GetOperator
These APIs that are not subject to flow control are also vulnerable to attacks, which can easily overload the PD.
for example , if I run the following SQL on the TiDB:
CREATE TABLE employees (
id int unsigned NOT NULL,
fname varchar(30),
lname varchar(30),
hired date NOT NULL DEFAULT '1970-01-01',
separated date DEFAULT '9999-12-31',
job_code int,
store_id int NOT NULL
) PARTITION BY RANGE (id)
INTERVAL (100) FIRST PARTITION LESS THAN (1000) LAST PARTITION LESS THAN (100000) MAXVALUE PARTITION;
mysql> split partition table t between (0) and (100000000) regions 1000;
split partition table t between (0) and (10000000) regions 1000;
then the qps of AskBatchSplit will super high, and make the leader PD's memory and CPU explode instantly.
there are at least two things we can do:
add ratelimit for this API
limit the batch size for batch-split
The text was updated successfully, but these errors were encountered:
Enhancement Task
Currently, we have implemented rate limiting on some interfaces of grpc:
pd/server/grpc_service.go
Lines 416 to 417 in a6e855e
pd/server/grpc_service.go
Lines 646 to 648 in a6e855e
pd/server/grpc_service.go
Lines 749 to 751 in a6e855e
pd/server/grpc_service.go
Lines 794 to 796 in a6e855e
https://github.com/tikv/pd/blob/a6e855eef6744adfac232833769219be4f806756/server/grpc_service.go#L1265C4-L1267
pd/server/grpc_service.go
Lines 1309 to 1311 in a6e855e
pd/server/grpc_service.go
Lines 1354 to 1356 in a6e855e
pd/server/grpc_service.go
Lines 1398 to 1400 in a6e855e
While for other apis, we do not support rate limit:
These APIs that are not subject to flow control are also vulnerable to attacks, which can easily overload the PD.
for example , if I run the following SQL on the TiDB:
then the qps of
AskBatchSplit
will super high, and make the leader PD's memory and CPU explode instantly.there are at least two things we can do:
The text was updated successfully, but these errors were encountered: