Ejabberd-Cluster Database Configuration

ESL Developer Blog - - December 11, 2009

In a recent post to the ejabberd mailinglist Jesse Thompson shared his insights on hof to configure the mnesia-database dependencies and storage locations in an ejabberd cluster that has more than one node.

I formated his inforamtion and put them here, since I found them to be rather insightful.

He makes a few basic inferences and then walks the list of database tables to show what has to be done to conform to this simple set of rules:

Inference #1:

If the master is RAM&disc, then the slave should be:

  1. RAM&disc: If you want it available when slave starts up alone
  2. RAMcopy: If you don’t

Inference #2:

If the master is RAMcopy, then the slave should be:

  1. RAM copy (instead of Remote Copy): So that the feature works on the slave when the master is down.
  2. Remote copy: If the feature only works if the master is up.

Inference #3:

If the master is DiscOnly, then the slave should be:

  1. Remote copy: If the feature only works if the master is up.
  2. There is a possible synchronization problem if we try to set the slave to DiscOnly (needs to be confirmed)
  3. Consider changing both master and slave to RAM&disc

These rules boil down to the following configuration for the locations of the mnesia tables of a “normal” ejabberd install:

Table Name Master Slave
acl RAM and disc copy RAM and disc copy
caps_feature RAM copy RAM copy
config RAM and disc copy RAM and disc copy
disco_publish Disc only copy Remote copy
http_bind RAM copy RAM copy
http_poll RAM copy RAM copy
iq_response RAM copy RAM copy
last_activity Disc only copy Remote copy
local_config RAM and disc copy RAM and disc copy
motd Disc only copy Remote copy
motd_users Disc only copy Remote copy
muc_online_room RAM copy Remote copy
muc_registered Disc only copy Remote copy
muc_room Disc only copy Remote copy
offline_msg Disc only copy Disc only copy
privacy Disc only copy Disc only copy
private_storage Disc only copy Remote copy
pubsub_node Disc only copy Remote copy
roster RAM and disc copy RAM and disc copy
route RAM copy RAM copy
s2s RAM copy RAM copy
schema RAM and disc copy RAM and disc copy
session RAM copy RAM copy
user_caps RAM and disc copy RAM and disc copy
user_caps_resources RAM and disc copy RAM and disc copy
vcard Disc only copy Remote copy
vcard_search Disc only copy Remote copy

Jesse makes some more comments on his descisions in his mailinglist post but the essence of it is:

  • avoid remote copies if you want your service to run without the master
  • keep stuff in RAM, or at least RAM and disc
  • if you have big databases (like offline_msg), store them on disc only, so they don’t eat up your RAM

      • Thanks for the advice and the allowance to post this here, Jesse!



Categories: Blogs  ESL Developer Blog  

Comments

No comments so far, you could be the first.

Add comment

Name:

Email:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?