Posts Tagged ‘XtraDB’

MariaDB 10.0.10 Overview and Highlights

Tuesday, April 8th, 2014

MariaDB 10.0.10 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.10/

This is the first GA (“Generally Availability“, aka “recommended for production systems”) release of MariaDB 10.0, and 11th overall release of MariaDB 10.0.

Since this is the initial 10.0 GA release, this is primarily a bug-fix and polishing release.

Here are the main items of note:

  1. The Audit Plugin is now included in MariaDB (MDEV-5584)
  2. Improved XtraDB performance by fixing incorrect calculation of flushed pages (MDEV-5949)
  3. Fix for GTID duplicate key multi-master corruption bug (MDEV-5804)
  4. Default TokuDB compression is now TOKUDB_ZLIB (instead of TOKUDB_UNCOMPRESSED)
  5. Various algorithm improvements for engine-independent table statistics (EITS) (MDEV-5901, MDEV-5917, MDEV-5950, MDEV-5962, MDEV-5926)

You can read more about the 10.0.10 release here:

https://mariadb.com/kb/en/mariadb-10010-release-notes/

And if interested, you can review the full list of changes in 10.0.10 (changelogs) here:

https://mariadb.com/kb/en/mariadb-10010-changelog/

Hope this helps.

 

MariaDB 10.0.9 Overview and Highlights

Friday, March 14th, 2014

MariaDB 10.0.9 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.9/

This is the second RC (“Release Candidate”) release of MariaDB 10.0, and 10th overall release of 10.0. All features planned for MariaDB 10.0 GA are included in this release.

There were 6 notable changes in MariaDB 10.0.9:

  1. InnoDB upgraded to version 5.6.15
  2. Extended-keys optimization is now enabled by default.
  3. MariaDB can be compiled to use the system’s PCRE library.
  4. Added MASTER_GTID_WAIT() and @@last_gtid.
  5. When a TIME value is casted to a DATETIME, the date part will be the CURRENT_DATE, not 0000-00-00. This is compatible with the SQL standard and MySQL-5.6. One can use @@old_mode=ZERO_DATE_TIME_CAST to revert to the old behavior.
  6. XtraDB is now the default InnoDB implementation, Oracle InnoDB is a plugin that can be dynamically loaded if desired.
  7. Builds for Debian Sid and Ubuntu Trusty are being made available for the first time in the MariaDB repositories. For this release the Trusty packages are considered as alpha releases. The Sid packages will likely always be considered as such. Both were made as part of normal MariaDB development, and we’re making them available for those that want to test or try them out.

Also, if you read my MariaDB 10.0.8 Overview post, you will have noticed there was a build issue with Percona’s XtraDB that was preventing it from being the default in MariaDB 10.0. I’m glad I posted about it, as the MariaDB and Percona Devs began working together immediately, and resolved the issue in days, and now XtraDB+ is back the default InnoDB in MariaDB 10.0. (This is mentioned in the bullet point #6 above, but I wanted to explicitly mention it as well, so it did not go unnoticed.)

You can read more about the 10.0.9 release here:

https://mariadb.com/kb/en/mariadb-1009-release-notes/

And if interested, you can review the full list of changes in 10.0.9 (changelogs) here:

https://mariadb.com/kb/en/mariadb-1009-changelog/

Hope this helps.

 

MariaDB 5.5.36 Overview and Highlights

Friday, March 14th, 2014

MariaDB 5.5.36 was recently released (it is the latest MariaDB 5.5), and is available for download here:

https://downloads.mariadb.org/mariadb/5.5.36/

This is a maintenance release, and so there are not too many big changes of note, just a number of normal bug fixes. However, there are a couple items worth mentioning:

  1. Includes all bugfixes and updates from: MySQL 5.5.36
  2. TokuDB is now included in RPM packages for CentOS 6 on x86-64

Note this release did not contain the bugfixes from XtraDB 5.5.36 yet. There is one bug fix in XtraDB 5.5.36 that is fairly serious, so if you are a *heavy* XtraDB+ user, I might wait for MariaDB 5.5.37 to be released, so you get this fix. I should note the bug was partially fixed in 5.5.35, and I did not see reports of the same issues in 5.5.35, so perhaps that covered it, or at least the majority. 5.5.34 had the worst of this bug, so if you are running 5.5.34, then I *would* definitely recommend upgrading.

Additionally, if you are using MySQL’s InnoDB in MariaDB, then I would definitely recommend upgrading to MariaDB 5.5.36 as well.

If interested, there is more about the 5.5.36 release here:

https://mariadb.com/kb/en/mariadb-5536-release-notes/

And the full list of fixed bugs and changes in MariaDB 5.5.36 can be found here:

https://mariadb.com/kb/en/mariadb-5536-changelog/

Hope this helps.

 

Comprehensive How-To for Enabling the Standard InnoDB Plugin in MariaDB and MySQL

Monday, June 24th, 2013

I’m always switching back-and-forth between the 2 different InnoDB flavors in MariaDB – XtraDB+ and the standard InnoDB plugin, so I thought I’d simply post all of the various combinations in a single place. (And then I cover enabling the InnoDB Plugin in MySQL, since it’s an option in 5.1.) [Addition: Thanks to Andrew and Sergei for the tips on shortening plugin-load=. The changes are reflected below.]

Note: Below is for Windows. For Linux, simply change “.dll” to “.so” where appropriate.

MariaDB 10.0:

Do not add anything, as the standard InnoDB plugin is the current default (as of 10.0.3, although I do anticipate this changing in the near future, and I’ll update the post accordingly when that happens).

MariaDB 5.5:

# Enable the 2 below to disable XtraDB+ and enable the standard InnoDB Plugin
ignore_builtin_innodb
plugin-load=ha_innodb.dll

MariaDB 5.3:

# Enable the 2 below to disable XtraDB+ and enable the standard InnoDB Plugin
ignore_builtin_innodb
plugin-load=ha_innodb_plugin.dll

MariaDB 5.2:

# Enable the 2 below to disable XtraDB+ and enable the standard InnoDB Plugin
ignore_builtin_innodb
plugin-load=ha_innodb_plugin.dll

MariaDB 5.1:

# Enable the 2 below to disable XtraDB+ and Enable the standard InnoDB Plugin
ignore_builtin_innodb
plugin-load=ha_innodb_plugin.dll

Note that enabling it in 5.1, 5.2, and 5.2 are the same. As for 5.5, the only difference is that the name of the .dll has changed from “ha_innodb_plugin.dll” to “ha_innodb.dll” (so that needs changed in each place it occurs).

MySQL 5.1:

For MySQL 5.1, you would enable the InnoDB Plugin in the same way you would for MariaDB 5.1:

# Enable the 2 below to enable the standard InnoDB Plugin
ignore_builtin_innodb
plugin-load=ha_innodb_plugin.dll

MySQL 5.5+:

In MySQL 5.5+, the InnoDB Plugin is the default (and only InnoDB flavor of InnoDB in MySQL).

And finally, since I’m discussing the InnoDB Plugin, I do have some older posts on the subject for anyone who may be interested:

InnoDB Plugin Versions
http://www.chriscalender.com/?page_id=628

Ease of Switching to the InnoDB Plugin and the Numerous Benefits
http://www.chriscalender.com/?p=99

InnoDB Plugin Version Numbering in MySQL and MariaDB
http://www.chriscalender.com/?p=1205

Hope this helps. :)

 

Enabling the Verbose InnoDB Lock Monitor in MariaDB and Percona Server for XtraDB+ and XtraDB

Monday, March 25th, 2013

I enabled the InnoDB Lock Monitor in my MariaDB 5.5 instance (using XtraDB+ as the InnoDB – which is the default in MariaDB) and noticed that while the SHOW ENGINE INNODB STATUS was being logged to the error log, it wasn’t logging the “additional” lock information – it just looked like the plain ‘ole INNODB STATUS.

Long story short, Percona added a new variable so one has better control over what gets logged:

innodb_show_verbose_locks

If off (default), then the InnoDB Lock Monitor logs the normal INNODB STATUS, and if enabled, then it logs it with the extended lock information.

They also created another variable that goes along with this one (and the InnoDB Lock Monitor), which is:

innodb_show_locks_held

This variable indicates the number of locks to print that are held for each InnoDB transaction (the default is 10, max is 1000).

For reference, these 2 options are discussed further in Percona’s manual.

Hope this helps. :)

 

InnoDB Plugin Version Numbering in MySQL and MariaDB

Monday, March 18th, 2013

As some of you may or may not know, I’ve maintained a list of all InnoDB Plugin versions as they’ve historically contained a different version (entirely different numbering scheme) than the MySQL distribution they were included with.

This list was most helpful for troubleshooting various InnoDB issues when the plugin may (or may not) have been involved, and/or for benchmarking, etc. And it’s fair to say it was more useful when the InnoDB plugin was not the mainstream, which it is now.

However, with the latest releases, in MySQL and MariaDB, the “InnoDB Version” simply matches the “MySQL Version”. These “latest releases” include: MySQL 5.6.10, MySQL 5.5.30, MySQL 5.1.68, and MariaDB 5.5.30

Of course this isn’t the most newsworthy story, but having maintained this “list” the past couple/few years, I was happy to see the change, and at least wanted to mention it.

There won’t be a need for me to further update the page, but it is up-to-date now, so if you happen to need to know what version of InnoDB Plugin an older version of MySQL or MariaDB is using, then this page will still be there for you (it’s also in the right-hand column of my site under “Pages” titled “InnoDB Plugin Versions“).

Hope this helps. :)

 

How to Enable the Original InnoDB Plugin in MariaDB 5.5

Friday, May 25th, 2012

As I mentioned here, there is a slight change for enabling the [original] InnoDB Plugin in MariaDB 5.5 (as compared to how you would enable it in 5.1).

Remember, in MariaDB 5.5, if you do not “enable” (i.e., add anything to the config file to do so) the InnoDB Plugin in MariaDB 5.5, you’ll end up with XtraDB+ for your InnoDb plugin. However, if you do “enable” the InnoDB plugin, then you end up with the original InnoDB plugin provided by Oracle/InnoDB.

The change is that the plugin file (.dll for Windows, .so file for Linux) which was previously named “ha_innodb_plugin.dll” is now just “ha_innodb.dll”.

Thus, if you previously enabled the plugin with (would have been in a 5.1 instance):

[mysqld]
ignore_builtin_innodb
plugin-load=innodb=ha_innodb_plugin.dll;innodb_trx=ha_innodb_plugin.dll;
innodb_locks=ha_innodb_plugin.dll;innodb_lock_waits=ha_innodb_plugin.dll;
innodb_cmp=ha_innodb_plugin.dll;innodb_cmp_reset=ha_innodb_plugin.dll;
innodb_cmpmem=ha_innodb_plugin.dll;innodb_cmpmem_reset=ha_innodb_plugin.dll

You now need to use:

[mysqld]
ignore_builtin_innodb
plugin-load=innodb=ha_innodb.dll;innodb_trx=ha_innodb.dll;
innodb_locks=ha_innodb.dll;innodb_lock_waits=ha_innodb.dll;
innodb_cmp=ha_innodb.dll;innodb_cmp_reset=ha_innodb.dll;
innodb_cmpmem=ha_innodb.dll;innodb_cmpmem_reset=ha_innodb.dll

That is the only difference, so after making that change, just restart your instance, and you’ll be in business.

For reference, if you encounter this, you might see an error similar to the following in your error log:

120524 19:24:56 [ERROR] Can't open shared library
 'C:\Program Files\MySQL\MariaDB 5.5\lib\plugin\ha_innodb.dll'
 (errno: 0 The specified module could not be found.)
120524 19:24:56 [ERROR] Couldn't load plugin named 'innodb' with
 soname 'ha_innodb.dll'.
120524 19:24:56 [ERROR] C:/Program Files/MySQL/MariaDB 5.5/bin/mysqld:
 unknown variable 'innodb_buffer_pool_size=10M'
120524 19:24:56 [ERROR] Aborting

Hope this helps.

 

Building XtraDB on Windows

Monday, February 6th, 2012

As you may or may not know, Windows is not yet a supported platform for XtraDB.

I thought I’d try to build it, and see what happens:

  1. Download XtraDB 5.5 Source
  2. cd C:\xtradb-5.5
  3. mkdir bld
  4. cd bld
  5. cmake ..
  6. VS08: File -> Open -> Solution -> C:\xtradb-5.5\bld\MySQL.sln

Build Ended With:

========== Build: 70 succeeded, 17 failed, 2 up-to-date, 10 skipped ==========

The first failure had to do with innobase:

18>Generating Code...
18>Build log was saved at "file://c:\..\innobase.dir\Debug\BuildLog.htm"
18>innobase - 9 error(s), 3 warning(s)

I checked the innobase build log and found this:

sql_prepare.cc
..\sql_prepare.cc(2199) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2232) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2639) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2672) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2808) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2848) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2940) : error C3861: 'gettimeofday': identifier not found
..\sql_prepare.cc(2973) : error C3861: 'gettimeofday': identifier not found
...
sql_parse.cc
..\sql_parse.cc(5750) : error C3861: 'gettimeofday': identifier not found
..\sql_parse.cc(5827) : error C3861: 'gettimeofday': identifier not found

The ‘gettimeofday’ function is a Unix-only (i.e., there is no direct analog of the gettimeofday() in Windows) .. more details here.

So, this part of the code has simply not been ported to Windows yet.

I got to looking, and it is a reported bug already:

https://bugs.launchpad.net/percona-server/+bug/737895
https://bugs.launchpad.net/percona-patches/+bug/421925
https://bugs.launchpad.net/percona-patches/+bug/390156

But, do not worry. If you want to take advantage of the InnoDB enhancements found in XtraDB on Windows, you can simply use MariaDB.

There are pre-built MariaDB binaries for Windows, and MariaDB contains XtraDB+ (which is XtraDB plus some additional enhancements on top of it).

..

Related Build Links:

Hope this helps.

Building MariaDB 5.1 on Windows

Monday, January 23rd, 2012

Recently, I found myself needing MariaDB 5.1.60 for Windows for some testing purposes. Therefore, I needed to build it from source. I ended up using what I’d call a “blend” of the commands listed in this “how-to” and the readme file INSTALL-WIN-SOURCE, so I thought I’d post those steps.

  1. Download 5.1.60 MariaDB source from here.
  2. cd C:\mariadb-5.1
  3. win\configure.js
  4. cmake .
  5. VS: File -> Open -> Solution -> MySql.sln
  6. VS: Build -> Build Solution
  7. VS: Right-click “PACKAGE” -> Build (in “Solution Explorer” View)

That’s it.

Let’s fire it up:

MariaDB> select version();
+----------------------+
| version()            |
+----------------------+
| 5.1.60-MariaDB-debug |
+----------------------+

MariaDB> show global variables like 'innodb_version';
+----------------+-------------+
| Variable_name  | Value       |
+----------------+-------------+
| innodb_version | 1.0.17-13.0 |
+----------------+-------------+

MariaDB> show engines;
+------------+---------+---------------------------...
| Engine     | Support | Comment		   ...
+------------+---------+---------------------------...
| CSV        | YES     | CSV storage engine	   ...
| InnoDB     | DEFAULT | Percona-XtraDB, Supports t...
| PBXT       | YES     | High performance, multi-ve...
| MARIA      | YES     | Crash-safe tables with MyI...
| MyISAM     | YES     | Default engine as of MySQL...
| FEDERATED  | YES     | FederatedX pluggable stora...
| MRG_MYISAM | YES     | Collection of identical My...
| MEMORY     | YES     | Hash based, stored in memo...
+------------+---------+---------------------------...

..

For reference, here are my full outputs:

C:\Users\Chris>cd ..\..\mariadb-5.1

C:\mariadb-5.1>win\configure.js

C:\mariadb-5.1>cmake .
-- Check for working C compiler: cl
-- Check for working C compiler: cl -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: cl
-- Check for working CXX compiler: cl -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
build CSV as static library (libcsv.lib)
build FEDERATEDX as static library (libfederatedx.lib)
build HEAP as static library (libheap_s.lib)
build MARIA as static library (libmaria_s.lib)
build MYISAM as static library (libmyisam_s.lib)
build MYISAMMRG as static library (libmyisammrg_s.lib)
build PBXT as static library (libpbxt_s.lib)
build XTRADB as static library (libxtradb.lib)
build ARCHIVE as DLL (ha_archive.dll)
build BLACKHOLE as DLL (ha_blackhole.dll)
build EXAMPLE as DLL (ha_example.dll)
build FEDERATED as DLL (ha_federated.dll)
build INNODB_PLUGIN as DLL (ha_innodb_plugin.dll)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/mariadb-5.1

Open Visual Studio -> File -> Open -> Project/Solution -> Select C:\mariadb-5.1.60\MySql.sln

Build Solution Output:

========== Build: 79 succeeded, 0 failed, 2 up-to-date, 2 skipped ==========

Package Build Output:

1>------ Build started: Project: PACKAGE, Configuration: Debug Win32 ------
1>
1>Performing Post-Build Event...
1>CPack: Create package using NSIS
1>CPack: Install projects
1>CPack: - Install project: MySql
1>CPack: -   Install component: Unspecified
1>CPack: -   Install component: headers
1>CPack: -   Install component: mysqltest
1>CPack: -   Install component: runtime
1>CPack: -   Install component: scripts
1>CPack: -   Install component: sqlbench
1>CPack: Compress package
1>CPack: Finalize package
1>CPack: Package C:/mariadb-5.1/MariaDB-5.1.60-win32.exe generated.
1>Build log was saved at "file://c:\mariadb-5.1\PACKAGE.dir\Debug\BuildLog.htm"
1>PACKAGE - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 81 up-to-date, 0 skipped ==========

 
 
..

 
 

Upgrading from MySQL to MariaDB is Easy as 1,2,3

Tuesday, January 10th, 2012

This post is just to show how easy it is to upgrade or migrate from MySQL to MariaDB.

I should begin by stating this article is geared more towards MySQL 5.1 and prior, as MySQL 5.5 users will likely want to wait until MariaDB 5.5 is available (which I believe will be in the near future).

As you may or may not know, there are actually 3 flavors of MariaDB currently: 5.1, 5.2, and 5.3.

All three are based off of the 5.1 MySQL code base, just 5.2 and 5.3 have further improvements over 5.1. So, that’s why I say this upgrade is “easy” and there’s no need to be afraid, especially for 5.1 users. But even if you were a 5.0 user, the upgrade to MySQL 5.1 compared to MariaDB 5.1 would not be any different. So, why not give it a go?

You’ll have all of the benefits from using MySQL, but also all of the added improvements from MariaDB and XtraDB+.

I like the fact you can “ease” into it. For instance, if running MySQL 5.1.60 (the most current 5.1) on Linux with the InnoDB Plugin, you can simply move to MariaDB 5.1.60 using the InnoDB Plugin1.

Then basically everything is the same, but now you have access to the new features. For instance, you’d now have the Aria, XtraDB, PBXT, and FederatedX storage engines. You could easily upgrade your InnoDB Plugin to use the XtraDB+ Plugin instead once you have MariaDB installed (basically it’s the same InnoDB but with a number of extra performance-related improvements). It’s all up to you once you make the switch.

I should note that if you are running Windows, then I suggest you migrate straight to MariaDB 5.2, as there are numerous Windows-specific improvements starting with MariaDB 5.2 (and even more Windows performance enhancements in 5.3). (I would imagine that once upgrading, one would want to benefit from the 5.2 improvements anyways, and perhaps benchmark 5.3 in the meantime.)

As for all of the specific details, let me first quote the MariaDB Compatibility page from their manual, just for reference:

“For all practical purposes, MariaDB is a binary drop in replacement of the same MySQL version (for example MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 are compatible. MySQL 5.5 will be compatible with MariaDB 5.5).”

http://kb.askmonty.org/en/mariadb-versus-mysql

The above page goes on in-depth about the compatibility, drop-in binary replacement upgrade, how to replace an rpm, and even the couple incompatibilities (from MySQL 5.1 to MariaDB 5.1, 5.2, and 5.3). Everything is well-documented, and the above is a great reference for anyone planning (or even considering) to upgrade.

As I mentioned, there are currently 3 series of MariaDB: 5.1, 5.2, and 5.3. The latest 5.1 is 5.1.60 (and it is GA), the latest 5.2 is 5.2.10 (also GA), and the latest 5.3 is 5.3.3 (which is “Release Candidate” status – so close to GA).

You can download MariaDB from here (there are links to all 3 series):

http://downloads.askmonty.org/mariadb/

And the improvements are too many to list, but let me post some:

5.1:

o New storage engines: Aria, XtraDB, PBXT, FederatedX 2
o Speed Improvements
o New Extensions & New Features
o Upgrade and Testing improvements

5.2:

o New storage engines: OQGRAPH and SphinxSE
o Virtual columns
o Extended User Statistics
o Segmented MyISAM key cache
o Pluggable Authentication
o Group commit for the Aria engine

5.3:

o Subquery optimizations
o Semi-join subquery optimizations
o Non-semi-join optimizations
o Subquery Cache
o Optimizations for derived tables and views
o Disk access optimization
o Join optimizations
o Index Merge improvements
o Optimizer control
o Microsecond support
o Windows performance improvements

And for the full list of improvements in each series, please refer to the following links for 5.1, 5.2, and 5.3, respectively:

http://kb.askmonty.org/en/what-is-mariadb-51
http://kb.askmonty.org/en/what-is-mariadb-52
http://kb.askmonty.org/en/what-is-mariadb-53

Thus far, everything sounds like an improvement. But as far as I can tell, if you take a great product and add even more enhancements on top of it, it’s hard to go wrong.

If I were pressed to come up with a “con”, I would say there might be a slight delay (up to a month) from the latest MySQL available version compared to the latest MariaDB version. However, this may not be a “con” anyway. After all, merging monthly gives the MySQL code a couple weeks to mature, basically letting others run into any new bugs before it’s merged into MariaDB. In fact, it reminds me of the old “Quarterly Service Packs” versus the “Monthly Rapid Updates” MySQL used to provide. Therefore, if one were to apply that reasoning, it could be said that you might be less likely to encounter a regression bug in MariaDB (therefore overall stability could be improved).

And if you need support for MariaDB, just contact SkySQL, as we fully support it:

http://www.skysql.com/how-to-buy

Notes:

1: In MariaDB, if you use the built-in InnoDB, then you are using XtraDB+. Otherwise, if you enable the InnoDB Plugin, then you are enabling the standard InnoDB plugin. Note that XtraDB+ is an improvement over XtraDB as it contains even further enhancements.

2: FederatedX is a huge improvement over Federated – a “must have” if you use Federated.


Period Panties by Period Panteez Menstrual Underwear Menstruation PMS Panty