1
Routing behavior is configured
Role-based ports and read/write splitting are distinct patterns. The correct choice depends on Router version, application behavior, and consistency needs.
MySQL Database Reliability Engineering
MySQL Router as a tested connection layer
MySQL Router consulting and remote DBA services for InnoDB Cluster routing, read/write splitting, bootstrap, TLS, redundancy, and failover testing.
In short: MySQL Router is lightweight middleware that uses InnoDB Cluster metadata to route application connections to suitable MySQL members. It can provide role-based endpoints, and current Router 8.4 releases also support a read/write-splitting route with documented statement rules. Router redirects new connections; applications still own safe reconnect and retry behavior.
2
Router needs its own redundancy
A highly available database behind a single Router host still has a connection-layer single point of failure.
3
Failover breaks sessions
Topology awareness helps route subsequent connections, but an interrupted transaction or session must be handled safely by the client.
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.
Routing policy
Select role-based endpoints, read-only distribution, read/write splitting, fallback behavior, destination strategy, and consistency boundaries.
Resilient deployment
Design multiple Router instances, service discovery or load balancing, metadata access, process supervision, capacity, and upgrade flow.
Security and TLS
Review client and server TLS modes, certificates, metadata credentials, REST exposure, filesystem permissions, secrets, and patch state.
Connection-path testing
Exercise primary change, member loss, metadata unavailability, Router restart, pool behavior, timeouts, retries, and transaction replay safety.
Evidence we examine
- Router and MySQL versions, bootstrap state, generated and custom configuration, routing sections, metadata-cache state, and logs.
- Application endpoints, connection pools, session assumptions, transaction patterns, read-after-write requirements, retries, and timeouts.
- Router host or Pod placement, load balancers, DNS, health checks, TLS chain, process supervision, resource limits, and upgrade process.
- InnoDB Cluster status, member roles, primary-election traces, connection errors, latency, saturation, and failure-test results.
Important boundaries
- MySQL Router is not itself a database quorum or backup system; it reflects topology and routes connections according to configured policy.
- Read/write splitting is version- and configuration-specific. Statement classification has documented rules and unsupported cases that must be tested against the application.
- Router cannot make an interrupted transaction safe to replay. Idempotency, commit uncertainty, session state, and retry policy belong in end-to-end testing.
- No uptime or failover-time promise follows from installing Router. Redundancy, health checks, capacity, clients, networking, and operations determine the observed result.
Delivery method
From discovery to tested handover
- 01
Trace
Map applications, endpoints, pools, Router instances, load balancers, metadata access, cluster roles, and failure dependencies.
- 02
Specify
Define routing semantics, read consistency, TLS, redundancy, health checks, timeouts, retries, observability, and upgrade controls.
- 03
Test
Validate representative statements and run connection-path failures with application-visible success, error, and recovery evidence.
- 04
Operationalize
Deliver configuration, monitoring, alerts, dashboards, deployment automation, failure runbooks, and responsibility boundaries.
Technical review and primary sources
Router guidance checked against current MySQL documentation
Review scope: InnoDB Cluster metadata routing, role-based endpoints, read/write splitting, statement behavior, application considerations, TLS, redundancy, upgrades, and recovery testing. Recommendations, recovery targets, service levels, and outcomes remain configuration-, workload-, and contract-specific.
Review owner: JusDB Database Reliability Engineering team. Last reviewed: .
- MySQL Router 8.4
Official Router architecture, deployment, configuration, connection routing, TLS, REST, and lifecycle reference.
- Read/write splitting
Configuration and operating behavior for Router's current read/write-splitting route.
- Statement rules
Documented statement classification, transaction, locking, function, and unsupported-case boundaries.
Common questions
What teams ask before engaging
What does MySQL Router do for InnoDB Cluster?
Router reads InnoDB Cluster metadata and opens configured routing endpoints for appropriate member roles. It helps applications avoid hard-coding a specific server and can update destinations as cluster membership changes. It does not replace Group Replication, backups, application retries, or a redundant network entry point.
Does MySQL Router automatically split reads and writes?
Not in every configuration. Traditional bootstrapped Router deployments expose separate read-write and read-only endpoints. MySQL Router 8.4 also documents a read/write-splitting route that classifies supported statements, but teams must enable and validate it against transactions, session state, functions, locking reads, and consistency requirements.
Will Router reconnect an existing session after failover?
No. Router can direct a new connection based on current topology, but an existing connection can fail when its server becomes unavailable. The application or pool must reconnect, and it must resolve whether an interrupted transaction is safe to retry.
How many MySQL Router instances are needed?
There is no universal count. The design should avoid a shared failure domain and consider application placement, host or zone loss, deployment method, load balancer behavior, connection volume, maintenance, and capacity. Multiple Router processes alone are insufficient if every endpoint depends on the same host or network path.
Can MySQL Router be upgraded without application downtime?
A rolling Router upgrade can reduce interruption when multiple healthy instances sit behind a tested connection-distribution layer, but the outcome depends on draining, health checks, process startup, configuration compatibility, client pooling, and available capacity. The procedure should be rehearsed with the deployed versions.
What does a Router DBRE assessment deliver?
Deliverables can include a connection-path diagram, routing and consistency decision record, configuration review, security findings, redundancy plan, workload and failure-test results, monitoring recommendations, upgrade procedure, and application retry actions. Scope and ownership are agreed before changes begin.
Related MySQL reliability work
MySQL InnoDB Cluster
Group Replication, quorum, consistency, Router integration, lifecycle, and failure testing.
Review serviceMySQL High Availability
End-to-end availability design across database, routing, application, network, and recovery layers.
Review serviceMySQL Performance Tuning
Evidence-led query, connection, concurrency, resource, and configuration analysis.
Review serviceTest the connection path, not just the cluster
Share the Router configuration, topology, application pool behavior, and a recent failover trace. We will map the actual recovery path and identify gaps between member election and successful application traffic.
Scope the engagement