explaingit

openark/orchestrator

5,762GoAudience · ops devopsComplexity · 4/5LicenseSetup · hard

TLDR

Orchestrator is an open-source MySQL replication topology manager that maps, visualizes, and automatically recovers replication setups. It detects primary failures and promotes a replica to primary, with a web UI, CLI, and HTTP API for automation.

Mindmap

mindmap
  root((repo))
    Topology Management
      Auto discovery
      Visual web UI
      HTTP API
    Failure Recovery
      Primary failure detection
      Replica promotion
      Multi-datacenter awareness
    Replication Modes
      Standard replication
      GTID replication
      Binlog servers
    Operations
      Command-line tool
      Automation hooks
      Alerting
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Automatically detect and recover from MySQL primary server failures by promoting a healthy replica

USE CASE 2

Visualize and audit the current MySQL replication topology across all servers and datacenters

USE CASE 3

Reorganize replication relationships between servers without manual SQL commands

USE CASE 4

Integrate replication failover into automation pipelines via the HTTP API or CLI

Tech stack

GoMySQLHTTP APIWeb UISQL

Getting it running

Difficulty · hard Time to first run · 1day+

Requires a running MySQL replication setup. Orchestrator itself is a Go binary with a config file. Active development has moved to the Percona fork, use that for new deployments.

Apache 2.0, free to use, modify, and distribute, including commercially. Just retain the license notice.

In plain English

Orchestrator is a tool for managing MySQL database replication setups, particularly in situations where high availability matters. MySQL replication is a system where one primary database server continuously copies its data to one or more secondary servers, so the secondaries can take over if the primary fails. Orchestrator sits on top of that setup and helps operators understand, reorganize, and recover from failures in it. The tool runs as a background service and continuously maps the current state of the replication topology, meaning it tracks which servers are replicating from which. It provides a web interface with a visual diagram of this topology, making it easier to see the relationships between servers and spot problems. The same functionality is also available through a command-line tool and an HTTP API for automation. When something goes wrong, such as the primary server going down, Orchestrator can detect the failure automatically and either alert the operator or attempt recovery on its own. Recovery involves promoting one of the secondary servers to become the new primary and updating the other secondaries to replicate from it. The tool understands several different replication modes that MySQL supports, so it can handle the restructuring correctly across different configurations. It also tracks which data center each server is in, which helps when deciding how to redistribute replication responsibilities across physical locations. Orchestrator was originally developed at Outbrain in 2014, then maintained at GitHub from 2016 to 2020, and later moved to an open-source organization. The repository at this location has since been archived. Active maintenance has moved to a fork maintained by Percona, and the README directs contributors there. The project is licensed under Apache 2.0.

Copy-paste prompts

Prompt 1
I have an Orchestrator deployment managing MySQL replication. Walk me through how to configure automatic failover so that when the primary goes down, a replica is promoted without manual intervention.
Prompt 2
Using the Orchestrator HTTP API, how do I query the current replication topology and programmatically trigger a master failover for a given cluster?
Prompt 3
I'm setting up Orchestrator with GTID-based MySQL replication. What configuration options do I need to set in orchestrator.conf.json to ensure correct topology discovery and recovery?
Prompt 4
How do I configure Orchestrator to be aware of multiple datacentors so that it prefers promoting a replica in the same datacenter as the failed primary?
Prompt 5
What hooks does Orchestrator provide to run custom scripts before and after a failover event, and how do I wire them up?
Open on GitHub → Explain another repo

← openark on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.