Skip to content

Conversation

@anotherrachel
Copy link
Contributor

@anotherrachel anotherrachel commented Dec 13, 2019

What is changed?

This PR:

  • adds introduction.md of best practices
  • adds pd-scheduling.md to the best practices series
  • adds glossary.md

Any related PRs or issues?

Which version does your change affect?

anotherrachel added 2 commits December 13, 2019 14:27
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
@anotherrachel anotherrachel force-pushed the best-practices branch 2 times, most recently from 512d772 to 504a57e Compare December 13, 2019 07:47
anotherrachel added 4 commits December 13, 2019 16:47
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
Signed-off-by: anotherrachel <wangyajing@pingcap.com>
@anotherrachel anotherrachel marked this pull request as ready for review December 13, 2019 09:35
@dcalvin dcalvin requested review from Hoverbear and dcalvin December 13, 2019 09:37
@anotherrachel anotherrachel changed the title [WIP] Add PD scheduling best practices and glossary Add PD scheduling best practices and glossary Dec 13, 2019
Signed-off-by: anotherrachel <wangyajing@pingcap.com>

## L

### leader/follower/learner
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe these can be split up

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean they can be introduced separately?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they can be separate entries in this glossary?

summary: Glossaries about TiKV.
menu:
docs:
parent: Concepts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reference is more appropriate

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think these are some good concept material (reference, too) which users may want to notice easily when they are learning about TiKV.


- `scheduler show`: Shows currently running schedulers in the system
- `scheduler remove balance-leader-scheduler`: Removes (disable) balance-leader-scheduler
- `scheduler add evict-leader-scheduler-1`: Adds a scheduler to remove all leaders in Store 1
Copy link
Contributor

@Hoverbear Hoverbear Dec 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this and some further examples you use concrete examples, but above you used [limit], can we make it consistent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really appreciate your suggestions. I'll work on it.

Copy link
Contributor Author

@anotherrachel anotherrachel Dec 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Ana, here I think we can make it consistent by using scheduler add/remove [scheduler name] but I am not sure with "operator [add | remove]". The examples are concrete, yes, but more accessible to users since this operation usually involves a specific region (or store). What's your opinion?

@Hoverbear
Copy link
Contributor

I feel like most of the first half of this article should probably be something for learning as part of concepts maybe? The rest of it seems to be troubleshooting/issue resolving. It's good and useful stuff. :)

But... I'm not really sure where the "Best Practices" part of this article this. It doesn't go into recommending for example, how to improve a PD cluster from the default configuration to one optimized for your needs. It doesn't talk about how to decide which options/topologies are ideal for your needs. It doesn't talk about tradeoffs involved between these options, etc.

@dcalvin
Copy link
Member

dcalvin commented Dec 17, 2019

@lilin90 PTAL

I feel like most of the first half of this article should probably be something for learning as part of concepts maybe? The rest of it seems to be troubleshooting/issue resolving. It's good and useful stuff. :)

But... I'm not really sure where the "Best Practices" part of this article this. It doesn't go into recommending for example, how to improve a PD cluster from the default configuration to one optimized for your needs. It doesn't talk about how to decide which options/topologies are ideal for your needs. It doesn't talk about tradeoffs involved between these options, etc.

@lilin90
Copy link
Member

lilin90 commented Dec 17, 2019

I feel like most of the first half of this article should probably be something for learning as part of concepts maybe? The rest of it seems to be troubleshooting/issue resolving. It's good and useful stuff. :)

But... I'm not really sure where the "Best Practices" part of this article this. It doesn't go into recommending for example, how to improve a PD cluster from the default configuration to one optimized for your needs. It doesn't talk about how to decide which options/topologies are ideal for your needs. It doesn't talk about tradeoffs involved between these options, etc.

@Hoverbear Agree with you. Thanks! We'll consider giving some suggestions to those who'll write best practices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants