[ejabberd] Node Clustering issue

Matthew Reilly matthew.reilly at sipphone.com
Thu Jun 12 00:34:32 MSD 2008


Florian Jensen wrote:
> Ok, I got it running. I now can access the erlang console.
>
>   
Out of curiosity, how did you get it fixed?

> So, now, how can I let it sync all? And how can I let it start 
> automatically in cluster mode?
>
>   
I'm doing this from memory, so I apologize if I get something wrong.

Now that you have connected, you should be able to do (from the erlang 
console):
erl> mnesia:info().

This should show both your main node and your new node.

You want to have it set up so that the next time you start your new 
node, it remembers to connect to the original node.

To do this:

erl> mnesia:change_table_copy_type(schema,node(),disc_copies).

This creates a copy of the mnesia schema on the local drive, so that 
when you restart the local node, it remebers to connect to the main node.

What that means is that when you kill your console (with 
control-C/control-C), and start ejabberd on the second node (with the 
same ./start script), it will come up in clustered mode -- you don't 
need to do anything else for (basic) clustering! (on the ejabberd side 
-- you still need to set up DNS entries pointing to the second node, or 
no clients will find it).

Once you've done this, the first node stores all data, and the second 
node stores none of the data (except for the schema itself). This means 
that every mnesia lookup (which is done e.g. everytime a 
message/presence stanza is sent) works by having the second node send a 
network request to the first node, the first node lookups up the info in 
its mnesia table and sends it back to the second node.

That is the default behavior, which may be acceptable --the mnesia 
traffic/CPU load is not very large. However, this only gives you 
scalability benefits of clustering, but not fault-tolerance. For 
example, if your first node went down, the second node would suddenly 
become unusable (since it has no copies of the mnesia tables locally).

To add fault tolerance, you'll need to stay in the console mode (or 
reenter it if you've left it), and do a mnesia:add_table_copy() for each 
table. This'll be tedious, and if anyone else knows a more automated 
way, I'd like to hear it.

To get a list of the tables, do:
erl> mnesia:info().

You get output similar to:
[{'ejabberd at ds2248',ram_copies}] = [session,route, ...]
[{'ejabberd at ds2248',disc_copies}] = [privacy,...]
[{'ejabberd at ds2248',disc_only_copies}] = [offline_msg,...]

There are three types of tables: RAM resident (ram_copies), RAM & disc 
resident (disc_copies), and just disc resident (disc_only_copies).

For each table, you tell the mnesia system that you want a clustered 
copy on the second node by issuing these commands from the erlang 
console (one the second node):

erl> mnesia:add_table_copy(session,node(),ram_copies).
erl> mnesia:add_table_copy(route,node(),ram_copies).
...
mnesia:add_table_copy(privacy,node(),disc_copies).
...
erl> mnesia:add_table_copy(offline_msg,node(),disc_only_copies).
...

If you do this for each table, the second node will be able to keep 
running if the first dies. You only have to do this once -- even if you 
restart the second node, it knows which tables to cluster.

Note: The actual list of tables you'll need to cluster will differ 
depending on the modules you've configured in your ejabberd.cfg as well 
as whether you're using a SQL backend. If you add a new module to 
ejabberd.cfg, it may add a new mnesia table, and you made need to do a 
mnesia:add_table_copy() for the new table.
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
>   



More information about the ejabberd mailing list