-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vtcombo] Expose --tablet_types_to_wait
flag
#14951
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
c6831db
to
b91ee0f
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #14951 +/- ##
==========================================
+ Coverage 67.41% 67.48% +0.06%
==========================================
Files 1560 1561 +1
Lines 192752 193343 +591
==========================================
+ Hits 129952 130485 +533
- Misses 62800 62858 +58 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rest LGTM, but I don't think we should change the definition of replica count wherein it includes the primary tablet as well.
--tablet_types_to_wait
flag
577ac6f
to
fb528bb
Compare
Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
fb528bb
to
de43b28
Compare
I changed this to not change how |
I removed the |
Description
At GitHub, we use
vtcombo
in our CI system and our local development environments.While investigating slow CI setup times, I noticed that
vtcombo
by default is starting 3 tablets (PRIMARY
,RDONLY
andREPLICA
) per keyspace/cell. For a small topology, that's not really an issue, but we run multiple hundreds of keyspaces in CI, and just starting this setup takes almost a minute.This is quite wasteful, especially because we don't use
RDONLY
andREPLICA
tablets at all in CI or local development. To improve this, we can setreplicaCount
to1
to only start a singleREPLICA
tablet (which will be promoted to primary), andrdonlyCount
to-1
to start noRDONLY
tablets.Unfortunately,
vtcombo
will startvtgate
and instruct it to wait forPRIMARY,REPLICA,RDONLY
tablets to be available, which, based on the above configuration, won't ever happen. Eventually, thevtgate
will run into a timeout while waiting and then start serving requests anyway.Exposing the
tablet_types_to_wait
CLI flag allows setting the flag to e.g.PRIMARY
only, which brings down the startup time forvtcombo
to ~20 seconds in our setup, which is quite an improvement.Related Issue(s)
N/A
Checklist
Deployment Notes