Load Balancing Registries - Revision history

Vmurrell at 16:31, 30 October 2025

2025-10-30T16:31:59Z

Vmurrell at 05:56, 11 September 2023

2023-09-11T05:56:29Z

Plazarou: /* Mechanisms */

2022-02-10T15:20:59Z

‎Mechanisms

Plazarou: /* Mechanisms */

2022-02-10T15:20:38Z

‎Mechanisms

Plazarou at 15:19, 10 February 2022

2022-02-10T15:19:15Z

Plazarou: /* Cron Jobs */

2022-02-10T15:18:20Z

‎Cron Jobs

Plazarou at 15:17, 10 February 2022

2022-02-10T15:17:32Z

Plazarou: /* Mechanisms */

2022-02-10T15:16:31Z

‎Mechanisms

Plazarou: /* Mechanisms */

2022-02-10T15:15:00Z

‎Mechanisms

Plazarou: /* Mechanisms */

2022-02-10T15:11:23Z

‎Mechanisms

@@ Line 1: / Line 1: @@
-[[Category:How_To]]
+[[Category:Fusion Registry Configuration]]
 == 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).

← Older revision		Revision as of 05:56, 11 September 2023
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).

← Older revision		Revision as of 15:20, 10 February 2022
Line 3:		Line 3:

	== 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:
−
−	~~[[File:FR-LoadBalancing.png\|200px\|thumb\|The settings page of Fusion Registry showing database polling set to 20 seconds]]~~

@@ Line 4: / Line 4: @@
 == Mechanisms ==
 The Fusion Registry supports 2 mechanisms for keeping its internal cache in sync:
 . 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.
 . 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]].

← Older revision		Revision as of 15:19, 10 February 2022
Line 12:		Line 12:

	== Cron Jobs ==		== 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~~	+	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]].
−	~~#REDIRECT~~ [[~~Target page name~~]]

← Older revision		Revision as of 15:18, 10 February 2022
Line 12:		Line 12:

	== Cron Jobs ==		== 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".	+	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
		+	#REDIRECT [[Target page name]]

← Older revision		Revision as of 15:17, 10 February 2022
Line 10:		Line 10:

	[[File:FR-LoadBalancing.png\|200px\|thumb\|left\|The settings page of Fusion Registry showing database polling set to 20 seconds]]		[[File:FR-LoadBalancing.png\|200px\|thumb\|left\|The settings page of Fusion Registry showing database polling set to 20 seconds]]
		+
		+	== 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".

← Older revision		Revision as of 15:16, 10 February 2022
Line 9:		Line 9:
	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.

−	::[[File:FR-LoadBalancing.png\|200px\|~~frame~~\|left\|The settings page of Fusion Registry showing database polling set to 20 seconds]]	+	[[File:FR-LoadBalancing.png\|200px\|thumb\|left\|The settings page of Fusion Registry showing database polling set to 20 seconds]]

← Older revision		Revision as of 15:15, 10 February 2022
Line 9:		Line 9:
	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.

−	::[[File:FR-LoadBalancing.png\|~~600px~~\|frame\|The settings page of Fusion Registry showing ~~Database~~ polling set to 20 seconds]]	+	::[[File:FR-LoadBalancing.png\|200px\|frame\|left\|The settings page of Fusion Registry showing database polling set to 20 seconds]]

← Older revision		Revision as of 15:11, 10 February 2022
Line 9:		Line 9:
	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.

−	::[[File:FR-LoadBalancing.png\|600px]]	+	::[[File:FR-LoadBalancing.png\|600px\|frame\|The settings page of Fusion Registry showing Database polling set to 20 seconds]]