Description: Looking for advice how to configure connection pooling to database during disaster recovery exercise

Dev Notes & Context:

• JBPM DB runs using Amazon Aurora DB mysql engine 5.6.10a
• Database is deployed to East/West region with one being the master cluster and another being the Read Replica
• Each Cluster has 2 nodes deployed including a Writer and a Reader node
• During Disaster recover we promote the Read Replica to a Master Database and cut traffic at a higher level to our application

Problem Statement: Today we have an issue where ReadReplication fails between Master -> Slave due to the way our jbpm server is deployed. Essentially we run a "SmokeTest" to create a new ProcessInstance in the database in both regions (Since we are deployed as Active/Active). JBPM startProcess function will insert the state into the database and will break replication because incoming records from the master do not expect this – thus running into a Primary Key Conflict on the ProcessInstanceLog table.

Desired Outcome

• JBPM Application server that is deployed in a Secondary Region points to the Primary region to avoid any replication conflicts. The only record that we would insert is part of the smokeTest because we never route customer traffic to the secondary region.

Discussed Solution
Create a route53 record or CNAME that we can point to in our standalone configuration. We have connection pooling enabled and assume it will handle a failover scenario where we may point the DNS to a failover region.

Can you advise if the above would work? We have questions around how quickly validation occurs, is there any dns caching on the jvm that we should be concerned about.

In the event of a DR excercise:
1. we would promote the Secondary Database to a Master
2. switch the Route53 CNAME to point to the new Master

Reference:
[1] Attached standalone-full.xml
[2] Proposed routing structure