Data Integration

 View Only
Expand all | Collapse all

IBM CDC i-series DR Planning (Situation: Target ahead AS400 Source)

  • 1.  IBM CDC i-series DR Planning (Situation: Target ahead AS400 Source)

    Posted Fri December 31, 2021 03:54 AM

    I am planning a new environment with IBM CDC between AS400 and Linux (DB2).

    enter image description here

    As the diagram is showing the situation, Journal A04 was the producton latest journal position. Unfortunately, it is possible for the DR not synchonized up to the point A04 and say A02.

    Then, the target may be synchonized up to A03. How do I recover the CDC replication (w/o full initial load)? Can I get the journal positon of A02 to modify the target database?

    It is possible to have a large table with 100G. The downtime for reinitialization is really a concern. Is there any clue for solving this possible situation?



    ------------------------------
    Samuel SUM
    ------------------------------


    #DataIntegration
    #DataReplication


  • 2.  RE: IBM CDC i-series DR Planning (Situation: Target ahead AS400 Source)

    Posted Fri December 31, 2021 05:31 AM
    Hello Samuel
    This is a large topic and I cannot really discuss all the potential scenarios in all the details in this reply. If you need further help you should consult IBM or a business partner with expertise in this area to assist you with DR planning.

    There are some things you should know

    1) CDC keeps its bookmark on the target. The bookmark for an iSeries source indicates the journal receiver and sequence number that has been committed 

    2) The iSeries engine is scraping the local journal. However the local journal on the standby system recording the changes made to the files by whatever HA software is being used will not have the same sequence numbers or receivers as the local journal on the primary. So if the iSeries is switched over the bookmark by itself cannot be used. [The only way to avoid this is to have some low-level disk synchronous replication or switchable disk, which you clearly do not have from your post]

    3) The restart position for replication can be specified manually for an iSeries source using the SETJRNPOS command, either by sequence number or timestamp

    4) iSeries has something called a remote journal which is a copy maintained synchronously or asynchronously by the OS - many software-based HA solutions rely on it to transport the changes to the standby iSeries and the HA solution then applies the changes to the files on the standby system, generating entries in the standby local journal that can be scraped in the event of a switchover. 

    Most switchovers are planned switchovers in which the AS/400 standby is up to date with the AS/400 primary, the target primary is up to date with the AS/400 primary and the target standby is up to date with the target standby. In this scenario you are either testing your switchover procedures or making the  source application (and target application possibly) available when the primary systems are down for routine maintenance. Since all four systems are aligned, you can switch over just the primary AS/400 or just the primary target or both.

    Unplanned switchovers are by their nature harder to deal with as there is no guarantee with anything other than synchronous replication that any standby will be aligned with its primary or that the target systems will be aligned with the source systems. If the secondary AS/400 is ahead of the target database, then the only challenge is to determine from where to restart the replication using SETJRNPOS. If you have a remote journal you can look at the this to determine the timestamp relating to the target bookmark. If you do not have a remote journal and you do not record the latest apply timestamp in the target data, you will have to set the position to some arbitrary point in the past and probably repeat transactions (which is better than losing transactions). If the standby iSeries is behind the target database, then you have to refresh to avoid data loss. On the other hand the standby iSeries is now the version of the truth and data applied to the target after the source position no longer reflects real events. Unless you are using LiveAudit or writing to flatfiles or Kafka, or have a way of using the target database transaction log to undo, you cannot really undo these changes.

    From my experience, the chances of having to perform an unplanned switchover in anger are very small. and generally the HA replication is ahead of the CDC replication when the HA replication is running continuously

    Optimising the refresh of a 100 Gb file is possible but outside the scope of this reply.

    Hope this helps

    Robert


    ------------------------------
    Robert Philo
    ------------------------------

    Original Message


  • 3.  RE: IBM CDC i-series DR Planning (Situation: Target ahead AS400 Source)

    Posted Sat January 01, 2022 10:28 PM
    Hello Robert,

    Nice to hear from you again.?? If I could have the storage level
    synchronization like SAN level (only way to have some seq. & receiver),
    I think it is possible to have the chance to have identical (nearly
    identical) AS400 image.?? It is possible for us to have such low level
    disk level replication.

    With this, it is likely not to have the gap between A03 or A04 from the
    diagram.?? However, I think the team needs to do some more hard-work and
    different round of testings on the possible scenarios of failure.

    If it is required to be re-initializing the replication, it is not
    really a HA solution with a down-time for those transaction tables being
    REFRESH before MIRROR.?? That's the biggest concerns as supporting a call
    center 7x24.

    Thanks again for your sharing.

    Regards,
    Samuel


    Original Message