How Gaea Reinvents MySQL Middleware with Go‑Based Sharding and Hot‑Reload

Background

Many MySQL middlewares exist (MyCAT, Atlas, Sharding‑Sphere, Kingshard, Vitess). Xiaomi’s internal services used a heavily modified MyCAT 1.6 for sharding and read‑write splitting, but the codebase became hard to maintain, lacked monitoring metrics, and required DBA command‑line configuration changes.

Gaea Overview

Gaea is a Go‑implemented MySQL middleware compatible with MyCAT core features, providing read‑write splitting and sharding. It consists of three components: Gaea Proxy (MySQL protocol endpoint), Gaea CC (central control service for configuration distribution), and Gaea Web (visual console that talks to CC). Configuration data is stored in etcd and shared by Proxy and CC.

Core Concepts

Namespace : logical business unit; the basic partitioning scope.

User : MySQL‑like credential; a username/password uniquely identifies a namespace and can be read‑only or read‑write.

Slice : a group of MySQL instances containing one primary and zero‑to‑many replicas; multiple slices in a namespace enable sharding.

Key Features

Full support for most SQL on non‑sharded tables.

Sharded tables are routed using MySQL or Kingshard routing rules.

Aggregations (MAX, MIN, SUM, COUNT, GROUP BY, ORDER BY) are supported.

Multi‑slice joins are allowed when routing rules match; cross‑database joins are not supported.

Quick Start

Build : Clone the repository, ensure Go 1.12+ is installed, then run make to download dependencies and compile the gaea binary.

Configuration : Provide a Proxy config file (ports, logs, namespace handling) and a namespace config (users, DB instances). In production namespaces are stored in etcd; for single‑node testing a file‑based config is also accepted.

Run Proxy : bin/gaea -config=etc/gaea.ini. The default listening port is 13306.

Execute Queries : Connect with any MySQL client using the namespace credentials. Non‑sharded queries work out‑of‑the‑box; DML on sharded tables is supported, while DDL on sharded tables is rejected.

Monitoring : Gaea exports Prometheus metrics (QPS, latency, slow/erroneous SQL, CPU, memory, goroutine count, GC time). A reverse‑lookup feature maps SQL MD5 hashes to the original statements.

Implementation Details

Architecture

Request flow: MySQL protocol parsing → session management → SQL parsing (TiDB parser) → routing decision → query rewrite (if sharded) → execution via pooled backend connections → result aggregation → MySQL protocol response.

Network Protocol

Gaea implements both the MySQL text protocol (inspired by Kingshard) and the binary prepared‑statement protocol according to MySQL specifications.

SQL Parsing

The TiDB parser is used for its robust compatibility and AST manipulation. The AST’s Restore() method enables query rewriting for sharded tables.

Connection Management

Client sessions expire after one hour of inactivity, managed by a time‑wheel. Backend connections are pooled with configurable limits (max connections, idle timeout). The pool performs automatic failover from replicas to the primary and supports load‑balanced reads from replicas.

Hot Configuration Reload

Namespace changes are hot‑loaded in three stages: (1) modify etcd, (2) send a prepare request to all proxies to load the new config, (3) commit. Proxies switch to the new namespace without locking and retire the old namespace after a one‑minute grace period to allow in‑flight queries to finish.

Performance

Internal sysbench tests show approximately a 20 % QPS improvement over MyCAT for point queries after protocol‑level and execution‑layer optimizations.

Future Work

Planned enhancements include transaction tracing, distributed transaction support, an open‑source Gaea Web UI, and a Gaea Agent for automated MySQL instance management and shard scaling.

Open‑Source Repository

Project source: https://github.com/XiaoMi/Gaea