Our Shared Edition architecture is built on a "shared everything" model, which allows us to offer our Shared Edition starter workspaces. While incredibly cost-effective, relying on a single SingleStore cluster posed a resiliency risk—a single point of failure. This led us to explore solutions for powering Shared Edition with multiple SingleStore clusters behind the scenes.
Integrating the traditional MySQL protocol into a modern, multi-cluster serverless architecture introduced significant complexity. We needed a solution capable of intelligently routing connections without compromising the client experience.
This technical deep dive explains how our custom SharedMysqlProxy was built to intercept the MySQL handshake, extract crucial routing information early, and seamlessly transfer the connection state across a multi-cluster environment.
The MySQL Protocol Paradox: Routing Blind
The fundamental challenge in routing lies in the "server-first" nature of the MySQL protocol. When a client initiates a connection, it waits for the database server to send the Initial Handshake Packet.
Crucially, the information required for intelligent routing—the target database name and username—is not available immediately. This essential data is contained in the Handshake Response Packet, which the client sends after receiving the server's initial packet, and often following any necessary SSL exchange. To route a client to the correct SingleStore cluster, our proxy needed to acquire this database name much earlier in the flow.
The Serverless MySQL Proxy Solution: State Interception
To overcome this inherent delay, we engineered the SharedMysqlProxy to temporarily assume the identity of the target database server.
Handshake Generation
Upon a client connection, the SharedMysqlProxy immediately generates a "fake hello packet"—the Initial Handshake Packet—and sends it back to the client. This packet must be structurally valid and include a unique ConnectionId (uint32) and AuthPluginData (a scramble).
A simplified view of the required packet structure:
1type InitialHandshakePacket struct {2 // ... fields omitted for brevity ...3 ConnectionId uint324 AuthPluginData []byte // Scramble5 // ...6}
Data Extraction
After receiving the proxy's initial packet (and handling any SSL requests), the client transmits the Handshake Response Packet. The proxy intercepts this packet, successfully extracting the database name needed for intelligent, multi-cluster routing.
Seamless Hand-off with PPv2
Once the destination cluster is identified, the proxy must transfer the context of the half-completed handshake to the SingleStore engine instance so that the engine can complete the authentication process.
This is achieved using Proxy Protocol version 2 (PPv2):
- The proxy connects to a new, dedicated port exposed on the engine specifically for this hand-off.
- The proxy sends a PPv2 packet containing the Connection ID and the scramble generated earlier.
- The target cluster accepts this state, effectively inheriting the proxy's role. The proxy then proceeds to forward the client’s subsequent SSL packets and connection data directly to the cluster, completing the proxy connection.
.png?width=1024&disable=upscale&auto=webp)
This protocol interception capability is the foundation for supporting multiple SingleStore clusters powering Shared Edition and dramatically improving resiliency. By intercepting the necessary information early, the SharedMysqlProxy can determine the correct target cluster efficiently, prioritizing speed and availability.
_feature.png?height=187&disable=upscale&auto=webp)
