Is there An Enterprise-Level Open Source RDBMS? 177
Colm@TCD asks: "This is something I've run up against, and I'm sure that anyone else who's trying to bring Linux and Open Source software into 'enterprise' systems has encountered the same problem: Are there any OSS 'enterprise-quality' RDBMSs out there? Many (most) business setups require a fast, solid database engine to run back-end stuff. Fast SQL support isn't enough, though -- these systems need to be able to fail-over automatically to a backup machine in the event of the main system falling over. What are the best of the available systems? Are there ways of taking the existing systems like PostgreSQL and making them failover-able?"
Re:RDBMS (Score:1)
looking forward to it... (Score:1)
Re:OSS is not a solution for every problem. (Score:1)
Re:OSS is not a solution for every problem. (Score:1)
So far, we have Interbase, which is currently in that odd limbo state, so common to formerly-commercial opened releases, of being called Open Source, but still no code being out. Will this actually arrive under an open license, and become the core for a free-for-all of open improvements, eventually eclipsing even Oracle, the second-largest software manufacturer in the world, in features, performance and stability?
We'll see. For now, we have the label "Open Source" on the website, a binary-only release, and a promise of code sometime in the next three months.
Until such a thing comes to pass, it's still just in "let's suppose"-land. It's still up to the garage hackers, so I stand by my comments.
--
Re:OSS is not a solution for every problem. (Score:1)
--
Re:Replication (Score:1)
Re:Postgres-- what about DSS/OLAP? (Score:1)
http://linuxtoday.com/stories/19117.html
May help..in October:-)
Applixware also seem to have one..http://freshmeat.net/appindex/1999/05/11/926
Martin
Re: DB2 vs MS in 18 months time (Score:1)
MSSQL 7 does support row level locking.
MSSQL 6+ support online backup and restore, better than any of the others - you can backup the DB while it is still up and running, instead of making a copy of the DB and backing _that_ up.
(No idea why they have this and at least Sybase, who had the same codebase, don't. Some Microserf must've briefly channeled a code deity. Weird.)
What the hell did you need raw I/O for anyway? You get a perf boost using it under some OSes, but only because of quirks in the given OS. Raw I/O != better for all systems.
MSSQL has its roots in the Sybase code. Be fair, slap them too if you don't like where they came from. As if several years ago history were in any way relevant...
MSSQL can and does support enterprise applications - I've installed apps for many Fortune 1000 companies, and it's done as well or better for us than Oracle or Sybase, even when those are running on Un*x boxen. Don't get me wrong, for the serious datacrunching, you've got to go with Oracle or Sybase on the big iron, but for anything other than monster projects it'll do what you need.
Yes, like any product, it's got bugs. But so do Oracle and Sybase, and I'm sure all the others though I don't have the first hand experience with those.
I'm not a M$ bigot, nor have I ever worked for them. I just can't stand folks who just fire off mindless salvos against a product just because of the logo on the box. Especially when they don't know what they're talking about.
-reemul
If you want to attack M$, find me the bastard who thought a talking paperclip was a neat idea!
I used Interbase from day 0 - a recommendation (Score:1)
http://www.zdnet.com/intweek/stories/news/0,416
Many years ago (15 to be exact) I was the technology manager for a very high tech system specification tool. The first version was developed on VAX/VMS. We chose DEC Rdb v1, which just hit the market when we launched the company, over Oracle (which was four years old at the time and in V3.x). Rdb was just better performing and had a much more sophisticated feature set (including blobs, which Oracle didn't have at the time and was a must have feature for us).
After we finished our first version of our tool, we had to port it to workstations, including Suns and Apollo. Just around this time Starkey left DEC to found Interbase, along with my old boss, Dave Root (whom I had worked for in a DBMS development company called SEED). Choosing Interbase was a no brainer - it was the most advanced RDBMS of its time (the competion then was Oracle and Ingres), Starkey and Root were brilliant developers, and Apollo (now owned by HP) OEM'ed Interbase, plus the API of Interbase was almost 1 to 1 with Rdb.
I lost touch with the company many years ago, but I followed it in the news, as it was bought by A-T and then Borland. It was a great example of brilliant technology that was never marketed properly.
When I first heard Interbase was going open source, I was pretty excited. Of course, my concern was that since the original founders hadn't been involved for years, the quality of the product might have deteriorated. I haven't used Interbase in over 10 years. Hence my great excitement in reading the above article. The combination of Starkey's involvement in the new company with the open source model ensures, IMHO, that the new/old Interbase will be one hot SQL DBMS solution.
Re:list of open source RDBMS's (Score:1)
(Is'nt everyone now days)
We are going with Postgres and it works.
Re:OSS is not a solution for every problem. (Score:1)
Informix was the first of the big RDBMS vendors to port to linux. I think the quote was "We just typed make"
GNU enterprise level software - is there any? (Score:1)
I've been wondering a similar question myself.
Is there any gnu/freeware that are robust enough to be categorized as "Enterprise-Level"?
Please don't take this as an insult, I am just genuinely wanting to find out the answer.
If you know about any, whether it is ERP (Enterprise Resource Planning) or office-suites, or databases, or whatever that is/are freeware/opensource/gnu (Free as in freedom and/or beer), please drop me a not or two.
My email address is: knife@newmail.net
Many thanks in advance.
Re:Testing (Score:1)
Re:Database failover is only available commerciall (Score:1)
I am not impressed with what I've heard and observed about the Oracle failover and MS SQL failover. I would completely trust Tandom non-stop, however that's a very high-end solution. I'm not sure about DB2, Informix, and Sybase. When I used Sybase at AOL, we didn't have failover, only RAID.
Most of these systems (except I think Tandom) are limited in a number of ways. Requiring shared hardware (in Oracle's case, as in some others) is not scalable and very expensive, not to mention not ideally reliable. Most are limited to one master machine that replicates to others, often hot spares rather than distributed load processing.
Systems like Tuxedo act as a front-end to database systems and manage distributed transactions, failover, and load balancing. IMHO, this is the way to go.
I have been studying this problem and working on solutions for a while now. If there is anyone who would be interested in working on a transaction monitor project with me, please let me know.
Thanks sdw
Re:Not at all unreasonable! (Score:1)
Perhaps it's the chance for a young hacker to begin writing an RDMBS with a simpler and modular design and breaking the myth about RDBMSs being necessarily complex.
In fact, I'm not 100% convinced about the relational model (with it's SQL) being the best one for using at enterprise level, there should be better solutions for the 100.000% availability problem.
s/RDBMS/Operating System (Score:1)
I'm not even sure that an enterprise-level OSS kernel makes sense. If you're talking about an enterprise-level product, you probably have the resources to afford to purchase a commercial Operating System. Both Sun and QNX have decades of experience building robust, rock hard, operating systems that you can bet your company jewels on, and both companies have x86 versions of their OSs. I'm not sure about Compaq (Digital), they may have an x86 version of their OS too.
Right now, attempting to deliver an OSS kernel that can beat time-tested operating systems from Sun and QNX would be quite a challenge, to say the least. People will just have to accept the fact that OSS can't solve every problem in the world. It's certainly feasible that one day Sun or QNX might decide to release their respective kernels under an OSS license (which should certainly be quite a shock to many people), that's probably the
most likely scenario.
Re:OSS is not a solution for every problem. (Score:1)
Moderate this up! (Was: Re:whats wrong with you) (Score:1)
Re:Replication (Score:1)
Re:Postgres (and views) (Score:1)
And I really don't think that it takes that much longer to select off a view than doing a huge join - the SQL server has to do the same work (select with a big join) either way, it's just less typing when you use a view.
Maybe this elusive column-level security does the same sort of thing, I don't know. Care to explain what it is, so there's a better chance of it getting implemented?
--
Re:Postgres (and views) (Score:1)
The workaround is to deny the users access to the base table(s) and allow them access to a view that contains a subset of the original information.
As for a join in a view versus a join in a stored proce, you're right, it's the same difference.
--
Re:OSS is not a solution for every problem. (Score:1)
-dk
HA is easy to add services to. (Score:1)
To add new services, you pretty much need a start, stop and test script. The data reside on shared disks that get transfered between the machines on failover.
On failover, the new primary will run the start script and serve PostGresql. On failure, it will try to run the STOP script before it dies and the other machine become primary (see beginning of paragraph until bored).
Of course, dedicating two machines to an HA setup and running (good fast hardware) RAID with SCSI joined to the two machines means then buying/hacking your HA software means that you're dropping some cash on this. And you're running PostGresql.
If the service is worth dropping that sort of cash on, do you really want to use a product with nobody to call when some stored procedure causes a crash? Or might it be worth putting a little cash into support as well? (and count the time when you spend 4 days debugging a problem. if it takes 4 people 4 days @ (say) US$600/day, then you've just spent around $10000. And that's cheap labor.
So, that said, it's not hard to add jo-blow services to the HA systems I've worked with.
Re:Column Level Security (Score:1)
This product was apparently included in Oracle 8i
See This PDF [oracle.com]
Re:Postgres (and views) (Score:1)
Okay, granted, just about anything that performs multiple joins against a bunch of different tables is going to slow down the query engine, but have you ever created a view without joins in in a properly normalized database? I'll let you in on a secret: my users and I know that running the monthly calculations (oodles of stored procs one right after another) take forever to do - they just let me know when they're starting, and then we all go out for coffee and a long lunch.
I've played with several databases in my life, and I think I can safely say that taking a performance hit in the face of complex queries is pretty universal amongst all of them.
And yes, I've thought about writing my own query engine, something that would be more efficient and put all those Oracle and SQL Server slowpokes to rest once and for all...
Easier said than done. I realized, much to my chagrin, that Common Joe DBAs like me can write query engines that run pretty quickly <u>if</u> your Joins only deal with Indexed Fields. This is fine in a <i>properly</i> designed DB, I guess, until your other DBAs start to play Pin The Blame On The DBD.
When you have to add functionality to allow Joins against Non-Indexed columns, you begin to acquire an appreciation for what the software developers who wrote your RDBMS had to go through - suddenly, waiting a measly 20 minutes for your DB View off a server with 250 other clients doesn't seem as bad anymore.
Skevin
Database Design and Programming
Disney Televentures
Re:Not at all unreasonable! (Score:1)
I thought he/she did that on purpose.
Re:Three months time???? (Score:1)
In any case, it's great that there will be two transactional open source databases availble, and I'm sure each will push the other in good ways. More choice is a great thing.
-Tim Dyck
Re:Oracle strategies generalized to other RDBMS (Score:1)
Re:Hypersonic SQL (Score:1)
Re:Open-Source OODBMS? (Score:1)
Re:Hypersonic SQL (Score:1)
RDBMS relatively new design? (Score:1)
Has Computer Science really been around long enough to consider a 30-year old field "relatively new"? Even if you were to say that CS got going in 1940 (and I'd be interested to hear that argument), RDBMS ideas would have been around for 50% of the time, 1970 - on (or whenever Codd released his stuff).
Re:OSS is not a solution for every problem. (Score:1)
And whatever he said, I will say, linux does not scale well at all. Once you have more than a handfull of processors, linux loses, and NT, Solaris, etc all win. And K/Gnome??? Sure, they're configurable, and powerful, but when it comes to doing work (other than trumped up shell windows), neither comes close to win98/macos for ease of use, consistency, or navigability. *inhales sharply*
Don't get me wrong, I like linux, I think OSS is a Good-Thing(tm), and we run all our webservers on Linux where I work. However, we know, when it comes to enterprise-level databases, it just won't cut it, and for that we have a Sun with Oracle 8, because we know it will stand up, and if it doesn't, there are people to sue.
My
G-funk
1stPostDB (Score:2)
Work on Enterprise Linux RDBMS (Score:2)
Re:MySQL performance (Score:2)
failover postgres (Score:2)
I was annoyed with my proffesional collegues using Oracle 8i etc (excellent products) but not setting them up to facilitate their features. The 'use Oracle and don't worry about our databases fullstop' attitude is everywhere.
Anyway, to the point:
I used PostgreSQL with an additional layer underneath my application which done all selects on the same node as the process and all other operations on all nodes. There are a few tricks to getting this done, such as counters etc need to be setup to be multiples of, say, 100, with the cluster number added to that number. (this means if things screw up, nodes can operate independantly as much as possible then sync up when possible). I hope this makes sense, it's late. Other hacks, such as code to sync/check integrity etc databases after failing are relatively straight forward.
So, the bottom line:
Performance over n nodes only as good as one node (_slightly_ worse).... but then, hardware's cheap...
Reliability: We have had all sorts of things go wrong, but at the end of the day, when the macines are live again, we have never had a problem.
Im no expert by any stretch of the imagination, but with continuous incremental backups etc and a little common sence we are using PostgreSQL with a $$$ (8 digit) online business, and I can sleep at night, even though im personally responsible for the systems.
PS: Total expenditure on software for the system: $0 (we have/had the $ to purchase expensive software; OS solutions just came out on top)
Re:Postgres / Illustra (Score:2)
Let me follow up to that.
Once upon a time I spent a year and a half developing applications for Illustra, the commercial follow-on to Postgres. Illustra had the same features as Postgres, plus SQL-compatibility, plus all of the standard SQL datatypes, while still including all of the ORDBMS features of Postgres. They even had support.
What Illustra didn't have, couldn't have, and what Postgres will never have is speed. The Object-Relational data model is not as efficient at doing plain Relational data work -- it can't be. Using Illustra/Postgres for normal relational databases is like trying to fight Mike Tyson with one arm tied behind your back -- you're playing the other guy's (in this case Oracle/DB2/Sybase) game, and giving him points to start out. Why is this important? Because all of the database APIs (SQL, ODBC, JDBC) only understand rows in tables with cursors, and all of the back-end reporting engines only cope with relational tools.
Illustra and Postgres are much more interesting for storing object data ... but the only way to take advantage of their capabilities is to use their special APIs. At which point you've thrown away portability and standards, and you've bought yourself a proprietary (even if it's open source) solution. It may be the perfect solution to your problem, but like a black hole, it will warp everything around it. Take replication -- replication is hard for ordinary RDBMSes to implement reliably; when you add object IDs to every row of every table in every database, you multiply the problem, since you can't just copy the rows directly from one database/table to another, for the same reason that you can't easily serialize a C structure containing memory pointers -- all of the pointers (object IDs) will be wrong.
I should really be talking about Illustra in the past tense -- the company got bought out by Informix several years ago, and Informix folded most of Illustra's technology into their Universal Server database. Dr. Stonebreaker (the creator of Ingres, Postgres, and Illustra) went on to become the VP of Technology for Informix.
Re:OSS is not a solution for every problem. (Score:2)
Maybe, but things look much better now. (Score:2)
I doubt it was K&R style code - it was probably written for the Borland C compiler and it's been on Windows for quite a while. It is certainly possible that it might have some ugly code. We can fix that.
Thanks
Bruce
Overextension of the Open Source concept (Score:2)
At times people seem to get carried away with the Open Source phenomenon. We need to remember to take a step back and realize what an incredibly miniscule blip on the radar of innovation that OSS is, and that for a good three decades conventional development models produced some great things. Relational database code is one of them.
--
Re:Open Source Databases (Score:2)
MySql is neither Free nor is it (yet) an RDBMS
Actually older versions are GPLed. Newer version are free enough IMO: you can modify, redistribute and use at will, you're just not allowed to sell them for a profit (as in selling a product that would only work with it). So for me it's Free, if not in the general sense. Then, Monty in an interview hinted that he was trying to have it fully FREEed (Open Source'd).
Looks like I'm not the only one (Score:2)
So A big Sun box and Oracle are going to be the back end. Even Oracle on Linux runs into the filesize limit, because of the lack of raw device access in the kernel.
Sometimes, free software isn't the way to go. You have to pick the right tool for the job.
Re:OSS is not a solution for every problem. (Score:2)
Please re-read your licensing agreements with these respective vendors. You can't sue them, you can't even think about suing them. With oracle, I think they can actually have all of your children killed if you think about suing them and they find out.
It's amazing how long elementary FUD like this can abound, especially after it's been refuted countless times in OSS diatribes. Who do you know who has ever sued Microsoft for lost data and won? Have you ever heard of Sun getting busted up over a hardware failure? It is EXTREMELY difficult to prove that the system failed in the first place (who's to say you configured it correctly? not the experts from Oracle, that's for sure), and even if you can, you agree to a LOT of things when you put that software on your server.
I'd trust Postgres against Linux any day (and YES, I do work at the "enterprise level") simply because at least they're straightforward about there being no-one to sue. If I really needed to get hard-core (not too many machines, lots of RAM and processor, zero tolerance for failure) maybe FreeBSD would fit the bill.
Most likely though, I would be averse to anything that involved x86 hardware for real reliability. So it would probably be NetBSD.
Fun conspiracy theory here :-) (Score:2)
I put it to you: is it just a coincidence that we have here a claim that Micro$oft coined the term? Or is there some deeper conspiracy that has been in progress these many years?
Or is it just another example of Micro$oft falsely claiming innovation?
--
What you're looking for is InterBase (Score:2)
You're looking for InterBase. While it's not yet Open Source, IB 6.0 will be released under MPL 1.1. While they sanitize their code, you can get free (beer) beta releases of InterBase 6.0 for Linux, Windows, or Solaris from http://www.interbase.com [interbase.com] at http:// www.interbase. com/open/downloads/60beta_downloads.html [interbase.com]. There are RPMs and Tarballs there, and Debian packages are forthcoming.
You can also check out the community springing up around InterBase at http://www.interbase2000.org [interbase2000.org].
From my own personal experience with InterBase, I can tell you that it is most certainly an enterprise-grade database, with amazing speeds and all the features you could ask of a modern DB.
Postgres (Score:2)
Postgres seems quite robust, but slower than MySQL. If you can live with the slight speed hit for the cool features (views, and stored procedures come to mind) it's well worth it.
Postgres works great with PHP, btw.
--
My english skills are fine... (Score:2)
a) My usage is far from incorrect, though in more formal writings i'll frequently use other forms.
b) Slashdot is a casual discussion forum; colloquial language is generally fine, so long as the writing remains coherant.
Nonetheless, I generally agree that the bulk of slashdot writing is piss-poor, even for this forum.
...gotta run
Re:OSS is a solution for some problem. (Score:2)
It might be impossible to answer with absolute certainty, but nothing in this world is absolute. Would you say it's similarly impossible to know with any real certainty that a group of, say, medschool grads from Harvard are going to engineer a chip that can compete head to head against the latest offerings from Intel (et. al)? This of course, is just a random example, but you should get my point. You can accept perhaps one or two of them having the desire, but the odds of a whole community of them getting together to create something quite complex, and outside of their range of experience, for a long duration, are very slim.
That being said, I agree with your later point.
It's not (all) about the software. (Score:2)
What sets Oracle or IBM DB2 apart is that they have large user communities, and that means a lot of people trained in using them, a lot of third party add-ons, a lot of "how-to" books, etc. The real selling point of the commercial enterprise level RDBMS systems is not software, it's market position and widespread use.
Whether that kind of support is something that matters to you enough to pay the steep prices that those systems cost, you have to decide for yourself.
The only system that comes close to Oracle or DB2 in terms of popularity is MySQL. If you can live with its limited feature set in your application, consider using it.
In the long run, hopefully some open source database will become as popular as the big commercial guys. The most likely path to that is no an Oracle clone, but the development of a new kind of database paradigm and popularizes it with an open source implementation.
Re:MySQL performance (Score:2)
Re:Hypersonic SQL (Score:2)
bzzzzt. . . . next . . .
-------
Re:Failover info... (Score:2)
So, we have an enterprise-class RDBMS on a world-class operating system with RAID and failover capability, and several world-class organizations supporting it. Sounds like a Real World Solution to me.... So it doesn't scale into the terabyte range. How many folks really need that? and how many folks are employed by small businesses?
--
"We came, we saw, we kicked its ass!"
-- Bill Murray, "Ghostbusters"
Re:OSS is not a solution for every problem. (Score:2)
Yeah, I noticed.
> Linux is not where your major enteprises turn when they need 24/7 huge scalable solutions.
Some [netcraft.com] do, though I suppose you could define "major interprises" to filter them out.
> this according to Gartner Group
O Bastion of Bullshit. And PHB Fertilizer.
You're right in that some of the commercial solutions are still better. How long that will last, anyone can tell. But what makes you think OSS can't provide a RDBMS that is at least useful, and useful for lots of people?
> It takes more than opinions to form valid statements but it takes less than an minute to spout something on Slash.
[This tart retort intentionally left blank.]
--
Re:Question ... (Score:2)
Apple's Enterprise Object Framework is the best way I've seen. There's also the free GNUStep alternative GSDB. The downside with the GNUStep version is that there aren't a lot of drivers (postgress, sybase, and MSSQL at this point). EOF/GSDB completely abstracts everything and presents a true OO view of your data with no queries, transactions, or anything to worry about, the framework handles fetching and resource management.
Excluding that, your best bet is to keep operations on your data source sperate. Thing's like Perl's DBI are just a API abstraction and not a Database abstraction. The way around this is to seperate out all your data fetching functions so that all your app does is call things like fetchCustomerList(start, end). That way to switch DB's you just create a new DB module for the new DB and your application could care less.
Hypersonic SQL (Score:2)
I gave up dB work a year or two ago. Maybe it was starting with MS Access and enjoying its compact, RAD, toy quality. Unscaleable and inapproriate for Enterprise stuff of course (and making no pretence to such garlands), but fast, small (well, the .mds were small if you compacted them) and fun.
The problem was the inevitable upgrade lead me to MS SQL Server 6.5 (I was stuck on NT at the time). SQL Server had a lot of stuff I was missing in Access - triggers, stored procedures, scaleability - but it also brought a lot of frustrations. The domain aggregate functions were poorer than those offered by Access, which was a pain as I was trying to roll my own OLAP [dbmsmag.com] before it all got proprietarized into a Babel of different buyouts and skill-subsets. Its big-iron feel didn't stop it having a ludicrous 255 byte limit on varchar fields. For bigger you had to futz about wastefully amalgamating BLOBs of text with READTEXT/WRITETEXT. Plus it was grotesquely high-maintenance. I didn't want to become a DBA. I just wanted to hack SQL. And wasteful. The 'devices' ('Honey, I bloated the database') were huge and couldn't be shrunk, no matter how svelte the actual data.
By the time I escaped the NT shop I was naively looking to Oracle to save me from these frustrations. Unfortunately, I'll never know the joys or horrors of that particular 'platform', because at 600 Mb for the Linux installation I just bailed out and cried 'Enough of this grotesquely bloated crap!' and pursued XML or BerkeleyDB solutions to anything remoteley persistence-flavoured thereafter. I knew that fast and small were synonyms, but the vendors were growing fat on the antonym line and there was nothing I could do about it. Even MySQL [mysql.com] and PostgreSQL [postgresql.org] were part of the problem. They're all emacs. None of them are vi.
Recently I ran my periodic, wishful, wistful Google-grep for 'fast', 'small' and 'rdbms' and found myself, after rejecting Brian Jepson's [uwinnipeg.ca] TinySQL [ids.net] as ridiculously small and cute but strictly pedagogical, finally discovering The One.
Hypersonic SQL [www.lynx.ch], a tiny Open Source Java database weighing in at less than 100K, supports correlated subqueries, transactions, referential integrity, indexes, stored procedures and JDBC - everything basically, but GROUP BY, cursors and triggers. I never used cursors myself. I'd rather iterate in Perl. The other two, admittedly are fondly missed, but not life-threatening. It doesn't support failover. But with such a small, developer-friendly codebase anything's possible.
Did I say 'Perl'? 'But it's a Java database', I hear you cry. How can this beast talk Perl? Well, it can't, which is why I'm working on a Perl DBI interface to it talking to a native driver over TCP/IP. If anyone wants to contribute (I wouldn't need to hack it if some brave soul wants to polish up the languishing JNI [cpan.org] module in JPL [oreilly.com] to support embedding Java in Perl on Linux (currently it only works for Win32)), please get in touch. I'm almost certainly way out of my depth and entering a world of pain.
Oh, did I mention? It's 7 times faster [www.lynx.ch] than SQL Server.
Re:Replication server for postGreSQL? (Score:2)
DBI. It allows you to do round-robin connections,
among other things.
Three months time???? (Score:2)
And in terms of "advanced", Interbase will probably never catch PostgreSQL. PostgreSQL is the king of features in RDBMS with its ORDBMS features. Interbase may one day be faster, but more featureful or advanced, I doubt.
Frontbase & Standards Compliance (Score:2)
Frontbase looks pretty nice - I'd never heard of it, though. Although... it does look a lot like some product the OpenLink ODBC people had. Is it related in any way?
I'm not too sure about the benefits of full ANSI 92 compliance.
For sure, standards are a good thing, but if no one supports them, what's the use?
For instance, take Sybase & Oracle & SQL Server. For simple select, insert & update queries the SQL is farily portable. Once they get a bit complicated you'll probably need to do some fixing to get it to work.
But that isn't the major problem with porting between databases. The real "problem" is the way different DBs have different strengths.
For instance, on Oracle you use cursors all the time, and they work really well. They are fast, efficent and a great way to do some thing.
Try porting them directly to SQL Server or Sybase, and your server will die really quickly - they just don't support the same number of similtanious cursors that Oracle does. Even if they were all ANSI SQL 92 compliant, it won't fix problems like that, which are much more difficult to fix than a few syntax differences.
Question (Score:2)
What is the difference between cold standby & a database server with replication facilities?
I'm thinking of Interbase & Replication, or even Interbase and the database mirroring it has built in. Is there anything else needed for it to be classed as cold-standby at least?
I'd think it would be pretty close to warm standby if you used it with some kind of heartbeat monitor, wouldn't it?
I agree there is a fair way to go before Interbase supports hot standby, though.
Not quite (Score:2)
Interbase has been available on many non-windows platforms for a long time (15 years+) now. On Win32, they use MS VC++ to compile it.
The code was never a mess like people have been saying, but it (apparently) has a fair amount of conditional defines for various platforms. That's the stuff they are fixing now, adn why it is taking so long.
This is an email Ann Harrison (president of Interbase) posted on a list back in January:
Sorry the formatting is so screwed up! I hope it clears up some misconceptions, though.
BTW, it's good to see you're not so cynical about Inprise any more, Bruce. I was their sole defender on Technocrat when you posted that story on them a couple of months back.
I agree (Score:2)
I've done a fair bit of stuff on SQL Server, and while it is limited in that it can only run on NT, it is so much better than Sybase (for instance) that it isn't funny.
For instance, I'm using Sybase Adaptive Server 11.92, and guess what? No row locks, non-ANSI join syntax, and you can't seem to have outer joins where you filter the joined table by another (non-join) field.
SQL Server has wonderful development tools, too - like Query Analyzer. After spending the first year and a half of my working life trying to work out Oracle query plans, MS Query Analyzer was such an amazing revalation.
You are right that there a lot of (surprisingly) big enterprises relying on SQL Server. I think version 7 was a big step forward in this area.
SQL Server still can't match Oracle on joins of more than four table with lots of data, though - of course, not much can really.
Re:looking forward to it... (Score:2)
Yeah... I know what you mean.
They do seem to be very dedicated, though.. they listened to the community on the licence and everything.
I doubt there will be any problems, but it will be nice when the source is out.
Interbase (Score:2)
Interbase [interbase.com] is a RDBMS, and it is free (beer) now and will be Open Source (MPL) soon (June).
Nice, but the benchmark is crap (Score:2)
I'm pretty impressed! It seems a pretty nice bit of work - joins seem to work okay (I didn't try any out joins, and there is no ANSI 92 syntax, though)
I think the benchmark is crap, though - simply testing how fast you can create a table and an index, and then do an insert might be fair enough, but testing select speed by doing a select * from that table is a bit of a joke. I'd love to see how it performed with a 4-way join and lots of data.
That shouldn't be seen as a flame, though. I'm really, really impressed with this as a whole.
Re:Yes, but Open Source is the solution for THIS o (Score:2)
If we don't have an obnoxious Corporate eXecutive iMission Critic@l eAcronym (oCXiCeA) for OSS, then OSS is not suitable for obnoxious Corporate eXecutive iMission Critical eTasks (oCXiCeTs). Several Corporate eXecutive iMission Critic@l eConsultants (CXiCeCs) have demonstrated that OSS should be deployed in the eCorporation within several quarters, or iTimeUnits as they are now called. This will enhance our VC-funded eCorporation's rapid execution of oCXiCeTs.
Furthermore, numerous CXiCeCs have given me an executive summary about OSS, from which I have learned that because OSS is all capital letters, it will fail to succeed in eBusiness, E-commerce, and/or iWare deployment. One eConsultant suggested a paradigm shift to oSS, while another one suggested O-ss. But the latter was actually an E-consultant and not an eConsultant, and he hardly ever uses the IT acronym, so I called an eXecutive iMeeting where we all met in a conference room where we reached a consensus that the so called "E-consultant"'s credibility is lower.
Seriously, I agree with Bruce. "OSS" is highly obnoxious. Don't use it.
So is eAnything, E-anything, iAnything, and many more. Terms like those reek of marketing, rich presentation (read: content free tripe), and all those other things which make the web, computing, and many other things less fun. (Maybe Bruce agrees with that point too, but I wouldn't want to speak for him. He's been misrepresented enough as it is.) Whenever I see eFoo or E-Bar, I turn the other way as fast as I can. You should too.
Re:Replication server for postGreSQL? (Score:2)
Postgres speed (Score:2)
Not very far off, especially when considering that Oracle probably optimizes their DB specifically concerning benchmarks.
Have no link, sorry.
Oracle et al however have some edge or two regarding reliability features (and features in general).
Re:MySQL performance - a decent hack (Score:2)
My problem is this:
This is a database of commercial real estate data. There is really only one main table, but it has lookup fields that reference as many as 7 other tables, most with funky outer joins. Performing even simple queries on it is horrific.
My hack is this:
Every night, at 3am, do a GIGANTIC 7-way merge of all the relevant tables, and insert the results into a MAMMOTH SINGLE TABLE, the cache table. Lookups are lightning fast, and the data is at most 24 hours old (this is reasonable in my case). Building the cache actually only takes 15 seconds or so --- abominable if you're waiting for a web page to load, but no so bad at 3am
This technique may or may not be available to you, depending on your circumstances. I find it to work quite well with mine.
- jonathan.
Re:Transactional DSS/OLAP? (Score:2)
Transactions/Rollback are not critical (we have our own rollback solution over Acumate, made by Kenan [kenan.com]) but in a read-write environment, they sure are good to have around.
OTOH, you're right; in a DSS environments reads are always way more common than writes, so a rollback layer could actually be preferrable to a built-in transactional functionality.
So, forget about transactional control, it's not even essential; are there *any* OSS OLAP apps out there? they sure would make a nice toy
engineers never lie; we just approximate the truth.
Re:OSS is not a solution for every problem. (Score:2)
Let's suppose that a fairly good-sized company came out with an open-sourced RDBMS/OLAP framework, that has all the groundwork to be fast and extensible. I am sure there are a few companies out there that would benefit to contribute to such a project for their own uses... Why can't OSS act as a framework and collaboration scheme, instead of just a toy for hobbyists?
engineers never lie; we just approximate the truth.
Re:RedHat 6.2 and some custom code? (Score:2)
Imagine the following scenario: You, client C, initiate a service/transaction with server A. Server A crashes. Your service/transaction fails over to server B. However, server B knows nothing about what's been going on in your stateful connection, and is thus unable to help you.
The only solution that you can have within a database for failover is in the case when you have a stateless connection, and/or full state replication across the cluster of server machines. However, this alone is going to almost certainly bog down any of your transactions to the point where you don't want to continue anymore!
A company which has done this extremely well is the old Tandem, with their NonStopOS and NonStopSQL. Their mastery of failover in transactions was superb, and quite a bit of wall street is still running their stuff, even though Compaq has been quite unable to successfully market their services now (NonStopNT.... that's a complete oxymoron!).
I suppose you COULD implement the type of service you're talking about with failover stateless connections, but if you're going to do that you're much better going with an app server in the middle, which handles failover of connections in an EJB type model, and use the features of the app server to handle this.
So to sum it all up: For simple services like RPC and HTTP and FTP and whatnot, which are stateless (or very nearly so) by their nature, simple failover is fine. For extremely stateful services (like a database system), you've got to use much more complicated measures.
Open-Source OODBMS? (Score:2)
RedHat 6.2 and some custom code? (Score:2)
While they don't mention database servers specifically, "Generic service" indicates that they've figured out some way (probably similar to watchdog coupled with some form of ARP spoofing) to fail a down server over gracefully. Which leaves data replication.<P>
Would this work in conjunction with a simple mirror program? What I'm thinking of is... <P>
A small daemon that runs (and listens) on the 'master' box. When a database connection is initiated it reads the commands sent by the client and sends them on to the 'master' database server, and again to a secondary server.<P>
Both the master and secondary server have current copies of the data, and then leave the actual failover to whatever RedHat has concocted (still downloading the
Re:Postgres (Score:2)
MySQL is certainly fast as heck, but it's still missing alot of functionality one takes for granted these days. (Transactions being one of them.) Alot of people (myself included) use MySQL for business class stuff.
As the original question was one of "it cannot fail, EVER"... you're going to have to buy that level of security. There are several commercial databases for Linux that will do what you need -- they are not free (save Sybase.) But I suspect, you aren't concerned about "free". (security, speed of bug resolution, etc.)
Re:if you're not a religious fanatic... (Score:2)
Re:OSS is not a solution for every problem. (Score:2)
Enterprise database applications are subject to FUD that runs far deeper than what we see in the desktop OS competition. I implement enterprise datawarehousing solutions for a living, and I see that most clients will ONLY accept an implementation that's built on the RDBMS they already use in house.
You can open source the operating system, or the desktop environment, because your test bed starts out as hobbyists (the early adopters). Good luck finding the first company that will take the plunge and bet their entire transactional system on an untested platform, when they can pay for the insurance of an Oracle or a SQLServer.
-JTB
Re:OSS is not a solution for every problem. (Score:2)
You mean, for instance, an operating system [kernel.org]?
Or maybe a graphical desktop environment [kde.org] or two [gnome.org]?
How terribly shortsighted. I'm sure there are many people out there who are up to the challenge.
Besides, what you're basically saying is that open source projects don't scale very well, and all of the above examples disprove that.
---
If not relational, then what? (Score:2)
RDBMS is a very mature, flexable technology. SQL (& RDBMS) does have some shortcomings, but then every tool does. For many (most?) typical business applications, RDBMS is the tool of choice.
Because modern RDBMS's are so pervasive and accessable, many people forget that designing databases and writing SQL is a specialized and difficult art. A well-designed database can outperform a poorly-designed one by an order of magnitude or more. When people talk about RDBMS's having poor performance my first instinct is to question the db design and not the engine. Sadly, in my experience, most programmers treat the database almost as an afterthought. (I design databases for a living, in case you havn't guessed)
"The axiom 'An honest man has nothing to fear from the police'
Add DB2 to the list of "enterprise-ready" RDBMS (Score:2)
erlang / mnesia / rdbms (Score:2)
Erlang deserves to be better known: it is one of the biggest and best open source projects.
Re:MySQL Clustering (Score:2)
Re:Interbase (Score:3)
It also is ANSI SQL-92 compliant, as far as I'm aware, as well as adding a couple of nifty extensions to the language that negate the need for looping through cursors (for those who have used Sybase/MSSQL).
I have used Interbase on several Windows projects and it scales brilliantly from the single user desktop version to the server.
Just bite the bullet and buy Oracle or DB2 (Score:3)
Added to which, you can get excellent support (at a price) for these products, which may ultimately be worth more to you than anything else.
Failover vs. Replication (Score:3)
Replication generally does not take place on as current a basis. Replication can be done with any currently-existing RDBMS simply by adding a "last changed" timestamp to each record, and then occasionally querying out all records before a certain timestamp and sending those records to the remote server. Replication thus ensures that you have a snapshot of the data at some point in time, but not necessarily an up-to-date version of that data.
Those differences are why replication can be done by third-party software, while "real" standby requires specific support at the RDBMS level. I have done replication with technology as crude as dBase II by explicitly programming it into my applications. Standby, on the other hand, is a different issue.
Finally: For small businesses, none of these particularly matter. Small businesses don't have the money for big replication servers and such. They rely on an older version of replication: they have a paper copy of everything that goes into the computer, and make nightly backups (small businesses, unlike large businesses, don't run 24/7 and thus the RDBMS is stable at that time of night, they don't need the ability to do "hot" backups). If the database crashes and eats their data, they restore it from tape, then manually type in any transactions that weren't on the tape (using their paper copies). PostGreSQL is already "there" as far as small businesses are concerned, from a price/feature standpoint. PostGreSQL's only real issue is performance, especially performance when adding records, which is pathetically slow (using transactions helps, in that at least you don't get a sync for each "insert" but rather a single set of syncs at the "end transaction" time, but it's still less than 1/3rd the speed of MySQL even if you turned off the syncs altogether and ran it in the dangerous "async" mode). However, most small businesses don't need to add 200,000 records in a short period of time... I can add 200,000 records in little over 3 minutes with PostGreSQL on modest hardware, which is pretty pathetic, but far beyond the needs of a small business.
-E
Re:Postgres speed (Score:3)
Much of Postgres's reputation for slow speed stems from attempts to use it as a CGI back end database. PostgreSQL, like Oracle, takes a long time to open and close connections. This is because PostgreSQL spawns off an entirely new process for each connection, complete with checking the user permissions etc., while MySQL spawns a thread, which is considerably faster to do but potentially less reliable if a thread dies due to a bug in the RDBMS (ask Microsoft what happens when a thread dies without releasing any locks that it has! Ever wonder why Windows dies so often?!).
In short, if you want to use PostGreSQL as a web back end, use a persistent connection -- do NOT open and close the database for each CGI transaction!
-E
Yes, but Open Source is the solution for THIS one. (Score:3)
By the way, "OSS" is an acronym coined by Microsoft, and one I've never liked. Can we please call it "Open Source"?
Thanks
Bruce
Re:list of open source RDBMS's (Score:3)
Postgres-- what about DSS/OLAP? (Score:3)
Since I am a DSS ("Data Mining") guy though, I am more interested in an extension to your question? is there any decent OSS OLAP/DSS DB system out there that can handle multiple dimensions, transactions, partitioning, ? If not, how many people would be interested in one?
engineers never lie; we just approximate the truth.
Chris Browne has a good site for this. (Score:3)
Replication (Score:4)
That said, database failover is *not* easy.
The basic problem is that you don't just read from a database, you read and write to the database. Database replication is a very non-trivial thing to do. You have to deal with the possibility of data being inserted, updated or removed from any of the servers that are involved. This requires that you have things like global locks, timestamps on everything, primary keys that are generated in a way unique to each replicated version of the database, etc.
Most of the work of replication is handled very nicely by the big commercial databases (but you will find that they want you to pay for it.), but even with those you might have to make minor changes in your application (or maybe just the database structure) in order to handle replication properly...
AFAIK, there's nothing you can get for free that will be able to handle any kind of real-time n to n (or 1 to n and n to 1 simultaneous, even) replication. You can do stuff like have mysql dump a log of everything that's done that changes the database, and then import those changes into another mysql instance someplace else; but that's nowhere near what the big commercial databases can do when it comes to replication.
Given that replication is gonna cost real money, just get your free database running on a good-quality machine with good backups (that you make sure include the database) and maybe things like redundant power supplies. You can make a really robust box for much less than Oracle will charge you to license 2 instances with replication.
(Or hire a team of 10 database programmers to spend a year or 3 adding replication to postgresql. Well... maybe they could do it wrong in a month -- I'm trying to give a wild estimate for doing it vaguely close to right.)
Failover info... (Score:4)
Sorry.. I forgot to talk about failover.
There is a third-party, non-open source replication tool available fro Interbase 5 and 6 that will handle that data replication stuff you need for failover. The actual server switching I think you might have to write yourself... I suspect you might find there are a lot of people willing to help you.
MySQL Clustering (Score:4)
http://www.freshmeat.net/appindex/2000/01/15/9479
It's a toolkit for clustering MySQL, which may or may not provide the failover facilities that you need. It looks beta, but may work... I haven't played with it yet. And of course, this is only if you're willing to use MySQL. Looks fun, though.
Otherwise, if you're doing serious enough work to need serious RDBMS backend, I hope you're making enough serious dough to afford a serious RDBMS. But before I invested big bucks into a failover setup using a commercial RDBMS, I'd cover my other bases first. Most DB failures I've seen were not a fault of the RDBMS itself, but hardware, power, diskspace, OS, human error, etc. The only time I've seen an RDBMS crap the bed at work, it was Micros~1 SQL Server and you should know better than to buy that. With our Sybase machines, it's always NT that takes down the box, not Sybase. Get these bases covered (hi-quality hardware, reliable power with a big UPS or generator, non-Micros~1 OS, and a DBA that knows what they're doing) and you most likely won't need a failover system.
Re:OSS is not a solution for every problem. (Score:5)
The graphical desktop environments you point out are still in the infancy stage, after 3-4 years of development. Although they're very cool, (as is Linux), both are basically aping existing art, and not very well in some cases. (Go on, moderate me down as flamebait and argue with me; this is not my primary point.)
RDBMS design is relatively new in the long view of the art of Computer Science. The commercial vendors that pay thousands of people fulltime to develop them still don't have it down correctly. It's certainly not progressed to the point where it's textbook knowledge, where any fresh-faced CS grad can get in there and build one.
I think the most telling evidence that this is beyond the current state of the art of Open Source, though, is the fact that it doesn't exist yet. It's not like this Ask Slashdot is the first time anyone's ever thought about free alternatives to the big boys of databases. It's a known need.
And the "Cathedral and the Bazaar" theory of Open Source as 'developers scratching their own itch' would seem to mean that if it COULD be done, it WOULD be done. Intrepid hackers would have taken Postgres or the GPL'ed old MySQL or the like and had a project underway years ago if it were just that easy. Apparently, it's not.
Open Source projects do not _innately_ scale well, merely from the fact of them being open. There are a lot of preconditions for a project to work. At least these three need to exist:
1) A critical mass of developers see the need.
2) That mass of developers (or a subset thereof) can be organized into a team to do the work.
3) That mass of developers has the knowledge and skills to do the required work.
As an example, there's a large set of people that would like an open-source engine to crack DES keys in real-time on commodity hardware. That takes care of 1. Getting a set of crypto hackers together to do this work would be a snap, cf OpenSSL et al. There's 2. But, the art isn't there. The general public, the mass of developers out there, simply don't have the knowledge or experience to do that. Maybe it can be done, maybe it can't, that's not the point. The point is that just saying "I'm starting an Open Source project to do [something really cool]" doesn't mean it's something you actually CAN do.
So, back to the topic at hand, yes, RDBMS is something that's outside of the Open Source world at this point. The skills required to do such a thing are reporting for work at Redwood Shores and Emeryville and the like, and not willing or able to share their really-quite-esoteric knowledge with the free software universe.
And pointing to a handful of other projects that are working doesn't prove that this project, or any other, will. Look around; the code's not coming, mostly because, no, there aren't many people out there who are up to the challenge. Or else they'd be doing it.
The proof, as they say, is in the pudding.
--
OSS is not a solution for every problem. (Score:5)
This is, perhaps, one of those situations where you are rather unlikely to find an OSS solution. An enterprise-level RDBMS is not exactly an overnight hack. It would take an enormous kind of time and effort to put an enterprise-level RDBMS.
I'm not even sure that an enterprise-level OSS RDBMS makes sense. If you're talking about an enterprise-level product, you probably have the resources to afford to purchase a commercial RDBMS. Both Sybase and Oracle have decades of experience building robust, rock hard, RDBMSes that you can bet your company jewels on, and both companies have Linux versions of their RDBMSes. I'm not sure about Informix, they may have a Linux version of their database engine too.
Right now, attempting to deliver an OSS RDBMS that can beat time-tested RDBMSes from Sybase and Oracle would be quite a challenge, to say the least. People will just have to accept the fact that OSS can't solve every problem in the world. It's certainly feasible that one day Sybase or Oracle might decide to release their respective RDBMS engines under an OSS license (which should certainly be quite a shock to many people), that's probably the most likely scenario.
--
Not at all unreasonable! (Score:5)
Firstly, kernel's are not all that complicated.
Secondly, Linux's kernel is about as simple you can get.
Thirdly, Linux, thus far, has had the advantage of being behind the curve in development. It has had the benefit of essentially just being able to copy features, design, and even some code. While the code may be from scratch, virtually nothing else is. In other words, Linux's code was built with 20/20 hindsight. Furthermore, it's done nothing particularly spectacular with that opportunity.
Fourthly, the motive and feedback in developing an enterprise class RDBMS are vastly different. In developing Linux, there is something quite tangible, such that most "geeks" can get relatively instant gratification. Do geeks really personally need such a database (of course not, not even their hardware approaches this)? Contrast this with an RDBMS, if "they" make the system %.001 more reliable, by whatever measure, under heavy loads, how can they appreciate that? (never mind testing it) These things are about numbers. A company that does 1 million a day in sales with a broken database can't afford that %.001, but a geek screwing around developing a database in his spare time for his uses is not likely to experience such a problem. And even if he is, does that %.001 really mean anything to him? He can just reboot. Sure, you can say "given enough eyes all bugs become shallow", but ask yourself: Whose eyes, and how do these bugs become apparent? A minor bug in Linux, and a couple geeks have to reboot their PC (which presumably prompts them to patch it). Which company is going to volunteer to expose itself to such a bug---possibly millions of dollars in lost revenues (amongst other concerns). The scale of the two uses changes the nature greatly (likewise, empirically, Linux demonstrates such leanings--towards areas which most geeks appreciate, but not necessarily enterprise)
Fifthly, the development process itself is vastly different. Because Unix, and particularly Linux, is quite modularized, it can be developed is a ragtag fashion. This is not true with an RDBMS. They're are very complex and interconnected.
Sixthly, support is a major issue. Despite all that hype amongst the linux community about "support" it is absolutely undemonstrated. And when you consider issues such as proper documentation....
Seventh, given some of the risks i've mentioned, what company is going to prefer to try to save 10k in software fees for the increased risk. The expected value in this case could very well be negative.
...I can think of more, but that is plenty of doubt right there. Think critically, not dogmatically.
Database failover is only available commercially (Score:5)
I cover databases for PC Week Labs, and in my view (and in my tests), the most sophisticated OSS relational database is PostgreSQL. In three months, though, that title will be held by InterBase. It has a more complete SQL implementation, has a (third-party) replication option and is generally more mature. However, it doesn't have any failover.
The products that do provide failover are (non exhaustive list, but these are the main ones): Oracle Parallel Server (or Oracle with the Failsafe option if you want just 2 node failover), Sybase ASE, IBM DB2 UDB, Informix, Tandem NonStop SQL and Microsoft SQL Server. The cheapest option in terms of purchase price will be Microsoft SQL Server with Microsoft Cluster Server, but it only runs on NT and only supports 2 node failover, and does not cluster.
Note that when you talk about failover (particularly with stateful connections), you need to also get failover-capable hardware systems. The databases mentioned above all need special, tightly spec'ed high availability hardware configurations from Sun, HP, etc. In general, a shared SCSI bus is required.
You also need to decide what level of failover you need: (from simplest and cheapest to most complex, expensive and best):
* cold standby (replicate to a standby server) -- no shared storage, mostly up-to-date, cheap, manual intervention required for failover
* warm standby (shared storage or transactional replication to a standby server) -- ensures no data loss for all committed transactions, requires fault-tolerant hardware and a fault-tolerant dbms, failover is automatic but may take several minutes to roll the log forward, warm up the cache and reconnect users
* hot standby (shared storage) -- no data loss for committed transactions, fast failover (30 seconds or less) -- this is a very specialized area, and you should have your dbms vendor work with you on setting up these kinds of HA setups. This is an ongoing area of research; Sybase 12 and Oracle8i 2.0 introduced new features specifically in this area to do things like pre-connect users and pre-warm the cache to speed failover times.
If you want to have an OSS solution, I'd advise using PostgreSQL or InterBase and writing stored procedures in C to replicate inserts, updates and deletes to a second server, then coding reconnect and heartbeat logic into your front-end apps. This will be easiest to do with an app server since you have a single point of data access. This will not provide atomicity or durability though (unless the updates use 2PC) -- you'll need to run a consistency check on the db on failover.
This is hairy, though. Overall, I advise paying for something that someone else has gotten working.
Regards,
Tim Dyck
Senior Analyst
PC Week Labs
Interbase (Score:5)
--JRZ
Interbase, Interbase, Interbase!!! (Score:5)
Interbase v6 is in (free beer) beta right now, and will be released under the MPL (Mozilla Public Licence) by Mid-June
You can download the beta now for Linux, Windows or Solaris from Interbase.com [interbase.com] or The Interbase Developers Inititive [interbase2000.org]
Supports databases up to 32 TB (!!!) spread over 2GB files and is fast and reliable. (It's been around for 15 years.) The biggest known Interbase DB is over 200GB.
It's is ANSI 92 SQL compliant (well.. as compliant as any DB I've ever seen - better than Oracle for instance), and the support is Amazing
Join the email lists at www.mers.com [mers.com], and you'll be able to get answers from Ann Harrison (the president of Interbase.com), or from a lot of other people - it's the best support I've even seen.
As for enterpise features - well, apart from large DB support, it has row level locking, transactions, referential integrity, blobs, Multi-Generational commits, stored procedures... ummm... I can't think of what else to say.
Basically, if your Databases are less than 50GB then Interbase is the number 1 choice - above that maybe Oracle would be better, but that isn't exacly open source.
Oracle strategies generalized to other RDBMS (Score:5)
Here's a good way to do it in oracle, that'll probably genralize to almost any RDBMS:
The simplest way is to have two unix boxes, each physically attached to a raid unit (dont use raid 5, use mirroring for performance). Don't use clustering software, just mount the filesystems on only one machine at a time. If the primary system fails, then mount the filesystems on the secondary , startup the database, and you're on your way with minimum downtime. Script it and tie it to some ping or other fail detection strategy if you feel lucky, but in my opinion, keep a human in the loop to actually execute the switchover.
Another great solution is a so called "standby database". You make a copy of the primary database to your standby machine, using your backup tapes. Then you start to "roll forward" the standby database by applyin all offline redo logs of the primary database, as it is generated. This method should work for any database that logs transactions including Sybase, Informix and probably MySql. The equivalent of a redo log in MySql appears to be the "update Log". but I have no experience with MySql. One big drawback of this solution though, is that even though a transaction has been committd to disk on the primary, the event may not make it to the offline redo logs before the system crash. So a standby database can only be within some delta-T of the primary database, the last fiew transactions before the crash are lost. Sometimes this is acceptable, but if you billed the customer then lost the order, maybe not. You tune the redo logs buffering parameters to trade of performance for small "lag time" of getting redo logs across to the standby database.
The truth is that it takes 10x effort to get failover and cluster software correct, and 9 times out of 10, the automatic failover either triggers accidentally (bad news) or triggers correctly but fails to come up on the secondary. This is because you have to be incredibly scrupulous about keeping non-shared resourses in sync on the two machines and you can't test the failover (politically that is) until it actually fails. Heck, I just took a call this past saturday for this very problem: Site paid $$ for a bigger consulting firm to implement cluster, firm cant be reached on saturday when cluster trips but does not failover successfully. Customer calls me. I am to gracious to say I told you so.
My free advice: Make two machines, not a cluster. Keep the two machines in sync, using the "standby technique", or make the raid unit accessable by both machines. Keep a human in the failover loop.