2 Nodes in cluster have diverged- can they be re-synced?

Openfire Openfire Support
1

Hi,

I’ve got 2 nodes set up in a Hazelcast cluster, both running 3.10.3 and hazelcast pluging 2.1.2 (was 2.0.0).

Unfortunately some of the config has diverged and I’d like to trigger a resync from the “master” to the "slave " without blowing away the entire config on one and starting afresh.

For example the Chat Rooms on the 2 are different (this is the most noticable difference):

MASTER

select * from ofMucRoom \G

*************************** 1. row ***************************

serviceID: 1

roomID: 27

creationDate: 001442914167383

modificationDate: 001442914167392

name: *****

naturalName: *****

description: *****

lockedDate: 000000000000000

emptyDate: 001447521590372

canChangeSubject: 0

maxUsers: 0

publicRoom: 1

moderated: 0

membersOnly: 0

canInvite: 0

roomPassword: NULL

canDiscoverJID: 0

logEnabled: 0

subject:

rolesToBroadcast: 7

useReservedNick: 0

canChangeNick: 1

canRegister: 1

<---- snip ----->

11 rows in set (0.00 sec)

SLAVE

mysql> select * from ofMucRoom \G

*************************** 1. row ***************************

serviceID: 2

roomID: 1

creationDate: 001432937112297

modificationDate: 001432937112322

name: ******

naturalName: ******

description: ******

lockedDate: 000000000000000

emptyDate: 001439640080463

canChangeSubject: 0

maxUsers: 0

publicRoom: 1

moderated: 0

membersOnly: 1

canInvite: 0

roomPassword: NULL

canDiscoverJID: 0

logEnabled: 1

subject:

rolesToBroadcast: 7

useReservedNick: 0

canChangeNick: 1

canRegister: 1

<— snip -->

8 rows in set (0.00 sec)

2

You need to run all the Openfire nodes in your cluster against a single (master) database server during runtime. You can use a master-slave DB replication model to keep a “cold” standby DB server ready to go in the event of a failure of the master DB, but you will need to update the DB connections string and restart Openfire to move from the failed master DB to the slave (new master) DB.

Note that for performance reasons Openfire makes extensive use of caching to keep information from the database in memory. Therefore, any out-of-band database updates must be done only when the application server (Openfire) is completely shut down.

3

OK thanks for confirming this- I’ll import a dump from the master and set up replication on the MySQL database.