Additional tips

Useful cross data center native functions

In order to send the in-memory state for cross DC replication, application logic can call these native functions to serialize the in-memory state into a blob or deserialize a blob into the original data item.

In a passive mode standalone monitoring application, the following function is available for use to launch a shell script to start the real Streams application in order to do the failover.

If both data centers go down at the same time

If both the DCs went down exactly at the same time, DC1 will have the last known replicated data snapshots for DC2 and vice versa. In this case, users can optionally send such replicated data snapshots to their respective data centers where they originally came from. Users can indicate this preference via this configuration setting:

sendDataSnapshotsToOriginDCAtStartup=true

After both data centers have been brought up correctly, users can either delete this configuration setting belonging to each DC or simply set it to false.

Scaling to work with a larger application topology

A larger application topology running with many operators on a Linux cluster with many machines will require an equivalent level of scaling done at the CrossDataCenterFailover composite. Since the crossdc-failover communicates via HTTP with the remote DC, it needs more HTTP sender/receiver pairs to handle the load from a larger application topology. By default, there is only one pair of sender/receiver. So, users can assign a required number of HTTP sender/receiver pairs by using the submission-time parameter called numberOfHttpSenderReceiverPairs when starting the application.