Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Wait timeout in yb-ctl when using more or less nodes than RF #310

Closed
bmatican opened this issue May 30, 2018 · 0 comments
Closed

Wait timeout in yb-ctl when using more or less nodes than RF #310

bmatican opened this issue May 30, 2018 · 0 comments
Assignees
@bmatican
Labels
kind/bug This issue is a bug

Comments

@bmatican
Copy link
Contributor

When setting up the redis table, we wait for a number of tservers to come up, equal to the replication factor in that call to yb-ctl. This means that if a node went down, or if you used add_node to bring up new ones, we'll timeout the wait.

Traceback (most recent call last):
 File "./bin/yb-ctl", line 732, in <module>
   ClusterControl().run()
 File "./bin/yb-ctl", line 377, in run
   self.args.func()
 File "./bin/yb-ctl", line 723, in setup_redis
   raise RuntimeError("Timed out waiting for Yugabyte cluster!")
@rao-vasireddy rao-vasireddy added the kind/bug This issue is a bug label May 30, 2018
mbautin pushed a commit that referenced this issue Jun 6, 2018
@bmatican @mbautin
#310: Fixes for yb-ctl setup_redis wait and num_shards
fa00466 
Summary:
Setting up the redis table was waiting for RF number of servers, which would break if you
had added any extra nodes after creating the cluster. Also, not passing num_shards to the yb-admin
command lead to the redis table coming up with 8 shards per TS instead of whatever we ask for in
yb-ctl.

Test Plan: created a cluster, added a node, called setup_redis, checked UI for load distribution

Reviewers: mikhail, hector, bharat

Reviewed By: bharat

Subscribers: kannan, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D4906
@bmatican bmatican closed this as completed Jun 6, 2018
jasonyb pushed a commit that referenced this issue Jun 11, 2024
PG-174: Code cleanup. (#310)
634f0ce 
pg_stat_monitor is a bit longer; therefore, it requires some code cleanup.
Therefore I decided to turn these tasks into multiple commits and PR to avoid
various changes in one PR. This will ease the review and Q/A process.
In this commit, I have done these tasks.

1 - Fixing compilation issue, cause by previous commit, where we removed
the benchmarking code. It was causing problem for PostgreSQL-12.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bmatican bmatican

Labels
kind/bug This issue is a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bmatican @rao-vasireddy