From 0545c68436c0b661b4b701c3037e0d60b0bf7e67 Mon Sep 17 00:00:00 2001 From: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com> Date: Thu, 8 Oct 2020 08:01:46 +0300 Subject: [PATCH] Update content/en/docs/reference/features/tablet-throttler.md Co-authored-by: Byron Landry --- content/en/docs/reference/features/tablet-throttler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/features/tablet-throttler.md b/content/en/docs/reference/features/tablet-throttler.md index 639eed018..2937b4ec9 100644 --- a/content/en/docs/reference/features/tablet-throttler.md +++ b/content/en/docs/reference/features/tablet-throttler.md @@ -23,7 +23,7 @@ Some common database operations include mass writes to the database, including t These operations can easily incur replication lag. However, these operations are typically not time-limited. It is possible to rate-limit them to reduce database load. -This is where a throttler gets in. A throttler can tell "replication lag is low, cluster is healthy, go ahead and do some work" or it may say "replication lag is high, please hold your next operation". +This is where a throttler becomes useful. A throttler can detect when replication lag is low, a cluster is healthy, and operations can proceed. It can also detect when replication lag is high and advise applications to hold the next operation. Applications are expected to break down their tasks into small sub-tasks (e.g. instead of deleting `1,000,000` rows, only delete `50` at a time), and check in with the throttler in-between.