Exchanging SSL certificates for Db2 Q Replication

Important: IBM Cloud Pak for Data Version 4.7 will reach end of support (EOS) on 31 July, 2025. For more information, see the Discontinuance of service announcement for IBM Cloud Pak for Data Version 4.X.

Upgrade to IBM Software Hub Version 5.1 before IBM Cloud Pak for Data Version 4.7 reaches end of support. For more information, see Upgrading IBM Software Hub in the IBM Software Hub Version 5.1 documentation.

After you enable and activate replication, you need to use the Q Replication REST API to trust the target and exchange SSL certificates between the source and target systems.

About this task

This task can be completed on the cluster host after you have added the replication target. You must collect the following information before running the curl commands:
  • Target database host name
  • Target database user name
  • Target database user password
  • Target replication REST API server external port number
  • Source database host name
  • Source database user name
  • Source database user password
  • Source replication REST API server external port number

Complete these steps on the replication source database.

Note: Q Replication must run in Security Enhanced Linux (SELinux) enforcing mode.

Procedure

  1. Run the following curl command to prompt the source to trust the target: 
    - curl -X --insecure POST "https://source_hostname:{source_rest_external_port}/dr/v2/target/trust-target?targetEnvironment=DB2U-db2oltp" -H "accept: application/json" -H "Content-Type: application/json" -d "{ "targetDatabaseHost": "{target_hostname}", "targetDatabaseUsername": "{user_name}", "targetDatabasePassword": "{password}", "targetRestServerPort": {target_rest_external_port}"
    To find the REST external port number, run the following command:
    oc get svc -n ${PROJECT_CPD_INST_OPERANDS} | grep db2oltp
    The results should be similar to the following example:
    [root@api.db2u-dr4.cp.fyre.ibm.com ~]# oc get svc | grep db2
c-db2oltp-1630636239936781-db2u                ClusterIP   172.30.56.242    <none>        50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP   33d
c-db2oltp-1630636239936781-db2u-engn-svc       NodePort    172.30.33.105    <none>        50000:30350/TCP,50001:31715/TCP                                                   33d
c-db2oltp-1630636239936781-db2u-internal       ClusterIP   None             <none>        50000/TCP,9443/TCP,50052/TCP                                                      33d
c-db2oltp-1630636239936781-etcd                ClusterIP   None             <none>        2379/TCP,2380/TCP                                                                 33d
c-db2oltp-1630636239936781-qrep-mq-svc         NodePort    172.30.91.42     <none>        1414:31535/TCP,1415:31667/TCP                                                     33d
c-db2oltp-1630636239936781-qrep-rest-svc       NodePort    172.30.89.122    <none>        9444:31313/TCP
    Look for the c-instance-ID-qrep-rest-svc entry. The value in the right column contains the replication port number, which in this example is 9444:31313/TCP. The 31313 portion is the replication port number.
  2. The following curl command exchanges the db2 ssl certificate between the source and target databases.
    Upon successful completion of this command, the replication REST API server is restarted after 60 seconds on both the source and target replication containers.
    - curl -X --insecure PUT "https://{source_hostname}:{source_rest_external_port}/dr/v1/target/configure_db2_ssl/{source_database_name}/{target_database_name}/{target_db2_ssl_external_port}/<db_name>/{target_rest_external_port}?restartOption=Y" -H "accept: application/json" -H "Content-Type: application/json" -d "{ "dbUsername": "target_database_user_name", "dbPassword": "{password}"}"

    The restart might take up to 10 minutes.

    Verify if the Q Replication REST API server is active by running the following commands:
    oc exec -i {<source_replication_podname>} -- /opt/ibm/bludr/scripts/bin/bludr-status.sh
    oc exec -i {<target_replication_podname>} -- /opt/ibm/bludr/scripts/bin/bludr-status.sh
  3. Schedule the Db2 source and target servers to be restarted for the exchanged certificates to take effect inside the source and target Db2 pods.