MariaDB 10.4: A Brief Introduction
MariaDB 10.4 is a current development branch of the MariaDB which recently released the third candidate (10.4.5) on the 21st May. That’s why we thought it is a good idea to take a look at the new MariaDB Cluster 10.4 features.
We are going to share some thoughts on MariaDB for the information about the release and all the details in the changelog of MariaDB 10.4.0.
We know that Unicode character sets are typically slower in comparison to charsets like latin1 due to their size. Previously, MySQL 8.0 brought significant improvements, and now MariaDB 10.4 is noticeably faster than 10.3.
It is quite an important improvement, and people are really loving to use emojis that require UTF8 to be enabled. Some of the work has also been done in the optimizer, MariaDB 10.4 should work better for the subqueries because it is now possible to push conditions into various materialized subqueries.
Moreover, starting and stopping InnoDB takes a while depending upon the amount of data in redo logs. The new MariaDB 10.4 improve startup, shutdown, and purging.
These improvements are important given the popularity of tools like mariabackup and xtrabackup. These tools, in the end, go through the InnoDB startup process from shutdown when applied redo logs. Therefore, every improvement should reduce the time to restore backups.
MariaDB 10.4 received an instant DROP COLUMN operation making it possible to reorder the columns in the table. You may wonder what can be the most common operations in the production environment?
We would say it is the addition or removal of an index. One more common operation is the operations on the columns such as adding a new column and removing the existing one.So far, the most common approach till now was to use external tools such as pt-online-schema-change, or gh-ost. However, both have their own limitations, which make it impossible on your system.Notably, the foreign keys are tricky with the instant DROP COLUMN and instant ADD COLUMN as a big part of the schema changes which are performed ad hoc without any detailed scheduling and planning.There are non-blocking schema changes such as creating an index; however, such operations pose a serious challenge when the replication lag is induced.Thus, even though the operation is executed on the live system, we prefer to use workarounds such as pt-online-schema-change for keeping better control over the process.This isn’t only one improvement in how schema changes are executed. But, MariaDB 10.4 benefits from a faster extension of VARCHAR columns character set and the collation changes on the non-indexed columns.
One of the most significant changes is in the user management. User accounts and global privileges are kept in the mysql.global_priv table. This is a potential change for all the tools having an option to manage MySQL and MariaDB users.While we acknowledge the changes, this definitely doesn’t help to maintain tools for both MariaDB and MySQL to make the tooling landscape more divided. Talking about the users, MariaDB 10.4 comes with an option for the expiring user passwords.
This definitely is a step in a first direction to enforce good practices regarding password management. Even though I could have written it in a separate blog in more detail, I must mention here the support for Galera 26.4 - MariaDB 10.4 benefiting a new Galera version with features such as streaming replication, improved SST, backup locks and many more.Finally, in MariaDB 10.4 you have the liberty to set sql_mode=MSSQL. Though it’s an initial implementation, sql_mode=ORACLE was an initial implementation at some point.This shows how MariaDB focus well on enterprise customers. If the Oracle customers decide to migrate, MariaDB adoption among Microsoft SQL Server also grows as more features will be added in the future.
MariaDB Being A Fork
Quite recently, I saw a blog post that explained MariaDB stance on InnoDB changes and compatibility factors. The gist is that MariaDB longer merges InnoDB features from MySQL and the focus will be on the stability plus performance improvement.
Basically it means that MariaDB can become incompatible with MySQL. Thus, if you could do the binary upgrade in the past, in the future, it will not be possible as it is trickier to execute in the present.This increases the importance of tools such as mydumper/myloader because the logical backup can be the only way for migration. The good is that MariaDB will own the stability of their fork of InnoDB.But, they will not have to deal with the issues introduced by upstream developers; hence, we can expect fewer bugs being introduced. If we talk Performance-wise, we will have to wait for benchmarks, but given the historical data, it is easy to assume that MariaDB will be slower than MySQL.Moreover, in the past parameters what we have typically seen is that the performance increase for MariaDB kicks in when in more recent times InnoDB version has been integrated.Here it will no longer be the case that makes us wonder how MariaDB fares in the performance comparison from now on if the improvements introduced by MariaDB are well enough to keep up with MySQL 8.0 and its further versions.
On the other hand for us users, it means that MariaDB 10.4 should be more stable than all other previous releases. Also, it means that eventually, we will have to learn the internals of two different storage engines - especially when we care about the performance.Tools will have to be designed such that they work with one or the other versions of InnoDB (or additional work has to be added to support both MySQL and MariaDB). We are going to keep an eye on how this is going to progress.
When you think about it, it doesn't comes up with many surprises because MariaDB always had taken its time to integrate with more recent versions of InnoDB.With more and more incompatible features that are adding to MariaDB, huge changes introduced in MySQL 8.0 clearly makes sense to focus on developing new functionalities rather than porting incompatible InnoDB from upstream MySQL.To conclude, I hope this short blog post gave you an insight into changes which hits the production systems to MariaDB 10.4.