High Availability Solutions for Databases?

An anonymous reader asks: "What would be the best high availability solution for databases? I don't have enough money to afford Oracle RAC or any architecture that require an expensive SAN. What about open source solutions? MySQL cluster seems to be more master/slave and you can lose data when the master dies. What about this Sequoia project that seems good for PostgreSQL and other databases? Has anyone tried it? What HA solution do you use for your database?"

Comments

Whatever else they tell you

[Anonymous Coward]

Don't buy the RAC hype. I've seen too many misperformant RAC clusters that Oracle couldn't fix to save their life (and no, they weren't all bad vendor configuratins either).

MySQL Cluster != master/slave

[cravey]

While MySQL supports master/slave replication, MySQL Cluster specifically avoids that entire model. It's an entirely synchronous database storage engine. If you want master/slave, use postgres. If you want high availability and can handle the lack of a small number of features, MySQL Cluster is the way to go. The only real downside to the architecture required for CLuster is that all of the data is stored in RAM based tables. transactions are logged to disk every (configurable) time interval. If you're going to try for HA, you might want to RTFM on the available options before you settle on one.

Re:MySQL Cluster != master/slave

[afabbro]

The only real downside to the architecture required for CLuster is that all of the data is stored in RAM based tables

...for an "only real downside" that's a pretty big one. I mean really, what sort of database is this - 256MB? 500MB? 1GB? Fine for small websites, not fine for large apps. I don't mean to be a "big shop" snob, but this is a ridiculous limitation.

Unfortunately, open source hasn't caught up to the big guys yet in the area of replication.

Re:MySQL Cluster != master/slave

[cravey]

Name a DB from a 'big guy' that doesn't require a shared resource. Oracle? Nope. RAC requires a shared storage solution. Lose your single storage device device and you lose access to your db. MS-SQL? Don't make me laugh. SAP? No. Postgres? No. Firebird? No. Who's left? MySQL is the ONLY available 'shared nothing' (tm) solution available.

Yes, the RAM only tables suck for large DBs. On the other hand, they're REALLY fast and they can be easily scaled up on commodity hardware rather than requiring faster and bigger servers and storage. I'm in medium shop that only requires a few gigs of table space. I'm n+2 on webservers/sql servers and data storage nodes for under $15k. If I wanted to use Redhat on amd64 with gobs of ram/machine, I could probably be n+2 to 64G for under $50k. The only time I will EVER have to take my cluster down is to add more storage space or to replace my switch. That will result in about 10 minutes of downtime. Based on growth, I won't have to do that for another 18 months. If I wanted to spend another $10k, I could avoid having to take down the system in the event of switch failure. I've never had a carrier grade switch failure on any of my networks, so I'm feeling pretty good about availability.

Yes it's expensive to get up into the terabyte range with ram based tables, but there's also no other way to do it without either spending ridiculous amounts of money or being dependent on a single piece of hardware.

Re:MySQL Cluster != master/slave

[Joff_NZ]

The other thing to note with MySQL Cluster, is that, even in 'stable' releases of MySQL, is horribly unstable, and prone to massive data loss..

We deployed it ourselves, and it worked ok for a while, but things went very very wrong when we tried updating one of the configuration parameters, causing us to to inexplicably lose quite a bit of data.

Avoid it. At least for another generation or two, or three.

Re:MySQL Cluster != master/slave

[jorela]

Actually we have implemented disk storage.
Hopefully it will make into version 5.1.

MySQL Cluster 4.1/5.0 supports:
* transactions
* transparent data partitioning and transparent data distribution
* recovery using logging
* (multi) node failure and automatic non blocking hot sync for crashed/stopped nodes
* hot backup

MySQL Cluster 5.1 will support:
* user defined partitioning
* cluster to cluster async. replication (like "ordinary" mysql replication)

The disk impl. supports
* support putting column in memory or on disk
    (currently index columns has to be in memory)
* all HA features mentioned above.

Re:MySQL Cluster != master/slave

[delta407]

Name a DB from a 'big guy' that doesn't require a shared resource. Oracle? Nope. RAC requires a shared storage solution. Lose your single storage device device and you lose access to your db.
...
The only time I will EVER have to take my cluster down is to add more storage space or to replace my switch.

Sorry, what? You're bashing Oracle for having a system with a single point of failure, then add two of your own?

"Shared storage" doesn't mean "not highly available". If you're serious about building a database that cannot go down, you get multiple servers, each with two Ethernet interfaces and two Fibre Channel cards. Get two Fibre Channel switches, and two Ethernet switches. Get two Fibre Channel disk arrays. Hook together as follows.

Both disk arrays have one or more uplinks to both FC switches. Each server has one HBA connected to each switch. Then, use Linux multipathing to provide automatic failover in case either switch dies or either HBA dies, and use Oracle ASM or Linux MD to mirror the data so you're good even if you unplug the shared storage.

Set up the servers to use 802.1q VLAN tagging. (Remember, it's a good idea to keep your inter-node communication separate from client-to-server communication.) Create two Ethernet bridges, using the Linux bridging driver, binding eth0.2/eth1.2 to one and eth0.3/eth1.3 to the other. Take the two switches, set up 802.1q on the ports going to your database servers, and connect them together (preferably using high-speed uplinks, but channel bonding works fine). Enable spanning tree on the switches and on the bridges. Connect both switches to the rest of your network.

Now, if a switch starts on fire, spanning tree on the servers will fail over to the other one automatically. If a network cable gets cut or a network card goes out on one node, that one node will fail over all traffic to the remaining interface, and the inter-switch trunk will make everything keep working. Suddenly, you've got a robust network.

So, we've got network and storage covered. What about the database software? Neither MySQL nor Postgres can use this sort of configuration, but Oracle RAC can. Add a dash of TAF, and suddenly, any component -- network switch, database server, SAN switch, disk array -- can fail in the middle of a SELECT and the application won't notice. That is highly available.

Yes, this solution costs more. Our data -- more accurately, the cost of it not being accessible -- justifies the expense. But don't tell me that shared storage is a weakness.

Re:MySQL Cluster != master/slave

[duffbeer703]

MySQL was prone to massive data loss for years... what's the big deal?

Re:MySQL Cluster != master/slave

[delta407]

Yep, Oracle RAC requires a quorum disk (CRS calls it a "voting disk"). However, if you use OCFS2 to store the data files (including the voting disk) the solution above cannot produce split-brain. Putting the data files in OCFS2 puts the responsibility of guarding the shared storage in the filesystem, which solves the problem as follows.

Each node in an OCFS2 cluster updates a special file every two second and maintains a TCP connection to its neighbors. If this process doesn't work (i.e. writes are failing, are backlogged, or for whatever reason don't hit the disks in a timely fashion), the node will fence itself. Likewise, if the node starts on fire, it will naturally stop updating the heartbeat data. Either way, other nodes are aware of who is up and who is down, even if the IP network dies. If a node's access to the storage system dies, OCFS2 won't be able to successfully read back its own heartbeat timestamp, and the node fences itself.

Note that this heartbeat procedure happens on the same block device that the data files are on. There's no way to reach the data files unless a node is in agreement with every other node, thus no way to cause "split-brain".

Say, somehow, a series of failures occur all simultaneously that results in Array 1 being connected only to nodes 1-4 and Array 2 being connected only to nodes 5-8. Each node keeps heartbeating, and after a little bit, Node 5 notices that Node 1 hasn't updated its timestamp, but that Node 1 just said that it did (over Ethernet). OCFS2 notices this immediately, much inter-node communication happens, and nodes 5-8 decide to fence themselves, leaving 1-4 as the only nodes allowed to touch either disk array. Still working as advertised.

Let's examine that failure. First, you'd have to terminate the links between both fibre channel switches. Then, you'd have to break uplink 2 on array 1 and uplink 1 on array 2. Then, you'd have to take out the second HBA on nodes 1-4 and the first HBA on nodes 5-8. Simultaneously. And the system handles this gracefully.

Now, what happens when the network goes out too, you ask? Remember that each node has one connection to both switches. Say we lose a switch -- all the nodes fail over to the other one. Hmm. Say we unplug nodes 1-4 from switch 2 and unplug nodes 5-8 from switch 1 -- both switches are connected together directly, and thanks to VLAN trunking, all the nodes can still reach each other. Darn. Say we also unplug that link. Well, both switches are plugged into the rest of the network, right? Assuming you also set up VLAN trunking there, the switches will be able to reach each other through a third switch. Hmm. What if we unplug those, too?

Congratulations! Split-brain! Nodes 1-4 proceed on Array 1 and Switch 1, and nodes 5-8 proceed on Array 2 and Switch 2. You only had to unplug 22 different cables -- eight Ethernet cables and eight FC cables from the nodes to the switches, two inter-switch links (one Ethernet and one FC), two disk array uplinks (one from each array to each switch), and two Ethernet uplinks (one from each Ethernet switch) to the rest of the network -- simultaneously.

As I said, no single point of failure.

Re:MySQL Cluster != master/slave

[msanto]

For the OCFS2 special file not to be a single point of failure, I assume it's mirrored between both storage arrays. If you lose all connectivity between data centers, assuming each DC has a storage array and a node then don't you still have both halves thinking they are it and still have split brain? That's 2 simultaneous outages and if your company is anything like those I've worked with 1 outage may suffice.

In my current company, our network group tends to keep things to themselves and we'd never have known we didn't have redundant fiber if someone didn't shoot out our cable that ran through a bad neigborhood and it became a topic of conversation (yes, with a gun).

I also worked at another company that had redundant fiber lines that were both taken out by a single backhoe, apparently they were bundled together.

MySQL - Master / Slave is the only option

[digerata]

You can use MySQL's in-memory cluster replication, which is pretty cool. You can have quite a few nodes, each serving requests against the same database. However, your database size is limited to the amount of RAM a single node can support. That really limits long term scalability of the database. What we just hit 8 GB? What do we do? Sorry, boss, I need another ten grand for an unplanned DB upgrade. Also, if you are used to the atomic transactions InnoDB provides, forget that. The cluster storage system NDB does not support all of the features that InnoDB does.

We chose to go with a Master / Slave option which basically gave us failover within 3 seconds. Any more fine grained monitoring and the CPU performance on the slave gets pretty high. Not ideal, but probably the best option that uses MySQL when you don't want to be tied so much to one platform.

Re:MySQL - Master / Slave is the only option

[cravey]

Your database size is NOT limited to the amount of RAM a single node can support unless you're only running 2 nodes. It's possible that your tables size may be limited, but I don't believe that that is the case. No, the cluster storage system does not support all the INNO DB features, but INNODB doesn't support all of the MyISAM features. Does that make MyISAM better?

Oh that's easy...

[ipoverscsi]

It's called a filing cabinet. It's got full text search and an easy to use index. Although it has 99.9999% availability (it's blocked by crap stacked in front of it the other 0.00001%), it's a bit difficult to make backups without access to the office copier, two toner cartriges and 20 boxes of paper.

What are you doing? It's important.

[anon mouse-cow-aard]

It's odd that all these people are answering without hearing a thing about your application. How big is the db? How often is it written? How often is it read?

For example, we run a site with data from a thousand odd different data sources, with each source getting updated every hour or so. We do it by parsing the data into static pages. We we receive a datum, we rebuild the pages that depend on it.

We have another site that runs off an Oracle db. the static page site runs about 90x faster, and is basically in memory (disk access is nil.) Now take into account that we can (and do) replicate the static page solution with zero load, we get to a solution that is literally 900x faster.

Now folks are thinking 'oh, the horror!' well... tough! There is no substitute for thinking about your data, and how it flows. A DB is not a given, but a (potentially wrong) answer to a question after you have done some analysis.

Nice "question"

[photon317]

Hello, anonymous Sequoia promoter seeking free advertising. (BTW, You might try picking a product name that normal people can spell without thinking about it).

Your solution is not database clustering, and should not be advertised as such. It's more a long the lines of a database connection proxy which supports multiple simultaneous backends and operating on them in parallel, with some added features to make HA-like solutions relatively easy.

The downside of this style of approach, as opposed to an architecture of the likes of Oracle "RAC", is that it doesn't scale up as you add backend nodes (at least not for writes, but in any case for read-only scaling there are simpler solutions for all of the vendors, even the free ones), and it must have limits on how many transactions it can backlog and replay to a temporarily-unreachable/down server before that server has to be re-synced from scratch in order to catch back up (and I have to wonder if there's really any real-world scenario under real transaction load in which the practical net effect wouldn't be a complete resync of a backend server anytime something goes wrong with it, in which case one could throw out any attempt to backlog transactions for a single failed server and just keep things simple - you fall out of sync, you resync).

The open source world really needs a RAC-like solution for PostgreSQL and MySQL (I'm a fan of friendly open-source competition, so while my personal preference is PostgreSQL, I hope both projects stay current and popular for many years to come). Unfortunately there is unlikely to be a generic way to do this, it will probably have to be re-invented for each database project.

I took a brief look around PostgreSQL's guts a while back, and it actually seemed like the architecture they use isn't far off from something RAC-capable to begin with, just nobody's quite buttoned together a few peices here and there to make it happen. Basically on SMP multiple co-operating backends already serve parallel requests and synchronized on a shared memory cache. There's patches out there for the linux kernel to support network-synchronized distributed shared memory. Put two and two together, and what do you get? Something not far off from a first-pass hack at a RAC-like network-distributed database caching system. Most of the other details are easy to solve (start/shutdown, join/leave cluster, tracking of processes across the cluster, etc), or belong in another problem domain (implementing shared storage filesystems (hey, we have GFS, Oracle OCFS, etc available...)). One of the biggest issues would be multiple nodes all having pg "Writer" processes. The first step would probably be to put the writer on one node and failover the writer functionality when that node dies, to be quickly replaced by a scheme whereby multiple writers can work by synchronizing through a distributed lock manager (there are already dlm modules available for linux). Then there's the issue of making the current distributed shared-memory patches do the right thing performance-wise for this kind of usage, and so on. It's not easy, but it's not outside the realm of possibility.

Re:Nice "question"

[cecchet]

I am working for the Sequoia project. I don't think that this post was made by anyone of our group. I don't necessarily share your vision with the advantage of a shared disk architecture over shared nothing.

As a SAN has to be shared between all nodes in your cluster, this already limit the availability and scalability of your database to your SAN capabilities (you are shifting the problem to the disk). With a shared nothing architecture you are also replicating the disks and thus distributing the IO workload as well. Note that when you want to synchronize nodes that are not collocated, then a SAN does not work anymore.

You should read some papers about C-JDBC (the original name of the Sequoia technology) and you will find that the technology can scale quite well. We were able to achieve throughput of a million transaction a minute... that should be quite enough for many businesses.

This looks like a religious war between shared-disk and shared-nothing solutions but a SAN and its admin cost is usually not compatible with someone seeking for an open source solution. If you can afford the SAN, why not just using Oracle RAC?

MySQL cluster and replication are not the same

[Scott]

The submitter of this question seems to have confused the two, Cluster and the older replication. Cluster does not in any way rely on a master/slave setup. Think of Cluster as RAID for databases, where you can lose a node (or more, depending on your configuration) before you lose your db. The current drawbacks of cluster are that it is in-memory and doesn't support certain features, such as fulltext indexing. Replication isn't going to cause you to lose data either if your application is designed to handle a situation where the master server (which you kick your writes to) hits the bricks. Have the app go into a read only mode from your slave.

Neither option is really "beautiful", though Cluster has a lot of promise for the future, especially in 5.1.

DRBD

[Bios_Hakr]

Have you looked into DRBD? It works kinda like RAID1 over a network. It uses 2 computers to store the database. Another computer acts as a heartbeat server. You'll need 3 NICs in the database servers; one for the connection to the network, one (gig-e preferably) for the connection between servers, and one for the connection to the heartbeat server.

http://www.drbd.org/

If you are smart, you'll play around with this on a test network or VMWare first. Get it all tweaked out and actually test it by killing a server while in mid-transaction to see if it works for you.

speaking from experience

[mrselfdestrukt]

High availability is NEVER as highly available as on paper...
*sob*

Re:speaking from experience

[anon mouse-cow-aard]

In my experience, you're right. But you have to take the long view. You don't just say... let's do an HA project, put it in, and walk away. to get more 9's you start with something that makes sense, and then look at every failure that happens, and fix the cause.

case in point:
We started off with HA, figured out how to go to cloned configuration: two servers, two RAIDS, no SPoF, right? We had some LAN issues which caused traffic storms, there was a bug in the controller logic, so both RAIDS crashed simultaneously. We fixed it by using another brand of RAID for one of the units. Those servers have not crashed since...

If you do the accounting, the biggest cause of lack of availability with HA sites is number 18, 18 inches in front of the keyboard. That's not because people are less skilled than before, it is because we have eliminated all the hardware issues, the stuff you don't automate is all the stuff that is too complicated to automate, so only human error in making complicated changes remains. So every down time, there is usually an analyst looking sheepish, but it is usually not his/her fault. The process had some failing in it, and you have to fix the process. It's a lot like I hear airliner crash investigations are like. Find out what happenned, fix the process, so that it doesn't happen again.

You hone it over years, and every failure or even glitch is precious. Study it.

Slony + PGPool are one postgresql option.

[Anonymous Coward]

If you want to stay within open source Slony + PgPool is a viable option. Slony is a very capable master-slave replication system and PgPool is an easy way of handling failover and load-balancing (of reads).

For commercial postgresql options, Afilias (who wrote Slony and uses it to power the .NET domain registry) will happily sell you commercial support for less than similar microsoft-or-oracle stuff. I think a company called Command Prompt also has a commercial solution for postgresql, but I haven't tried it.

MOM - Motherly Object Model

[ACORN_USER]

A typical transaction:
Phone: Ring Ring
Son: BEGIN TRANSACTION!
Mum: Oh, hi dear. How have you been? Did you know that ..
Son: *cough* Work, remember?
Mum: Yes, dear.
Son: WRITE_DOWN into notepad ADDRESSES. fname='John'. sname='Smith'
Mum: Wait, i have to look up the next identity number thingie. Oooh, that's a big number, I can't even recite it.
Son: Hush! address='12 Rover Roa..
Mum: Oh, dear. My pencil broke.
Son: Ok, Roll back!
Mum: That's fine for you to say. I don't have any erasers.

Take a look at Avokia

[Wojtek_at_Avokia]

Hey, first, full disclosure: I work at Avokia. But we do have an availability solution that is cheaper than RAC (doesn't require a SAN) and combines the value props of both RAC and DataGuard. We virtualize the data layer enabling many identical databases to be in production serving your users. And you can put these databases into geographically distant datacenters. So you get a live-live-live... set-up without the need for manual conflict resolution that others require. Check it out at: www.avokia.com Wojtek (I'm the product manager).

Radiant Data PeerFS

[darkone]

http://www.radiantdata.com/
Radiant Data has a product called PeerFS which is a replicated filesystem (rw/rw, active/active) which allows you to also hold MySQL databases on it. You run 2 seperate MySQL servers pointing to the same data folder, and have it use POSIX locks for writes. The data is physicaly held on each server, and synced across the network.
  I am testing it at work ( http://www.concord.org/ ) now for our websites. VERY easy to setup, but it supports MyISAM tables, and NOT InnoDB (or the other way around).
  This does not solve IP failover, but there are other solutions out there for that. As a bonus we're holding our php webpages and MySQL databases files on the replicated PeerFS Filesystem.
  -Ben

Clustering, Master/Slave, Load- balancing

[queenb**ch]

High availability is another one of those marketing buzz words that really doesn't have a good, nailed down definition.

You can acheive this in three basic ways. Each has their own pros and cons. I recommend that you weigh them out and come to a decision you think you can live with.

Clustering - You have a group of servers (physical hardware) each running the same software and working to stay synched up with each other. Now clustering comes in two flavors active/active and active/passive. The active/active clusters share the requests between them. The active/passive clusters wait for a node to fail and then another node in cluster assumes the active role.

Master/Slave - This is similiar to clustering in that you have a group of servers (physical pieces of hardware) each running copies of the software. The master does not service requests directly and operates only as a central repository replicating all the data to the slaves. The slaves synch with the master. If one slave fails, there is normally some means for another slave to take over. Note: While this is old and largely deprecated, it is still quite functional and cost-effective under certain circumstances.

Load-Balancing - There are several physical pieces of hardware who each process transactions all the time. All updates/writes/commits are sent to all the servers, but reads are serviced only by one. Note: Again, this is deprecated, but can still be quite functional in specific circumstances.

My experience has been that typically all that is needed for clustering to work is some shared drive space for the various instances in the cluster to manage their own internal bookkeeping. In all honesty, there are several factors here that would make a big difference in what I would recommend for you. One - how much data are you talking about storing? Two - What are you using it for? If this is driving your web site, a second or two of latency while something fails over won't be noticable to the end user. If you're transmitting medical records to an EMT team, it might be fatal. Three - Why are you looking at HA? What need are you trying to fill?

2 cents,

Queen B.

Links for you to consider -
http://www.linuxlabs.com/clusgres.html
http://www.openminds.co.uk/high_availability_solut ions/databases/postgresql.htm

PS: Yes, I like Postgres. It supports foreign key relationships out the box (ummm...*R*DMBS, anyone?) It also doesn't force me to put in unnecessary indexes to use fk's. I will say that MySQL has managed to address some of my previous complaints about not supporting views, stored procedures or triggers. I haven't had time to test their version 5 for now, so I'll be silent as I have no opinion on their implementation.