The server weighting feature of MaxScale may initially be seen as a way to influence load balancing for unequal servers, but it can also be useful for other reasons. Here we look at how we can use it to segregate different workloads within a cluster of MariaDB or MySQL servers.
The need for this post became obvious after receiving an increasing amount of questions which were related to linking, library versions and paths in MaxScale. Moreover, I know that there are many who want to make things with their bare hands so it is good to have something which hopefully makes the whole process smoother.
Elon Musk has “Va Va Voom”. His forward thinking has delivered many successes over the years, from payment provider PayPal, to SpaceX, which manufactures space launch vehicles. No surprise then he has been compared to Tony Stark (Iron Man from the Marvel comic series). However, his latest announcement shows shrewd business judgement, something Musk is renowned for, shining through as he sets his sights on the global car industry.
Read more on open shared innovation in this blog by Patrik Sallner, CEO at SkySQL.
MaxScale is a modular proxy application, the modules can be considered as the building blocks of your proxy implementation within your MySQL database environment. It is important to know what building blocks you have at your disposal. The release of version 1.0 as a beta means that the number of available modules has grown once again. Normally I post about the incremental changes in what is available, but I thought that maybe it was a good time to post a short summary of all the modules. This is not designed to be comprehensive documentation for the functionality available, merely as a summary of what is available.
Today we will use the MariaDB Cluster cluster we created in the previous two blog entries, and tie it all together with an HA Proxy virtual machine setup with separate read and write pools. This assumes your application is already using different connections for reads and writes, or you're using MaxScale, MySQL Proxy, etc to splits reads and writes.
Profiling & Debugging is an argument that would require an entire book, the aim of this(and the others) posts of this series is to give you the basic knowledge on how to work with these tools and techniques withing Eclipse. For instance if you want to learn to profile with OProfile you should study on the abundant and separate resources, you may start from: http://OProfile.sourceforge.net
One of my favorite new features of MariaDB 10 is parallel slave replication ( https://mariadb.com/kb/en/parallel-replication/ ). With earlier versions of MariaDB and MySQL, the slave runs in a single thread, and applies replication events serially. This was a performance bottleneck in highly concurrent environments, as transactions are able to utilize separate CPU cores on the master, while the slave could only use one CPU core to execute the replication events.
Metadata locking has been an exciting adventure for the last couple years in MySQL and MariaDB. Users and applications using only MyISAM tables are learning the joys of locking conflicts between transactions/connections.
You've decided to move from MySQL to MariaDB, but you're a little nervous. The last thing you want is to become mired in a slough of brokenness. Don't worry, because MariaDB is designed to be a drop-in replacement for MySQL. You should be able to install MariaDB over your MySQL server, and then go about your business without drama.
In this part we will prepare Eclipse to profile our recently compiled(see Part 3) MariaDB(or MySQL).
Profiling means basically measuring where the time is spent by the application.
You may be interested in knowing how much time is spent in a specific function execution,
or you may want to know statistics about the dustribution of function calls, that is operating a data aggregation.