Mixer: A MySQL proxy that is implemented with go

This is a creation in Article, where the information may have evolved or changed.

Introduced

Mixer is a MySQL proxy with go, which supports the basic MySQL agent function.

MySQL middleware many, for the existing powerful proxy on the market, I mainly examined the following several:

• Mysql-proxy,mysql's official agent, which is not friendly to use, requires LUA customization, and I have doubts about its stability and performance.
• Cobar, Ali of the things, quality did not say, but for our project, a little overkill feeling, in addition we will not Java.
• Atlas,360 's Mysql-proxy-based enhanced version, which has almost rewritten the core framework with C, has nothing to say about performance and stability.

Of course, there are a lot of strong proxies, I can not one by one involved, and at this stage of our project is using the atlas (this is not counted to the Atlas hit an ad?). ）。

Since there are so many proxies, why do I want to implement one myself? Perhaps the main reason is the interest.

MySQL Feature support

When I started the mixer development, I knew that mixer was not MySQL, it could not proxy all MySQL functions. So, I decided that mixer only supports the following MySQL commands:

• Com_query
  • Select, insert, UPDATE, delete, replace
  • Set autocommit
  • Set names
  • Begin, Commit, rollback
• Com_ping
• com_init_db
• Com_stmt_prepare, Com_stmt_exec etc com_stmt_* command, only support PREPARE of com_query command above

[Mixer] (Https://github.com/siddontang/mixer does not support a lot of commands, list some:

• Set variable. If supported, mixer needs to maintain the state of each variable, adding complexity. However, mixer supports settings for autocommit and names.
• Prepare statement for SQL text mode.
• Show command.
• Stored procedures.

Although very versatile at this stage, no follow-up support is excluded.

Highly Available scenarios

Mixer provides a set of MySQL high-availability scenarios at this stage, with the following main features:

• Read-write separation, send select to Slave, rest send to master execution, everything in master executes. At this stage, only one master and one standby is supported.
• Master and Standby automatic switch, when the primary MySQL is not available, according to the relevant rules to switch to backup MySQL execution.

Todo

Mixer is not perfect, many functions need to be implemented, follow-up priority needs to realize the function:

• Parser, syntax parsing SQL, building AST, at the proxy level to prevent some of the MySQL hidden dangers, such as injection attacks, delete no where and so on.
• A custom route that routes SQL to different MySQL executions according to routing rules. For example, a hash of the SELECT statement is performed on a different slave based on the primary key.
• Statistical functions.

The code https://github.com/siddontang/mixer here. It is very hoped that the children's shoes interested in proxy will be involved in the improvement of mixer, making it another MySQL middleware solution.