Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Databases

First MySQL 5.5 Beta Released 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."
This discussion has been archived. No new comments can be posted.

First MySQL 5.5 Beta Released

Comments Filter:
  • Editor Fail (Score:2, Informative)

    by OverlordQ ( 264228 )

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

  • "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 :)
  • by Monkeedude1212 ( 1560403 ) on Friday December 18, 2009 @12:44PM (#30489824) Journal

    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.

  • by ducomputergeek ( 595742 ) on Friday December 18, 2009 @12:49PM (#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.

    • 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!
      • by h4rr4r ( 612664 )

        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.

    • by msimm ( 580077 )
      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 pr
    • 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 thei

      • Re: (Score:3, Insightful)

        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. :)

    • by Macka ( 9388 )

      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.

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

    • 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.

  • 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".
  • ...but I don't think it means what you think it means...

    Bequeath [answers.com]

  • 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.

    • by Sxooter ( 29722 )

      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.

      • by mysidia ( 191772 )

        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 th

      • ... 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.

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants

Working...