The Doom of XtraDB and Percona Server?

Posted in: Technical Track

In The Doom of Multiple Storage Engines, Peter talks about how the storage engine concept of MySQL is usually spoken of in positive terms, but there are many negatives.

I have a hard time trying to figure out the deeper meaning behind Peter’s post, given that Percona writes a storage engine for MySQL, XtraDB. Does this mean that Percona will stop developing XtraDB? Does this mean that the Percona Server will diverge farther and farther away from MySQL so that they’re not compatible any more and migrating from MySQL to Percona Server is very difficult?

Or maybe it’s just that Peter is saying one thing and doing the opposite; which just seems wrong because that would be blatant hypocrisy on Percona’s part.

(This idea was a comment on the blog post but seems to be trapped in the spam filter, so I’m posting it; apologies if the comment comes through eventually….)

My own opinion of the issue: Peter is factually correct with what he says. However, it’s nice to have the framework and be allowed to use more than one storage engine, or use exclusively one storage engine that’s not MyISAM.


Interested in working with Sheeri? Schedule a tech call.

5 Comments. Leave new

I don’t think that blog post was meant to be anything more than a invitation to discuss the issue. Percona is a great company, but I don’t think they want to fork Mysql so much that its completely different than mysql. That would be a huge task and would require a huge amount of man power they don’t currently have.

I also wouldn’t even come close to calling it hypocrisy. For one thing Xtradb is pretty much just a few ( very valuable) patches on innodb. Its not anything radically different. Seccond, even if you did believe that he thought there should only be one, he specifically mentions that he doesn’t necessarily think it should be any particular storage engine.

“Now lets think what we could have if we have a version of MySQL Server which drops everything but Innodb Storage engine (it could be NDB, PBXT etc, it does not matter).”

Its very clearly a thought experiment. Maybe it will lead to something more, but more likely not.

Sheeri Cabral
May 10, 2010 12:31 pm

William — I understand, I’m continuing the discussion. You missed the part where I said that “I have a hard time trying to figure out the deeper meaning behind Peter’s post, given that Percona writes a storage engine for MySQL”.

What that means is “I’m confused” and so I posed *possible* meanings that I can think of, including:

– Percona Server should be written to only use xtradb, so it can take full advantage of everything xtradb can do without having to cater to the needs of other storage engines. This is what he says MySQL should do with regards to storage engines, therefore it would make sense that it’s what he will do regards to his MySQL analog and his InnoDB analog.

– Otherwise, Peter’s pointing out a problem, but contributing to it, by following the same model. That’s the possible hypocrisy.

– Or, maybe they will change Percona Server to use one specific storage engine that isn’t xtradb…..

If there’s really no change to Percona server, then Peter’s just pointing out an imaginary world and saying “imagine if we lived there”……and if that’s the case, it’s a thought exercise which has no value, because the world is imaginary and won’t come to pass.

Sheeri Cabral
May 10, 2010 4:54 pm

This just in: According to Peter, who left a comment in his own journal instead of actually putting it here where it belongs:

it’s the last point — an imaginary world.

Shlomi Noach
May 11, 2010 3:46 am


I think that a discussion on an imaginary world is still a valid discussion.

In the particular case of Peter’s post, and even assuming everything’s completely imaginary and will never take the shape of the described changes, it’s still worthwhile to understand the advantages/disadvantages with the current status.
Why? Because it teaches us on the internals of MySQL; of why multiple storage engines make for both transaction logs & binary logs (I see many people coming from other RDBMS getting very confused about this); of how a direct design solves many of the existing problems; of how a SE based design solves other problems.




I would actually wonder: Why does Peter’s post have to have a “deeper meaning”? I read it merely as pointing out that modularization has both positives *and* negatives. I myself have pointed that out many times too… but that doesn’t mean that it’s not a valid design decision. It means: know your limitations and know the positives and negatives of any system you using.




Leave a Reply

Your email address will not be published. Required fields are marked *