Db2 Q-replication for MobileFirst 8.0 in an Active-Active Configuration
Deploying a mobile application is more than just building a mobile application and deploying it to the public app store. A mobile application talks to a back-end system. If the application can be used in many places around the world by a large community, it is likely that the backend servers will be located in several data centers to more efficiently serve the requests from the mobile application.
Setting up an active-active topology for your mobile application built with IBM MobileFirst Platform Foundation (formerly Worklight Platform Foundation) achieves:
Increased availability and performance.
Distribution of workload across sites.
Better disaster recovery, compared to an active-passive solution.
The active-active topology, also known as master-master topology, consists of IBM MobileFirst Platform Foundation(MFP) deploying the server in two or more data centers that are all active. This deployment means that the server instances are all ready to respond to requests from the clients. In IBM MobileFirst Platform Foundation, these requests come from the mobile applications.
For detailed information on configuring active-active configuration refer to the tutorial and reference links under the References section. Please note that the base tutorial published is based on older MobileFirst version, however the only change that is needed would be to change the database names corresponding to MFP v8 table names which can be referred here.
Starting MobileFirst v8.0, enabling the DB2 q-replication for all the MFP runtime/push databases following the Db2 Q-replication tutorial will fail with the following error while running q-replication scripts to create subscriptions.
ASN2003I The action "Create Subscription" started at "Friday, May 4, 2018 5:18:06 PM UTC". Q subscription name: "LICENSE_TERMS0001". Q Capture server: "MFP1". Q Capture schema: "ASN". Q Apply server: "MFPDB". Q Apply schema: "ASN". The source table is "MFPSRVR.LICENSE_TERMS". The target table or stored procedure is "MFPSRVR.LICENSE_TERMS". ASN0999E "Column ID with datatype GENERATE ALWAYS is part of the primary key. This is not supported" : "*" : Error condition "*", error code(s): "*", "*", "*"
Reason for this error is documented here.
For any existing customers, who already have the MobileFirst server running and in production, but want to use the Q-replication feature, we recommend them to run the following steps prior to attempting Q-replication.
In both the datacenters, connect to your MFP database and alter the license terms property.
db2 connect to <MFPDBNAME> user <MFPUSER> using <MFPPWD> db2 alter table <MFPSCHEMANAME>.license_terms alter column ID drop identity db2 alter table <MFPSCHEMANAME>.license_terms alter column ID set generated by default as identity
MFPDBNAME is MFP1
MFPUSER is db2inst1
MFPPWD is db2pwd
MFPSCHEMANAME is MFPSRVR, then the command to run will be
db2 connect to MFP1 user db2inst1 using db2pwd db2 alter table MFPSRVR.license_terms alter column ID drop identity db2 alter table MFPSRVR,license_terms alter column ID set generated by default as identity
Repeat the above step for the other active datacenter as well.
Once the above prerequisite is done in both the MFP servers, customer can follow the Db2 Q-Replication tutorial to configure Q-replication.
For new Installation
Starting MFP CD Update 22.214.171.124-IF201807180449, APAR
PH00066 DB2 Q-REPLICATION WITH MFP DB NOT WORKING IN MFP8 has been fixed, which updates the SQL scripts to fix this limitation during the installation. So for any new Installation, customers can simply go ahead and configure the Db2 Q-replication as long as they have done fresh installation of MFP v8 using the CD cumulative install pack .
Refer to the documentation of this in the CD release notes here.
Impact for existing customers
With our tests, we have observed that
db2 alterdoes not affect the contents of the table. Only the identity column is modified. The rest of the data is intact. We have also tested that the normal behavior of licensing feature works as expected, and subsequent runs properly append entries to license-terms table.
We have tested that for the tables we chose for Q-replication , active-active configuration sync happened perfectly in both directions.
Note that even in the parent turorial, DB2 replication is recommended only for runtime and push tables. We expect the Admin deployments to happen manually on each cluster of the topology.
Data replication is real time. However, depending on network bandwidth, resource contention or distance, replication may take slightly longer to be visible between DB instances ( data center - data center).