Release Notes Changelog What is MariaDB 10.1?
MariaDB APT and YUM Repository Configuration Generator
The MariaDB project is pleased to announce the immediate availability of MariaDB 10.1.4. This is a Beta release.
See the Release Notes and …
[Read more]MariaDB 10.1.3 was recently released, and is available for download here:
https://downloads.mariadb.org/mariadb/10.1.3/
This is the 1st beta, and 4th overall, release of MariaDB 10.1, so there are a lot of new changes, functionalities added, defaults changed, and many bugs fixed (I counted 420 – 117 in 10.1.2 & 637 in 10.1.1, fwiw).
Since it’s beta, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).
To me, these are the highlights of the new features:
[Read more]MariaDB 10.1.2 was recently released, and is available for download here:
https://downloads.mariadb.org/mariadb/10.1.2/
This is the third alpha release of MariaDB 10.1, so there are still a lot of new changes, functionalities added, defaults changed, and many bugs fixed (I counted 117, which is *way* down from the 637 fixed in 10.1.1). Since it’s alpha, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).
To me, these are the highlights of the new features:
Sometimes users ask for something that doesn’t really make sense. On the first glance. But then you start asking and realize that the user was right, you were wrong, and it is, actually, a perfectly logical and valid use case.
I’ve had one of these moments when I’ve heard about a request of making triggers to work on the slave in the row-based replication. Like, really? In RBR all changes made by triggers are replicated from the master to slaves as row events. If triggers would be fired on the slave they would do their changes twice. And anyway, assuming that one only has triggers one the slave (why?) in statement-based replication triggers would run on the slave normally, wouldn’t they?
Well, yes, they would, but one cannot always use statement-based replication. If one could, RBR would’ve never been implemented. There are many cases that statement-based replication cannot handle correctly. Galera requires RBR too. And as …
[Read more]Let me start with a little story. You sit in your house near the fireplace in the living room and need a book from the library… Eh, no, sorry, wrong century. You’re building a robotic arm that will open your beer or brew your coffee or supply you with whatever other drinks of your choice… while you’ll be building the next robotic arm. So, you — soldering iron in one hand and Arduino in another — ask your little brother to bring a box with specific resistors (that you unexpectedly run out of) from the cellar. The problem — your brother is small and cannot tell a resistor from a respirator. You explain that it’s small thing with two wires sticking out of it. And he starts going back and forth brining you boxes after boxes of different small things with two wires.
This is approximately where we were in MySQL when NDB Cluster was
just added. The use wants to find a row, say WHERE
number_of_wires=2 AND size='small' AND …
I don’t think it’ll surprise anybody if I say that MariaDB or
MySQL server knows a lot more about server system variables, then
just their values. Indeed, every variable can be session or
global only, read-only or writable, it has an associated help
text (that is printed on mysqld --help --verbose),
certain variables only accept values from a given set of strings
(this set of allowed values is also printed in mysqld
--help --verbose since MariaDB 10.1.0), numeric variables
have lower and upper range boundaries of valid values (that are
never printed anywhere), and so on. I always thought it’s kind of
a waste that there is no way to query this information. That
could’ve been very convenient, in particular for various GUI
clients — they could show the help in tooltips, validate values
and so on.
But recently we’ve got our users asking for it — precisely, for system variable metadata, whether a variable …
[Read more]MariaDB 10.1.1 was recently released, and is available for download here:
https://downloads.mariadb.org/mariadb/10.1.1/
This is the second alpha release of MariaDB 10.1, so there are a lot of new changes and functionalities added, and many, many bugs fixed (I counted 637). Since it’s alpha, I’ll only cover the major changes and additions, as there are a lot of great new features, and omit covering any of the bug fixes (feel free to browse them all here).
To me, these are the highlights of the new features:
One of the most popular plugin types both in MariaDB and MySQL is INFORMATION_SCHEMA plugin type. INFORMATION_SCHEMA plugins add new tables to the INFORMATION_SCHEMA. There are lots of INFORMATION_SCHEMA plugins, because they can be used to show just anything to the user and are very easy to write.
MariaDB 10.1.1 comes with nine INFORMATION_SCHEMA plugin:
Every now and then there is a need to execute certain SQL
statements conditionally. Easy, if you do it from your PHP (or
Java or whatever) application. But if all you have is pure SQL?
There are two techniques that MariaDB and MySQL use in the
mysql_fix_privilege_tables.sql script (applied by
mysql_upgrade tool).
IF statements
inside, call it once and drop it. This requires the user to have
the CREATE ROUTINE privilege and
mysql.proc table must exist and be usable (which is
not necessarily true — we’re doing it from mysql_upgrade,
right?).
SET @str = IF (@have_csv = 'YES',
'CREATE TABLE IF NOT EXISTS general_log (
event_time TIMESTAMP(6) NOT NULL,
user_host MEDIUMTEXT NOT NULL,
thread_id BIGINT(21) UNSIGNED NOT NULL, …
Yes! In MariaDB 10.1.1 tables in PERFORMANCE_SCHEMA
do not use .frm files. These files are not created,
not read — in fact, PERFORMANCE_SCHEMA tables never
touch the disk at all.
This became possible due to a lesser-known feature of MariaDB —
new table discovery (“old table
discovery” was implemented in MySQL for NDB Cluster in 2004),
implemented in MariaDB 10.0.2. Instead of reading and parsing
.frm files, MariaDB simply asks
PERFORMANCE_SCHEMA table, what structure it has, and
because these tables always have a fixed structure, the table
directly returns it to MariaDB with no need for any external data
dictionary.
It also means, you never need to upgrade
PERFORMANCE_SCHEMA tables, they always have the
correct structure corresponding to the MariaDB version …