Difference between revisions of "Load Balancing Registries"
(→Mechanisms) |
|||
| (8 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:How_To]] | ||
| + | [[Category:Fusion Registry Install]] | ||
== 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 == | ||
| + | [[File:FR-LoadBalancing.png|200px|thumb|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: | 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. | 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. | ||
| Line 9: | Line 14: | ||
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. | 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 [[Secondary_Server | here]]. | ||
Latest revision as of 21:56, 10 September 2023
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.
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.
