Posts Tagged ‘XtraDB’

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).

Of course it goes without saying that do not use this for production systems as it is only the 1st beta release. However, I definitely recommend installing it on a test server and giving it a go, test-drive the new features, throw some load at it, try to break it, and so forth.

So there are no real crucial fixes requiring an upgrade, however, if you’re running the audit plugin, or TokuDB, or you want the benefits of the new fixes in general, then you should consider an upgrade.

Overall, there are no critical nor security related bugs fixes, so that is great. As for upgrading, if you’re using any of the above storage engines or the audit plugin, it would be a good idea to consider upgrading (at least review the fixes applicable to you to determine if they will be worth it or not).

This is the seventh GA release of MariaDB 10.0, and 17th overall release of MariaDB 10.0.

For the most part, there are not a whole lot of changes to report for this release, but there are 2 enhancements of note – one being the JSON table type (still *experimental*) and the other a new variable to aid with index statistics calculations on large tables, as well as some security fixes.

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).

simple_password_check password validation plugin. It can enforce a minimum password length and guarantee that a password contains at least a specified number of uppercase and lowercase letters, digits, and punctuation characters.

cracklib_password_check password validation plugin. It only allows passwords that are strong enough to pass CrackLib test. This is the same test that pam_cracklib.so does, installed by default on many Linux distributions.

This is the sixth GA release of MariaDB 10.0, and 16th overall release of MariaDB 10.0.

This release has an important InnoDB/XtraDB fix, a new addition, security enhancements (and improvement) – all related to yaSSL, so be sure to check out these fixes if you’re running MariaDB 10.0, and not up to 10.0.15 yet. (MariaDB 10.0 is the current stable series of MariaDB. It is an evolution of the MariaDB 5.5 with several entirely new features not found anywhere else and with backported and reimplemented features from MySQL 5.6.)

Here are the main items of note:

This release fixes a serious bug in InnoDB and XtraDB that sometimes could cause a hard lock up of the server (MDEV-7026)

This is the first release that includes Mroonga full-text search storage engine.

When compiled with OpenSSL, MariaDB now supports TLSv1.2 protocol. Limit it to TLSv1.2 ciphers only with –ssl_cipher=TLSv1.2. Limit it to SSLv3 ciphers with –ssl-cipher=SSLv3. RPM and DEB packages from MariaDB.org are built with OpenSSL, others (for Windows and generic Linux) are built with yaSSL.

Given the severe InnoDB/XtraDB bug, if you’re running a prior MariaDB 10.0 version, I’d recommend upgrading (assuming you’re using InnoDB). Likewise, if you’re using SSL. And then there were a number of fixes to other fixes for TokuDB, CONNECT, and Sphinx, so if you’re using those technologies, you may want to consider upgrading as well.

Not a ground-breaking post here, but if you are interested in knowing more about the innodb_log_block_size variable, or if you use SSD cards and/or large InnoDB log files on ext4, then this is for you.

I’d read about it before briefly before, but didn’t give it too much thought until I ran across the following entry in an error log the other day:

Basically, this variable changes the size of transaction log records. Generally, the default of 512 is a good value. However, it has been found that setting it to 4096 has been beneficial when using SSD cards. (Note that while it is possible to set this to a value other than 512 or 4096, those are currently the only 2 values that make sense to use.)

Also, it has been found that 4096 is the best setting if you run ext4 along with innodb_flush_method=ALL_O_DIRECT (note both innodb_log_block_size and ALL_O_DIRECT are specific to XtraDB/XtraDB+; read: MariaDB and Percona server).

What is ALL_O_DIRECT and when it is useful?

“ALL_O_DIRECT: use O_DIRECT to open both data and log files, and use fsync() to flush the data files but not the log files. This option is recommended when InnoDB log files are big (more than 8GB), otherwise there might be even a performance degradation.”

Thus if you’re running large InnoDB log files (8G+) on ext4, you may want to consider ALL_O_DIRECT, and because you’re on ext4, you should set innodb_log_block_size=4096, the default log-block-size in ext4, in order to avoid the unaligned AIO/DIO warnings.

Likewise, if running with SSD cards, you’d likely see a performance improvement with innodb_log_block_size=4096 also.

If interested, there is a bit more about the innodb_log_block_size option here:

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:

InnoDB: You can now use OPTIMIZE TABLE to defragment InnoDB tablespaces (merged the Facebook/Kakao defragmentation patch). (Good blog post here.)

Default roles allow roles to be enabled automatically when a user connects.