Version 1.2 release notes

IBM® Data Replication for Availability supports highly available Db2® Warehouse, Db2 Warehouse on Cloud, and Db2 database environments by synchronizing table and schema contents whether on the same platform, across the data center, or around the globe. This software replication offering supports active and standby replicas for workload balancing and shifting workloads during planned outages while also dramatically reducing the time to recovery for unplanned outages when used with application management and automation solutions.

This replication solution supports both row- and column-organized Db2 Warehouse, Db2 Warehouse on Cloud, and Db2 database environments. That said, there are functional differences and prerequisites that are tied to column-organized sources and targets:

Currently, one source to many targets for the same column-organized table requires a customized configuration that cannot be set up from the replication console. Contact IBM if you need this capability.
Db2 transient logging to support replication by default requires disk space from /scratch on an IAS appliance. This space is where supplemental logs for column-organized tables are staged; they are not part of the Db2 recovery logs. If the space fills up, replication operations might be affected. It is recommended that you reserve enough space to replication for sustaining periods where replication is stopped. For example, if you stop replication for 12 hours because you are upgrading a server, you might want to ensure 12 hours of supplemental logs can be staged. Consider using SAN storage instead of /scratch. For more information, see Using SAN or NFS storage for Db2 supplemental logs for column-organized tables.

Known issues

When you create a replication set for COISBAR-enabled tables on IAS 1.0.27 by using the replication console, the console does not correctly pick the columns to be used for the replication key. A set that is created with this error does not replicate. The console should pick only the SYSROWID column for the key, but it is picking other unnecessary columns.
You can work around this problem by using the ASNCLP command-line program to define the replication set:
1. Create an empty replication set (no tables selected) in the console.
2. Get the name of the replication queue map that is used for the set on the target database by using the following SQL statement:
```
select MCGNAME,REPQMAPNAME from asn.ibmqrep_mcgsync
```
3. Use the following ASNCLP commands to create the replication set:
```
ASNCLP SESSION SET TO Q REPLICATION;
                SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
                SET PWDFILE "password_filepath";
                SET SERVER CAPTURE TO DB source_database;
                SET SERVER TARGET TO DB target_database;
                SET CAPTURE SCHEMA SOURCE QASN;
                SET APPLY SCHEMA QASN;
CREATE QSUB USING REPLQMAP "queue-map-name" (SUBNAME "replication-set-name"
                        "target_schema"."target_table_name" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN Y
                        START AUTOMATICALLY YES CAPTURE_TRUNCATE T
                        CREATE IF NOT EXIST TARGET NAME "target_schema"."target_table_name" CONFLICT ACTION F ERROR ACTION D LOAD TYPE 0);
```
  - password_filepath is one of the following:
    - IAS: /head/bludr/logs/replication/asnpwd.aut
    - Db2 Warehouse: /mnt/blumeta0/bludr/logs/replication/asnpwd.aut
  - source_database can be found by running the IBM MQ dspmq command at the source to obtain the queue manager name. The first part of this name is the source database name; for example, if the queue manager name is EEWGHGN_CQM, the source database name is EEWGHGN. Follow this same procedure at the target to find the value for target_database.
  - queue-map-name is the name that you obtained in Step 2.
  - replication-set-name is in the format queue-map-name_schema_tablename.
  You can use HAS LOAD PHASE I if you want to let replication truncate and load the target table.
  
  For each additional table that you want to add to the script, you only need to add additional CREATE QSUB commands, substituting values for the queue map, target table, and other options.
  
  You can add these commands to a file and run the file as an ASNCLP script by using the following command:
```
asnclp -f filename
```
  Run the script under the dsadm user ID.
  
  After you run the script, you can use the console to start replication for each table.

If you plan to use the asnmon or asnmail monitoring programs in IAS 1.0.27, you must create the following columns manually. You can use the following SQL statements:

ALTER TABLE ASN.IBMSNAP_MONPARMS ADD TLS_KEYDB varchar(1040);
ALTER TABLE ASN.IBMSNAP_MONPARMS ADD TLS_LABEL varchar(128);

Without these two columns, asnmon does not start, which results in a message as below:

2021-12-16-08.02.15.836057 ASN0552E "Asnmon" : "max01d" : "Initial" : The program encountered an SQL error.
The server name is "MAX01D". The SQL request is "FETCHONE2". The table name is "IBMSNAP_MONPARMS_2".
The SQLCODE is "-206". The SQLSTATE is "42703". The SQLERRMC is "TLS_KEYDB". The SQLERRP is "SQLNQ075".

If you are using the bluadmin custom group name (such as bluadmgrp), when you install Db2 Warehouse 11.5.6 or 11.5.7, if you do a fresh deployment of 11.5.6, or if you activate replication after a Db2 common container upgrade on 11.5.6, the dsadm user is not automatically added to the custom group/bluadmin group. Before starting replication, ensure that the dsadm user is added to your custom group/bluadmin group and then run the following commands to change the permissions of directories under ${BLUDR_DB2_DATA_PATH}/repl:
```
chgrp -R BLUADMIN_CUSTOM_GROUP_NAME/BLUADMIN_GROUP_NAME ${BLUDR_DB2_DATA_PATH}/repl
chmod -R g+s ${BLUDR_DB2_DATA_PATH}/repl
```
If you did a new installation of 11.5.6 or if you activated replication after a Db2 common container upgrade on 11.5.6, run the following commands:
```
mkdir ${BLUDR_DB2_DATA_PATH}/repl/logs ${BLUDR_DB2_DATA_PATH}/repl/errors
chgrp -R BLUADMIN_CUSTOM_GROUP_NAME/BLUADMIN_GROUP_NAME ${BLUDR_DB2_DATA_PATH}/repl
chmod -R g+s ${BLUDR_DB2_DATA_PATH}/repl
```
Restart the Db2 Docker container after you activate replication.
If you upgrade to IAS 1.0.26 or Db2 Warehouse 11.5.6 with Windows Active Directory or external LDAP with a custom bluadmin group name, before you upgrade it is recommended that the last consistency point for all replication sets is caught up. If the last consistency point for any replication set is not current, you need to take extra steps before and after the upgrade to preserve the apply program's access to files that are needed for replication. See Upgrading to IAS 1.0.26 or Db2 Warehouse 11.5.6 with a custom bluadmin group name for details.
Kerberos user security authentication is not supported for replication on IAS 1.0.26.
After you upgrade the Db2 common container from v11.5.4-CN2 to v11.5.5.1, the replication web console does not open on the upgraded source or target system because of a problem with the SSL certificate exchange. On Integrated Analytics System this problem can occur when you upgrade from IAS v1.0.23.2 to v1.0.25. Follow one of these procedures to resolve the issue, depending on whether you are using replication on Db2 Warehouse or IAS:
Db2 Warehouse
1. On the source system, save a copy of the original /opt/ibm/dsserver/wlp/usr/servers/dsweb/bootstrap.properties.template file:
```
cp /opt/ibm/dsserver/wlp/usr/servers/dsweb/bootstrap.properties.template /opt/ibm/dsserver/wlp/usr/servers/dsweb/bootstrap.properties.template.orig
```
2. Comment out the following entries in the /opt/ibm/dsserver/dsweb/bootstrap.properties.template file:
```
# wlp.keystore.password={aes}AAz66Q4xSzzSYp6RcIBybNbFCIn5Jzlg5bwIpv+eNq3h
# wlp.keystore.location=${dsserver_home}/wlp/usr/servers/dsweb/resources/security/key.jks
# wlp.keystore.type=jks
```
3. Insert the following entries in the same file:
```
wlp.keystore.password={aes}AK6uAD0D9c0Oc/IyKLJE+/D386vg9QvmAKy5PEqbzWf0
wlp.keystore.location=${dsserver_home}/wlp/usr/servers/dsweb/resources/security/key.p12
wlp.keystore.type=PKCS12
wlp.truststore.type=jks
```
4. Restart dsserver on the source by running the following command:
```
/opt/ibm/dsserver/bin/restart.sh
```
5. On the target system, which has the console certificate, add the following line to the /opt/ibm/dsserver/wlp/usr/servers/dsweb/bootstrap.properties.template file:
```
wlp.truststore.type=jks
```
6. Restart dsserver on the target by running the following command:
```
/opt/ibm/dsserver/bin/restart.sh
```
7. Exchange the Db2 SSL certificate between the source and target by running the bludr-configure-certs.sh script on the source system. The format of the command to run the script is as follows:
```
/opt/ibm/bludr/scripts/bin/bludr-configure-certs.sh source_hostname target_hostname
```
  Where source_hostname and target_hostname are fully qualified host names.
Integrated Analytics System

If you have problems opening the Replication home page on the source system web console after upgrading IAS from v1.0.23.2 to v1.0.25, first verify that the following conditions are true within the Db2 container on the source system. Exec into the container by using docker exec -it dashDB bash and switch to the dsadm user by running su - dsadm:
- The /opt/ibm/bludr/scripts/bin/bludr-status.sh command returns INACTIVE state.
- The ps -ef | grep bludr command results show the bludr process in running state.
- The file /head/bludr/settings_backup/customCert.p12 command returns Java KeyStore.
- The grep wlp.keystore.location /scratch/web_console/configuration/bootstrap.properties.template command returns wlp.keystore.location=${dsserver_home}/wlp/usr/servers/dsweb/resources/security/key.p12.
- The ls -l /opt/ibm/dsserver/wlp/usr/servers/dsweb/resources/security/key.p12 command returns /opt/ibm/dsserver/wlp/usr/servers/dsweb/resources/security/key.p12 -> /head/bludr/settings_backup/customCert.p12.
If all of these conditions are true, follow these steps in the source system Db2 common container under the user dsadm:
1. Run the following command to save a copy of the original customCert.p12 file:
```
sudo cp /head/bludr/settings_backup/customCert.p12 /head/bludr/settings_backup/customCert.p12.bad_from_10232
```
2. Run the following command to copy the default SSL certificate of the web console, key.p12, to the settings_backup directory:
```
sudo cp /scratch/web_console/configuration/resources/security/key.p12 /head/bludr/settings_backup/customCert.p12
```
3. Exchange the Db2 SSL certificate between the source and target by running the bludr-configure-certs.sh script on the source system. The format of the command to run the script is as follows:
```
/opt/ibm/bludr/scripts/bin/bludr-configure-certs.sh source_hostname target_hostname
```
  Where source_hostname and target_hostname are fully qualified host names.
Before you upgrade to IBM Integrated Analytics System v1.0.24.0, you must make a copy of the customCert.p12 SSL certificate file at the replication target database and then restore the file to its previous location after you upgrade IAS.
If you migrate your replication environment to the IBM Integrated Analytics System v1.0.22.0 or Db2 Warehouse v11.5.3 releases, the CURRENT_LEVEL and CONTROL_TABLES_LEVEL columns in the IBMQREP_CAPPARMS control table are set to an incorrect value of 1140.104. The values should be 1140.105. You can correct the values by running the following SQL statement on the replication source database:
```
update qasn.ibmqrep_capparms set CURRENT_LEVEL = '1140.105', CONTROL_TABLES_LEVEL = '1140.105';
```
Restart the capture program after you make this change.
If you must add a unique constraint for replication, it is strongly advised to deactivate and reactivate the database before adding the table to the replication set. Otherwise, Db2 performance might not be optimal for changes to that table because Db2 supplemental logging is unaware of the constraint until it refreshes its cache on all its data members in the system.
Replication for a table will be deactivated upon restart of the replication capture process if DDL and DML statements for a column-organized table are mixed in a single transaction. When issuing DDL on a column-organized table in a partitioned database environment, you must commit the transaction after altering the table and before doing inserts on that table. If alters are followed by inserts or updates in the same transaction for the modified columns, the table becomes inactive and displays as stopped in the web console. You must start the table, which causes a reload of the target table with all of the data from the source table.
Two console features, Load all tables in the replication set when the set is started and Load all tables that were newly added to the replication set, do not work if the target table contains Boolean columns. If you want the target table to be loaded and the source table has Boolean columns, you can create the target table manually and define the corresponding columns with a compatible data type (SMALLINT, INT, or BIGINT) before you add the table to the replication set.

Limitations

Replication of external tables (files) is not supported. External tables display in the console as tables that you can add to a replication set and have an N value in the Viable key column, but you should not select these tables. If you do select an external table, the console shows error ASN7527I after the set finishes configuring, and you must manually start the set.
You cannot use the ADMIN_MOVE_TABLE stored procedure to make structural changes to a column-organized table that is subscribed for replication, such as changing the partitioning key from random to hash. Whenever the structure of the table is modified with ADMIN_MOVE_TABLE, you must drop the subscription and recreate it after the new table is created. This procedure requires reloading the target table.