1
The original repository is archived
Version provenance, downstream packaging, patches, dependencies, image ownership, and upgrade plans must be treated as production risks.
Existing-estate reliability and modernization
Operate MySQL Orchestrator with lifecycle visibility
MySQL Orchestrator for existing async replication estates: topology discovery, recovery-policy review, security, failure tests, and modernization.
In short: Orchestrator discovers MySQL asynchronous-replication topologies and can execute policy-driven recovery. The original openark/orchestrator repository was archived on 18 February 2025 and is read-only. Existing estates therefore need an explicit distribution, patch, security, ownership, and exit decision—not an assumption that upstream maintenance continues unchanged.
2
Recovery is policy-driven
Candidate rules, lag, data-center constraints, hooks, acknowledgements, downtime detection, and recovery exclusions determine what automation does.
3
Async replication can lose writes
A promoted replica may not contain every transaction acknowledged by the failed source. Recovery objectives must reflect that failure mode.
DBRE engagement scope
Engineering work tied to evidence
Recommendations are based on the deployed version, topology, workload, failure model, and operational constraints—not a generic feature checklist.
Estate and version review
Inventory binaries or images, provenance, forks, dependencies, backend database, Raft or single-node mode, configuration, and patch exposure.
Recovery policy analysis
Review candidate rules, lag and errant transactions, data-center constraints, hooks, acknowledgements, suppression, and manual controls.
Security hardening
Assess topology credentials, web and API exposure, authentication, TLS or proxy controls, filesystem permissions, secrets, and auditability.
Modernization decision
Define whether to retain with owned packaging, use a supported downstream integration, or migrate to another recovery architecture.
Evidence we examine
- Exact Orchestrator build, source or image provenance, release history, dependencies, operating system, deployment model, and ownership.
- Discovery configuration, credentials, topology data, recovery and candidate rules, hooks, acknowledgements, audit log, and suppressed recoveries.
- MySQL replication mode, GTID state, lag, errant transactions, relay-log health, durability settings, network partitions, and failure domains.
- Past recoveries, promotion evidence, transaction-loss exposure, application endpoint changes, backup and restore state, and current exit plan.
Important boundaries
- JusDB does not describe the archived upstream project as actively maintained. The selected build or downstream distribution must have a named owner and lifecycle decision.
- Orchestrator does not make asynchronous replication lossless. Candidate freshness, durability, semi-synchronous behavior, and failure timing determine the possible data gap.
- Automatic recovery is not inherently safer than controlled recovery. False positives, network partitions, stale candidates, hooks, endpoint updates, and split-brain controls require testing.
- Topology visualization is not a complete availability system. Clients, proxies or DNS, fencing, backups, monitoring, security, and human escalation remain separate dependencies.
Delivery method
From discovery to tested handover
- 01
Inventory
Establish the exact software lineage, deployment, topology, configuration, credentials, integrations, ownership, and business dependency.
- 02
Threat-model
Analyze stale or unsafe promotion, split brain, false detection, credential exposure, archived dependencies, and operational lock-in.
- 03
Exercise
Run controlled discovery and recovery scenarios with transaction, topology, endpoint, fencing, application, and rollback evidence.
- 04
Decide
Document retain, repackage, integrate, or replace options with risk, effort, support, cutover, and decommission criteria.
Technical review and primary sources
Orchestrator guidance reflects the archived upstream lifecycle
Review scope: Repository status, topology discovery, recovery policy, asynchronous replication risk, security, downstream use, failure testing, ownership, and modernization options. Recommendations, recovery targets, service levels, and outcomes remain configuration-, workload-, and contract-specific.
Review owner: JusDB Database Reliability Engineering team. Last reviewed: .
- openark/orchestrator repository
Primary upstream repository, visibly archived and read-only since 18 February 2025.
- Topology recovery documentation
Upstream recovery concepts, candidate selection, hooks, acknowledgements, and failure handling.
- Percona Operator architecture
A current downstream integration illustrating Orchestrator use and async-replication loss boundaries.
Common questions
What teams ask before engaging
Is the original MySQL Orchestrator project still maintained?
The original openark/orchestrator GitHub repository was archived by its owner on 18 February 2025 and is read-only. Some products and downstream projects still integrate Orchestrator, but that does not make every binary or image equivalent. Confirm the exact source, maintainer, patch process, compatibility, and support boundary.
What does Orchestrator do during MySQL failover?
Orchestrator detects topology problems and can run a configured recovery that selects a candidate, promotes it, and repoints replicas or invokes hooks. The behavior depends on discovery state, recovery rules, candidate eligibility, replication health, topology constraints, acknowledgements, and external endpoint or fencing automation.
Can Orchestrator guarantee no data loss?
No. In an asynchronous topology, a replica can be behind the failed source, so a promoted candidate may lack acknowledged transactions. Semi-synchronous settings can reduce some exposure but do not replace failure-specific analysis, transaction comparison, backups, or a defined recovery objective.
Should a new MySQL deployment adopt Orchestrator?
That requires a lifecycle decision, not a generic yes. Review the MySQL topology, recovery requirements, available maintained integrations, operational skills, security expectations, and exit cost. For new designs, compare native InnoDB Cluster and current supported operator or platform patterns before accepting archived-upstream ownership.
How is Orchestrator secured?
The service holds MySQL discovery credentials and exposes web or API capabilities, so network isolation, authentication, TLS termination or trusted proxy design, least-privilege database access, secret storage, filesystem permissions, audit logging, and administrative change controls are important. Controls depend on the chosen build and deployment.
What does an Orchestrator modernization assessment deliver?
The assessment can deliver a software bill of materials, topology and recovery map, security findings, transaction-loss analysis, failure-test evidence, current-state runbooks, and retain-versus-replace options with migration and decommission criteria. The recommendation is based on the actual estate, not tool popularity.
Related MySQL reliability work
MySQL High Availability
Compare topology, routing, failure, consistency, fencing, and recovery designs without tool lock-in.
Review serviceMySQL InnoDB Cluster
Assess native Group Replication, AdminAPI, Router, consistency, and failure testing for current MySQL estates.
Review serviceMySQL Migration
Plan compatibility, rehearsal, validation, cutover, recovery, and decommissioning for topology changes.
Review serviceMake the Orchestrator ownership decision explicit
Bring the build provenance, configuration, topology, a recent recovery trace, and current support model. We will separate immediate reliability risks from the longer-term retain or replace decision.
Scope the engagement