Just to be certain, this sounds like you’ve set up multi-region for disaster recovery, by asynchronously replicating to a second location. You’ll be able to do a manual operation to have your secondary cluster recover to a consistent snapshot of the database, but one that will be missing the last 1-5 seconds of changes to your data. If you’re looking for a highly available setup, where your cluster will stay available if a datacenter is lost, then you’ll need to look into adding a satellite location.
Though FoundationDB does support multi-region as two regions, please do be very careful about your coordinator choice. For FDB to elect a leader, it does need quorum from the coordinators, so it would be wise to make sure that you either have coordinators in different AZs in the two regions, or preferably that you have a third region that only has a coordinator.
fileconfigure didn’t reject your region JSON, then that’s a good sign.
Concretely, I’d suggest looking at
DatacenterVersionDifference logged from the cluster controller. If the replication is working, and working well, then you should see a
Difference being logged of something roughly under 5,000,000.
Also, before you put any important data or traffic onto this cluster, it’d be good to intentionally kill the primary side, and run through the steps detailed in Handling datacenter failures on how to use
force_recovery_with_data_loss to make your secondary recover and begin serving clients.
As I assume you’ve seen already, then only documentation that we have for multi-region configuration is Configuring Regions. @mpilman has written Running FoundationDB in the Cloud with Three Data Hall that gives some AWS advice, but is about
three_data_hall mode and not multi-region.