Comments on: New in MySQL 5.1: Sheeri’s Presentation

By: Slides & photos of L.A. Meetup presentations of Sphinx, Mysql Sandbox & MySQL 5.1 rolling in « MySQLTalk.com

Sun, 19 Apr 2009 05:12:34 +0000

[...] presentation was on “What’s new in MySQL 5.1″. Here are the slides in PDF, and notes via blog post. If you’re thinking about upgrading, check it out. I had read the release notes earlier but [...]

By: Heidi Schmidt

Heidi Schmidt — Wed, 18 Feb 2009 18:50:46 +0000

Thanks CaptTofu. Much appreciated. I will email you follow up offline that fills in what I attempt to explain below.
To explain… Yes, we pass the federated flag on startup. A developer created tables that were meant to be federated in dev, yet without the federated engine enabled the object in dev defaulted to InnoDB (the engine specified in our my.cnf that defines what any object defaults to unless specified)
The parent database has the correct federated setup for the table and has the engine enabled on startup. When the developer created the dev target table in dev it defaulted to InnoDB. A side effect is that the information_schema meta data gets skewed and will intermittently give an error on read of some (not all) information_schema tables “ERROR 1431 (HY000) at line 1: The foreign data source you are trying to reference does not exist. Data source error: error: 1054 ‘Unknown column ‘column_name’ in ‘field list’” and then no metrics are able to be gathered as a result.

By: CaptTofu

CaptTofu — Wed, 18 Feb 2009 16:36:04 +0000

Heidi,

I was one of the developers on Federated. I’m not sure exactly what the problem is that you are having when you say “â€“federated, wasnâ€™t passed on startup” do you mean that federated is not enabled on MySQL startup and that you create a table with “engine=’federated’” and it silently fails and creates instead using the default engine, though information_schema still thinks that it’s a federated table?

As far as consistency checks, the only consistency check that is performed is whether the table exists or not, both when the table is created and when it is opened. There’s nothing to ensure that columns match up- which is part of the Federated spec that says a Federated table doesn’t know how it’s remote table is stored. Though, maybe a that’s something that could be added as an option down the line.

Feel free to shoot me an email at patg at patg dot net. I intend Next month to jump-start federated development. I’m currently finishing a book after 10 months and have neglected Federated.

By: Heidi Schmidt

Heidi Schmidt — Wed, 18 Feb 2009 14:34:51 +0000

A FYI regarding the use of Federated tables in 5.1.30
If the target and source don’t match up for whatever reason. Say, the engine –federated, wasn’t passed on startup and a table was created with the default engine defined in my.cnf
It can cause havoc where queries on the information_schema meta data will fail with vague data source errors. And it will also trip up mysqldump as well unless the tables are ignored.
It’s been making a challenge for me to report on InnoDB “data_free” aka data used space usage.
If anyone is using 5.1.31 and has any intel on Federated tables behavior and consistency checking I’m all ears.
Thanks, Heidi hschmidt@online-buddies.com

By: Log Buffer #130: a Carnival of the Vanities for DBAs

Log Buffer #130: a Carnival of the Vanities for DBAs — Fri, 09 Jan 2009 18:42:06 +0000

[...] Giuseppe Maxia, the Data Charmer, has a Q&A on MySQL 5.1, which clears up some unanswered questions in Sheeri’s post on what’s new in 5.1. [...]

By: Giuseppe Maxia

Giuseppe Maxia — Sun, 04 Jan 2009 15:40:56 +0000

Hi Sheeri.
I listed some specific Q&A related to this presentation in a blog post of mine:
http://datacharmer.blogspot.com/2009/01/q-on-mysql-51.html

Cheers

Giuseppe

By: Sheeri Cabral

Sheeri Cabral — Fri, 02 Jan 2009 23:06:29 +0000

Correction: In the video I say that the way MySQL used to determine a GA release was “no critical bugs.” I was reminded that the policy was “no known critical bugs”.

Releasing with critical bugs is not as awful as it sounds, because:

1) there have been more tests developed, so internal tests catch more than they did. This includes regression testing.

2) More people used 5.1 in beta, so there was more external testing going on.

Previous releases have gone GA and had critical bugs in it, though they weren’t known (whether some were known in 5.0 is a bit iffy, but definitely before 5.0 there were no known critical bugs). I’ve seen the list of the handful of critical bugs left, and they’re not bugs that affect common features — they’re somewhat obscure.