Skip to content

Orchestrator Integration#1626

Merged
enisoc merged 7 commits into
vitessio:masterfrom
enisoc:orchestrator
Jun 6, 2016
Merged

Orchestrator Integration#1626
enisoc merged 7 commits into
vitessio:masterfrom
enisoc:orchestrator

Conversation

@enisoc
Copy link
Copy Markdown
Contributor

@enisoc enisoc commented Apr 7, 2016

This change is Reviewable

@alainjobart
Copy link
Copy Markdown
Contributor

LGTM

Approved with PullApprove

@enisoc enisoc force-pushed the orchestrator branch 2 times, most recently from f150afa to 7157b9b Compare April 29, 2016 01:08
@enisoc enisoc force-pushed the orchestrator branch 3 times, most recently from ae7084f to 3397cbc Compare May 30, 2016 03:12
@enisoc enisoc changed the title [WIP] Orchestrator Integration Orchestrator Integration Jun 2, 2016
@enisoc
Copy link
Copy Markdown
Contributor Author

enisoc commented Jun 2, 2016

@alainjobart PTAL. The main integration features are there now. What's left is to write documentation, and incorporate it into the local example as well. I can do that after the code freeze.

@alainjobart
Copy link
Copy Markdown
Contributor

alainjobart commented Jun 2, 2016

:lgtm: cool stuff

Previously, enisoc (Anthony Yeh) wrote…

@alainjobart PTAL. The main integration features are there now. What's left is to write documentation, and incorporate it into the local example as well. I can do that after the code freeze.


Reviewed 3 of 4 files at r1, 13 of 13 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

Approved with PullApprove

@enisoc enisoc added this to the v2.0 milestone Jun 6, 2016
Anthony Yeh added 6 commits June 6, 2016 14:16
This can be used to propagate Vitess identity info to tools that work at
the MySQL level.
For now, it is a single instance. Later, I plan to connect multiple
nodes, each containing its own Orchestrator+Galera.
This clears out the connection parameters in addition to the replication
position.
If a tablet finishes restoring and finds that it's supposed to be the
master, it should not try to replicate from itself. Instead, we'll wait
for the operator to elect a new master, because it's not clear how we
ended up in this situation.
This prevents the operator from having to manually tell Orchestrator to
discover new shards. It also makes a number of scenarios self-healing --
for example, if the Orchestrator backing database is lost, it will
automatically repopulate over time.
When Vitess stops replication on purpose (e.g. for vtworker batch
processes), we now take a maintenance lock on it. This tells
Orchestrator not to reparent the instance or restart replication on it.
@enisoc enisoc merged commit 1129d69 into vitessio:master Jun 6, 2016
@enisoc enisoc deleted the orchestrator branch June 6, 2016 21:30
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.

3 participants