ejabberd - Comments for "MUC with clustering vs. HA/High Availability" https://www.ejabberd.im/forum/25467/muc-clustering-vs-hahigh-availability en Apparently something like https://www.ejabberd.im/forum/25467/muc-clustering-vs-hahigh-availability#comment-67026 <p>Apparently something like that is provided in the ejabberd Business Edition: room automatic migration to another node when a node goes down. It isn't mentioned in <noindex><a href="https://www.process-one.net/ejabberd/protocols/" title="https://www.process-one.net/ejabberd/protocols/" rel="nofollow" >https://www.process-one.net/ejabberd/protocols/</a></noindex> or maybe it's included in "Consistent hash clustering"</p> Wed, 31 Aug 2016 09:11:19 +0000 badlop comment 67026 at https://www.ejabberd.im Hi Savek, This is something https://www.ejabberd.im/forum/25467/muc-clustering-vs-hahigh-availability#comment-67024 <p>Hi Savek,</p> <p>This is something I'm trying to do as well. Have you found a solution yet?</p> <p>It seems the built-in clustering does not provide this. I'm now considering the following construction, which feels a bit fragile, but could work:<br /> • Have one ejabberd instance (the master) running, and the other (the standby) stopped.<br /> • From the standby computer, perform the following actions over and over:<br /> · make a database backup of the master using ejabberdctl backup;<br /> · transfer the backup file to the standby;<br /> · install the backup file on the standby using ejabberdctl install_fallback.<br /> Whenever one of these actions fail (or you note in another way that the master is down), start the ejabberd instance on the standby. It will use the latest succesful database dump from the master.</p> <p>How often you can make, transport and install the backup will depend on the size of the database, the speed of the server and the connection between master and standby. In my setup (very small server) it takes a only few seconds, so you could do this a few times per minute and thus miss very little data when the standby has to take over.</p> <p>One big disadvantage of this scheme is that recovering from a failure might be tricky: when the standby takes over, new messages and other data will end up in the standby database. However, if the failure of the database transfer is due to network partitioning, the master could have some new messages as well. You would need to merge the two databases somehow if you don't want to lose any history.</p> <p>Also, it feels silly to dump and transport the entire database every time, copying the same data over and over.</p> Tue, 30 Aug 2016 09:45:51 +0000 ariep comment 67024 at https://www.ejabberd.im