Recently a colleague of mine ask me to provide a simple example on how ProxySQL can perform sharding.
ProxySQL is a very powerful platform that allow us to manipulate and manage our connections and query in a simple but effective way.
In this article I will show you how.
Before starting is better to clarify some basic concepts.
ProxySQL organize its internal set of servers in Host Groups (HG), each HG can be associate to users and to Query Rules (QR).
Each QR can be final (apply = 1) or can let ProxySQL continue to parse other QR.
A QR can be a rewrite action, or can be a simple match, it can have a specific target HG, or be generic, finally QR are defined using regex.
You can see QR as a sequence of filters and transformation that you can arrange as you like.
These simple basic rules give us enormous flexibility, and allow us to create very simple actions, like a simple query re-write or very complex chains that could see dozens of QR concatenated.
Documentation can be found here
The information related to HG or QR is easily accessible using the the ProxySQL administrator interface, in the tables mysql_servers, mysql_query_rules and stats.stats_mysql_query_rules; the last one allow us to evaluate if and how the rule(s) is used.
About sharding, what ProxySQL can do for us to achieve what we need in a (relatively easy) way?
Some people/company include sharding logic in the application, and use multiple connection to reach the different targets, or have some logic to split the load across several schemas/tables.
ProxySQL allow us to simplify the way connectivity and query distribution is suppose to work reading data in the query or accepting HINTS.
No matter which kind of requirements the sharding exercise can be summarize in few different categories.
- By split the data inside the same container (like having a shard by State where each State is a schema)
- By physical data location (this can have multiple mysql servers in the same room, as well as having them geographically distributed)
- Combination of the two, where I do split by state using a server dedicated and again split by schema/table by whatever (say by gender)
In the following examples I will show how to use ProxySQL to cover the three different scenario defined above and a bit more.
The example below will report text from the Admin ProxySQL interface and from MySQL console.I will mark each one as follow:
- Mc for MySQL console
- Pa for ProxySQL Admin
Please note that mysql console MUST use the -c flag to pass the comments in the query. This because the default behaviour, in mysql console, is to remove the comments.
I am going to illustrate procedures that you can replicate on your laptop.
This because I want you to test directly the ProxySQL functionalities.
For the example describe below I have used PrxySQL v1.2.2 that is going to become the master in few days.
You can download it from :
- git clone https://github.com/sysown/proxysql.git
- git checkout v1.2.2
- Then to compile :
- cd make
- make install
Finally you need to have the WORLD test db loaded, world test DB can be found here
First example/exercise is :
Shard inside the same MySQL Server using 3 different schemas split by continent.
Obviously you can have any number of shards and number of relative schemas.
What is relevant here is to demonstrate how traffic can be redirect to different targets (schemas) maintaining the same structure (tables).
This discriminating the target on the base of some relevant information in the Data or pass by the application.
Ok let us roll the ball.
For this exercise you can use single host or multiple servers in replica.
Summarizing you will need:
- 3 hosts: 192.168.1.[5-6-7] (only one needed now but the others are for future use)
- 3 schemas: Continent X + world schema
- 1 user : user_shardRW
- 3 hostgroups: 10, 20, 30 (for future use)
We will create the following Schemas Asia, Africa, Europe first.
Create the user:
Now let us start to configure the ProxySQL:
With this we have defined the User, the servers and the Host groups.
Let us start to define the logic with the query rules:
I am now going to query the master (or a single node) but I am expecting ProxySQL to redirect the query to the right shard catching the value of the Continent.
Well you can say ... "hey you are querying the schema world, of course you get back the correct data".
But this is not what had really happened, ProxySQL did not query the schema world but the schema Europe.
Let see the details:
Let me explain what happened.
Rule 31 in ProxySQL will take all the FIELDS we will pass in the query, it will catch the CONTINENT in the where clause, it will take any condition after the WHERE and it will reorganize the query all using the RegEx.
Does this works for any table in the sharded schemas
Of course it does.
A query like:
Will be transformed into:
Another possible a approach to instruct ProxySQL to shard is:
Pass a hint inside a comment.
Let see how.
First let me disable the rule I have just insert, this is not really needed but so you can see how :)
Now what I want to have is that *ANY* query that contains comment /* continent=X */ should go to the continent X schema, same server.
To do so, I will instruct ProxySQL to replace any reference to the world schema inside the the query I am going to submit.
How this works?
I have defined mainly to concatenated rules.
The first capture the incoming query that contains the desired value (like continent = Asia).
If the match is there ProxySQL will exit that action, but while doing so it will read the Apply field and if Apply is 0 it will read the FlagOUT value. At this point it will go to the first rule (in sequence) that has the value of FlagIN equal to the FlagOUT.
The second rule will get the request and will replace the value of world with the one I have define.
In short it will replace whatever is in the match_pattern with the value that is in the replace_pattern.
Now what happens here is that ProxySQL implement the Re2 google library for RegEx.
Re2 is very fast but has some limitations, like it does NOT support (at the time of the writing) the flag option g.
In other words if I have a select with many tables and as such several "world." Re2 will replace ONLY the first instance.
As such a query like:
Will be transformed into :
The other day with Rene' we were discussing how to solve this given the lack of implementation in Re2. Finally we had opted for recursive actions.
What this means?
It means that ProxySQL from v1.2.2 now has a new functionality that allow recursive calls to a Query Rule, the maximum number of iterations that ProxySQL can run, is managed by the option (global variable) mysql-query_processor_iterations.
Mysql-query_processor_iterations define how many operation, a query process can execute as whole (from start to end).
This new implementation allow us to reference a Query Rule to itself in order to be executed multiple times.
If you go back you will noticed that QR 34 has FlagIN and FlagOUT pointing to the same value of 25 and Apply =0.
This will bring ProxySQL to recursively call rule 34 until it change ALL the value of the word world.
The result is the following:
You can see ProxySQL internal information using the following queries:
As you can see ProxySQL has nicely replace the word world.
And executed only on the desired schema.
How I can shard redirecting the queries to an Host?
(Instead of a schema)This is even easier :)
The main point is that whatever match the rule, should go to a defined HG.No rewrite imply which means less work.
So how this is done?As said before I have 3 NODES 192.168.1.[5-6-7]For this example I will use world db (no continent schema), distributed in each node, and I wil retrieve the node bind IP to be sure I am going on the right place.
What I will do is to instruct ProxySQL to send my query by using a HINT to a specific host.
I choose the hint "shard_host_HG" and I am going to inject it in the query as comment.
As such the Query Rules will be:
While the queries I am going to test are:
Running the query for Africa, I will get:
That will give me :
In this example we have NO replace_pattern this is only a matching and redirecting Rule, where the destination HG is defined in the value of destination_hostgroup attribute while inserting.
In the case for Africa is HG 30.
The server in HG 30 is:
Which match perfectly with our returned value.
You can try by your own the other two continents.
Another way to assign to which final host a query should go is to use the the destination_hostgroup, set the Schema_name attribute and use the use schema syntax in the query.
And then in the query do something like :
I mention this method because is one of the most common at the moment in large companies using SHARDING.
But it is not safe, because it relays on the fact the query will be execute in the desired HG.
While the risk of error is high.
Just think if a query doing join against a specified SHARD:
This will probably generate an error because shard03 is probably NOT present on the host containing shar01.
As such this approach can be used ONLY when you are 100% sure about what you are doing and when you are sure NO query will have explicit schema declaration.
Shard By Host and by Schema
Finally is obviously possible to combine the two approaches sharding by host and have only a subset of schemas
To do so let us use all the 3 nodes and have the schema distribute as follow:
- Europe on Server 192.168.1.5 -> HG 10
- Asia on Server 192.168.1.6 -> HG 20
- Africa on Server 192.168.1.7 -> HG 30
I have already set the query rules both using HINT so what I have to do is to use them BOTH to combine the operations:
As you can see rule 11 has two HITS, which means my queries will go to the associated HG.
But given Apply for rule 11 is =0, ProxySQL will first continue to process the QueryRules.
As such it will also transform the queries as for rules 31 and 32, each one having the expected number of hits (1 the first and the 4 because the loop, the second).
How to shard base on a MOD
to shard base on a MOD value Like handle table sharding based on the mod of the user id?
such that `insert into 'foo' ('user_id', 'name') values (180, 'bar')` becomes `insert into 'foo_X ('user_id', 'name') values (180, 'bar')` based on 180 % 25, where 25 is the number of sharded tables.
Based on 180 % 25, where 25 is the number of sharded tables.
Solution is to create X number of query rules to manage the MOD value:
As you can see below this solution allow the transparent assignment using MOD 25
1 2 3 4 5 6 7
mysql> CREATE TABLE foo_00 (user_id INT, name VARCHAR(30)); mysql> CREATE TABLE foo_01 (user_id INT, name VARCHAR(30)); mysql> CREATE TABLE foo_02 (user_id INT, name VARCHAR(30)); mysql> CREATE TABLE foo_03 (user_id INT, name VARCHAR(30)); mysql> CREATE TABLE foo_04 (user_id INT, name VARCHAR(30)); mysql> INSERT INTO foo (user_id,name) VALUES (1000,"nameA"); mysql> INSERT INTO foo (user_id,name) VALUES (7456076,"nameB");
It is obvious that I need to acknowledge and kudo the work Rene' Cannao is doing to make ProxySQL a solid, fast and flexible product.
I have also to mention that I was and am working with him very often, more often than he likes, asking him fix and discussing with him optimization.
Requests that he try to satisfied with surprising speed and efficiency.