[Maria-discuss] Giuseppe Maxia: Forking MySQL/ for how long can forks keep up?
Giuseppe Maxia asks some questions: http://datacharmer.blogspot.hk/2013/09/forking-mysql-for-how-long-can-forks....
The comments featuring Justin Swanhart and Stewart Smith make a lot of sense - 5.6 was GA, it wasn't a GA-ready product. Its getting there to some extent (as do all MySQL releases: 6-9 months from GA date)
Feel free to comment on the blog post above
cheers, -colin
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
Why do you claim it wasn't GA ready? By MySQL standards I think it was very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
On Wed, Sep 25, 2013 at 11:37 PM, Colin Charles byte@mariadb.com wrote:
Giuseppe Maxia asks some questions:
http://datacharmer.blogspot.hk/2013/09/forking-mysql-for-how-long-can-forks....
The comments featuring Justin Swanhart and Stewart Smith make a lot of sense - 5.6 was GA, it wasn't a GA-ready product. Its getting there to some extent (as do all MySQL releases: 6-9 months from GA date)
Feel free to comment on the blog post above
cheers, -colin
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Mark,
On 26 Sep 2013, at 16:06, MARK CALLAGHAN mdcallag@gmail.com wrote:
Why do you claim it wasn't GA ready? By MySQL standards I think it was very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
I am merely inferring from Justin's comments, which you can also read[1]. In fact, from your own team at Facebook: - DROP/ALTER table was slow. Fast implementation in 5.5 didn't make it to 5.6, fixed - GTID implementation in production is hard to do in 5.6 (I understand facebook-5.6 has some solution around this possibly) - http://bugs.mysql.com/bug.php?id=70265 - http://bugs.mysql.com/bug.php?id=68220 (maybe not a bug, but a behavioural oddity) - https://www.facebook.com/notes/mysql-at-facebook/eq_range_index_dive_limit-s... (maybe even you wrote this? One can't tell from the FB note)
There's a longer list in Yoshinori's excellent talk on MySQL 5.6 at Facebook. I hope those slides make it online somewhere/sometime
And given that I also have no experience with something like Oracle, I have no idea if their new releases are any better either or take a similar amount of time to stabalize
I see you have commented on the blog post, I look forward to the discussion there as well.
cheers, -colin
[1] - What maybe is not clear overall are the reasons as to why some features in MariaDB are being re-written. I see some good documentation in an example like https://mariadb.atlassian.net/browse/MDEV-452 but this is not always the case as to why there is reasoning for a decision (some are probably in commit logs, some are probably discussed on IRC, etc.)
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
Hi,
Many of these problems I uncovered in just a few days of testing with Shard-Query:
The database would crash if you dropped a database with an orphaned innodb table - fixed in newest release.
ALTER TABLE can consume all memory on the system
CRASH when using replication tables (fixed)
CRASH when using purge thread
New optimizer features (BKA/ICP) don't work with partitioning
client compiled with readline is not backwards compatible
problems with new replication features like MASTER_DELAY (fixed)
MRR/BKA don't work because cost based optimization is broken
plan changes for I_S.partitions (fixed)
slow drop table (a bug I had open since 5.0 was closed and reopened on 5.6)
alter table can crash leading to data dictionary inconsistency and then crash (crash probably fixed now)
handler_commit is STILL incremented for SELECT! (all the way back to 5.1...)
and others..
On Thu, Sep 26, 2013 at 3:20 AM, Colin Charles byte@mariadb.com wrote:
Mark,
On 26 Sep 2013, at 16:06, MARK CALLAGHAN mdcallag@gmail.com wrote:
Why do you claim it wasn't GA ready? By MySQL standards I think it was
very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
I am merely inferring from Justin's comments, which you can also read[1]. In fact, from your own team at Facebook: - DROP/ALTER table was slow. Fast implementation in 5.5 didn't make it to 5.6, fixed - GTID implementation in production is hard to do in 5.6 (I understand facebook-5.6 has some solution around this possibly) - http://bugs.mysql.com/bug.php?id=70265 - http://bugs.mysql.com/bug.php?id=68220 (maybe not a bug, but a behavioural oddity) - https://www.facebook.com/notes/mysql-at-facebook/eq_range_index_dive_limit-s... even you wrote this? One can't tell from the FB note)
There's a longer list in Yoshinori's excellent talk on MySQL 5.6 at Facebook. I hope those slides make it online somewhere/sometime
And given that I also have no experience with something like Oracle, I have no idea if their new releases are any better either or take a similar amount of time to stabalize
I see you have commented on the blog post, I look forward to the discussion there as well.
cheers, -colin
[1] - What maybe is not clear overall are the reasons as to why some features in MariaDB are being re-written. I see some good documentation in an example like https://mariadb.atlassian.net/browse/MDEV-452 but this is not always the case as to why there is reasoning for a decision (some are probably in commit logs, some are probably discussed on IRC, etc.)
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
If Yoshi's slides are only to serve as fodder in the MariaDB v MySQL marketing battle then I hope they don't get published.
MySQL 5.6 has bugs, new features in 5.6 have even more bugs. That isn't a surprise, that is an opportunity for people like me and companies like Percona to help make it better. The surprise to me is that early 5.6 releases are in good shape despite so many changes.
Negative opinions about releases should be earned. If you think 5.6.X is bad, you had better spent some time using it to figure that out. I hope this side of the world doesn't become full of unearned opinions. Too much marketing like that will limit your community.
Given Justin's list of problems he encountered, it looks like he earned his opinion.
On Thu, Sep 26, 2013 at 1:20 AM, Colin Charles byte@mariadb.com wrote:
Mark,
On 26 Sep 2013, at 16:06, MARK CALLAGHAN mdcallag@gmail.com wrote:
Why do you claim it wasn't GA ready? By MySQL standards I think it was
very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
I am merely inferring from Justin's comments, which you can also read[1]. In fact, from your own team at Facebook: - DROP/ALTER table was slow. Fast implementation in 5.5 didn't make it to 5.6, fixed - GTID implementation in production is hard to do in 5.6 (I understand facebook-5.6 has some solution around this possibly) - http://bugs.mysql.com/bug.php?id=70265 - http://bugs.mysql.com/bug.php?id=68220 (maybe not a bug, but a behavioural oddity) - https://www.facebook.com/notes/mysql-at-facebook/eq_range_index_dive_limit-s... even you wrote this? One can't tell from the FB note)
There's a longer list in Yoshinori's excellent talk on MySQL 5.6 at Facebook. I hope those slides make it online somewhere/sometime
And given that I also have no experience with something like Oracle, I have no idea if their new releases are any better either or take a similar amount of time to stabalize
I see you have commented on the blog post, I look forward to the discussion there as well.
cheers, -colin
[1] - What maybe is not clear overall are the reasons as to why some features in MariaDB are being re-written. I see some good documentation in an example like https://mariadb.atlassian.net/browse/MDEV-452 but this is not always the case as to why there is reasoning for a decision (some are probably in commit logs, some are probably discussed on IRC, etc.)
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
Hi,
I was an Oracle DBA from 7.3 to 9i, and actually got my 9i certification. I guess I'm in the minority :)
In general, at least back then, there was an "R1" rule. You never ran 10G. You waited for 10G R1, or if you did run 10G, you only used 9i R2 features because they were solid in 10G. Regressions were uncommon, but using a mix of new features in a new release could sometimes be a nightmare.
I became a MySQL DBA because I was using ORACLE TEXT + PARTITIONING + Parallel Query on 9iR2 and I would get a DDL deadlock during TRUNCATE PARTITION. All of the local indexes on all of the partitions on the 2TB table (this was 10 years ago and that was big data) were invalidated when this would happen! Trust me, you don't want your search engine to start doing full table scans of a 2TB table in the middle of the night. :)
Oracle told us to upgrade to 10G as they would not fix 9iR2 and my boss refused because we were paying over 500K per year for 9iR2 support and licenses (it was still under active support) to be told basically to shove off and just upgrade instead of them supporting us properly.
Thus began my long march to MySQL, having to manually recode all the features I loved about Oracle, like intra-query parallelism (shard-query), and materialized views (flexviews). Finally, now with my tools and MySQL 5.6 we can approach 8/9i feature parity :) [except we dont' have pl/sql, user defined data types, etc..]
So... nothing is perfect. And I don't expect it to be. But I do want bugs that have been open for years and are rather trivial to fix to actually get fixed in new releases. And I want new features to be well tested TOGETHER. It seems that the new features are tested in isolation, and may work well that way, but I think more black box testing is necessary instead of relying on the community to do that.
--Justin
On Thu, Sep 26, 2013 at 9:50 AM, MARK CALLAGHAN mdcallag@gmail.com wrote:
If Yoshi's slides are only to serve as fodder in the MariaDB v MySQL marketing battle then I hope they don't get published.
MySQL 5.6 has bugs, new features in 5.6 have even more bugs. That isn't a surprise, that is an opportunity for people like me and companies like Percona to help make it better. The surprise to me is that early 5.6 releases are in good shape despite so many changes.
Negative opinions about releases should be earned. If you think 5.6.X is bad, you had better spent some time using it to figure that out. I hope this side of the world doesn't become full of unearned opinions. Too much marketing like that will limit your community.
Given Justin's list of problems he encountered, it looks like he earned his opinion.
On Thu, Sep 26, 2013 at 1:20 AM, Colin Charles byte@mariadb.com wrote:
Mark,
On 26 Sep 2013, at 16:06, MARK CALLAGHAN mdcallag@gmail.com wrote:
Why do you claim it wasn't GA ready? By MySQL standards I think it was
very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
I am merely inferring from Justin's comments, which you can also read[1]. In fact, from your own team at Facebook: - DROP/ALTER table was slow. Fast implementation in 5.5 didn't make it to 5.6, fixed - GTID implementation in production is hard to do in 5.6 (I understand facebook-5.6 has some solution around this possibly) - http://bugs.mysql.com/bug.php?id=70265 - http://bugs.mysql.com/bug.php?id=68220 (maybe not a bug, but a behavioural oddity) - https://www.facebook.com/notes/mysql-at-facebook/eq_range_index_dive_limit-s... even you wrote this? One can't tell from the FB note)
There's a longer list in Yoshinori's excellent talk on MySQL 5.6 at Facebook. I hope those slides make it online somewhere/sometime
And given that I also have no experience with something like Oracle, I have no idea if their new releases are any better either or take a similar amount of time to stabalize
I see you have commented on the blog post, I look forward to the discussion there as well.
cheers, -colin
[1] - What maybe is not clear overall are the reasons as to why some features in MariaDB are being re-written. I see some good documentation in an example like https://mariadb.atlassian.net/browse/MDEV-452 but this is not always the case as to why there is reasoning for a decision (some are probably in commit logs, some are probably discussed on IRC, etc.)
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
-- Mark Callaghan mdcallag@gmail.com
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi Mark,
On 26 Sep 2013, at 22:50, MARK CALLAGHAN mdcallag@gmail.com wrote:
If Yoshi's slides are only to serve as fodder in the MariaDB v MySQL marketing battle then I hope they don't get published.
No, these are not the only bits of fodder. I was focusing on something that you might have had some close contact with. Besides, I'm no seasoned marketeer but what kind of battle would it be if you showed that things were buggy but were getting fixed so that you could migrate to it? I'm sorry but that just seems like bad marketing to me.
MySQL 5.6 has bugs, new features in 5.6 have even more bugs. That isn't a surprise, that is an opportunity for people like me and companies like Percona to help make it better. The surprise to me is that early 5.6 releases are in good shape despite so many changes.
This is great.
Negative opinions about releases should be earned. If you think 5.6.X is bad, you had better spent some time using it to figure that out. I hope this side of the world doesn't become full of unearned opinions. Too much marketing like that will limit your community.
Please keep in mind that I have *never* had a negative opinion of 5.6. In fact, when I talk about things, you know I always commend the great work Oracle and Percona are doing to push the MySQL ecosystem forward. I was merely *paraphrasing* what Justin & Stewart wrote in this email thread.
It is also my belief from past experiences with MySQL (when releases came out of MySQL AB, Sun, and even Oracle's 5.5) that it *does* take 6-9 months before you start seeing deployments and bugs ironed out. Maybe this has changed with 5.6, but on a personal note for various reasons, my first experience with 5.6 started a few months ago with 5.6.12. This is four months after it became GA. I know you have vast experiences with it, having used it and improved it since last year, so thank you.
I also hope this side of the world isn't filled with unearned opinions. It is clear that MariaDB 10 will be "5.6-like", and the decision to not be a straight merge was made last year. The reasons given were made public in various blog posts and on this list. I don't have to support MySQL 5.6, but I can imagine people on "this side of the world" do. My interest in it is merely to see what the new features are, see what people are using, and contribute usefully to make sure that they exist in some form in MariaDB.
Given Justin's list of problems he encountered, it looks like he earned his opinion.
Which was exactly what was paraphrased/summarised here!
On Thu, Sep 26, 2013 at 1:20 AM, Colin Charles byte@mariadb.com wrote: Mark,
On 26 Sep 2013, at 16:06, MARK CALLAGHAN mdcallag@gmail.com wrote:
Why do you claim it wasn't GA ready? By MySQL standards I think it was very stable early on. You can decide whether I am more or less biased than other people making comments on this. Given that I have no experience with something like Oracle, I am not sure that early Oracle releases for a new major version are any better.
I am merely inferring from Justin's comments, which you can also read[1]. In fact, from your own team at Facebook: - DROP/ALTER table was slow. Fast implementation in 5.5 didn't make it to 5.6, fixed - GTID implementation in production is hard to do in 5.6 (I understand facebook-5.6 has some solution around this possibly) - http://bugs.mysql.com/bug.php?id=70265 - http://bugs.mysql.com/bug.php?id=68220 (maybe not a bug, but a behavioural oddity) - https://www.facebook.com/notes/mysql-at-facebook/eq_range_index_dive_limit-s... (maybe even you wrote this? One can't tell from the FB note)
There's a longer list in Yoshinori's excellent talk on MySQL 5.6 at Facebook. I hope those slides make it online somewhere/sometime
And given that I also have no experience with something like Oracle, I have no idea if their new releases are any better either or take a similar amount of time to stabalize
I see you have commented on the blog post, I look forward to the discussion there as well.
cheers, -colin
[1] - What maybe is not clear overall are the reasons as to why some features in MariaDB are being re-written. I see some good documentation in an example like https://mariadb.atlassian.net/browse/MDEV-452 but this is not always the case as to why there is reasoning for a decision (some are probably in commit logs, some are probably discussed on IRC, etc.)
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
-- Mark Callaghan mdcallag@gmail.com
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
participants (3)
-
Colin Charles -
Justin Swanhart -
MARK CALLAGHAN