Wiki Release: 2026.09.8 · UltimateClans: 9.1.4 · Documentation branch: 9 · Multiserver
Multiserver#
Multiserver adds cross-server clan synchronization using Redis/proxy-oriented high-sync messaging. The pages in this section explain what players see in-game, what administrators need to configure, the normal setup flow, and the most common problems you may need to diagnose.
Compatibility#
- Component version:
1.0 - Documentation release:
2026.09.8 - Minimum UltimateClans version:
9.0.0
What you can do with it#
- Configure the same Redis host/port/database/channel and compatible server naming across all participating nodes
- Enable high sync, start two test servers and change one clan field on server A
- Verify server B receives the update before enabling the network for players
How it works#
Synchronization model#
Multiserver is a transport/synchronization module, not the primary clan database. High sync publishes clan/player update messages through Redis/proxy listeners so other server nodes can refresh their local state quickly. Every node still needs a compatible authoritative storage configuration.
First setup#
Before enabling the feature for players, review these installed files:
config.yml
Recommended in-game workflow#
- Configure the same Redis host/port/database/channel and compatible server naming across all participating nodes.
- Enable high sync, start two test servers and change one clan field on server A.
- Verify server B receives the update before enabling the network for players.
This feature is mainly automatic or accessed through the parent plugin/GUI, so it does not need a large standalone command tree.
What administrators should configure#
- Use the same authoritative clan storage strategy across nodes.
- Enable sent/received/dispatch debug only while diagnosing; it can be noisy.
Configuration map#
config.yml—Sync(high)
The Configuration page lists the available paths and defaults from the installed configuration, with notes on what each area controls.
Before going live#
- Back up the component data/configuration.
- Start the server and confirm the component is detected without startup errors.
- Test with a non-OP player and the lowest clan role that should have access.
- Exercise the complete flow once, including the failure/deny path, not only the happy path.
- Restart the server and verify that persistent state survives.
- If the network is multiserver, repeat the test from a second node and verify storage/synchronization.
Troubleshooting quick reference#
| Symptom | Likely cause | What to check |
|---|---|---|
| Server B never receives updates | Redis unreachable, different channel/database, sync disabled or authentication mismatch | Test Redis connectivity from both hosts and compare every Sync.high.redis.* value. |
| Updates loop/duplicate | Nodes dispatch the same change repeatedly or server identity is inconsistent | Check server-name/source filtering and dispatch debug. |
| Clan state differs after restart | Database and Redis sync strategies disagree | Confirm all nodes load from the same intended storage and then apply sync. |
For a longer diagnostic flow, open the Troubleshooting page for this component.