Load Balancing Registries

From Fusion Registry Wiki
Jump to navigation Jump to search


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).


The settings page of Fusion Registry showing database polling set to 20 seconds

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.

Cron Jobs

If you are load balancing Registries and are making use of Cron jobs from Fusion Portal, you will need to set some of the load-balanced Registries as "Secondary Servers". Read more about this here.