A colleague and I have been looking at GTID on MySQL recently and you may be interested in the blog post that results from that. You can see it here. http://blog.booking.com/mysql-5.6-gtids-evaluation-and-online-migration.html.
A colleague and I have been looking at GTID on MySQL recently and you may be interested in the blog post that results from that. You can see it here. http://blog.booking.com/mysql-5.6-gtids-evaluation-and-online-migration.html.
Madrid MySQL Users Group will have its next meeting on 20th March. Details can be found on the group’s Meetup page.
I will be giving a presentation on MySQL replication hopefully aimed at all levels, but covering some details relevant to larger setups. The meeting will be in Spanish.
Look forward to seeing you there.
La próxima reunión de Madrid MySQL Users Group tendrá lugar el jueves 20 de marzo. Se puede encontrar más detalles en la página del grupo. Ofreceré una presentación sobre replicación de MySQL dirigido a gente de todos los niveles, pero incluirá información relevante a entornos más grandes. La presentación será en español.
Espero veros allí.
MySQL 5.6 has been GA for just over a year now. See MySQL 5.6.10 Release Notes. Congratulations on your birthday! That is quite a long time. I was using it earlier in production because it worked and could do things that 5.5 could not do, but earlier versions were to use at your own risk, and indeed if prodded incorrectly would fall on the floor. That is fair enough because they were work in progress, yet if you poked them the right way they did a very good job. Those dev versions have been long since upgraded which is good so they do not need quite as much care and attention.
So from where I see 5.6 it works very well. One big change that has made a large difference but which I think a lot of people may not really understand or use is the performance_schema database. That provides a huge amount of great and detailed information about what the server is doing, where it is busy and why, and allows you to know these things rather than twiddle and guess which in the past we have been forced to do. So a big thanks for that. It does require quite a lot of study and Mark Leith’s dbahelper goes a long way to making PS useful to the average DBA. A recent issue came up and I was asked (by Oracle support) to use it to find out the causes: a few SELECTs and hey presto the answers were staring me in the face. So Oracle is eating its own dog food and it tastes nice… If you have not had time to look at performance_schema or dbahelper yet take a poke.
The current MySQL 5.6 GA version (5.6.16) is pretty good now. I am aware of a few bugs which I am waiting to get fixed, but all in all the version works pretty well and I am happy with it. I have filed quite a few feature requests and the reason for these is often to make my day to day life a bit easier, as when MySQL breaks, and as you watch over more servers this happens, things which might not bother other people become more of a problem. This includes better logging, addition of counters to measure more things which help when problems occur or to diagnose how frequently a problem might be happening and now this information is missing.
I am still working on getting systems upgraded to MySQL 5.6 and have some work to go. It is surprising just how long this can take, but that is often due to changes in a growing business which means that new systems appear, changes happen to existing ones and the time needed to get the MySQL 5.6 upgrade tasks done gets a lower priority than ideally I might like. That said MySQL 5.5 works and works well but 5.6 does have new things I want and shortly those remaining systems will have been upgraded and the job will have been done.
Well not quite. Recently I have been looking at 5.7 DEV. A lot of work is going on there. Some of this is to give us new features that I have wanted for some time:
So a lot of these new features look quite juicy and more stuff will probably arrive in 5.7.4, so the GA version, when it arrives, is going to be good.
One thing that I have been looking at recently is GTIDs in MySQL. This is quite a topic in itself. Oracle has implemented this in 5.6 a certain way and in MariaDB 10 (currently DEV version) the implementation is approached differently, so that should prove quite interesting as neither mode is compatible. The end result that DBAs want is to ensure that it is easier to synchronise the state of master and slaves, and to prevent the re-application of transactions that have already been applied to a system. As it will soon be possible to replicate from multiple sources in MySQL and MariaDB then this topic will become more tricky and help from the “system” is much appreciated.
That said while I have used GTID a little on a few systems and it does seem to work and make life easier, it is not quite as nice and easy to use as one would like. Work seems to be ongoing in that direction to improve things and in helping us make the transition from a non-GTID environment to one which is GTID aware. All that help is most appreciated.
For a replicated MySQL environment that has to run 24 x 7 x 365 downtime is painful to a DBA, and expensive to a business. Things do break. We expect that, whether that is due to bugs, hardware or even human failure. We then need to be able to recover these systems as best as we can, as quickly as we can and once we have done that be confident that we understand what broke, what damage was done and what further work may or may not be required to complete the job. So if replication uses GTID that focus has to be understood and taken into account by the developers, and support for GTID should cover those needs. That is vitally important.
All in all I am looking forward to the preparation for the next GA version of MySQL even if it is still maybe more than 6 months away. It is a bit like planning your summer holiday in the cold winder. Lots of things to look forward to, plenty of interest in trying them, and the slight frustration you have to wait just a little bit longer before that time comes. I’m looking forward to the sun already…
I’ve just updated my RPMs to now support postfix-2.10. The Source and binary RPMs (for RHEL5 and RHEL6 x86_64) can be found at the following location http://ftp.WL0.org/official/2.10.
As you probably are aware I am not really following postfix development any longer, but I was recently asked about an issue for an older version, so if you still use these packages and see any issues please let me know and I will try to address them.
Yesterday we had our third Madrid MySQL users group meeting. That was quite interesting. Thanks go to Juan for his presentation.
We plan the next meeting on January 16th after the New Year is out of the way. If you are interested in MySQL and happen to be in Madrid please consider coming to see us.
More information about the next meeting can be found on the group’s web page. Note: The meeting will be in Spanish. I look forward to seeing you.
I was really pleased to see the announcement by Oracle MySQL yum repositories that they have now produced a yum repository from where the MySQL RPMs they provide can be downloaded. This makes keeping up to date much easier. Many companies setup internal yum repositories with the software they need as then updating servers is much easier and can be done with a simple command. For many people at home that means you set this up once and don’t need to check for updates and do manual downloads, but can do a quick yum update xxxx and you get the latest version. Great! This new yum repository only covers RHEL6 did not include RHEL5 which is not yet end of life and still used by me and probably quite a lot of other people. I filed bug#70773 to ask for RHEL5 support to be considered, especially as it was being provided already, and asked for them to also consider including 5.7, but have been told that RHEL5 support will not be added. As you will see later perhaps it is now clear why.
I was somewhat surprised then to read a later post Updating MySQL using official repositories which showed that actually the rpms in this new repository are completely different to the previous ones (MySQL community rpms) that we have been downloading from http://dev.mysql.com/downloads/mysql/#downloads. The package names differ being MySQL-server…rpm, MySQL-client…rpm on the latest page whilst the package names in the new yum repository are named mysql-community-client…rpm, mysql-community-server…rpm, etc. It looks like these packages are incompatible, thus for those of us already using the first set of RPMs the new yum repository is rather useless, and switching from one set of RPMs to another is quite a nuisance if you have a number of servers.
To avoid confusion in any later comments in this article I will refer to the ORIGINAL MySQL packages as the ones provided by Oracle previously and the NEW MySQL packages as these new ones provided in the new yum repo.
No mention of these differences was made by Oracle in their announcements, so obviously no reasons were given for why they might have chosen to name packages differently and not simply provided a yum repository containing the existing packages they have already built. That is what I had assumed they’d done and would have seemed to have been the most logical step to take.
Independently of the reasons that Oracle has decided to build two sets of RPMs, one thing is clear: They now have to maintain 2 different sets of package for the same distribution (RHEL6) in parallel. It also brings up the question of what will happen with MySQL 5.7 that is out there already being offered in the ORIGINAL packaging format and whether or not new 5.7 packages will be provided in ORIGINAL or NEW versions or both…. I have been trying out the current DEV version of 5.7 and indeed I know that 5.7 can change anyway Oracle chooses until they declare the version GA, so fair enough. The only thing it does is raise doubt about how to prepare for that moment as MySQL 5.7 has many interesting features and some of us way want to use those as soon as possible.
Anyway I digress. I thought that I would see what differences there may be between the src rpms of the ORIGINAL and NEW packages. As the src rpms are available I was able to download these packages to see. One would expect them to be pretty much the same, as after all the software is the same. It is also true that the NEW packages must provide support for Fedora releases so some changes would have been necessary to make that work correctly. Other than that I would not expect many differences.
I downloaded the src rpms from both locations, the original sets of MySQL community rpms has a package named MySQL-5.6.14-1.el6.src.rpm, and the new yum repo version is called mysql-community-5.6.14-3.el6.src.rpm. There’s a minor release difference here but that difference should be easy to see in the spec file.
I installed the src rpm which basically unpacks it ready for building. Given I have setup my rpm directory structure to install the src packages into a directory named after the package it is quite easy to then compare the resulting files contained in the source rpm. The source rpm normally contain the spec file which defines how the package should be built, the original source tarball files and any patches that may need applying to the original source files to build the final binaries.
The results can be seen below with the first listing being from the ORIGINAL src rpm and the second from the NEW src rpm:
$ <strong>ls -l MySQL/</strong>
-rw-r--r-- 1 sjmudd sjmudd 80764 Sep 10 09:43 mysql.5.6.14.spec
-rw-r--r-- 1 sjmudd sjmudd 36005278 Sep 10 09:43 mysql-5.6.14.tar.gz
$ <strong>ls -l mysql-community/</strong>
-rw-r--r-- 1 sjmudd sjmudd 160 Oct 16 13:11 filter-provides.sh
-rw-r--r-- 1 sjmudd sjmudd 159 Oct 16 13:11 filter-requires.sh
-rw-r--r-- 1 sjmudd sjmudd 919 Oct 16 13:11 my_config.h
-rw-r--r-- 1 sjmudd sjmudd 23994221 Oct 16 13:11 mysql-5.1.70.tar.gz
-rw-r--r-- 1 sjmudd sjmudd 8403 Oct 16 13:11 mysql-5.6.14-mysql-install.patch
-rw-r--r-- 1 sjmudd sjmudd 59388513 Oct 16 13:11 mysql-5.6.14.tar.gz
-rw-r--r-- 1 sjmudd sjmudd 37 Oct 16 13:11 mysql.conf
-rw-r--r-- 1 sjmudd sjmudd 607 Oct 16 13:11 mysql_config.sh
-rw-r--r-- 1 sjmudd sjmudd 1058 Oct 16 13:11 mysqld.service
-rw-r--r-- 1 sjmudd sjmudd 640 Oct 16 13:11 mysql-embedded-check.c
-rw-r--r-- 1 sjmudd sjmudd 56865 Oct 16 13:11 mysql.spec
-rw-r--r-- 1 sjmudd sjmudd 1422 Oct 16 13:11 mysql-systemd-start
As you see there are several differences just in the number of files that are being provided. It is nice to see that the NEW package actually contains an older version of mysql (5.1.70) which I’m assuming is used to build the older “shared-compat” libraries. That was missing from the ORIGINAL package and actually meant that it is not completely possible to build the ORIGINAL package binaries only from the src.rpm.
Some of the files in the NEW package are clearly for Fedora’s new systemd, which is the replacement for the traditional init scripts.
I also diff’d the spec files, and there you see several differences. One surprising one is there’s a difference in the licensing: The ORIGINAL rpms have a GPL license specified, whilst the NEW rpms have a GPLv2 license. Oracle never changes things without a reason and I know there have been many discussions on the topic of GPLv2 vs GPLv3 so I wonder why this change exists.
There are quite a lot of other differences in the 2 spec files, some changes seems insignificant but others may not be. I have not had the time to investigate further.
Many of you may remember that we have had bugs related to Oracle releasing multiple tarballs of the same name but having different checksums. Unlike some other package managers, RPM is not good at noticing or recording these differences so they can go unnoticed. I actually filed a feature request to RH to see if this may get fixed. That is their bug#995822. If you think this may be useful please tell RedHat.
That feature request refers to bug#69512 where this issue came up and I noticed it again in bug#69987 in September. Oracle said they would ensure they would not distribute source tar balls with the same name and different contents to avoid the confusion that can result from this. It seems they have already forgotten as I see:
$ <strong>md5sum MySQL/mysql-5.6.14.tar.gz</strong>
$ <strong>md5sum mysql-community/mysql-5.6.14.tar.gz</strong>
So yes, it seems they have done this again. I know that they build from a VCS but if they tag something as 5.6.14 it really helps to have a single tar ball that refers to that tagged version. I haven’t bothered to do a diff between the 2 tarballs but can imagine the new tarball is somewhat more up to date than the last one. However, that is really no excuse. So time to file yet another bug report which I have done with bug#70847.
In the end it seems that Oracle is trying to do the right thing and make life easier for us. That is welcome. However, they seem to trip up making that effort. Things need not be this complicated.
I had a quick check of the differences in the 2 tarballs which are hugely different in size:
$ <strong>diff -uNr ORIGINAL NEW | diffstat</strong>
CMakeLists.txt | 2
Docs/ChangeLog | 57
Docs/INFO_SRC | 10
Docs/mysql.info |31803 +++++++-----
INSTALL-SOURCE | 40
man/comp_err.1 | 4
man/innochecksum.1 | 4
man/msql2mysql.1 | 4
man/my_print_defaults.1 | 4
man/myisam_ftdump.1 | 4
man/myisamchk.1 | 7
man/myisamlog.1 | 4
man/myisampack.1 | 4
man/mysql-stress-test.pl.1 | 4
man/mysql-test-run.pl.1 | 4
man/mysql.1 | 4
man/mysql.server.1 | 4
man/mysql_client_test.1 | 4
man/mysql_config.1 | 4
man/mysql_config_editor.1 | 4
man/mysql_convert_table_format.1 | 4
man/mysql_find_rows.1 | 4
man/mysql_fix_extensions.1 | 4
man/mysql_install_db.1 | 4
man/mysql_plugin.1 | 4
man/mysql_secure_installation.1 | 6
man/mysql_setpermission.1 | 4
man/mysql_tzinfo_to_sql.1 | 4
man/mysql_upgrade.1 | 32
man/mysql_waitpid.1 | 4
man/mysql_zap.1 | 4
man/mysqlaccess.1 | 4
man/mysqladmin.1 | 4
man/mysqlbinlog.1 | 4
man/mysqlbug.1 | 4
man/mysqlcheck.1 | 4
man/mysqld.8 | 4
man/mysqld_multi.1 | 4
man/mysqld_safe.1 | 6
man/mysqldump.1 | 14
man/mysqldumpslow.1 | 4
man/mysqlhotcopy.1 | 4
man/mysqlimport.1 | 4
man/mysqlshow.1 | 4
man/mysqlslap.1 | 4
man/mysqltest.1 | 4
man/ndb-common-options.1 | 4
man/ndb_blob_tool.1 | 4
man/ndb_config.1 | 6
man/ndb_cpcd.1 | 4
man/ndb_delete_all.1 | 4
man/ndb_desc.1 | 4
man/ndb_drop_index.1 | 6
man/ndb_drop_table.1 | 4
man/ndb_error_reporter.1 | 216
man/ndb_index_stat.1 | 4
man/ndb_mgm.1 | 4
man/ndb_mgmd.8 | 4
man/ndb_print_backup_file.1 | 4
man/ndb_print_schema_file.1 | 4
man/ndb_print_sys_file.1 | 4
man/ndb_restore.1 | 12
man/ndb_select_all.1 | 4
man/ndb_select_count.1 | 4
man/ndb_setup.py.1 | 4
man/ndb_show_tables.1 | 4
man/ndb_size.pl.1 | 4
man/ndb_waiter.1 | 4
man/ndbd.8 | 4
man/ndbd_redo_log_reader.1 | 4
man/ndbinfo_select_all.1 | 4
man/ndbmtd.8 | 6
man/perror.1 | 4
man/replace.1 | 4
man/resolve_stack_dump.1 | 4
man/resolveip.1 | 4
mysql-test/collections/default.release.done | 2
packaging/rpm-fedora/CMakeLists.txt | 36
packaging/rpm-fedora/my.cnf | 31
packaging/rpm-fedora/my_config.h | 30
packaging/rpm-fedora/mysql-5.6-libmysqlclient-symbols.patch | 1038
packaging/rpm-fedora/mysql-5.6.14-mysql-install.patch | 239
packaging/rpm-fedora/mysql-embedded-check.c | 26
packaging/rpm-fedora/mysql-systemd-start | 52
packaging/rpm-fedora/mysql.conf | 1
packaging/rpm-fedora/mysql.spec.in | 1623
packaging/rpm-fedora/mysql_config.sh | 28
packaging/rpm-fedora/mysqld.service | 48
packaging/rpm-oel/CMakeLists.txt | 37
packaging/rpm-oel/filter-provides.sh | 6
packaging/rpm-oel/filter-requires.sh | 6
packaging/rpm-oel/my.cnf | 31
packaging/rpm-oel/my_config.h | 30
packaging/rpm-oel/mysql-5.6.14-mysql-install.patch | 239
packaging/rpm-oel/mysql-embedded-check.c | 26
packaging/rpm-oel/mysql-systemd-start | 52
packaging/rpm-oel/mysql.conf | 1
packaging/rpm-oel/mysql.init | 209
packaging/rpm-oel/mysql.spec.in | 1558
packaging/rpm-oel/mysql_config.sh | 28
packaging/rpm-oel/mysqld.service | 48
scripts/fill_help_tables.sql | 18
sql/sql_yacc.cc | 4428 -
sql/sql_yacc.h | 4
105 files changed, 27417 insertions(+), 14925 deletions(-)
Despite what looks like a large change set it seems most of the changes are in the documentation (mysql.info and man files) and these seem to be due to the fact that the source files have been regenerated between the tar balls, most of the changes are thus spacing or generated timestamp differences. Also mysql-5.1.70.tar.gz is included in the new mysql-5.6.14.tar ball so really there’s no need for it to be included separately in the mysql-community 5.6.14 src.rpm. That is likely to be an oversight and will no doubt get corrected.
My conclusion is that simply the mysql-community version of the mysql-5.6.14.tar.gz tar ball is simply more up to date than the one provided in the MySQL-5.6.14 src rpm. So perhaps much ado about nothing. That said a few questions remain unanswered so it will be interesting to see how things develop.
If you happen to have some free time tomorrow and are in Madrid please come along to the second Madrid MySQL Users Group.
Details can be found here. The meeting will be in Spanish. I look forward to seeing you.
I have been meaning to sit down and write about this for a while now but with the summer upon us have not had time.
I use CentOS 6 on my home PC for many reasons, but mainly because I have been using RedHat versions of Linux for quite a long time and am comfortable with it. CentOS, like its upstream parent RHEL, is good because it is well tested and stable and it is not absolutely necessary to perform a major version update every few months like its cousin Fedora. I do not have time for that and most security issues will be fixed with normal updates so this works well.
The downside of course is that RedHat can not afford to run bleeding edge versions of software which may be rather unstable and that can be a nuisance, if you need or want to use newer more recent versions.
An example of that, from my DBA perspective, is the version of MySQL which is shipped with RHEL 6.4: MySQL 5.1.66 is very old and I would not really want to run that on a production machine taking anything but toy load. However, in this case, others provide drop-in replacements: Oracle with MySQL 5.6 (current GA version) and both MariaDB and Percona versions are other good alternatives.
In the browser world I moved over some time ago to use Chrome. It seems to work well on my Mac and at the time I moved over it avoided me having to restart Firefox frequently as it was eating all my memory. There have been versions of Chrome available for CentOS 6 until rather recently, provided by Google and that was really good. It made life easy and I could switch machine with little trouble and use the same browser.
There are versions of Chrome for other Linux versions: Debian, SuSE and Fedora, but I want to keep using CentOS 6 for the reasons outlined above. Judging from other posts I have seen others feel the same. My understanding is that CentOS 6 support was dropped as newer libraries on which it depended were not available on CentOS 6: Requires: libstdc++.so.6(GLIBCXX_3.4.15)(64bit) says rpm when you try to install the latest version.
Upgrading the OS versions of these base libraries is just troublesome as it may break several things and while people sometimes do this to try and work around similar issues I do not think that is the way forward. Something will eventually break. Yet if these libraries are needed why can they not be built and located like google-chrome itself in a different location to the system default, and then link google-chrome using RPATH settings to the expected directory. I have done some stuff like this before in a previous job and unless I am mis-remembering the procedures this should work fine. Rebuilding the required libstdc++ in a different location to the default, such as /opt/google/lib64, and naming it something like google-libstdc++, and then adjusting the google-chrome dependencies to require this package and not the system libstdc++ is not really that hard. Doing so would fix the issue for google-chrome, and potentially make the library usable for others who might also want this newer version on CentOS. Given Google has already setup a yum repo for CentOS 6, the automatic install of these new dependencies would just work out of the box.
Others suggest moving over to Chromium, but I see it is not the same as Chrome and has given me a few issues since switching from Chrome. I would like to use the same browser on my different desktops and not have to worry.
It would also help if RedHat would recognise that some people will need to use newer versions of libraries that come with the OS, and if they do not want to make the effort to support this themselves, it would help if they would perhaps make recommendations on how this can be done by others, perhaps along the lines outlined above. In the end for them this avoids people being frustrated that their “stable OS” is not out-of-date, and also avoids issues with people hacking things around themselves, or resorting to building from source, when the whole point of a package based system is that you should not need to do that and the packaged builds tend to be more consistent and complete.
So here is to keeping my fingers crossed that perhaps we will see Chrome on CentOS 6 return in the future and make a few people happier.
What do you think?
My MySQL bugs is a list I recently created and intend to keep up to date with issues I have seen.
As mentioned here and after talking to a few people we have created a meetup page, http://www.meetup.com/Madrid-MySQL-users-group/ and proposed the first meeting on Thursday, 4th July. If you are interested and in the area come along and say hello. It should be interesting to see a few others who work in the field. If you can let us know you are coming so we have an idea of how much interest there is.
Once upon a time I did an operating system upgrade, a minor one that should do no harm, but just get me up to date by fixing any bugs in the version I had been using. It seemed like a good idea.
All seemed to be fine. I use a package provided by an external vendor and not the one produced by the operating system provider as this vendor provides a newer version of the package and I need that. The vendor has to make his package fit in the os environment his package is built for and normally does a pretty good job.
I use automation to build my systems and when I built a new one some issues appeared. Related to the new version of the OS the provider had enhanced one of his packages and the installation pulled in new dependencies. The install of the external package I use then broke as it conflicted with the new dependency provided by the OS. While a workaround is possible: uninstall this, install that, … the nice world the package manager provides you to make these problems a non-issue was suddenly broken. Horrible.
To make matters worse the external vendor can not easily fix this. If he builds a package which obsoletes this new dependency then in earlier versions of the OS he changes stuff that is not needed. If he does not do this the breakage remains in this latest version. Of course in the real world many people use a mixture of OS versions and expect a single package to do the right thing at least for the same major version of an operating system. An external vendor’s packagers life is not a happy one. It’s hard to provide a package that integrates seemlessly without it breaking something.
The story above is a real story relating to RHEL 5.9 versus the previous RHEL 5.8, or CentOS in my case and MySQL 5.5 and 5.6 rpms provided by Oracle. RedHat have enhanced the version of postfix they provide (a core component of the servers we use) and added MySQL library dependencies which were not there in RHEL 5.8. This pulls in the ‘mysql’ package as a dependency, and so installing the MySQL-server, MySQL-client and MySQL-shared-compat libraries I had been using breaks as these do not currently have an rpm “Obsoletes: mysql” entry needed to make the package install go nice and smoothly.
Real life means I do not run the latest version of MySQL 5.5 but a version which works on my systems and has been tested with my software, so if I use that on CentOS 5.9 now it will break. Oracle may not mind having to update their latest MySQL 5.5 rpm (for CentOS 5) but are unlikely to be interested in updating all their previous MySQL 5.5 or 5.6 rpms for this version of CentOS just in case I might be using one of their older versions. I also am not interested in upgrading all these MySQL 5.5 servers just to get a newer version which may have issues, so probably I will end up doing a work around “remove this package”, “add that one” in a adhoc way to avoid this problem. It should not be necessary.
It has always been stated when building software: do not make functional changes in a minor version upgrade as you will break something somewhere and upset someone. I understand that providing MySQL support to postfix (and perhaps other packages) seems like a good idea but this breaks this “rule”. I also think that having to provide a package within an existing OS framework, and try to avoid breaking any native OS packages is hard, but still think as I have commented in previous posts that coming up with a way of allowing external vendors a way to do this which does not interfere with “native OS” packages would be good. Recommend that these packages get named a certain way, do not get located in “native OS” locations, and do not conflict with “native OS” libraries.
If people want to use these packages show them how to link against them and add dependencies in a way which may favour these vendors’ packages if that’s a deliberate intention. Provide these rules and life will be easier for all of us. One world where this is done is the *BSD ports systems, which are intentionally independent of the “native OS” and located separately and people can use them if needed, or not at their convenience. In my opinion something like that in the rpm world would be nice indeed and external rpm repos would not have to worry so much about adding new functionality and breaking the OS.
I am not fully sure how I am going to work around this issue, but it has been causing problems for a while now and will require some poking. I will try and get in touch with the parties concerned to alert them to this change which has broken something for me.
Am I the only one who has noticed this?
Also likely to be an issue I guess for MariaDB and Percona rpms for RHEL 5/ CentOS 5 as they’ll likely implement the same dependency behaviour.
This is what I saw:
2013-06-18 00:48:55 +0200 /Stage[main]/Mysql::Client/Package[MySQL-client]/ensure (err): change from absent to 5.5.23 failed: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y install MySQL-client-5.5.23' returned 1: Transaction Check Error: file /usr/bin/mysql from install of MySQL-client-5.5.23-1.rhel5.x86_64 conflicts with file from package mysql-5.0.95-3.el5.x86_64 file /usr/bin/mysql_waitpid from install of MySQL-client-5.5.23-1.rhel5.x86_64 conflicts with file from package mysql-5.0.95-3.el5.x86_64
On a server that runs MySQL 5.5.23 (CentOS 5.8) I see:
[myuser@myhost ~]$ <strong>rpm -q --obsoletes MySQL-shared-compat</strong>
which actually looks wrong. CentOS 5 does not have a mysql-libs package, but a package named mysql. CentOS 6 does have such a named package and on early releases of the MySQL 5.5 rpms some packaging issues similar to the one described here did have to be ironed out.
Checking a later package I see things have changed but there still seems to be an issue.
[myuser@myhost ~]$ rpm -qp --obsoletes MySQL-shared-compat-5.5.32-1.rhel5.x86_64.rpm
MySQL-shared-compat-advanced < 5.5.32-1.rhel5
MySQL-shared-compat < 5.5.32-1.rhel5
mysql-libs < 5.5.32-1.rhel5
The first two entries need fixing (first first needs no version and the second should not be there) as they cause other issues, but I had not noticed until now the package name mistake in the last line (which mentions a package in CentOS 6, not CentOS 5 and should be just ‘mysql’).
Maybe, given I am not using the latest version of MySQL, I will need to repackage this version myself. A quick change to the rpm spec file and a rebuild should give me the package I need. Given the src rpm is available it is good I can do that. …. but no. Further inspection shows that the MySQL-shared-compat package is not built from the MySQL-X.Y.Z-r.src.rpm but is built independently of it and I think old libraries files are “bundled” in manually to make this package. I vaguely remember that maybe the source tar ball has the spec file for this shared-compat package. Let me check as maybe I have to do some deeper magic to roll my own package.
Oracle: please do not do this. Provide enough of the source in the normal tar ball to be able to build the old version libraries, and build _everything_ from that single tar ball. This would avoid all the magic you are doing now to build this package and others who need to adjust these packages can do the same.
I’m interested in meeting up and sharing experiences about using MySQL and managing MySQL servers with people here locally in Madrid. I had a quick look around and could see no MySQL user groups locally, so it might be nice to create such a group and exchange ideas over a beer, coffee or cola every once in a while. If you’re in Madrid and are interested please let me know. I’ve created a temporary email address: madrid-mysql-users-2013 AT wl0.org (careful with the domain), which you can contact me on to confirm an interest. Oh and I’d expect these meet ups to be in Spanish, but that’s not a requirement.
Estoy interesado en reunirme y compartir experiencias sobre el uso de MySQL y administración de servidores de MySQL con la gente aquí en Madrid. He echado un vistazo en Internet y no he visto ningún grupo de usuarios de MySQL a nivel local, por lo que sería bueno crear un grupo e intercambiar ideas mientras tomamos una cerveza, un café o una coca-cola. Si estás en Madrid y estás interesado por favor házmelo saber. He creado una dirección de correo electrónico provisional: madrid-mysql-usuarios-2013 AT wl0.org (cuidado con el dominio), que puedes usar para ponerte en contacto conmigo para confirmar tu interés en asistir. Estando aquí en España imagino hablaríamos en español.
Progress, slowly but surely. See: http://www.meetup.com/Madrid-MySQL-users-group/
I have been playing with ansible recently and quite like some of what I see.
One issue I have when setting up the ansible hosts file, which contains the inventory of all hosts known to ansible, is that at work my hosts have a slightly more complex pattern which ansible can not directly match, see http://ansible.cc/docs/patterns.html. So I patched 1.0 to cope with these.
This provides for:
The patch can be found here: http://merlin.wl0.org/201305/01/ansible-1.0-extend-patterns.patch and this allows me to include several types of servers at work in a simpler pattern more easily.
My python is still a bit rusty but this seems to do the right thing. It would be nice to see this patch incorporated into ansible.
I’ve just upgraded ansible on my Mac to 1.1 (via macports) and this patch hasn’t been applied yet. I think 1.2 is out soon so I’ll see if I can poke the developers to get this patch included. See: https://github.com/ansible/ansible/issues/3135
So the common solution is to artificially warm upthe server by doing queries which will fill the buffer pool. Typical solutions might be to do: SELECT COUNT(*) FROM some_table FORCE INDEX (PRIMARY) LIMIT ... on a number of tables to fill up the pool on startup. Fitting this into the standard mysql init start script is somewhat tricky as no hooks are provided for this sort of post-start action. (It would be nice to have this for other tasks too.)
MySQL 5.6 is out now and that is good news. I have already been using pre-GA versions on some production servers with good success and now that the few wrinkles I have seen have been ironed out, I am sure a lot of people will find the new features in 5.6 well worth waiting for.
However, that does lead to the question of: “what next?”
I still have several things that I would like to see in MySQL in no specific order of preference such as:
So these are just a few of the ideas I personally would like to see. I’ll see if I can update the post later providing some of the feature request bug reports as reference.
However, this is just part of the story. I have my ideas of what I would like to see in MySQL 5.7 and you have yours, but there does not appear to be a way currently with MySQL to voice interests to Oracle in a place where different people can be heard and it is possible to see what is most wanted.
My way of using MySQL may vary significantly to yours. My problems may also be quite different, but I would imagine that there is a lot of common ground. So what would you like to see in MySQL 5.7?
In the meantime I guess we will have to wait and see what will come out in 5.7 and where things are going to go. There’s likely I guess to be a 18 month wait for that, so plenty of time to do lots of new and exciting things. In the meantime MySQL 5.6 needs deploying on new servers once it has been fully tested and any issues resolved and that is quite a bit of work to keep me busy for a few days …
The blog title says it all: Do we need a MySQL Cookbook? I tend to think so.
This seems to be something that is missing with current MySQL documentation. There is lots of information available but finding the appropriate bit can be quite tedious and it often requires looking in multiple places.
A lot of other software has such books, but for some reason MySQL seems to be missing one.
A recent example comes from a “documentation feature request” I posted today: http://bugs.mysql.com/bug.php?id=68171. MySQL 5.6 provides a way to “move InnoDB tables” from one server to another. There are many reasons why you may want to do it, but the documentation is currently rather sparse. A simple “example recipe” for this would be good, as would an equivalent recipe for other engines where you can do this such as MyISAM. This is just an isolated example.
As far as I know there are no “best practices” on how to setup or manage a MySQL server, whether that come from Oracle, or the community. A common community view would probably be better as it makes “all vendors” work to a common goal, even if they compete in other areas. Look at the LSB as an example, adopted to some extent by all Linux distributions. And again often there may be several ways to solve some problems so a Cookbook would be quite nice as it would suggest how to solve common tasks and let you use those as the basis for real implementations.
So what things could these Best Practices or Cook book contain? Things that come to mind are:
What other things am I missing for a cook book?
I’m sure this list could include many other things and maybe there’s a need to avoid too many details, referring to existing documentation where appropriate for details, but just provide the recipes and the explication of why, how etc would be good for a large number of people. I for one have found from time to time that I could not find such a recipe to do a particular task, and I am sure there must be others like me with the same problem. Existing books are very good, but the focus seems to be slightly different and may go into a lot of detail when in some cases that detail may not be needed initially.
So would a cook book like this solve a need for you, and if so what might be missing from the suggestions I have made above?
After lots of pain and trying to get CentOS 6 to work on my Mac Mini mid-2011 and failing, I finally find that CentOS 6.3 does indeed install. Previous versions did not work for me, but I’m delighted to see that RedHat have done great work and the work they did that made it work on Fedora 17 has obviously been ported to CentOS 6. The issue in the past had been the Mac would not boot the install DVDs.
So all that was needed was for me to burn the (new?) CentOS-6.3-x86_64-netinstall-EFI.iso image, press ALT on boot and the DVD booted fine, and the install went along the same way as any normal CentOS/RHEL installation. In fact I’ve been able to keep my original Fedora setup as the Volume Group I’d previously had setup on my disk was recognised so all that I needed to do was to create a new “root” logical volume and install on to that.
So thanks RedHat. You now make it much easier for me to migrate my “main” but older system on to this Mac.
I saw a post on profiling memory usage today and this reminds me of several discussions I have had with different people.
Why would you want to profile the memory usage? Usually to see where memory is allocated and for what purposes, and usually you only care when memory usage is higher than expected. That is a DBA normally wants to use all available memory on a server for mysqld, whatever that size may be.
Configuration parameters may be inappropriate and need adjusting, so having a way to determine the range of memory usage based on those parameters would be most helpful. However, the configuration parameters as a whole put no limit on memory used, so different workloads can quite easily lead to memory being insufficient on the OS, triggering swapping or perhaps the mysqld process to be killed by the kernel’s OOM. None of this is ideal.
So I would like to configure a cap on the maximum amount of memory that can be used and indeed that is what most RDBMSes do. That is the allocation is made on startup, ensuring the memory is available, and any memory requests are taken out of this pool. This technique _should_ avoid you swapping (though I still see issues on NUMA architecture boxes). It also means that at some points in time the database server may not be able to honour memory requests and therefore must fail, wait until those needed resources are available, or it must free existing resources to make space for the requested new resource.
Doing this well is probably hard enough. Doing it in MySQL with different storage engines is probably harder still as each engine does things its own way.
Some mechanism like that would certainly help avoid strange behavioural issues when the query profiles change and this causes the server to behave in unexpected ways, such as swapping itself to death. The only solution right now seems to be to configure the server to ensure that these “edge cases” can not happen by using less memory, thus wasting valuable resources on the server.
Currently it is also pretty hard to see how memory is used. If you use InnoDB you know that the buffer pool takes up a sizeable portion of memory, but there is still a significant amount of other memory that’s used by each individual connection and this can vary significantly depending on the query profiles. It would be really nice to dynamically look inside MySQL and see how memory is used, and also see how adjusting different parameters may adjust this.
Of course none of this is in MySQL at the moment. I would certainly like to see first better information on current memory usage, I would guess some more tables in performance_schema, and at a later stage some way to cap memory usage to a desired level, and hope that when those limits get reached mysqld will figure out how to free up some resources in order to continue, wait or fail “gracefully”.
Until then we will have to continue playing the game of “configure mysqld”. See if it works and then ensure that queries to the system do not change enough to break the system and require us to go back and do it all again.
Note: there are several feature requests for this, so I do not think I am the only one in wishing for more visibility and configurability of the memory usage.
Some feature requests that seem related to all this are shown below:
I have been using virtualisation at home for some time, since the days of vmware-server on Linux. It works well and if you have a sufficiently powerful box is a great way to experiment without destroying your own server or installing software which a few hours later you may want to remove again.
I also recently bought a Mac mini 2011, which I put in 16 GB of RAM and was hoping to set it up as a host to contain various virtual machines. This was going to run Linux. I wanted to run the host as light as possible and do the real tasks inside my virtual machines. I also wanted to use this server to migrate from an older PC I use for my day to day services (web, dns, email, ftp services etc).
Getting Linux installed on the Mac was a bit trickier than expected. I have been using RedHat since version 3.0.3 so prefer that to Debian or Ubuntu, if only because it is an environment that I am more familiar with. I tried in vain to get CentOS 6 to install on the Mac but it seems the required EFI boot loader does not work. Others have had problems too I think. Less surprising is that Ubuntu installed first time (credit to them for getting it to work on more exotic hardware), and when I tried Fedora 17 I saw that also worked, so that is what I am using. I would still prefer to switch to CentOS as it stays stable for longer, and playing the upgrade game with Fedora gets to be a pain. Maybe some time soon…
There is a lot of noise around now about cloud computing and I had wanted to use something a bit more sophisticated than virt-manager on my PC. This requires you to organise the exact setup of the boxes, network, disk images and other cloud platforms seem to make this management easier for you.
oVirt seemed promising and there is even a Fedora 17 repo and it is supposed to work out of the box according to various blogs and articles, but I had trouble getting it all up and running. If you run it on a single host it does require a lot of packages and software to be installed. So after various attempts I gave up.
OpenStack is also pretty hot and has quite good documentation, though it seems complex perhaps because of the scale that it runs on in some deployments. Again I read the manuals and documentation and had trouble getting the whole environment to work. The configuration is quite complex, and it seems easy to make a mistake. If you do that then figuring out what is broken or why is pretty hard. Again this is a shame especially as this seems to be perhaps the most sophisticated of the 3 cloud environments I tried.
Family circumstances mean I have a lot less time than I would like to investigate but I did do quite a bit of homework before starting so this has been quite frustrating.
I then tried OpenNebula, version 3.8.1. It seems that the software is still evolving quite quickly so has evolved quite a lot over time. It also seems that this is the smallest package: the tar ball is tiny and at least on Fedora 17 it did not take me long to get the software installed (including sunstone-server). I see this is tagged to be included in Fedora 17 but could not find actual packages to install.
There are quite a few howtos and tutorials but for OpenNebula, but some of these are for older versions, and if you follow them thing will not work as expected. (Differences in the templating options etc.) This is confusing for a new user.
I use Fedora 17 but do not see packages for OpenNebula. Working packages for Fedora, CentOS, Ubuntu etc would be most welcome as this would probably ensure that the different components were configured correctly with the OS components like virt-manager etc.
Most of the OpenNebula daemons have start and stop commands but no status command. This would at least allow you check that the configuration was correct and the daemons correctly started, especially when doing manual installs.
I would like to see some sort of “check installation” command to allow for a more complete set of checks to be done to see if the installation is correct and complete, for each of the different components that makes up or is needed by OpenNebula. In many places the documentation says “Assuming you have a correct kvm setup …”, “Assuming you have a correct isci setup …”, etc, yet provides no way for you to check if the setup of these base components actually works as required by OpenNebula. Whether that documentation is included in the documentation or on a wiki somewhere “How to setup kvm on Fedora X for OpenNebula….” I do not really mind but I have had problems with PolicyKit not allowing oneadmin access to the virtual machine, with the virtual machines not seeing their disks (I think due to user/group permissions, as on Fedora 17 kvm seems to assign file ownership as qemu:qemu.), with the VNC connections in Sunstone not working, and I am pretty sure that most of these issues are “trivial” to fix if you have done this before and understand what OpenNebula expects and what the host operating system is doing “incorrectly”.
For initial testing including various standard template files which would useful, if only to allow helping to confirm simple things like:
I was confused by the network documentation and exactly how that relates to the underlying host’s network configuration. This does not seem to be well documented but “assumed”.
To summerise these technologies are here and being used quite widely, but I would guess in larger environments where the people using them have time to investigate and set things up properly. I was hoping that to set these up at home would not be that hard, but have found it much harder than I had anticipated to do this just reading the documentation and trying on my own. I think that all these platforms would be used more widely if they were more plug and play, that is they worked out of the box on most of the popular Linux distributions.
Having said that things have obviously progressed since the first virtualisation environments were created (on the x86 architecture) and probably in no time at all these technologies or similar will just work out of the box and be the norm. In the meantime I am going to keep poking away and hope to finally get one of these environments working for me.
So if you read this and have some useful pointers I would be most interested in using them to get up and running.
I see the OpenNebula work originally planned for Fedora 17 is now delayed (see: https://bugzilla.redhat.com/show_bug.cgi?id=815001), but there are RPMs for CentOS 6 which can be found or built from here: https://nazar.karan.org/summary/misc!opennebula.git. So it looks to me as if it’s likely I will soon be able to get some packaged version of OpenNebula working on my CentOS 5 and Fedora 17 home PCs some time soon. Still trying to make progress in the meantime.
Not much to add really to the bug I’ve filed here: bug#67159.
Again this GTID stuff looks good, but seems to prevent changes in the configuration of performance_schema, which I think is not appropriate, especially as P_S now has lots of extra goodies and after 5.6 will surely have even more.