Open Database Camp was just over a week ago, Mar 16-17th at Harvard University, co-located with Northeast LinuxFest. We had a great lineup of speakers, and we have processed all 11 videos in record time! We got new video cameras at the beginning of the year, so the video quality and resolution is stellar, you can see everything. Here are the videos:
2013 Open Database Camp
and Related Northeast LinuxFest Videos
I have had a lot of folks wanting to know when talks would be during Open Database Camp, and we had enough space in the schedule that we did not need to vote on talks, so I present the Open Database Camp Boston Schedule, now online. Lots of MySQL talks, but also a Mongo talk thrown in for good measure! (still hoping to sneak a Postgres talk in…)
As with any conference schedule, this might change. See you at Harvard University in Cambridge on Saturday and Sunday!
Over at the OurSQL podcast, Gerry and I were inspired by the Percona blog post about MySQL 5.5 and 5.6 default variable values differences. We were going to do a show where we talked about that, but in researching that topic, we found there were lots (around 20 to be exact) of variables and a few features in MySQL 5.6 that are ignored, removed or deprecated.
These are variables that should be removed from your configuration so as not to cause warnings or errors. When I was writing up the show notes I realized that it was a pretty good list of variables, that anyone can just read – whether or not you are willing/able to listen to the 28-minute podcast.
So if you want to see the list of variables that are deprecated, removed and ignored, complete …
[Read more]At Confoo last week, I tried out a new presentation, called “Different MySQL Forks for Different Folks”. The idea was to explain the differences among all the forks – Drizzle, MariaDB, Percona and of course Oracle’s MySQL. But I did not just go into technical merit of each fork; I also explained the values of each company, as that can be a big decision in deciding what software to choose.
There are PDF slides and a video on youtube. But I wanted to put some of the links I used to gather information here, as an easy place for folks to come and click links if they like, or if they want to research on their own.
At the official Drizzle documentation:
What is Drizzle?
…
While many attendees are repeat offenders, if 2013 is your first MySQL conference and you are relatively new with MySQL (say < 2 years experience), it can be daunting to determine which of the 8 or more concurrent sessions you should attend during the conference.
Here are my top recommendations that give you a good grounding in the various conference topics and a wealth of experience from known MySQL authorities, on important topics.
This month is a special month. It’s not because of President’s Day or even the exciting day where we revel in groundhogs. No, this month is special because the free book give-away is happening again. This is where you, the reader, gets to win something free for doing nothing more than posting a comment saying that you want a copy of my recently published book – The InnoDB Quick Reference Guide from Packt Publishing. The book is a great reference for DBAs, PHP, Python, or Perl programmers that integrate with MySQL and want to learn more about the InnoDB database engine.
So, all you have to do is post a comment here saying that you want a copy and write out a single (or more) sentence about how you use InnoDB in your development or production environment. At the end of the month two readers will be chosen via a random list sorting script that …
[Read more]When evaluating a MySQL system one of the first things to look at is the MySQL error log. This is defined by the log[_-]error variable in the MySQL Configuration file. Generally found like:
grep log.error /etc/my.cnf log_error=/var/lib/mysql/logs/mysql_error_log log-error=/var/lib/mysql/logs/mysql_error_log
It is possible to find multiple rows because this could be defined in the [mysqld] and [mysqld_safe] sections. It is also possible it is incorrectly defined twice in any given section.
Immediately I see a problem here, and the following describes why. If you look at this file name, in this case it’s actually found, but the file is empty.
$ ls -l /var/lib/mysql/logs/mysql_error_log -rw-r----- 1 mysql mysql 0 Feb 19 20:35 /var/lib/mysql/logs/mysql_error_log
An error log should never exist and be empty, because starting the instance producing messages. An error log could be empty because the system does …
[Read more]
Many users of MySQL install and use the standard directories for
MySQL data and binary logs. Generally this is
/var/lib/mysql.
As your system grows and you need more disk space on the general
OS partition that commonly holds /tmp, /usr and often /home, you
create a dedicated partition, for example /mysql. The MySQL data,
binary logs etc are then moved to this partition (hopefully in
dedicated directories). For example data is placed in
/mysql/data.
Often however, a symbolic link (symlink) is used to so MySQL
still refers to the data in /var/lib/mysql.
When it comes to removing the symlink and correctly configuring MySQL, you first stop MySQL and correctly defining the datadir my.cnf variable to point to the right location. However, MySQL still keeps the legacy directory information around and this will cause MySQL replication to fail in several ways when you attempt to restart your MySQL instance.
The binary …
[Read more]
When you enable binlogs in the my.cnf file you can either set the
log-bin flag to true, or you can set it to a path and file name
prefix such as this:
[mysqld] log-bin=/path/to/binlogs/mysql-binlog
This changes the default location where binlogs are stored.
The problem is that when you connect to mysql there is
currently no way to query the server to find out if that path
has been changed, and what it currently is. This means
you can't be sure where any server's binlogs are actually
stored.
Ok, so they're not really missing, but it's a known issue that
mysql doesn't make them easy to find. The server obviously
knows the path internally, but it doesn't make this information
available. Bug #35231 has been open on this issue since
2008 and is currently being ignored.
Why?
This is such a trivial change …
On a RHEL 6.3 server, we are running MySQL 5.1 (not MariaDB, not the Percona patched version, plain old regular MySQL):
$ rpm -qa | egrep -i "percona|maria|mysql" | sort
mysql-5.1.61-4.el6.x86_64
mysql-libs-5.1.61-4.el6.x86_64
mysql-server-5.1.61-4.el6.x86_64
percona-toolkit-2.1.8-1.noarch
percona-xtrabackup-2.0.5-499.rhel6.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
$
We went to do a system update today, and had a problem with dependencies, because the Percona repository wants to replace mysql-libs with Percona’s shared libraries. How rude!
# yum update mysql-libs
Loaded plugins: downloadonly, rhnplugin, security
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package Percona-Server-shared-51.x86_64
0:5.1.67-rel14.3.506.rhel6 will be obsoleting
---> Package …