I have not blogged about new features of OpenLogReplicator since version 1.0 was released. Now it is time to catch up. Every version apart from bug fixes and stability improvements include new major features: Version 1.5.0 Key feature of this release is the ability to produce metrics directly for Prometheus. The metrics include counters for […]
OpenLogReplicator 1.5.0 released Read More »
OpenLogReplicator can be fine-tuned over and over. Still something would to be imperfect. Some code might not be optimal and need refactor. Another feature might be recognised as super important and a must-have. This will never end. Still, after over 4 years of fixing bugs and constant development, the time has come to confirm that
OpenLogReplicator 1.0.0 released Read More »
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.
Is OpenLogReplicator ready for production usage? Read More »
After almost 3 years of development, the project has reached a moment, that most of the features planned for version 1.0 are finished for OpenLogReplicator. So … announcing version 0.9.0-beta. At this point the goal is to make the code stable as possible and fix all reported bugs. If you want to test the code
OpenLogReplicator reached beta version! Read More »
Technically speaking support of DDL is trivial. All schema is written in SYS.xxx$ tables. Just what you need to do is to track the changes, and once they appear, rebuild internal dictionaries. Someone adds column to table? Well, you would see an INSERT to SYS.COL$ and maybe some other tables. … A few months later
OpenLogReplicator has full DDL support? Read More »
One of the most confusing with Oracle replication tools is the inability to track changes of tables owned by SYS, SYSTEM or CTXSYS. Many system tables are internally using cluster type. Since the latest version OpenLogReplicator supports cluster tables it is now possible track also tables in SYS schema and send changes as events to
Oracle database: replicating objects from SYS schema Read More »
Replication latency is one of the key indicators of good replication. When I started working on OpenLogReplicator one of my key tasks was to keep the latency as low as possible. What does that mean? When a client commits a transaction and the database confirms that the transaction is committed – it means that the
OpenLogReplicator – replication latency Read More »
A side product of OpenLogReplicator is the ability to create logs which are in a very simular form as the logdump command from Oracle database. To create such dump you need to configure parameter in the OpenLogReplicator CFG file. There are 2 allowed values: create classic ‘logdump’ output create classic ‘logdump’ output enhanced with interpretation
OpenLogReplicator – logdump functionality Read More »
The OpenLogReplicator with the new release 0.2.0 has been extended to support chained rows. A chained row can appear when there is a bigger DML operation or the table uses more than 254 columns. This is an example of a table which uses 1000 columns. The table definition is: CFG definition file of OpenLogReplicator contains
OpenLogReplicator – chained row support Read More »
The OpenLogReplicator has been a new release 0.0.8 with new functionality: Added rowid field to JSON (Kafka target) Support for OP code 11.3 – Delete Row Piece Support for OP code 24.1 – DDL: Truncate table (only Kafka target) Here is an example of usage. Let’s create a table: CREATE TABLE SYSTEM.ADAM3( A NUMERIC );
OpenLogReplicator – Delete row piece (OP 11.3) and Truncate table (OP 24.1) Read More »