With any data replication technology, you may some day find that you need to replicate to a target database not currently supported by your replication technology. The good new is IBM's data federation technology can provide an easy way to extend your solution. For example, federation has long been used to extend IBM's SQL Replication so that it can replicate to PostgreSQL
and other databases. Federation also can provide the same benefit for a number of other replication technologies, including InfoSphere Change Data Capture. I'm going to use this post to talk about considerations from a federation perspective. However, I'm not going to into details from a CDC perspective. I recommend you talk to a CDC expert for that. For example, if you have a specific question, the developerWorks CDC message board
may be the right place.My Tips
It's a short list, but, if I find more later, I'll add them.
- You will most likely need to configure one of two federation interfaces - the ODBC wrapper or the JDBC wrapper.
- Why? CDC already supports a wide range of databases, so you'll probably be targeting one for which IBM federation doesn't have a named wrapper. For example, it doesn't have a "PostgreSQL wrapper."
- If the replication technology has its own tables that are written to in the same unit of work as target table nicknames, consider creating that table in the target database and then create a nickname for that table.
- For example, I believe you'll need to do this for CDC's TS_BOOKMARK table.
- If you do not do this, you will need to use 2-phase commit, which may not be available with a given target or may hurt performance.
- If you create nicknames for multiple target databases, have the replication technology process different target databases in different units of work.
- For example, create each CDC subscription so that it writes to nicknames for only for one target database within that subscription.
- Otherwise, you hit the 2-phase commit issue mentioned above.
- If you need to write to both local tables in the federated database and nicknames, put them in separate units of work.
- For example, that would mean having either local tables or nicknames in a CDC subscription, but not both.
- Otherwise, we're back to the 2-phase commit issue.
If you have questions, you can ask them in the comment section of this blog or use the message boards here on developerWorks.