[FLASH-332] Add backoff to getting gc safe point from pd #106
Conversation
|
It's strange, why does pd client need a tikv's backoff |
Move backoff to common namespace. |
|
I don't think pd client should retry by backoff. It's unconsistent with official pd client, what do you think @ilovesoup ? |
|
@ilovesoup @innerr In golang pd client, it returns error directy in stead of retry. I do retry only for a hot fix. |
Yes. As far as I know, backoff and retry strategy is different for TiKV and PD. At least here we only need things for PD now. KV backoff should be added when we working on it. Otherwise the code will remain untested. |
Yes we do want to keep the same behavior of client part and in near future the client might be moved out of TiFlash scope to TiKV.org. Any extra logic should be outside of client. |
| @@ -25,6 +25,7 @@ Client::Client(const std::vector<std::string> & addrs) | |||
| pd_timeout(3), | |||
| loop_interval(100), | |||
| update_leader_interval(60), | |||
| get_gc_safe_point_timeout(20000), | |||
There was a problem hiding this comment.
What's the overall retry logic here? How much total retry time budget and what if still fail?
|
Do you mean the user of pd client should retry(using backoff strategy) when get gc safe point fail? @hanfei1991 |
|
yes, and should not use backoff. |
|
What do you mean by "not use backoff" ? I guess it would be better to create a new issue to explain the right way to fix this problem when you have time? @hanfei1991 And how about closing this pr now? @ilovesoup |
…gcap#109) Disable eager raft log gc
No description provided.