Colin Charles Agenda

I currently maintain a host of machines in the RPM world from CentOS 5, CentOS 6, and now Fedora 20 (in preparation for CentOS 7). Being part of an upstream project that ships on many platforms, it is in my interest to make sure that all things “just work” on the myriad of platforms out there that we support.

In CentOS 6.5, changing a hostname is a process of editing /etc/sysconfig/network, making sure the /etc/hosts file is sensible and fixing it with the hostname command. Rackspace has a good support article on this.

This is the world before systemd. Now in Fedora 20, this muscle memory goes away in favour of using hostnamectl (docs from the excellent System Administrator’s Guide). Now all I have to do is: sudo hostnamectl set-hostname <newhostname>.

I see a whole host of feature requests with regards to MariaDB & systemd as well as a couple for MySQL. I’ll be spending some time on this in the near future.

(and in other news, shutdown doesn’t understand the -f switch – invalid option code – this was to skip fsck on reboot – still valid in CentOS 5, accepted input in CentOS 6, but unlikely for CentOS 7.)

I’ve had this question several times when presenting and once via an internal email thread so I figure I might as well write about it: What is the default transactional engine in MariaDB 10.0? The answer is simple – it is XtraDB.

However this answer has some history: initial releases of MariaDB 10 actually shipped with InnoDB from MySQL 5.6. Only in 10.0.9 RC did the default switch back to being XtraDB. As MariaDB users previously know, XtraDB was the default InnoDB in 5.1, 5.2, 5.3, and 5.5 too. As always, you can switch easily between InnoDB/XtraDB – read more in: Using InnoDB instead of XtraDB. 

How do you tell what version of InnoDB or XtraDB you are running? Simply, run: SHOW GLOBAL VARIABLES LIKE 'innodb_version';

MariaDB 10.0 (read more: What is MariaDB 10.0):

The asterisk (*) denotes the default engine choice.

Why are there odd InnoDB versions from 10.0.0 – 10.0.6? I can only point this to merge oddities. storage/innobase/include/univ.i is the file which contains common definitions such as INNODB_VERSION_MAJOR, INNODB_VERSION_MINOR and INNODB_VERSION_BUGFIX. INNODB_VERSION_BUGFIX in 10.0.6 pointed to MYSQL_VERSION_PATCH which you get from the VERSION file. For XtraDB, you will also see PERCONA_INNODB_VERSION in univ.i.

So, when XtraDB is the default (10.0.9 and 10.0.10 and releases going forward) you can put in my.cnf to load InnoDB:

ignore_builtin_innodb
plugin_load=innodb=ha_innodb.so

When InnoDB is the default (10.0.8 and 10.0.7) and XtraDB was merged, you can put in my.cnf to load XtraDB:

ignore_builtin_innodb
plugin_load=innodb=ha_xtradb.so

Percona Server only became GA with 5.6.13-61.0 which was 7 Oct 2013 which explains why the MariaDB 10.0.6 beta didn’t include a XtraDB.

Percona Server only ships XtraDB (source code in storage/innobase) while MariaDB ships both InnoDB (storage/innobase) as well as XtraDB (storage/xtradb).

If you want older release information about InnoDB plugin versions, a great resource is Chris Calendar’s blog post: InnoDB Plugin Versions. I’m just glad that going forward the InnoDB version will just match the release version as you can see with 10.0.7 and later.

Via Dave Stokes, MySQL Community Manager:

MySQL Central is truly a MySQL Community show. This year there are five tracks and the majority of the sessions in all the tracks except Performance and Scalability had many more submissions from the MySQL Community than from Oracle/MySQL.

This is impressive. There are about 200 submissions, 50 slots, a 1/4 chance of a talk getting in, and if we follow this logic we will see that MySQL Central @ OpenWorld will truly be a community event (in previous years, majority of the talks came from the MySQL team at Oracle). I can’t wait to see the final program, but as an attendee to the past two MySQL Connect events, I am looking forward to seeing this event grow and be a part of the main program (i.e. not the weekend before).

As Dave says, register now. Though I presume many will wait for the program first. Apparently it is mid-June when speakers will be notified so one can presume an agenda should be out by the end of that month.

While at the keynote of Tomas Ulin at Percona Live MySQL Conference & Expo Santa Clara 2014, he asked the audience what they were running, and most of the audience was on MySQL 5.5 while about 15% of the audience was on MySQL 5.6. This number is steadily increasing I’m sure, so one thing that becomes important is that people will probably start turning on Global Transaction Identifiers (GTIDs). 

As you may already know, MariaDB 10 has a different implementation of Global Transaction ID. To me, this poses a problem in a mixed use environment (or even a migration scenario). Which is why MDEV-4487 is so important: it is a feature request to allow replication from MySQL 5.6+ when GTID is enabled on the master. 

If you think the issue is important, you can vote and watch the issue on JIRA. I for one think this should be fixed for 10.0.11 or 10.0.12 and not wait for the 10.1 timeframe. Best not to comment here, focus on the JIRA request, MDEV-4487.

There are many MySQL related IRC discussion channels as the ecosystem itself grows. I join the following. Are there any that I’m missing?

Freenode (irc.freenode.net):

• #mysql – main channel for all kinds of end user MySQL related discussions (the noisiest of the lot, naturally)
• #maria – main channel for all kinds of MariaDB related discussions
• #webscalesql – for all kinds of WebScaleSQL discussions
• #percona – main channel for all kinds of Percona related discussions
• #tokutek – main channel for Tokutek discussions (TokuDB or TokuMX)
• SkySQL-specific channels: #maxscale and #mariadb-mgr

OFTC (irc.oftc.net):

• #debian-mysql – for all kinds of Debian MySQL related bits (packaging, bugs, etc.)

Rob Young is back in the MySQL ecosystem (now working at Percona), but he was previously at MongoDB (formerly known as 10gen), and he made a really interesting observation:

10gen places a huge importance on all employees having a working technical knowledge of its products. 

I joined 10gen with years of application and database development experience, mostly using relational models. While most concepts apply to a document-oriented model there are enough technical differences that leave me as a complete novice when it comes to specific MongoDB details and its practical use cases. I have spent my first month in a series of self-guided and instructor led technical training sessions and a practical, real-world bootcamp that have proven to be a welcome quickstart to my understanding and working with the technology. This will pay great dividends as I get more overwhelmed with my true PM duties.

I cannot agree more with this stand that MongoDB takes. All employees should have a working technical knowledge of the products that the company makes. 

I remember back in MySQL AB, it was a requirement that support engineers spent their first 3 months on support requests but were also required to get certified during that timeframe. That’s fine and dandy when you have a certification program that you’re selling ;)

I think its important for everyone to know what their products do, instead of just the engineering/consulting/sales engineering teams. It is important for the executive team to know what products they really offer. It is important for the sales team to go beyond what they are given in product brochures. It is important for the marketing team to know what they’re marketing (else they just spout garbage that no one listens to).

Kudos MongoDB for the smarts!