Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

First MySQL 5.5 Beta Released

kdawson posted more than 4 years ago | from the taking-care-of-business dept.

Databases 95

joabj writes "While MySQL is the subject of much high-profile wrangling between the EU and Oracle (and the MySQL creator himself), the MySQL developers have been quietly moving the widely-used database software forward. The new beta version of MySQL, the first publicly available, features such improvements as near-asynchronous replication and more options for partitioning. A new release model has been enacted as well, bequeathing this version the title of 'MySQL Server 5.5.0-m2.' Downloads here."

cancel ×

95 comments

Sorry! There are no comments related to the filter you selected.

So (-1, Troll)

jlechem (613317) | more than 4 years ago | (#30489574)

Has it now moved the 2000s in terms of features now? Or can I still poke fun at for being the kid on the bus who is just a little slower than the rest of us.

Re:So (0)

Anonymous Coward | more than 4 years ago | (#30489832)

Yes, around version 4.0

Troll, I know, but wrong decade. (2, Informative)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30491330)

If you look at the current state of data storage, the new trend is for *less* features and for more speed, concurrency, throughput and *eventual consistency*. So not supporting strict ACID and/or parts of ANSI SQL can allow databases to perform faster. Really depends on what you want to do with your data. No more one-size fits all db anymore. Even Oracle has different versions ( with a huge variance in price) for different use cases.

So depending on your use case, you can still make fun of it for not supporting many features, or for supporting too many features.

Re:Troll, I know, but wrong decade. (0)

Anonymous Coward | more than 4 years ago | (#30491366)

If you look at the current state of data storage, the new trend is for *less* features and for more speed

Just because it's a "trend" doesn't mean it's in any way a good idea.

Re:Troll, I know, but wrong decade. (2, Interesting)

GooberToo (74388) | more than 4 years ago | (#30491610)

Exactly! Especially since MySQL is already well known for both data loss and corruption in the name of performance. Made all the more embarrassing is that PostgreSQL consistently either meets or beats MySQL in performance and leaves it far behind in scalability. In short, PostgreSQL is literally the poster boy proving such an errant trend is bad for everyone.

At the end of the day, that's just MySQL marketing trying to explain why MySQL is inferior to PostgreSQL and other commercial offers. After all, bringing feature parity is lots of very, very, hard and complicated work. Best to simply not do it and market that as a pro rather than the con it is.

Re:Troll, I know, but wrong decade. (1)

dave87656 (1179347) | more than 4 years ago | (#30497186)

Especially since MySQL is already well known for both data loss and corruption in the name of performance. Made all the more embarrassing is that PostgreSQL consistently either meets or beats MySQL in performance and leaves it far behind in scalability.

We moved our DB from MySQL to PG about a year ago and experienced significant performance improvements over both InnoDB and MyISAM. Pretty interesting when you consider that PG is also more secure that MySQL.

My guess is that once PG reaches critical mass as an Open Source DB name, people will be moving away from MySQL in groves.

Re:Troll, I know, but wrong decade. (1)

LOLLinux (1682094) | more than 4 years ago | (#30491490)

So not supporting strict ACID and/or parts of ANSI SQL can allow databases to perform faster.

Yeah and who needs dumb things like data consistency and prevention of data corruption?

Re:Troll, I know, but wrong decade. (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30496570)

They aren't dumb, just expensive. If they cost more than their worth, you don't need them.

If you're dealing with real money, You *NEED* them. If you're dealing with tweets, you can't afford them.

Re:Troll, I know, but wrong decade. (1)

dave87656 (1179347) | more than 4 years ago | (#30497188)

They aren't dumb, just expensive. If they cost more than their worth, you don't need them.

True, but PostgreSQL is faster and more secure. Why not have both if you can?

Re:Troll, I know, but wrong decade. (1)

Errol backfiring (1280012) | more than 4 years ago | (#30497512)

Because of other things? To name one: I find MySQL a great database for agile database development. I can write SQL in a way that upgrades toward a situation instead of failing when the incorrect old situation was there . Lots of those things can be done without stored procedures, in a legible and maintainable manner. In PostgreSQL, I would probably have to write lots and lots of procedures, making this totally unmaintainable.

See Evolving a database with MySQL [howtoforge.org]

Re:Troll, I know, but wrong decade. (1)

dave87656 (1179347) | more than 4 years ago | (#30497600)

I moved our application of now over 1 millions lines from MySQL to Postgres with only a few minor changes and no stored procedures.

I'm not sure what you mean by "I can write SQL in a way that upgrades toward a situation instead of failing when the incorrect old situation was there." Can you elaborate?

In my experience, MySQL doesn't offer any more flexibility on the whole than Postgresql. Some stuff is better with MySQL, like replication, whereas other stuff is better with Postgres (performance of joins, variable length character fields, etc). But, mainly the reason for preferring PG over MySQL is performance.

Re:Troll, I know, but wrong decade. (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30499962)

You can't. I wasn't saying that MySql was perfect in all cases when you didn't care about ACID. Twitter can't use PostgreSQL. Facebook can't use PostgreSQL. The performance hit of ACID is too much. There isn't a single tool that solves all data storage and retrieval problems. You can argue that PostgreSQL is better for most usage cases than Mysql ( if you're dead set at arguing Mysql vs PostgreSQL while ignoring every other database.). I wouldn't agree with that statement, but it makes a lot more sense than claiming PostgreSQL is the optimal solution for a super massive read write workload. No one does that, and its not because they're stupid or biased against PostgreSQL.

Re:Troll, I know, but wrong decade. (1)

dave87656 (1179347) | more than 4 years ago | (#30502748)

I wasn't trying to imply that PG is better than everything else for all workloads. But, for relational database scenarios, I've found that PG is faster and more secure than MySQL. We've noticed a significant performance improvement even comparing PG to MyISAM tables. Given that,

Facebook, Twitter, Amazon, etc, I believe use Key-Value stores for performance reasons. Hadoop is a big player in that game, Google, Yahoo and IBM are using it. Not sure about Amazon, Facebook, Twitter and so on.

Re:Troll, I know, but wrong decade. (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30514508)

That's all I was saying. We agree then.

Re:Troll, I know, but wrong decade. (1)

plopez (54068) | more than 4 years ago | (#30494120)

Really? Any DB engine can do that. Just do a minimal install, remove all constraints and stop transaction logging. You'll be amazed how fast a DB engine can run.

BTW, *eventual* consistency is an oxymoron. Once it's gone it is gone. Unless you do a total wipe of all the tables and then reload them from the original data sources. Once a DB is corrupted, good luck cleaning it up. As many victims of identity theft have learned.

Re:Troll, I know, but wrong decade. (1)

fimbulvetr (598306) | more than 4 years ago | (#30496310)

It may be an oxymoron in the RDBMS world. In the distributed world, it's par for the course - in fact, it has its own letter in CAP.

Re:Troll, I know, but wrong decade. (1)

DragonWriter (970822) | more than 4 years ago | (#30514778)

If you look at the current state of data storage, the new trend is for *less* features and for more speed, concurrency, throughput and *eventual consistency*.

Speed, concurrency, throughput, distributability, scalability, etc. are all features. So its not "less features" but "a different mix of features".

And, actually, the trend of having new DBs that sacrifice ACID features for speed and performance features, which then evolve to have ACID features added in as people build bigger systems with them and realize the cost of not having ACID guarantees is not new -- the whole history of MySQL is an illustration of that.

frist psotgres (-1, Troll)

Hognoxious (631665) | more than 4 years ago | (#30489638)

Who cares? Psotgres is miles better.

Re:frist psotgres (0)

Anonymous Coward | more than 4 years ago | (#30489756)

You, sir, fail it.

Re:frist psotgres (2, Insightful)

rfelsburg (1237090) | more than 4 years ago | (#30489826)

Maybe it's just me, but I find 'Psotgres' to be far lacking compared to mysql. Ease of use also counts for something when working with the masses...and yes I am making fun of your inability to spell the very product you're trying to troll with. Fun times.

whooooosh (-1, Troll)

Hognoxious (631665) | more than 4 years ago | (#30490062)

Hint: when someone has a UID that's half yours and you suspect someone is a cunt, it's probably you. Especially if you're German.

Re:whooooosh (1)

kestasjk (933987) | more than 4 years ago | (#30490276)

Yay, your UID isn't half mine :-)

Re:whooooosh (1)

daveime (1253762) | more than 4 years ago | (#30492020)

Thank you, tears in eyes, coffee out of nose, sides aching, the whole works.

Read like a helpful tip from the pages of Viz. You're not Geordie by any chance are you ?

Re:whooooosh (0)

Anonymous Coward | more than 4 years ago | (#30492112)

I am guessing you registered when you were 5.

Re:whooooosh (1)

negRo_slim (636783) | more than 4 years ago | (#30494332)

Hint: when someone has a UID that's half yours and you suspect someone is a cunt, it's probably you. Especially if you're German.

What if they simply bought their UID [slashdot.org]

Who would the cunt be then?

Re:whooooosh (0)

Anonymous Coward | more than 4 years ago | (#30496446)

Actually, it's always the idiot who think UID matters. Always.

It's also the guy who tells stupid lies that he knows he can't suppport [slashdot.org] and throws tantrums when called out on them. [slashdot.org]

And no, the "Nuh-uh, it's the AC who's like totally a stalker 'n stuff" comeback isn't the withering retort you're trying to pretend it is. And yes, that IS what you were about to say.

Re:frist psotgres (5, Insightful)

nxtw (866177) | more than 4 years ago | (#30490096)

Ease of use also counts for something when working with the masses...

By that metric, MS Access wins every time...

Re:frist psotgres (1)

fooslacker (961470) | more than 4 years ago | (#30490192)

counts for something != counts for everything but nice try

Re:frist psotgres (4, Insightful)

nxtw (866177) | more than 4 years ago | (#30490406)

counts for something != counts for everything but nice try

I can't think of many criteria in which PostgreSQL is lacking compared to MySQL. In my experience, MySQL is "easier to use" only in that the default security configuration on some distribution packages is easier to understand.

Re:frist psotgres (1)

fooslacker (961470) | more than 4 years ago | (#30490624)

Oh I don't have a strong opinion on which is better, I've used both effectively. I was just responding to the guy above who was claiming Access should win because your selection criteria was flawed.

Re:frist psotgres (1)

cheekyboy (598084) | more than 4 years ago | (#30495412)

stop being a tool, it was obvious it was not his only criteria. And in any marketplace it is an important one that will gain more users.

Do I see netbsd high in the usage ranks?

Re:frist psotgres (1)

fooslacker (961470) | more than 4 years ago | (#30496378)

stop being a tool, it was obvious it was not his only criteria. And in any marketplace it is an important one that will gain more users.

Do I see netbsd high in the usage ranks?

Actually I didn't think it was obvious.

As I read it the first guy was just saying he preferred mysql to PostreSQL and that one of the deciding factors in that decision was ease of use.

The second guy as I read it was trying to discount the original argument by showing that ease of use should not be considered because that means Access would win which we consider absurd knowing many of the weaknesses with Access.

I don't think that pointing out that that is absurd reasoning is "being a tool" but I am impressed with the way you somehow agreed with my original point while calling me a tool and being as abrasive as possible.

Re:frist psotgres (1)

AbbyNormal (216235) | more than 4 years ago | (#30495602)

Out of the box replication in PostgresSQL was a bit lacking, last I checked. MySQL replication seems to work well for smaller scale projects.

Re:frist psotgres (1)

PerfectionLost (1004287) | more than 4 years ago | (#30492470)

I would bump this for humor if I could.

Re:frist psotgres (0)

Anonymous Coward | more than 4 years ago | (#30494800)

Ease of use also counts for something when working with the masses...

By that metric, MS Access wins every time...

very few people realize that when used correctly--that is, as a vb front-end for a sql server backend--nothing beats access for rad.

Re:frist psotgres (1)

CarpetShark (865376) | more than 4 years ago | (#30497796)

Actually, most desktop people who are just after ease of use end up using Excel :)

Re:frist psotgres (1)

nxtw (866177) | more than 4 years ago | (#30498910)

Actually, most desktop people who are just after ease of use end up using Excel :)

This is true; I actually thought about saying Excel instead of Access. I chose Access because it actually is a relational database.

When used with SharePoint, Access 2007/2010 is easier - SharePoint will automatically create an Access database using SharePoint lists/libraries as tables, and Access will synchronize the content. Setting up a custom SharePoint list (or customizing an existing one) isn't too difficult - certainly easier than creating a table in Access. This is perhaps one of the easiest ways to set up a database, albeit a rather limited one.

They aren't really intended to be used in this way, but SharePoint lists/libraries can form something that resembles a simple relational database.

Re:frist psotgres (2, Informative)

Anonymous Coward | more than 4 years ago | (#30490242)

Yeah, transactions. Those are a real bitch, aren't they? I mean, they get in the way all of the time, protecting your data's integrity. We can't fucking have atomicity. No fucking way. PostgreSQL totally lacks the random and unexpected data corruption that makes MySQL great.

And foreign key constraints! Stupid little motherfuckers, preventing arbitrary data entry and orphan records. In my MySQL database, I want to insert any sort of crap I feel like, even if it violates all sorts of constraints.

The worst, though, has to be all of the index types we have available. PostgreSQL gives so many, for all sorts of data. Fuck, nobody ever has to store, say, geospatial data and access it quickly. Never!

Oh, but don't forget the powerful PL/PgSQL language for writing functions. It's just fucking stupid to isolate frequently-used code in a single location. That might actually make testing and maintenance easy. That's a big No No in the MySQL world.

Fuck, I hate all of these low-end database features that PostgreSQL offers. It makes it so much more lacking compared to MySQL.

Re:frist psotgres (0)

Anonymous Coward | more than 4 years ago | (#30492538)

Not to refute everything you've said, but MySQL can do transactions, and can have spatial indexes.

Re:frist psotgres (1)

sproingie (1690772) | more than 4 years ago | (#30494292)

The indexes only work on MyISAM. Who needed transactions anyway? Every feature MySQL lays claim to is always full of gotchas like this.

Re:frist psotgres (1)

arndawg (1468629) | more than 4 years ago | (#30494544)

Only if you're using innodb amiryte? MySQL is the first database language most poeple learn using phpmyadmin so they'll just use the default.

Re:frist psotgres (2, Insightful)

GooberToo (74388) | more than 4 years ago | (#30490584)

What ease of use issues? That hasn't been an issue in years. PostgreSQL is well supported even on Windows these days.

For the vast majority of users, PostgreSQL scales better, has far more features, supports far more PLs, is technically more advanced, has a vastly superior query optimizer, is more stable, is well supported, and doesn't have the politics surrounding it like MySQL does. Even better, it teaches proper ANSI SQL which carries over to any number of other engines, excepting MySQL.

Given there are no ease of use issues and all the above, why would any sane person care about MySQL.

Re:frist psotgres (1)

FsG (648587) | more than 4 years ago | (#30492990)

Because most web publishers are deployers, rather than developers, of web software. The overwhelming majority of this software is written in PHP and assumes the presence of MySQL. Even those packages that support other databases often treat them as second-class citizens; they tend to be much less developed and tested.

I am a sane person, and I care more about using the database that'll work best with the apps I want to use (such as phpBB), than I do about promoting tech for its own sake.

Re:frist psotgres (1)

TheCowSaysMooNotBoo (997535) | more than 4 years ago | (#30494330)

Never had to 'solve' data correction due to the non-acid compliance of the db I suppose? And what features exactly are you using from mysql that isn't in postgresql?

pgsql vs. mysql (1)

codealot (140672) | more than 4 years ago | (#30495592)

Everytime I see this debate on slashdot it invariably degenerates into claims of mysterious missing features (what are they?) or non-transactional characteristics of MyISAM. Too bad, because I'm genuinely interested in a good comparison. I use MySQL extensively today but have worked on both in the past.

Anyone still tempted to go with the "non-acid" argument... give it up, else risk looking ignorant or foolish. MySQL is designed to support many storage engines. Anyone using MySQL this past decade who cares about their data creates most of their tables as InnoDB tables. And InnoDB is a very very good storage engine, if it matters.

I may have to try postgresql myself, if only to get to the bottom of this. What doesn't it have that I sorely need? Perhaps nothing. Then again mysql isn't missing much, either, for our needs. Perhaps, in the end, this is more like comparing AMD to Intel--no clear winner.

Re:frist psotgres (1, Insightful)

GooberToo (74388) | more than 4 years ago | (#30490986)

Maybe it's just me, but I find 'Psotgres' to be far lacking compared to mysql.

Factually, its just you. The fact is, MySQL is horribly lacking compared to PostgreSQL. MySQL is constantly chasing PostgreSQL's feature set. That's the facts. No trolling required.

Why do you think so many PostgreSQL supports are so rabid about how inferior MySQL is in just about every metric that matters for a RDBMS? Its like constantly watching Pinto [wikipedia.org] owners rave about how great their car is when for the same money they could have gotten just about anything else and been better off, not to mention safer.

and firebird! (3, Interesting)

Unordained (262962) | more than 4 years ago | (#30491634)

Just to wedge this in: Firebird users often feel the same way. Firebird 2.5 is now available as an official release candidate.

Yes, the database engine. Not the browser. *sigh*

Re:and firebird! (1)

GooberToo (74388) | more than 4 years ago | (#30491704)

Agreed. While I've never used Firebird, I've never once heard a bad thing about.

I share your pain.

Re:and firebird! (1)

aztracker1 (702135) | more than 4 years ago | (#30493490)

I like firebird a lot. What I really like is that it's easy to use the embedded version for applications, then transition to a stand alone RDBMS install with nothing more than a config change. It doesn't scale/replicate so well, but for small to mid sized projects it's far better than mysql, and for mid-large projects postgres is way better. Other than logging or chat (higher concurrency, low/no relational mapping), I can't see mysql being the best choice for anything.

Re:and firebird! (1)

Unordained (262962) | more than 4 years ago | (#30494786)

I'm curious: what kind of scaling / replication problem did you have?

Scaling: lots of connections, lots of tables, lots of requests, lots of data, ... ?

Replication: for sharding, for master / slave, for multi-site, for backups (incremental? hot?), ... ?

I ask because I haven't personally profiled FB vs. PG on any of those metrics, and they get enough less market share than other products to make finding such comparisons difficult.

Re:frist psotgres (1)

codealot (140672) | more than 4 years ago | (#30495676)

Okay I'll bite. I'm not familiar with postgresql versions since about 7.x.

From http://www.postgresql.org/about/:

  • An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data. Some general PostgreSQL limits are included in the table below.

Which of these are not also true of mysql? The InnoDB storage engine also has MVCC, snapshot recovery, hot backups, etc.

What are the compelling differences?

Re:frist psotgres (0)

Anonymous Coward | more than 4 years ago | (#30496134)

The last sentence: "Some general PostgreSQL limits". Compare it to MySQL's lists of caveats. You'll find what MySQL claims to support is often grotesquely crippled. Want full-text indexing? Hope you didn't also want transactions. Hope also you didn't want to tune the stopword selection process, override the tokenizer, add synonyms, or otherwise customize it. Want geospatial data? Again, forget transactions if you want to index it. Stored procedures? Don't even begin to look for an expressive procedure language.

Re:frist psotgres (1)

GooberToo (74388) | more than 4 years ago | (#30514944)

What are the compelling differences?

Security. Scalability. And recently, raw performance with more much more room through to exist. Superior query plan general for non-trivial queries; which also goes to the first three items listed. Extensibility such that MySQL can't even be compared. Geospacial capabilities with indicies + ACID. PLs for stored procedures and a multitude of choices and capabilities. Real life deployments where ACID accounts; compared to MySQL where people generally use it as a large, non-ACID storage retrieval system where data inconsistencies are typically also allowed, rather than an ACID-compliant RDBMS.

In all seriousness, for the vast, vast majority of users, the only literal advantage MySQL has over PostgreSQL is DB upgrade paths, and even then, huge strides are being made on the PostgreSQL front. See PG Migrator [pgfoundry.org] . Huge improvements have been made since the 7.x days. See the docs [postgresql.org] for more info.

Editor Fail (1, Informative)

OverlordQ (264228) | more than 4 years ago | (#30489704)

Downloads are not here. Might try actually putting a full URL in there instead of MySQLServer5.5.0-m2

Re:Editor Fail (2)

LOLLinux (1682094) | more than 4 years ago | (#30491244)

It's kdawson. 5 time winner of the "Worst Slashdot Editor of All Time" award.

Re:Editor Fail (2)

daveime (1253762) | more than 4 years ago | (#30492078)

5 times today ... or possibly 6. depends how many articles he posts.

Re:Editor Fail (0)

Anonymous Coward | more than 4 years ago | (#30493708)

This would explain why a version of the article that was (a) inaccurate, (b) several days late, and (c) posted by someone who obviously doesn't work for MySQL was chosen over 3 or 4 that were none of these.

There is too much data (1)

For a Free Internet (1594621) | more than 4 years ago | (#30489716)

Meyerson's law states that as the ration of data to metadata approaches any Reimann prime number, the corner cases of joins and sequential transactions will become NP-hard. Meaning, throw as much new hardware as you want at the problem, even Googles new top-secret quantumn coimputer, and yyou still get the mother of all performance bottlenecks. What we need now is an intelligent data garbage-collecting system that can cull expired or redundant data points. Otherwise, humanity is doomed.

Re:There is too much data (1)

Minwee (522556) | more than 4 years ago | (#30490132)

Thank you for your helpful comments, Dr. Sokal. We'll be in touch when the committee has made a decision on whether or not to publish your paper.

Re:There is too much data (1)

LOLLinux (1682094) | more than 4 years ago | (#30490994)

Because otherwise they'd have to admit that all their years diddling around with a toy database was all for naught?

semi-synchronous replication (2, Informative)

Honken (665599) | more than 4 years ago | (#30489796)

"near-asynchronous replication" is wrong, should be "semi-synchronous replication" as stated in the article. Striving for almost having replication asynchronous sounds like a poor implementation of synchronous replication :)

Re:semi-synchronous replication (0)

Anonymous Coward | more than 4 years ago | (#30490656)

Actually Synchronous replication and asynchronous data transfert would be a great implementation.

The Summary should have mentioned this (2)

Monkeedude1212 (1560403) | more than 4 years ago | (#30489824)

FTA:

MySQL 5.5 will also support the ANSI/ISO SQL standard method of programmatically returning errors inside SQL procedures, called Signal/Resignal, which some users have called for.

This was never really an issue, because MySQL always had it's way of preforming whatever you needed it to do, but I used it in Oracle and it really does make a difference. Here's a link that will show you a bit of what it does, for those who don't know.

All in all, I'm glad things are moving forward. Still not the forerunner but still in the game.

Re:The Summary should have mentioned this (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30489836)

Oops. I forgot to provide that link [oracle-base.com] I had.

Re:The Summary should have mentioned this (1, Informative)

Anonymous Coward | more than 4 years ago | (#30490134)

that links has nothing to do with signal/resignal.

Have they fixed NDBCLUSTER yet? (3, Interesting)

ducomputergeek (595742) | more than 4 years ago | (#30489900)

The last two times I tested it for a true shared-nothing HA cluster, NDBCLUSTER failed miserably without a lot of tweaking. The optimizer was buggy to the point of being broken. And basically the response I got from MySQL AB at the time was, "If you want to use NDBCLUSTER, you'd better get the Enterprise Support Package". After pricing out what it would cost in support from MySQL AB AND the cost of having to go through and rewrite a bunch of our code to optimize it, it was cheaper to buy DB2.

Company I work for now uses PostgreSQL for main product lines. But two of their package are third party and use MySQL including their billing system. It works, but as it stands right now, neither of those systems are being taxed on a Dual-Quad Core DB server with 12GB RAM. In fact, it barely runs at 5% of resource utilization. We still use MySQL for one of our website's CMS. And it does the job well.

MySQL works well up until you need more than one box. Replication can work in some circumstances, but as a HA solution, it looses any advantages it had in terms of cost vs. extremely proven and reliable systems.

Re:Have they fixed NDBCLUSTER yet? (0)

Anonymous Coward | more than 4 years ago | (#30489988)

You had me...up until the part where you spelled looses rather than loses. Why is it you IT guys all are so illiterate???

Re:Have they fixed NDBCLUSTER yet? (1)

TheLinuxSRC (683475) | more than 4 years ago | (#30490760)

What are you using to cluster Postgres? I have looked at a couple of options here [postgresql.org] but didn't see an open source solution that was current and able to handle multi-master synchronous replication with some sort of automatic failover.

Thanks for your response!

Re:Have they fixed NDBCLUSTER yet? (1)

h4rr4r (612664) | more than 4 years ago | (#30493056)

You generally would do the failover using another product like heartbeat, to promote a slave or whatever else needs to be done during failover. The unix way is each app does one thing and is good at it.

Re:Have they fixed NDBCLUSTER yet? (1)

msimm (580077) | more than 4 years ago | (#30491956)

I agree about the HA and if you've got a highly transactional application and need enterprise grade fail-over Oracle RAC or some variation of PostgreSQL might work great for you. But for many people MySQL is still a good option and has some nice/useful features (online fs-based backups sans datapump, previously mentioned replication). There's also an amazing amount of information available about MySQL tailored to just about any skill-level, including a number of alternative approaches to HA.

My current project is taking advantage of sphinx, which makes nice use of MySQL and my previous project involved using a combination of replication and sharding to improve reliability and write throughput. Oracle scales nicely across multiple cpus, but because of licensing eventually our growth was limited by database costs. Both Postgre and MySQL have been welcome solutions with my personal preference being MySQL mostly for familiarity and built-in replication.

Re:Have they fixed NDBCLUSTER yet? (1)

codealot (140672) | more than 4 years ago | (#30495776)

The NDB releases basically forked from mainline MySQL. Latest is NDB 7.x, which is actually very good at what it does. Not *quite* ready for what we need but getting very close. ALTER ONLINE is a nifty feature... I've used it to add/drop indexes on the fly from tables in continuous use.

Earlier releases of NDB required that all indexes and data fit in main memory, but that has been remedied with disk data tables. Currently, disk data tables can only store fixed-length data (all strings are padded to their full length). Once that limitation is addressed, I'll be ready to look at it again.

If you applications need frequent table scans, forget about NDBCLUSTER. If however you meticulously access all your data by primary key, I find NDB scales just fine with workload.

Re:Have they fixed NDBCLUSTER yet? (2, Insightful)

Zontar The Mindless (9002) | more than 4 years ago | (#30497556)

Nice to see some honest feedback from someone who's obviously tried the product. Glad you like ALTER ONLINE -- I'll pass that along to the devs.

MySQL 5.1.41 mainline has just been merged into what will be the next set of MySQL Cluster releases, BTW.

True variable-width columns on disk, indexes on disk, and better join performance are high on our list of priorities. As well as a few other goodies that'll be coming out early next year, but I can't talk about those just yet. :)

Re:Have they fixed NDBCLUSTER yet? (1)

Macka (9388) | more than 4 years ago | (#30497672)

How about using DRBD for Mysql High Availability clustering [mysql.com] instead of NDBCLUSTER? In a nutshell, one DB instance is used to handle writes and this is synchronously replicated to a Heartbeat cluster standby node using DRBD. Asynchronous replication to more DBs handle all the reads (with load balancing between them). Use Sharding to scale out when you need more capacity.

Re:Have they fixed NDBCLUSTER yet? (1)

Macka (9388) | more than 4 years ago | (#30497686)

Here's another link [mysql.com] with a better explanation and a nice pretty picture :)

Hmm (0)

Anonymous Coward | more than 4 years ago | (#30490166)

I wonder how they came to select all of the features in this current build.

Re:Hmm (1)

GeekLove (1604967) | more than 4 years ago | (#30490366)

SELECT * FROM features WHERE build = 'current'

Re:Hmm (0)

GooberToo (74388) | more than 4 years ago | (#30491240)

select * from features where build = 'current' and product = 'postgresql'

They are continuously chasing PostgreSQL.

Re:Hmm (1)

Tim99 (984437) | more than 4 years ago | (#30497694)

select * from features where build = 'current' and product = 'postgresql'

No, that's unfair - Surely you meant:
SELECT * FROM features WHERE build = (currentver -3) AND product = 'postgresql'

Choose: Referential Integrity or Partitioning (1)

w_mute (40724) | more than 4 years ago | (#30490484)

Still no support for foreign keys in partitioned tables. Makes partitioning pretty much worthless in most real world deployments.

Re:Choose: Referential Integrity or Partitioning (1)

fimbulvetr (598306) | more than 4 years ago | (#30491064)

They're also still missing 99% of the subquery optimizations they had in the 6.0 Alpha codebase and 99% of the other improvements. When they went sun they started worrying too much about BC and improvements slowed down substantially. In my opinion, if you want less buggy software on a faster release model, you need to not give priority to BC. But then you lose the support contracts, which is all sun cares about.

What happened to 5.4? (0)

Anonymous Coward | more than 4 years ago | (#30490990)

There was a beta like 9 months ago, but no cigar. Where is the final release?

CoJ3k (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30491102)

Seems Odd to me... (0)

Anonymous Coward | more than 4 years ago | (#30492946)

5.5 Still Betaware? Will they label it with number 6 when it finally come out of beta closet? Well similar numbering scheme as Kernel had some time ago... but with MySQL it seems to be he major number that counts.

Re:Seems Odd to me... (1)

dave87656 (1179347) | more than 4 years ago | (#30497172)

Will they label it with number 6 when it finally come out of beta closet?

Version 6 is the release that will have the Falcon Engine which is supposed to come closer to PostgreSQL performance.

Near-asynchronous? (1)

saleenS281 (859657) | more than 4 years ago | (#30495002)

Is that supposed to be near-synchronous? What the hell is "near-asynchrynous"? I don't even see how "near-asynchronous" would be possible. If you aren't synchronous, you're asynchronous, and it's just a matter of how far away from synchronous you are. That's like saying "he's traveling at near-not-the-speed-of-light".

Re:Near-asynchronous? (1)

dave87656 (1179347) | more than 4 years ago | (#30497160)

My thoughts exactly. "Near-asynchronous" sounds like it's still synchronous.

Re:Near-asynchronous? (1)

PiSkyHi (1049584) | more than 4 years ago | (#30502236)

Near-asynchronous means they're still waiting for their first query to return a result..

near-asynchronous replication? (0)

Anonymous Coward | more than 4 years ago | (#30495028)

implementing that must've been a tough job

Minus 3, TroLl) (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#30495166)

Development. BSD you to join the [amazingkreskin.cOm\] Is ingesting A previously whole has lost I won't bore you

You keep using that word... (1)

Will.Woodhull (1038600) | more than 4 years ago | (#30495544)

...but I don't think it means what you think it means...

Bequeath [answers.com]

Haven't even touched 5.1. (0)

Anonymous Coward | more than 4 years ago | (#30496208)

Are you kidding me? With the crap they pulled with the buggy and rushed 5.1 release, I don't see our company touching any version > 5.0.x with a 10 foot pole anytime soon. Our production servers are still running 5.0.x, and that will remain the case for a long long time thanks to the garbage they've been tossing around.

Near-asynchronous replication is a disappointment (1)

mysidia (191772) | more than 4 years ago | (#30496274)

MySQL already has perfect asynchronous master-slave replication through binary logging.

What's hard is synchronous replication it would be a very useful enhancement if 5.5 had a reliable synchronous replication option, and supported clustering, failover/hot-standby, and failed-node recovery/resynch.

Re:Near-asynchronous replication is a disappointme (1)

Sxooter (29722) | more than 4 years ago | (#30496496)

It has working async (log shipping isn't synchronous) but it has lots of bugs that can jump up and bite you in the ass that haven't been fixed yet. Search the MySQL bug database for examples. It still requires you to stop your whole cluster and replicate the master to the slave to work. For large datasets this is unworkable if you need continuous uptime.

It's pretty good, and super easy to setup, but it's not perfect.

Re:Near-asynchronous replication is a disappointme (1)

mysidia (191772) | more than 4 years ago | (#30496772)

It works fine, and I use it.. And no, you don't need to stop the master on a regular basis for any reason.

Clients that perform updates have to connect to master.

For select queries, use a load balancer that connects to the slaves.

When you are creating a new slave, you replicate it first, then add it to the load balanced cluster AFTER replication is proceeding.

The asynchronous nature has some drawbacks though, since your app can never really be 100% sure that what you see is the latest version of the database.

It helps if you record in-flight transactions and "hot" data using memcached, and consult the database for cold data.

Re:Near-asynchronous replication is a disappointme (1)

LizardKing (5245) | more than 4 years ago | (#30500374)

... it has lots of bugs that can jump up and bite you in the ass

Well, that's what you get for using a donkey [dictionary.co.uk] instead of database.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>