Free audit

View Audit Scope

Intelligent Database Proxy

MariaDB MaxScale Services

Executive Direct Answer · MaxScale Intelligent Database Proxy

MariaDB MaxScale is an enterprise database proxy and firewall engineered for MariaDB and MySQL architectures. It provides Layer 7 intelligent query routing, automatic read/write splitting, transaction replay, connection pooling, and in-proxy SQL firewall security. With native topology detection for Galera Clusters and MariaDB replication, it protects against failover split-brain. JusDB provides MaxScale DBRE and configuration hardening, with incident response at agreed initial-response targets.

Architecture: Protocol-Aware L7 Proxy·Routing: Read/Write Split & Replay·Topology: Native Galera & Replication Mon·Security: In-Proxy SQL Firewall·Response targets: per agreement

Deploy MariaDB MaxScale for intelligent query routing, automatic failover, read/write splitting, and advanced query filtering — the enterprise-grade database proxy for mission-critical MariaDB deployments.

Smart Routing
Query-Level
Auto-Failover
Monitor-Driven
Switchover
Planned & Online

Comprehensive MariaDB MaxScale Services

From initial deployment to advanced optimization, we provide end-to-end MaxScale solutions for enterprise MariaDB environments.

MaxScale Deployment & Configuration

Complete MaxScale installation, configuration, and integration with your existing MariaDB infrastructure

  • MaxScale installation and hardening
  • Listener, router, and filter configuration
  • SSL/TLS encryption setup
  • maxscale.cnf optimization and tuning

Read/Write Splitting

Intelligent query routing that distributes reads across replicas while directing writes to the primary

  • ReadWriteSplit router configuration
  • Transaction-aware routing
  • Slave lag-based routing policies
  • Query hint support for routing overrides

Automatic Failover & Switchover

Failover orchestration with automatic primary promotion and replica reconfiguration

  • MariaDB Monitor auto_failover setup
  • GTID-based replica promotion
  • Cooperative monitoring (multi-MaxScale)
  • Planned switchover orchestration

Query Filtering & Firewall

Advanced query interception, transformation, and database firewall rules for security and compliance

  • Database firewall filter (dbfwfilter)
  • Query rewriting and transformation
  • Regex-based query blocking rules
  • Audit logging and query analytics

Connection Pooling & Management

Efficient connection multiplexing and pooling to reduce backend server load and improve throughput

  • Connection multiplexing configuration
  • Idle connection management
  • Max connection limits and queuing
  • Persistent connection optimization

Monitoring & Observability

Comprehensive MaxScale monitoring, metrics collection, and alerting for production environments

  • MaxScale REST API monitoring
  • Prometheus and Grafana integration
  • Query performance analytics
  • Router and failover health alerting

MaxScale Production Failure Modes

Critical proxy routing, replication lag, and Galera flow control failure scenarios analyzed and resolved by JusDB DBREs.

Critical P1

Read-After-Write Consistency Breakage Across Replicas

When applications execute an INSERT/UPDATE followed immediately by a SELECT within separate autocommit transactions, MaxScale's ReadWriteSplit router directs the read to a lagging replica, causing phantom read anomalies and user data discrepancies.

JusDB Engineering Mitigation

Enable causal_reads=true and enforce max_slave_replication_lag=2s inside the ReadWriteSplit service, forcing reads within causal sessions to route to the primary until replicas catch up.

High P2

Galera Flow Control Freezes & In-Proxy Connection Lockup

When a slow node triggers Galera flow control (FC_PAUSE), writes on all cluster members pause. MaxScale instances with uncalibrated client timeouts queue incoming connections until file descriptor limits are reached, cascading into proxy-wide timeouts.

JusDB Engineering Mitigation

Configure available_when_donor=false, tune wsrep_flow_control_limit on backend nodes, and calibrate MaxScale connection_timeout and query_timeout limits.

High P2

MaxCtrl REST API Quorum Loss & Stale Topology Routing

If network partitions isolate MaxScale from MariaDB monitors, maxscale retains stale backend topology metadata and may direct traffic to split-brain master nodes or severed Galera partitions.

JusDB Engineering Mitigation

Configure cooperative monitoring across dual MaxScale instances, integrate keepalived VIP failover, and set master_failure_timeout thresholds to automatically isolate degraded backends.

Production MaxScale Diagnostic Runbooks

Administrative commands executed via the maxctrl CLI to inspect backend server topology states, routing metrics, and Galera cluster health.

maxctrl Server Topology & Routing
maxctrl CLI · Live

Validates master/slave topology states, server weights, and active connection distribution across the ReadWriteSplit service.

# Inspect live backend server status, roles, and replication lag
maxctrl list servers

# Audit ReadWriteSplit router connection metrics and router state
maxctrl show service ReadWriteSplit-Service
Galera Monitor Health & Client Sessions
Cluster Diagnostics

Audits Galera cluster monitor consensus health and checks active client connection sessions and memory consumption.

# Inspect Galera cluster monitor status and node sync state
maxctrl show monitor Galera-Monitor

# Query active client sessions and connection pooling descriptors
maxctrl list sessions

MaxScale vs MySQL Router vs Alternatives

Compare MaxScale against alternative database proxies across critical evaluation vectors including routing intelligence, Galera awareness, and firewall security.

Evaluation VectorJusDB MaxScale DBREMySQL Router / Cloud LBIn-House Generalists
Intelligent Read/Write Splitting & RoutingReadWriteSplit routing with automatic transaction tracking, read-after-write session consistency, and replica lag throttlingStatic port routing or manual application datasource splitting with no transaction-boundary awarenessApplication dual-datasource code prone to reading stale replica state immediately following critical write commits
MariaDB Replication & Galera IntegrationNative MariaDB-Monitor and Galera-Monitor integration with automated master failover, cluster rejoin, and split-brain preventionGeneric TCP proxies unaware of Galera donor states or asynchronous replica replication statusCustom health check scripts failing to detect Galera flow control freezes or MariaDB semi-sync replication stalls
In-Proxy Security & Database FirewallBuilt-in SQL firewall filtering injection patterns, blocking unindexed DELETE/UPDATE queries, and enforcing user permission boundariesBasic network CIDR firewall rules without SQL syntax inspection or query payload validationVulnerable to accidental table-drop scripts or rogue batch queries executing directly against production clusters
Connection Multiplexing & Resource EfficiencyOptimized connection pooling with threadpool integration, reducing backend connection count and the database memory those connections useUnbounded 1:1 client-to-backend thread allocations leading to high context-switch overhead during traffic spikesMicroservices spawning uncontrolled connection pools that saturate MariaDB max_connections thresholds
MaxCtrl CLI & REST Runtime ControlRuntime reconfiguration via maxctrl CLI and REST API; live server swapping and parameter tuning without restartsStatic configuration files requiring service restarts that disconnect active application clientsManual configuration file edits across proxy servers with configuration drift and high operational risk
Monitoring & Incident ResponseContinuous MaxScale REST API metric harvesting into Prometheus, routing latency alerting, and senior DBREs on your incident bridge. Initial-response targets: 2 to 4 hours in covered business hours; 30 minutes for P1 incidents with 24x7 on-call. Targets, not resolution guarantees.Standard vendor ticketing queues with multi-hour turnaround times and lack of hands-on query tuning supportOperations teams struggling to debug MaxScale routing logs and filter configuration errors during critical downtime

Why Choose MariaDB MaxScale?

MaxScale provides intelligent, protocol-aware database proxying with built-in failover orchestration, query filtering, and connection management for enterprise MariaDB deployments.

Intelligent Query Routing

MaxScale parses every SQL statement at the protocol level, understanding query types, transaction boundaries, and prepared statements. It routes reads to replicas and writes to the primary with full transaction awareness, eliminating stale reads and ensuring data consistency.

Transparent Failover

When the primary server fails, MaxScale automatically detects the failure, promotes the most up-to-date replica, and reconfigures the remaining replicas — all transparently to the application with no connection string changes required.

Database Firewall

Protect your databases with query-level firewall rules that block dangerous operations like DROP TABLE or TRUNCATE, enforce time-based access controls, and prevent SQL injection patterns from reaching your backend servers.

Connection Multiplexing

MaxScale efficiently multiplexes thousands of client connections into a smaller pool of backend connections, reducing memory consumption and connection overhead on your MariaDB servers.

Supported Topologies

Primary/Replica Replication
Standard MariaDB master-slave replication with automatic read/write splitting and GTID-based failover.
MariaDB Galera Cluster
Multi-primary synchronous cluster with Galera monitor integration, node weight routing, and donor node avoidance.
Multi-Source Replication
Aggregate data from multiple MariaDB sources with schema-based routing and conflict avoidance.
Cross-DC Replication
BinlogRouter proxy for efficient cross-datacenter replication with bandwidth optimization and compression.

MaxScale Router Types

MaxScale offers specialized routers for different use cases, each designed to handle specific traffic patterns and replication topologies.

Most Common

ReadWriteSplit

Statement-based read/write routing

Routes writes to the primary server
Distributes reads across replicas
Full transaction awareness
Prepared statement support
Causal reads with GTID tracking
Slave lag-based routing policies
Query hints for routing overrides
Session state tracking
Best for: Read-heavy workloads, web applications

Connection-Level

ReadConnRoute

Connection-based load balancing

Routes entire connections to one server
Round-robin load balancing
Adaptive routing by server load
Primary-only or replica-only modes
Simple and lightweight
No query parsing overhead
Ideal for single-server workloads
Connection affinity support
Best for: Simple load balancing, batch jobs

Replication Proxy

BinlogRouter

Binlog replication distribution

Acts as intermediate replication relay
Reduces primary replication overhead
Fan-out replication topology
Centralized binlog distribution
Cross-datacenter replication proxy
Binlog event filtering
GTID-based replication support
Semi-synchronous replication compatible
Best for: Large replica fleets, multi-DC replication

Our MaxScale Implementation Process

A tested methodology for deploying production-ready MariaDB MaxScale with comprehensive testing and validation.

1

Assessment & Planning

Analyze your MariaDB topology, query patterns, and traffic volume. Design the MaxScale configuration including router selection, filter pipeline, and failover strategy.

2

Deployment & Configuration

Install MaxScale, configure listeners, routers, filters, and monitors. Set up SSL/TLS, authentication, and connection parameters for your backend servers.

3

Testing & Validation

Validate read/write splitting accuracy, test failover scenarios, benchmark throughput and latency, and verify query firewall rules under realistic traffic conditions.

4

Production & Monitoring

Cut over production traffic to MaxScale with monitoring dashboards, alerting rules, and runbooks, plus team handover and operational training.

MariaDB MaxScale — Frequently Asked Questions

Common questions about MaxScale deployment, configuration, and management.

MariaDB MaxScale is an intelligent database proxy that sits between your application and MariaDB servers. It intercepts database traffic and routes queries based on configurable rules — sending reads to replicas and writes to the primary, handling automatic failover, filtering queries, and managing connection pools. MaxScale understands the MariaDB protocol at a deep level, enabling it to make smart routing decisions transparently without any application changes.

MaxScale's ReadWriteSplit router automatically analyzes each incoming query to determine whether it is a read or write operation. Writes (INSERT, UPDATE, DELETE, DDL) are routed to the primary server, while reads (SELECT) are distributed across available replicas. It handles transaction awareness, ensuring all queries within a transaction go to the same server, and supports hints for forcing specific routing behavior when needed.

MaxScale's MariaDB Monitor continuously health-checks all backend servers. When it detects the primary has failed, it can automatically promote the most up-to-date replica to become the new primary (auto_failover). This process includes reconfiguring replication on remaining replicas to follow the new primary. The failover is transparent to applications — they continue connecting to MaxScale without interruption or reconfiguration.

Yes, MaxScale includes a Database Firewall filter (dbfwfilter) that can block or allow queries based on configurable rules. You can create rules based on query type (block all DROP/TRUNCATE), time of day, regex patterns, user permissions, and query complexity. This provides an additional security layer between your application and database, preventing accidental or malicious destructive operations.

MaxScale is purpose-built for MariaDB and understands its protocol natively, including MariaDB-specific features like GTID and parallel replication. Unlike HAProxy (which operates at TCP level), MaxScale parses SQL and makes query-level routing decisions. Compared to ProxySQL, MaxScale offers deeper MariaDB integration, built-in failover orchestration, a richer filter pipeline, and the BinlogRouter for binlog-level replication proxying. MaxScale is the officially supported proxy from the MariaDB ecosystem.

The BinlogRouter allows MaxScale to act as an intermediate replication proxy. It connects to the primary as a replica, receives binlog events, and then serves those events to downstream replicas. This reduces the load on the primary (which only needs one replication connection to MaxScale instead of many), provides a centralized point for binlog distribution, and enables advanced topologies like fan-out replication across data centers.

Ready to Deploy Intelligent Database Proxying?

Let our experts implement MariaDB MaxScale for your enterprise databases with smart routing, automatic failover, and online switchovers.

Pair MaxScale with our MariaDB security audit to harden your proxy and listeners, ongoing remote DBA administration, and incident support with agreed response targets.

Explore all MariaDB services

Need a different MariaDB service? Browse our complete offerings.