The Zend Framework team announces the immediate availability of Zend
Framework 1.11.1, our first maintenance release in the 1.11 series. This
release includes around 80 bug fixes — many due to the highly successful
bug hunt two weeks ago.
You may download ZF 1.11.1 from the Zend Framework site .
Working with customer, I faced pretty nasty bug, which is actually not rare situation , but in this particular there are some lessons I would like to share.
The case is pretty much described in bug 55981, or
in pastebin.
Everything below is related to InnoDB-plugin/XtraDB, but not to regular InnoDB ( i.e in MySQL 5.0)
In short, if you use big BLOBS ( TEXT, MEDIUMBLOB, etc) (that allocated in external segment in InnoDB), you can get your database in trash state just executing update on row with blob and rolling back transaction twice ( on the same row)
The keywords that diagnose you hit this bug is
InnoDB: Serious error! InnoDB is trying to free page N
InnoDB: though it is already marked as free in the tablespace!
InnoDB: The tablespace free space info is corrupt.
InnoDB: You may need to dump your InnoDB tables and recreate the whole
InnoDB: database!
Trash state means that InnoDB won’t start, and you need to use innodb_force_recovery=3 and mysqldump your data. What makes problem even worse is that InnoDB does not report tablename, so you are pretty much blind and need to dump whole dataset, which can be long process.
The moment where DRBD come in play, is if you use DRBD for HA purposes ( as is in the case I worked with), you screwed,
as DRBD mirroring physical data, and MySQL keeping crashing on both instances – active and passive.
So DRBD can’t be considered fully reliable HA solution if there is risk that application corrupts data by itself
Now to bug 55981. It has MySQL version 5.6, but the problem exists in MySQL 5.1.50 or below and in MySQL 5.5, and
corresponding bug is 55543, which you actually can’t see, as
“You do not have access to bug #55543.”, because it is marked as “Security problem”.
And I actually tend to agree that bug can be considered as “security”.
If you running public hosting or your public users can execute direct SQL statements, I strongly recommend to upgrade to
MySQL version 5.1.51+ .
Now another interesting point – how can you be sure that 5.1.51 works.
The bug 55543 is not mentioned in ChangeLog for 5.1.51 nor 5.1.52. However if you look into source code and revision history, you can see that bug 55543 is fixed in MySQL 5.1.51. I assume it is technical problem with ChangeLog process and it will be fixed soon, but I reported it so it is not lost
At the end let me reiterate my points:
- if you have BLOB/TEXT fields in your InnoDB-plugin schema, it is recommended to upgrade to 5.1.51+
- if you provide public access to MySQL instance ( hosting provider, etc) with InnoDB-plugin installed – it is STRONGLY recommended to upgrade to 5.1.51+
- Review your HA schema. DRBD by itself (without additional solutions) can’t guaranty decent level of High Availability. And just to be clear, it is not DRBD problem, DRBD basically can’t help if there is possibility that application corrupts data by itself. For this case regular Master-Slave setup (in addition to DRBD) would protect from such problem.
Entry posted by Vadim |
6 comments
Add to: 
| 
| 
| 
| 
Erin and Mike, organizers of SF Meetup generously invited me to talk on coming SF Meetup on Dec-14 about new features in InnoDB in MySQL 5.1 and 5.5 and, what is pay attention to, when you upgrade from MySQL 5.0.
Although I personally mostly in 5.1->5.5 upgrade area, Erin insured me that upgrade from MySQL 5.0 is still actually question for many users, so I accepted invitation. Event details are on Meetup.com page. So if you are up for free pizza, soda and do not mind to listen to me, welcome to join!
Entry posted by Vadim |
No comment
Add to: | | | |
Symfony2 development activity exploded this week with thousands of changes, tweaks and additions across most of its components: twig bundle, forms and dependency injection improved their performance; the Output Escaper component was removed; and lots of methods were renamed to follow the new naming convention. Symfony2 is gaining momentum week by week and therefore, the release of PR4 version is around the corner and the first beta version could be published before the end of the year.
Symfony developer at Useweb – full-time based in Rennes (Cesson-Sévigné), France – Contact: cv@useweb.com
Przypadki » Grzegorz ?liwi?ski
(feed)
(English, Polish)
We’ve had such a large number of signups to our Migrating MyISAM to InnoDB webinar, that we decided to hold one more before the year is out:
December, 8th 9AM PST: Introduction to Percona Server, XtraDB and Xtrabackup.
As the title suggests: this presentation is an introduction. We will be running through the main aspects that change, and where you can expect to get the most benefit.
This will be a technical talk, but perhaps less technical than some of our other posts. I recommend inviting a few friends & colleagues that are already familiar with MySQL, but perhaps not regular readers of our blog.
(Time for Q&A will follow the main presentation).
Entry posted by Morgan Tocker |
2 comments
Add to: | | | |
Powered by Twitter Tools
Percona Server version 5.1.52-rel11.6 is now available for download.
The main purpose of this release is to update the current Percona stable release to the latest version of MySQL 5.1.
Release Notes for this and previous releases can be found in our Wiki.
The latest downloads are available on our website. The latest source code for Percona Server, including the development branch, can be found on Launchpad.
Please report any bugs found at Bugs in Percona Server.
For general questions, use our Percona Discussions Group, and for development questions our Percona Development Group.
For support, commercial, and sponsorship inquiries, contact Percona.
Entry posted by Fred Linhoss |
2 comments
Add to: | | | |
In just 3 short days, contributors managed to resolve exactly 111 issues . Fitting though, if you think about it, since this is the 1.11 branch for Zend Framework: 111 issues, 1.11 branch release… I’d like to say we planned it that way, but alas, it was merely coincidental the way these numbers worked out.
I do not know if it is because we’re hosting a free webinar on migrating MyISAM to Innodb or some other reason but recently I see a lot of questions about migration from MyISAM to Innodb.
Webinar will cover the process in a lot more details though I would like to go over basics in advance. You can also check my old post on this topic about Moving MyISAM to Innodb as well as searching the blog – We’ve blogged so much on this topic.
So what are the basics ?
Regression Benchmarks – Make sure to run regression benchmarks in particular in terms of concurrent behavior. You may have hidden dependencies of MyISAM table lock behavior in your applications, also check if your application handled deadlocks well. MyISAM will not produce deadlocks for Innodb you should always see deadlocks as a probability as long as you write to the database. They may be rate but it is rather hard to guaranty you will never run into them.
Performance Benchmarks – Innodb and MyISAM have different performance properties and you can’t really say one is faster than other it is very much workload dependent, and again concurrent tests should be important here. Innodb also may result in different plans for some queries which is rather easy to check with mk-upgrade
Feature Differences – There are some feature differences between MyISAM and Innodb though well it is typically easily spotted by converting tables to Innodb on restored backup. Full text search indexes, GIS, multi-column auto increment keys are great examples. There are also different limits for MyISAM and Innodb – it is possible to have some rows which can be stored in MyISAM but would not fit to Innodb, though this is an exception.
Space Innodb Tables tend to be larger. Again converting schema will show you some of this. Though the best is to take a look at the size after stressing system with load for a while as depending on the schema and usage Innodb tables may increase in size significantly due to fragmentation.
Usage Differences What works well for MyISAM may not work for Innodb and vice versa. You may benefit from different index structure for Innodb, including different primary key setup, as well as you may want to structure workload differently. With MyISAM it is often for people to do updates in small chunks, almost row by row to avoid holding table lock for long time in Innodb you want larger updates to reduce cost of transaction commit. You also may want to avoid excessive SELECT COUNT(*) FROM TBL (with no where clause) which is very fast for MyISAM but does table/index scan for Innodb.
Defaults You need to know two things about defaults for Innodb. First Depending on MySQL version they may be somewhere from suboptimal to absolutely disastrous, you do not want to try to run Innodb or XtraDB with them. Second Innodb is tuned to be ACID by default – if you’re moving from MyISAM often you do not need such strong guarantees and can at least change innodb_flush_log_at_trx_commit=2. It still will be much more secure than storing data in MyISAM. The 3 most important values to check are innodb_flush_log_at_trx_commit, innodb_buffer_pool_size and innodb_log_file_size. There are a lot more options for fine tuning but make sure at least these are right.
Entry posted by peter |
One comment
Add to: | | | |
Percona XtraBackup 1.4 is now available for download.
Version 1.4 fixes problems related to incremental backups. If you do incremental backups, it’s strongly recommended that you upgrade to this release.
Release Notes for this and previous releases of Percona Xtrabackup can be found in our Wiki.
The latest downloads are available on our website. The latest source code can be found on Launchpad.
Please report any bugs found at Bugs in Percona XtraBackup.
For general questions, use our Percona Discussions Group, and for development questions our Percona Development Group.
For support, commercial, and sponsorship inquiries, contact Percona.
Entry posted by Fred Linhoss |
5 comments
Add to: | | | |
Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com