Optimizing your database performance is important, but it often falls by the wayside in the bustle of daily business. This blog reviews three common performance issues, with easy-to-address tuning solutions.
In this second installment of schema sharing with MariaDB MaxScale to combine SchemaRouter and ReadWriteSplit MaxScale routers, we'll go through the details of implementing it in order to shard databases among many pairs of master/slave servers.
Most of the time when you start a database design you don’t imagine how your applications need to scale. Sometimes, you need to shard your databases among some different hosts and then, on each shard you want to split reads and writes between master and slaves. This blog is about MariaDB MaxScale being able to handle different databases across shards, and splitting up reads and writes into each of the shards to achieve the maximum level of horizontal scalability with MariaDB Server.
After reading this blog you will be able to:
Know how MariaDB MaxScale handles shards with SchemaRouter router;
Know how MariaDB MaxScale handles the split of reads and writes with ReadWriteSplit router;
Know how we can combine both mentioned router in order to have an scalable environment.
The 2.1.3 GA release of MariaDB MaxScale, introduces the following key features for the secure setup of MariaDB MaxScale Binlog Server:
The binlog cache files in the MaxScale host can now be encrypted.
MaxScale binlog server also uses SSL in communication with the master and the slave servers.
This blog covers how the binary log encryption works in MariaDB Server and in MariaDB MaxScale.
Red Hat, SUSE, CentOS, Fedora and many others already choose to have MariaDB Server as the default MySQL variant. Now Debian joins by making MariaDB Server 10.1 the default in Debian 9.
Today, a relational database like MariaDB Server (part of MariaDB TX) can read, write and query both structured and semi-structured data, together. MariaDB Server supports semi-structured data via dynamic columns and JSON functions. This blog post will focus on JSON functions with MariaDB Server, using examples to highlight one of they key benefits: data integrity.
This is a guest post by Vicențiu Ciorbaru, software engineer for the MariaDB Foundation.
MariaDB Server 10.2 has now reached GA status with its latest 10.2.6 release. One of the main focuses of Server 10.2 was analytical use cases. With the surge of Big Data and Business Intelligence, the need for sifting and aggregating through lots of data creates new challenges for database engines. For really large datasets, tools like Hadoop are the go-to solution. However that is not always the most practical or easy-to-use solution, especially when you’re in a position where you need to generate on-the-fly reports. Window functions are meant to bridge that gap and provide a nice “middle of the road” solution for when you need to go through your production or data warehouse database.
Performance is important and perhaps doubly so for a database proxy such as MariaDB MaxScale. When we started working with MariaDB MaxScale 2.1 we decided to make some significant changes to the internal architecture, with the aim of improving the overall performance. In this blog post, I will describe what we have done and show how the performance has improved.
MariaDB MaxScale includes multiple filters, and one of the most useful, flexible and easiest to use is the regex filter and in this blog we will look at how this can be used to transform SQL statements that aren't 100% compatible with MariaDB.
We are happy to announce the 2.1 GA release of MariaDB MaxScale, the next-generation database proxy for MariaDB.