[ejabberd] which mnesia tables to replicate in cluster?
skupko.sk at gmail.com
Sat Nov 21 02:08:50 MSK 2009
Jesse Thompson wrote:
> We have a 2-node ejabberd cluster. We begin with both running, then
> we shut down the master node, and the slave node continues to serve
> traffic just fine. However, when we restart the slave node (or if it
> crashes for some reason) while the master is down it does not start
> back up.
Just read something about how distribution of Mnesia DBMS works and you
will find the reason of that behavior yourselves probably.
It looks like there were only RAM replicas of some important tables.
> I seem to remember this working with ejabberd 1.4 by only replicating
> the roster table (we don't use internal authentication, so we don't
> have a password table) however we seem to have misplaced our
Are you 100% sure that you were replicating just roster? And what about
offline_messages, last_activity, muc_*, vcard, config and others?
> As an experiment, we have set up the slave node so that *every* mnesia
> table is 'RAM and disc copy'. The slave node now starts up. However,
> I don't think that it would necessarily be wise to run with this
> configuration in production.
This is list of tables and their 'locations' on our server:
<ejabberdctl mnesia info>
ram_copies = [bytestream,caps_features,http_bind,http_poll,
disc_copies = [acl,config,irc_custom,last_activity,local_config,motd,
disc_only_copies = [disco_publish,offline_msg,private_storage,pubsub_item,
> 2 questions:
> 1. Which tables specifically need to be replicated in order for a
> slave node to start without the master being available?
Read 'Distribution and Fault Tolerant' part of Mnesia User guide  - I
think it is important to have all mnesia tables replicated.
> 2. Is there any way to define the table replication settings in the
> configuration instead of doing this manually?
It is not ejabberd's responsibility - Mnesia is just storage subsystem
for ejabberd (application server) and it is your responsibility to
configure it in proper way. Just imagine that you are using PostgreSQL
for storage subsystem - would you expect that configuration options in
More information about the ejabberd