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.

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

Not able to scale down a docker cluster gracefully #112

Closed
schoudhury opened this issue Mar 21, 2018 · 2 comments
Closed

Not able to scale down a docker cluster gracefully #112

schoudhury opened this issue Mar 21, 2018 · 2 comments
Assignees
Labels
kind/bug This issue is a bug

Comments

@schoudhury
Copy link
Contributor

schoudhury commented Mar 21, 2018

Hitting an assert on scaling down a docker container based cluster.

  • Create a new docker local cluster with 3 nodes
  • Run the load tester against it
  • Add a new node using
./yb-docker-ctl add_node
  • Now remove a node
./yb-docker-ctl remove_node 4

All the nodes go down. The error from any one container:

F0321 18:27:46.960845   111 net_util.cc:203] Check failed: _s.ok() Bad status: Network error (yb/util/net/net_util.cc:195): Unable to resolve address yb-tserver-n4, getaddrinfo returned -2 (EAI_NONAME): Name or service not known
Fatal failure details written to /mnt/disk0/yb-data/tserver/logs/yb-tserver.FATAL.details.2018-03-21T18_27_46.pid1.txt
*** Check failure stack trace: ***
    @     0x7f4549f388eb  DumpStackTraceAndExit (yb/util/logging.cc:154)
    @     0x7f454910a0cc 
    @     0x7f454910bfdc 
    @     0x7f4549109c29 
    @     0x7f454910ca9e 
    @     0x7f4549f68249  ResolveInetAddresses<yb::HostPort::ResolveAddresses(std::vector<boost::asio::ip::basic_endpoint<boost::asio::ip::tcp> >*) const::<lambda(sockaddr_in*)> > (yb/util/net/net_util.cc:203)
    @     0x7f4549f68249  yb::HostPort::ResolveAddresses(std::vector<boost::asio::ip::basic_endpoint<boost::asio::ip::tcp>, std::allocator<boost::asio::ip::basic_endpoint<boost::asio::ip::tcp> > >*) const (yb/util/net/net_util.cc:226)
    @     0x7f454ebbcac8  CreateConsensusServiceProxyForHost (yb/consensus/consensus_peers.cc:457)
    @     0x7f454ebbcd74  yb::consensus::RpcPeerProxyFactory::NewProxy(yb::consensus::RaftPeerPB const&, gscoped_ptr<yb::consensus::PeerProxy, yb::DefaultDeleter<yb::consensus::PeerProxy> >*) (yb/consensus/consensus_peers.cc:477)
    @     0x7f454ebd4787  yb::consensus::LeaderElection::LeaderElection(yb::consensus::RaftConfigPB const&, yb::consensus::PeerProxyFactory*, yb::consensus::VoteRequestPB const&, std::unique_ptr<yb::consensus::VoteCounter, std::default_delete<yb::consensus::VoteCounter> >, yb::MonoDelta, yb::StronglyTypedBool<yb::consensus::TEST_SuppressVoteRequest_Tag>, yb::Callback<void (yb::consensus::ElectionResult const&)>) (yb/consensus/leader_election.cc:201)
    @     0x7f454ebf48a3  yb::consensus::RaftConsensus::DoStartElection(yb::consensus::Consensus::ElectionMode, bool, yb::OpIdPB const&, std::string const&, yb::StronglyTypedBool<yb::consensus::TEST_SuppressVoteRequest_Tag>) (yb/consensus/raft_consensus.cc:534)
    @     0x7f454ebe3f8b  yb::consensus::Consensus::StartElection(yb::consensus::Consensus::ElectionMode, bool, yb::OpIdPB const&, std::string const&, yb::StronglyTypedBool<yb::consensus::TEST_SuppressVoteRequest_Tag>) (yb/consensus/consensus.h:198)
    @     0x7f454ebe3f8b  yb::consensus::RaftConsensus::ReportFailureDetected(std::string const&, yb::Status const&) (yb/consensus/raft_consensus.cc:782)
    @     0x7f4549f245be  yb::Callback<void (std::string const&, yb::Status const&)>::Run(std::string const&, yb::Status const&) const (yb/gutil/callback.h:494)
    @     0x7f4549f245be  yb::TimedFailureDetector::CheckForFailures(yb::MonoTime const&) (yb/util/failure_detector.cc:131)
    @     0x7f4549f2302c  yb::RandomizedFailureMonitor::RunThread() (yb/util/failure_detector.cc:225)
    @     0x7f4549f970d5  std::function<void ()>::operator()() const (gcc/5.5.0/include/c++/5.5.0/functional:2267)
    @     0x7f4549f970d5  yb::Thread::SuperviseThread(void*) (yb/util/thread.cc:602)
    @     0x7f4546c7d693  start_thread (/tmp/glibc-20180109-1462-njgus6/glibc-2.23/nptl/pthread_create.c:333)
    @     0x7f45469bf3cc  (unknown) (../sysdeps/unix/sysv/linux/x86_64/clone.S:109)
    @ 0xffffffffffffffff 
    @     0x7f454ebd4788 yb::consensus::LeaderElection::LeaderElection()
    @     0x7f454ebf48a4 yb::consensus::RaftConsensus::DoStartElection()
    @     0x7f454ebe3f8c yb::consensus::RaftConsensus::ReportFailureDetected()
    @     0x7f4549f245bf yb::TimedFailureDetector::CheckForFailures()
    @     0x7f4549f2302d yb::RandomizedFailureMonitor::RunThread()
    @     0x7f4549f970d6 yb::Thread::SuperviseThread()
    @     0x7f4546c7d694 start_thread
    @     0x7f45469bf3cd __clone
    @                0x0 (unknown)

Version:

[root@8f69d3501259 yugabyte]# ./bin/yb-tserver --version
version 0.9.7.0 build 9 build_type RELEASE
@rkarthik007
Copy link
Collaborator

@ttyusupov - is this related to your recent fix? Do we just need to publish a new container?

@rkarthik007 rkarthik007 added the kind/bug This issue is a bug label Mar 21, 2018
@ttyusupov
Copy link
Contributor

ttyusupov commented Mar 21, 2018

Yes, looks like #97 which has been already fixed.

tvesely pushed a commit to tvesely/yugabyte-db that referenced this issue Feb 28, 2024
Currently, parallel hints on single relations cannot be enforced
properly without the GUCs related to parallelism to be reset first.
Perhaps there is not much of a use-case when it comes to that, but let's
add some regression tests to check this default behavior, as there was
nothing to check that in the existing test suite.

Per pull request yugabyte#112.

Backpatch-through: 10
jasonyb pushed a commit that referenced this issue Jun 11, 2024
devansh-ism pushed a commit to devansh-ism/yugabyte-db that referenced this issue Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug This issue is a bug
Projects
None yet
Development

No branches or pull requests

3 participants