Difference between revisions of "Load Balancing Registries"
(→Mechanisms) |
(→Overall) |
||
| Line 1: | Line 1: | ||
== Overall == | == Overall == | ||
| − | It is possible to run multiple load balanced instances of the Fusion Registry, however it is important to note that the Fusion Registry maintains a number of internal caches to improve performance. When load balancing Fusion Registry instances each instance needs to be made aware when changes take place (such as a structural changes or data being loaded into the Registry). | + | It is possible to run multiple load balanced instances of the Fusion Registry, however it is important to note that the Fusion Registry maintains a number of internal caches to improve performance. When load balancing Fusion Registry instances, each instance needs to be made aware when changes take place (such as a structural changes or data being loaded into the Registry). |
== Mechanisms == | == Mechanisms == | ||
Revision as of 07:05, 10 February 2022
Overall
It is possible to run multiple load balanced instances of the Fusion Registry, however it is important to note that the Fusion Registry maintains a number of internal caches to improve performance. When load balancing Fusion Registry instances, each instance needs to be made aware when changes take place (such as a structural changes or data being loaded into the Registry).
Mechanisms
The Fusion Registry supports 2 mechanisms for keeping its internal cache in sync:
1. Database Polling – if configured, the Fusion Registry will poll the database every ‘x’ seconds. If it detects a change, it will update the relevant parts of its cache. This mechanism will also work if deploying the Fusion Registry across geographical regions with a read replica database for each region.
2. Rabbit MQ PUSH Notification – if configured Rabbit MQ message broker will be used to inform all instances that there was a change, and each instance will update accordingly. Note: it is important to apply the MQ connection on the first Registry instance before starting the subsequent instances. This will ensure that when the subsequent Registry instances start that they will have the correct MQ settings, since this is read on startup, and this will ensure all Registries are kept synchronized.
