MySQL 5.1 Refresh

I've been following MySQL 5.1 for awhile now. It has many interesting/exciting features and improvements, but I have had a long-standing view that it was released too early and is not production ready. With the partial release/sneak-beta of MySQL 5.4, a performance-centric release based on 5.1, I've decided to take a look at the bugs I've been following in 5.1 and re-evaluate its production ready-ness.

I've been watching a set of bugs in 5.1 for awhile now and many have been closed. However, the following are still open and active.

Events - Mutex Deadlock
"When running mysql-5.1 with the new wrong mutex usage detector, several critical wrong use
of mutex was found in the event code. Any of these can lead to a deadlock when using
events in combination with show status, create database etc."

Replication - Rollback ineffective on slave
"If there is a trigger on an InnoDB table which updates a non-transactional (e.g. MyISAM)
table, changes performed on the InnoDB table get replicated and are visible on slave even
before a commit on master, and are not rolled back on slave after successful rollback on
master."
Note: While I follow this bug, its not a blocker. I don't view it as hugely important.

Partitioned table corruption on fs error
"if you try to rename a partitioned table, and a filesystem error occors during creation of
the 2nd (or nay later) of the MYD/MYI files for the partition, then reanme table will
leave some renamed and some not renamed files. => table is unusable"
Note: Patch has been written, but not pushed to a code tree.

Killing INSERT-SELECT causes corruption
Note: Patch written, but not pushed to a code tree.

kill + flush tables with read lock + stored procedures causes crashes!
"running stored procedures at the same time as flush tables with read lock and killing
connections leads to invalid reads of memory and crashes."

mysqladmin debug causes a crash when server is creating/dropping many tmp tables
mysqld-debug crashes with this stack trace when multiple threads are rapidly creating and
dropping temporary tables
NOTE: This doesn't sound important, but this bug is also triggered on SIGHUPs, such as those used for log rollover.

pthread related segfault
Crash on sighup, duplicate of above bug but it hasn't been marked as dup yet.

mysql server crash during update with join
"I can reproduce the bug by running a query manualy or via replication slave
UPDATE film_blok_rating r
INNER JOIN content ko USING (id_film)
INNER JOIN shop_price_relation sp USING (id_content)
SET r.status='ok', r.note='product'
WHERE r.status='no' AND sp.flag!='pred' AND sp.product_type_id IN (1,2,6,14,15)"

Server closes connections and restarts
"when I insert a field longer then max varchar field size mysql server closes all
connections and restarts."
Note: Patch accepted, but not committed

debug assertion and crash reloading grant tables after sighup
"1. Compile a debug binary
2. Run mysql-test-run.pl --start-and-exit --skip-ndb
3. kill -HUP the mysqld"
NOTE: Has not been reproduced on a non-debug build, but I'm watching for it.

Segfault with table corruption...not able to recreate table
"Create a table on the master which refreshes down to all the slaves every hour. Around the
hourly refresh when a session is accessing the data from the table the slave DB seems to
fail."

Innodb hangs leaving mysql datbase in corrupt state
"Have 8-10 db writes going simultaenously and peform complex query spanning 2-3 large
tables [100GB or more] . This will most of the time produce the same scenario as
described above."
Note: This his hard to reproduce, so its not that bad.

Query cache can lock up threads in 'freeing items' state
"The query cache can cause a lockup on a thread in some cases. The thread will be stuck in
the 'freeing items' state.
The threads are always in Query_cache::wait_while_table_flush_is_in_progress on the line
pthread_cond_wait(&COND_cache_status_changed, &structure_guard_mutex).
This seems to be directly related to the changes done for Bug #21074"

Large query cache still freezes server after fix for bug #21074
"Large query cache still freezes server after bug #21074 has been fixed if one issues UPDATE query."
Note: This is fairly easy to avoid

Summary:

Let me be entirely clear here, the MySQL dev team have closed _alot_ of bugs. Many of my long-standing concerns are gone. However, there are bugs in the above list I'm scared of. The two SIGUP reports in particular are very disturbing to me, as are the data corruption bugs. The query cache bugs are less important, but still annoying and as long as the server crashes are non-corrupting, they are less critical than some of the others. MySQL-5.1 is getting very close to something I want to start testing on my slave servers.....but not yet.

UPDATE: (some of these bugs have been closed and others have mitigation strategies. Below are the still active bugs with avoidance strategies)

Mitigation: Don't use 5.1 Events Support

Mitigation: Don't rename partitioned tables

Mitigation: No stored procedures.

Mitigation:.....?

Server closes connections and restarts
"when I insert a field longer then max varchar field size mysql server closes all
connections and restarts."
Note: Patch accepted, but not committed

Mitigation: Don't use user-defined collations.

Mitigation: Don't build with debug enabled.

Mitigation: Don't use truncate table in a replication environment

Mitigation: ....?

Mitigation: Apply patch here http://bugs.mysql.com/bug.php?id=43758

Large query cache still freezes server after fix for bug #21074
"Large query cache still freezes server after bug #21074 has been fixed if one issues UPDATE query."
Note: This is fairly easy to avoid

Mitigation: Don't have a huge query cache.

Narayan Newton

User login

Navigation