Slashdot Mirror
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."
Why not create a hybrid of MySQL and Oracle and give it out for a lower price than Oracle? Something that has the best features of both MySQL and Oracle.
And call it MyOracle [tm].
slashdot rocks
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.
MP3 Search Engine
I'm suprised Oracle is letting this fly--it probably somehow violates the EULA, by reverse engineering Oracle redo logs. Basically, it seems like they are targetting smaller shops, who don't want to buy Oracle Enterprise Edition (and hire a f/t DBA). My only question would be, how big is the market that needs to do replication, but can't spend the $ or â on Oracle Enterprise (which can be cheaper than you think for a small shop)
Yea that is what I tough. I saw the article I though oh cool something that may be helpful. Then I saw it linked to some guys blog to an app of some unknown company, for a product that is in Alpha. Yea Like I am going to print that out and show it to the DBA.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Definitely. After reading the blog post it just sounds like an extra layer of software that's able to replicate across different brands of database. Since most people don't want to maintain multiple database brands the only advantage I can see is in migration.
This doesn't sound all that innovative or even very useful.
Developers: We can use your help.
For possible something that is vaporware yes.
"will available for early adopter next month"
You cannot user oracle and save money at the same time. Oracle will change their licensing model so it it cheaper to buy oracle all the way.
You need a 3 day course anyway to understand oracle licensing.
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.
It's a simple matter of complex programming.
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.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Continuent? Continuent? Who thinks up this stuff? All I can think of is some suit explaining it. "We harness the synergistic energy of the word 'Continue' while simultaneously fulfilling our carnal, earthy ambitions by joining in sympathy with the Ents who will, perhaps in some future time or far-away land, form our products' user base."
Excellent points. In my experience it's most common to refactor the data or only use a subset when synchronizing disparate databases. So I expect to build a small custom data migration app when dealing with this. But your point is taken.
Developers: We can use your help.
For example, you can pull data for one table from your consolidated database while pulling data for another table from a web service.
It's a simple matter of complex programming.
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)
It sounds like somebody has never used SQLite. MySQL is WAY too complex for the majority of applications.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
We replicate from Oracle to MySQL using redo-logs and a 143 line perl script. This has worked for about the last year, although there is a 15 minute delay in Oracle 9i, as there is no easy way to query online redo logs. All that changes when our data warehouse goes up to 10g, at that point we will get real time replication.
The MySQL database is only 250gig, around 2.2 billion records, used for all our websites (read-only), while all update systems hit Oracle, the updates are fed to a single MySQL master, which then uses MySQL replication to replicate to the web farm. No need to validate data on the MySQL servers, as the Oracle box has already done that.
Why not just use Oracle databases for everything? Why replicate to MySQL? Doesn't that make sys admin work harder? The only reason I could imagine is licensing costs, but is there any other reason?
Developers: We can use your help.
Primarily cost, as load on the web site ramped up, we simply added more servers, no oracle licensing cost. Plus our dbadmins seem to have a hard time keeping the oracle boxes up for more than a week at a time, whereas the mysql boxes have been running for 90 days without a glitch, and our sysadmins love the fact that they do not have to do anything with them
MySQL is a lighter weight process so if you want to replicate to a low power machine like a laptop it's probably a better fit.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Hi, on the contrary, this is not just another layer of software. First, our software is alternative replication that fixes a number of problems with existing mechanisms like MySQL replication . Second, it provides replication (or will when we release) where it is sorely needed, namely low-end Oracle implementations. Whoever put this on Slashdot got the title right. Third, cross-database replication is a big problem for a lot of people and there's nothing in open source right now that addresses it effectively. Taken together this sounds pretty innovative to me. But then I wrote the original post, so these arguments are perhaps not unexpected. :)
Too hard for me. Where is the source code and what is the license? The downloads from https://forge.continuent.org/frs/?group_id=26 dont contain source and the svn repoistory svn://svn.forge.continuent.org/svnroot/treplicator does not work with my svn client or the browser link on the gforge page.
You are using a 143 line perl script to 'mine' redo-logs?? Great job! Then we can throw away the stupid DBMS_LOGMINER
:P
Can you give me any hint on how the redo-logs are parsed?
Sorry, we still use the stupid DBMS_LOGMINER packages to do it, then we get the SQL_REDO and just apply it to the MySQL server.
We just keep a running record of the last CSCN processed, and you have to make sure supplemental logging is on, as well as setting primary keys to appear in the logs as well.
The license for our current software is GPL v2. This covers replicating MySQL to MySQL as well as from MySQL into Oracle and other databases. Oracle redo log support will be commercial, but there will be a free version for up to 2 hosts. I will get source builds posted today . Finally, if you can tell me what the problem was with SVN I'll try to fix that as well. (SVN is making us a little crazy at the moment--sorry if you are infected by it. The MySQL guys recently switched to Bazaar, which is starting to look kind of attractive.)
Thanks for the info