Replication with Infosphere CDC : Troubleshooting
  
Troubleshooting
This section provides instructions and guidelines on how to prevent or troubleshoot common problems while configuring or using the IBM InfoSphere CDC Replication.
Initial connections are not successful
The components for the IBM InfoSphere CDC Replication must be installed and configured in the order described in Installing IBM InfoSphere CDC replication components and Configuring IBM InfoSphere CDC replication. Review the steps below and ensure that the installation and configuration steps were followed.
Installation order
solidDB® servers
IBM InfoSphere CDC for solidDB®
Access Server
Management Console
Important: At the end of the IBM InfoSphere CDC for solidDB® installation, the installer prompts you to start the Configuration Tool for creating a new IBM InfoSphere CDC instance. Do not select to start the configuration tool unless you have configured the corresponding solidDB® server according to the instructions in Configuring solidDB® for IBM InfoSphere CDC replication.
Configuration order
solidDB® servers
IBM InfoSphere CDC instances
Access Server and Management Console
Dependencies between components used in replication
To set up replication between databases, you need define and create various entities and components which are dependent on each other. These entities and components must be created in the following order and modified or deleted in the reverse order. For more details and instructions, see the IBM InfoSphere CDC documentation.
1 Databases
2 IBM InfoSphere CDC instances
3 Datastores
4 Subscriptions
5 Table mappings
Making changes to replication subscriptions
If you need to make changes to your replication subscriptions, you must first end replication on your subscriptions. For more details and instructions, see the IBM InfoSphere CDC documentation.
Subscriptions fail after performing hsb netcopy followed by a switchover
In High Availability (HotStandby) configurations, subscriptions where the solidDB® database is the source datastore might fail if a switchover is performed shortly after hsb netcopy.
The subscriptions might fail, for example, in the following cases:
1 After a failure or a maintenance break, primary server (node 1) and secondary server (node 2) are synchronized using ADMIN COMMAND ’hsb netcopy’.
2 Replication continues against the primary server (node 1) for few transactions.
3 The primary server (node 1) fails and switchover changes the secondary server (node 2) to be the new primary server.
4 Subscriptions fail and replication against the new primary server (node 2) cannot be restarted.
Causes
The command ADMIN COMMAND ’hsb netcopy’ does not copy any log files. Subsequently, because IBM InfoSphere CDC replication is asynchronous in nature, IBM InfoSphere CDC for solidDB® might not have processed all the transactions up to the point from which the hsb netcopy was made. This means that the log position IBM InfoSphere CDC for solidDB® tries to use after the switchover might not be valid – the log entry for the last transaction on node 1 before the hsb netcopy might not exist on the new primary (node 2).
Workaround
To ensure that IBM InfoSphere CDC for solidDB® has access to a valid log entry in the new primary server (node 2) after a switchover:
Before performing hsb netcopy, copy the log files from the primary server (node 1) to the secondary server (node 2). This ensures that IBM InfoSphere CDC for solidDB® has access to the log positions of the transactions that were executed before the hsb netcopy was made.
or
Do not perform switchover shortly after hsb netcopy or wait for several transactions to be replicated to the backend database before performing the switchover. This ensures that log positions in the primary server (node 1) and secondary server (node 2) are synchronized.
or
If the switchover has already taken place (for example, due to a failure of node 1):
1 Recover the old primary server (node 1).
2 Perform a switchover to return the old primary server (node 1) back to a primary server.
3 Restart replication on the subscription.
4 Before performing another switchover (to make node 2 the new primary server), wait for several transactions to be replicated. This ensures that log positions in the primary server (node 1) and secondary server (node 2) are synchronized.
IBM InfoSphere CDC for solidDB® connection to solidDB® server times out
IBM InfoSphere CDC for solidDB® connections to the solidDB® server can be idle for long periods of time, causing connection idle timeouts. By default, the solidDB® server timeout for idle connections is set to 480 minutes (specified with the Srv.ConnectTimeOut parameter).
Workaround:
Set the connection idle timeout for the IBM InfoSphere CDC for solidDB® connection to infinite by using the non-standard solidDB® JDBC connection property solid_idle_timeout_min=0. The IBM InfoSphere CDC for solidDB® connection settings are specified with the IBM InfoSphere CDC configuration tool (dmconfigurets), using the Database area > Advanced button in Windows operating systems or the Configure advanced parameters > Modify settings option in Linux and UNIX operating systems.
The timeout setting specified for the IBM InfoSphere CDC for solidDB® instance does not impact the server setting (Srv.ConnectTimeOut) for other connections.