Continuent To Bring Open Source DB Replication To the Oracle World

Robert Hodges, CTO of Continuent, has an interesting blog entry about a new approach to database replication that they are undertaking. The new approach aims to provide easier access to replication for low-end Oracle users in addition to the alpha offering they already have for MySQL. "It's not a coincidence that we chose to implement MySQL and Oracle replication at the same time. MySQL has revolutionized the simplicity and accessibility of databases in general and replication in particular. For example, MySQL users have created cost-effective read scaling solutions using master/slave replication for years. MySQL replication is not free of problems, but there is no question MySQL AB helped by the community got a lot of the basics really right. On the other hand, Oracle replication products offer state-of-the-art solutions for availability, heterogeneous replication, application upgrade, and other problems, albeit for high-end users. For example, Oracle Streams and Golden Gate TDM offer very advanced solutions to the problem of data migration with minimal downtime. The big problem with these solutions is not capabilities but administrative complexity and cost."

Comments

this does not match my experience

[jacquesm]

If there is one thing that really sucks in mysql it's replication, and no, they did not get it right.

Even running top notch hardware about as redundant as you can get after running for a couple of months the master and slave can be out of sync.

I think this is one of the major remaining issues with mysql.

Re:MySQL + Oracle = MyOracle

[Jellybob]

Isn't it Postgres?

Re:MySQL + Oracle = MyOracle

[jellomizer]

MySQL is better for small Databases, Oracle is better for Big ones.
(Small Databases consist of Millions of records, Big ones Billions) Installing Oracle for average Joe company is overkill, and huge overhead. That is why a lot of Oracle shops switched to Microsoft SQL, and MySQL.
It would be nice to have a lot of the features of Oracle with ability to manage small databases.

Re:MySQL + Oracle = MyOracle

[stoolpigeon]

Oracle Express - 0$

Yes - if you want more features, Oracle is expensive. Although that cost includes support. But that has nothing to do with his statement of a hybrid - unless you are saying the only thing that will be merged is cost.

Re:Targeted to smaller shops.

[jellomizer]

I am sure there is a huge market for Replication. Small Databases need to be rock solid too. Just because you may have a lot of data doesn't mean it isn't important or mission critical. Paying an extra $2000 for a server for a fail over is well worth the cost of your only SQL (Any Brand) server being down for a few hours to days.

Re:Looks a bit slashvertisment-y

[PinkPanther]

There are very good reasons to replicate (or at least synchronize) between disparate DB systems. For example, you have a LAMP website but want to feed it data from your backend ERP system. Another fantastic example is mobility, where you have a mobile database like SQL Anywhere on your PDA and/or laptop synchronizing to your enterprise DBs.

As always, the answer is 'It depends'

[johnlcallaway]

It depends on what type of replication one needs. The simplest means of Oracle replication is to create another database somewhere else and simply copy the logs over and apply them. We have done that for years for one simple reason ... for databases that don't require 5 nines service, I don't want an 'up-to-date' copy.

A major cause of database failures in my experience has been due to programmer or administrator error (i.e. program bug or someone typing truncate table wrong.) Creating scripts to copy the logs to another server as soon as they are created, and applying them after they are a few hours old, we maintain an environment where it only takes a few minutes to switch over and prevent the 'uh-oh' moments from corrupting both databases.

We have found that the decision to switch over to a remote database takes time. No one wants to do it because then we have to copy that whole database back to the primary site eventually, and that takes a lot of effort and time. When we have a failure, someone is tasked at getting the remote database ready while the discussions are held whether or not to fix or fail-over.

One benefit of this has been that when we have 'uh-oh' moments, the old data is still available and we can correct it, sometimes without the end-users even being impacted.

So .. for all of you database admins out there, replication is possible without the fancy software *IF* you can write scripts, create a somewhat simple system to repoint to the new one (i.e. DNS), and can live with a few minutes of downtime a couple of times a year.

Re:As always, the answer is 'It depends'

[johnlcallaway]

No machine is 'up-to-date' as there is no such thing as instantaneous data transfers *unless* data is applied and committed to both machines at the same time. This is very costly outside of a local area. Before Oracle had replication services, we used this and were able to keep the remote machine (which was 2,000 miles away) within 5 minutes of the primary 95% of the time. It dawned on us one day how dangerous this was and changed it to not apply the logs for 60 minutes since it would only take us about 10 minutes to catch it up and switch it from stand-by, longer than it would take to decide to fail over and change DNS.

I did not mean to imply this was the best solution for replication, only that if someone is using replication software for this type of purpose, i.e. disaster recovery, then this is a perfectly acceptable solution that probably will work for any database and does not require additional licenses *except* for the remote machine. Oracle allowed us to run the remote machine this way without a license since we did not use it in a production capacity.

A backup solution??? I guess it is a backup of the primary, but many replicate machines are this way since 2-way replication difficulties often limits the usability of the remote server beyond read-only access. The data is never used to 'restore' the original machine, it is an exact, fully usable copy. If the primary machine crashed, the choices are to restore from tape, or make the remote machine the primary. The remote machine can serve as the production server for as long as is necessary. To restore the primary machine after the remote server has been used for an extended period, a backup of the remote has to be taken and applied to the primary. This can take a few days as the amount of data needed to be transferred is very high. A backup is taken to tape, overnighted, applied, and then additional log files are applied until the two are in sync and a point is reached where a controlled fail-back can occur.

In fact, at one facility, we 'swapped' machines every 30 days to make sure they would function if one failed.

Re:Looks a bit slashvertisment-y

[rhodges]

Keep watching. It won't be alpha for long. On the plus side we are being completely open about the development and will not deceive you about the true state of the software. Robert (the guy that wrote the original blog entry)