Is OpenLogReplicator ready for production usage?

This is the question I hear very often. I think many people would like to hear a straight answer for this question. The reality is not possible to give a good answer. You might be surprised but, even though version 1.0 is not yet released, OpenLogReplicator is already used in production systems. Yet might be not feasible for everybody to use.

This leads to another question:

“Is it safe for me to use OpenLogReplicator my production system?”

This question is more precise. Before going into details it is necessary to understand the way OpenLogReplicator is developed. Or, generally speaking, how Oracle database CDC programs are developed. This is not the case like CDC for PostgreSQL, which is open source and the WAL format for is well described. There are basically 3 options you have for using redo log Oracle CDC:

1. pay money directly to Oracle for the effort of writing CDC and use Oracle GoldenGate

This way you might be 100% sure that the software does what it needs to do. Engineers which write CDC code have access to internal documentation and have easy work to do.

2. pay money to some 3rd party company

This solution is cheaper than 1. Using this approach 3rd party engineers would do redo log analysis and produce a program which is able to parse the binary format of the database redo log. Since the developers don’t have access to internal engineering documentation – the task is more difficult and requires a lot of case study, testing, etc. There are many commercial companies which have done this task, and users are using their software with success in production systems. Still you never have 100% warranty that the code not written by Oracle company correctly parses the redo log of the database.

3. invest your own resources to support Open Source community

An alternative to the previous point would be to help producing an open source tool that would do the same task. But it would not require a payed license for using software. The software, which is engineered would work the same like in 2. The task of correctly parsing a redo log binary format still requires a lot of effort. This is not an easy task to write a simple library. Reading redo log binary data might involve hundreds of hours of experiments. Testing, what appears in redo log file when you commit certain transaction. There might appear some edge cases which are hard to find and missed by the author of the software.

So you might ask yourself actually:

“Do I want to contribute to the development of OpenLogReplicator?”

The question you need to ask yourself is: “Do I want spend some of my resources to encourage the author of the software on further working on the project? Maybe I can test in my environment and send some feedback? Can I submit some information about a bug I have found? Am I willing to help the developer to actually fix it? Or maybe just complain that the code is worthless.”

It might be tempting to wait for other users to do this task. But this is a false approach – this is self-deception. At the end of the day you can’t avoid a situation that your system actually hits some edge case and OpenLogReplicator fails. You can ask yourself: What losses would that cause to your business? Maybe at some point replication from a production database stops and requires some help to move on.

“Can I find the bug myself and be sure that it would not break anything else? How else would I plan to make the problem fixed?”

“What can I do?”

If you have spent some time reading this short blog post – maybe OpenLogReplicator might be some value to you. You might start using successfully OpenLogReplicator on your production systems. This is possible, but it really depends actually on your engagement. If you believe that the moment has come to test OpenLogReplicator in your environment – please contact me to give some feedback.

Leave a Comment

Your email address will not be published. Required fields are marked *