Orchestrator visual cheatsheet, TL;DR the “smart” way

Orchestrator is really growing. And the amount of users (DBAs, sys admins) using it is growing. Which gives me a lot of immediate feedback in the form of “Look, there’s just too many options to move slaves around! Which ones should we use?”

TL;DR look at the two visualized commands below

They are enough

The “smart” commands to end all commands

So all relocation commands are important, and give you fine-grained, pin-pointed control of the method of topology refactoring. However, most of the time you just want to move those servers around. Which is why there’s a new “smart” mode which support these two commands, which you should be happy using:

relocate: move a single slave to another position
relocate-slaves: move all/some slaves of some server to another position.

What makes these commands Smart? You can move slaves around from anywhere to anywhere. And orchestrator figures out the bast execution path. If possible, it uses GTID. Not possible? Is Pseudo-GTID available? Great, using Pseudo-GTID. Oh, are there binlog servers involved? Really simple, use them. None of the above? Orchestrator will use “standard” binlog file:pos math (with limitations). Orchestrator will even figure out if multiple steps are necessary and will combine any of the above.

So you don’t have to remember all the possible ways and options. The visual cheatsheet now boils down to these two:

Let’s take a slightly deeper look

relocate

Moves a single slave X from any point to replicate another some server Z

As usual, orchestrator first confirms that X can replicate from Z (Z has log-slave-updates or is a binlog server; binlog format compatible, etc.)
With GTID/Pseudo-GTID, move from any point to any point
With binlog servers, move around the binlog server environment (at this point you are not using binlog servers, so ignore)
With normal replication, requires an “atomic” operation: either move the slave one level up, or make it replicate from a sibling.
You can relocate the same master, effectively repointing the slave back to its existing position. This serves to re-resolve master hostname; to reset relay logs; to verify slave is aligned with master.
Or combination of the above

relocate-slaves

Moves multiple slaves of server X to replicate from some other server W

By default moves all slaves of X, where possible
Each slave verified to be able to replicate from W. Those that can’t are left behind.
Can filter using regular expression via –pattern=some?[reg]ex on slave hostnames
Can relocate under same master, effectively repointing all slaves (see above explanation)
Can relocate below one of the very slaves of X. If Y is in itself a slave of X and you’re executing:
orchestrator -c relocate-slaves -i X -d Y
then Y is excluded from the list of relocated slaves. This effectively means “make Y local master of its current siblings”. Very cool stuff.
When binlog servers involved, simple math-less repointing takes place
When GTID involved, let MySQL/MariaDB (both supported) do the math on a per-server basis
When Pseudo-GTID involved, greatly optimize by dividing into equivalence classes and only doing the math on a representative of each class.
Or combination of the above

What about the other commands?

The above covers such commands as move-up, move-below, repoint, repoint-slaves, match-below, multi-match-slaves, regroup-slaves and more. It does not cover enslave-master and make-co-master which are a bit different.

My guess is you can pass 98% of your operations with relocate and relocate-slaves. Otherwise just run orchestrator with no arguments nor options to get a full-blown breakdown of available commands.