Data Synchronization in Hot Standby and Active-Active Modes
In both hot standby and active-active modes, the data centers are inter-connected with fully connected mesh topology in a ring configuration. The data synchronization happens at the application level and not through API Data Store. Hence, the data is symmetrical at any point of time.
As part of listener configuration you set up the port for gRPC channel through which each data center sends and receives the gossip. Later, with the ring configuration you establish connection with the associated data centers.
The underlying technology is same for both hot standby and active-active modes. The only difference is that, in the active-active mode you can have multiple data centers in a ring configuration and each data center can handle the client request. On the other hand, the hot standby data center can have only two data centers in a ring configuration and only one data center handles the client request.
- Application assets such as API key, identifiers, strategy, and client registrations that are associated with the strategy
- OAuth tokens, auth code, refresh tokens, and so on
- OAuth and OpenID scope mapping
- Application that are registered to API
The below table suggests the possible workaround that could be employed for the different classes of data:
| Data Type | Possible Workaround |
|---|---|
| APIs | Handle using Promotion Management. |
| Policies | Handle using Promotion Management. |
| Aliases | Handle using Promotion Management. |
| Packages | Handle using Promotion Management. |
| Plans | Handle using Promotion Management. |
| Subscriptions | Handle using Promotion Management. |
| Teams | Handle using Promotion Management. |
| Approval configurations | Handle using Promotion Management. |
| Keystore and Truststore configurations | Handle using Promotion Management. |
| Group | Handle using Promotion Management. |
| Email destination | Handle using Promotion Management. |
| JMS connection alias | Handle using Promotion Management. |
| Web service endpoint alias | Handle using Promotion Management. |
| Custom destination | Handle using Promotion Management. |
| Port | Handle using Promotion Management. |
| Service Registry | Handle using Promotion Management. |
| LDAP configuration | Handle using Promotion Management. |
| Password expiry settings | Handle using Promotion Management. |
| Analytics and Transaction Logs | Handle using external destinations. |
| Server Logs | Handle by pushing the logs to a centralized server. |
Promotion Management in Cross-DC Support
Promotion refers to moving webMethods API Gateway assets from the source stage to one or more target stages. For example, you might want to promote assets you have developed on servers in a QA stage (the source API Gateway instance) to data centers in a Production stage (the target API Gateway instance). If you have three data centers in a Production stage, you have to explicitly promote the webMethods API Gateway assets to each data center.
When you promote an asset from one stage to another, the asset's metadata is copied from the source instance to the target instance.