Ejabberd v17.11多域名场景下MySQL存储vcard的用户名冲突求助

Hey there, I’ve run into almost exactly this problem with a multi-domain Ejabberd deployment a couple years back—so let me walk you through the fixes that worked for us, plus some context on why this happens.

Why the Failure Happens #

The default Ejabberd MySQL schema for ejabberd.vcard only uses username as the identifying key, but in a multi-domain setup, username alone isn’t unique across your 20 domains. When Ejabberd tries to fetch or update a vcard, it gets multiple matching records, which breaks the mod_vcard module’s logic entirely—hence the full functionality failure you’re seeing.

Fix 1: Modify the MySQL Vcard Table & Ejabberd Config (Quickest Win) #

This is the most straightforward fix if you want to stick with MySQL:

1. Update the vcard table schema to add a domain column, and set a composite primary key to enforce uniqueness across username + domain:

   ALTER TABLE ejabberd.vcard 
   ADD COLUMN domain VARCHAR(255) NOT NULL AFTER username,
   ADD PRIMARY KEY (username, domain);
   

2. Backfill existing records with their corresponding domains. You can join with the ejabberd.users table (which tracks username + server/domain) to populate this:

   UPDATE ejabberd.vcard v
   JOIN ejabberd.users u ON v.username = u.username
   SET v.domain = u.server;
   

3. Update your Ejabberd config (ejabberd.yml) to tell mod_vcard to include the domain in all SQL operations:

   mod_vcard:
     db_type: sql
     sql_select: "SELECT vcard FROM vcard WHERE username = %(username)s AND domain = %(server)s"
     sql_insert: "INSERT INTO vcard(username, domain, vcard, created_at) VALUES (%(username)s, %(server)s, %(vcard)s, NOW())"
     sql_update: "UPDATE vcard SET vcard = %(vcard)s WHERE username = %(username)s AND domain = %(server)s"
     sql_delete: "DELETE FROM vcard WHERE username = %(username)s AND domain = %(server)s"
   

Restart Ejabberd after making these changes, and the vcard functionality should work correctly across all domains.

Fix 2: Migrate to LDAP (Long-Term Better Solution) #

You mentioned earlier that LDAP was suggested as a better option—and you’re absolutely right. LDAP natively supports distinguishing users across domains (via OUs, domain-specific attributes, or separate directory branches), so you won’t hit this kind of key uniqueness issue at all.

If your team can prioritize the migration, LDAP will also make user management across 20 domains much more scalable than maintaining a MySQL schema you have to tweak for edge cases.

Avoid the "Separate Instance Per Domain" Trap #

You’re right to skip this approach—spinning up 20 Ejabberd instances would create a maintenance nightmare, negate Ejabberd’s built-in multi-domain support, and waste unnecessary resources. The fixes above are far more sustainable.

内容的提问来源于stack exchange，提问作者João Paulo Bastos