Multi-server isolation

Run VotePlus across Survival / Skyblock / Prison on one MySQL DB without crossed wires.

If you run a network — Survival, Skyblock, Prison, etc. — and want all of them to use a single MySQL database for VotePlus, you need to be deliberate about which counters are shared and which are isolated. This guide walks the whole topology end-to-end so you don't end up with diamonds being given out twice for the same vote.

What's shared, what's isolated

Counter / state	Shared across servers?	Why
Per-player vote totals	No (per `server-id`)	A vote on Skyblock shouldn't double-pay rewards on Survival.
Per-player streaks	No (per `server-id`)	Streaks track engagement with this server.
Per-player milestones	No (per `server-id`)	A milestone reward shouldn't fire twice for the same player.
Per-player offline queue	No (per `server-id`)	The reward pool is per-server.
Vote-party counter	Yes (global)	The party is a network-wide event by design.

The single config knob that drives this is mysql.server-id in config.yml. Set it to a unique value per backend and you get clean per-server isolation for player counters while keeping the global party counter shared.

Setup

Pick your server-ids

Pick a short, unique string per backend:

Backend	Suggested `server-id`
Survival	`survival`
Skyblock	`skyblock`
Prison	`prison`
Creative	`creative`

These never appear in player-facing strings — they're just internal keys — so use whatever's clear to you.

Create one database, point all servers at it

CREATE DATABASE tdx_voteplus CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'tdx'@'%' IDENTIFIED BY 'a-strong-password';
GRANT ALL PRIVILEGES ON tdx_voteplus.* TO 'tdx'@'%';

Then in every server's plugins/TDXVotePlus/config.yml, point the mysql: block at the same database — but give each one its own server-id:

plugins/TDXVotePlus/config.yml (Survival)

general:
  storage: mysql

mysql:
  host: "db.your-host.tld"
  port: 3306
  database: "tdx_voteplus"
  username: "tdx"
  password: "a-strong-password"
  server-id: "survival"

plugins/TDXVotePlus/config.yml (Skyblock)

general:
  storage: mysql

mysql:
  host: "db.your-host.tld"
  port: 3306
  database: "tdx_voteplus"
  username: "tdx"
  password: "a-strong-password"
  server-id: "skyblock"

Decide on your Votifier topology

This is the part that bites people. There are two valid topologies, and they have very different implications for offline votes.

Option A — single Votifier endpoint (recommended for most networks)

NuVotifier runs on one server (often the proxy or a dedicated "vote-receiver" backend). When a vote arrives, it forwards the event to every backend. Every TDX VotePlus instance reacts in parallel.

Pros: simple, every server reacts the same way, offline-vote queueing works per-server cleanly.
Cons: every backend processes every vote, so the database gets N inserts per real vote (one per backend).

Option B — single backend receives, forwards via API

Only one backend receives votes from the trackers. It uses the TDX VotePlus public API or an external bridge to push the vote to other backends as needed.

Pros: only one DB write per vote.
Cons: you have to write the bridge, and offline-vote queueing becomes a custom problem.

If you're not sure, use Option A. It's what 95% of networks should pick.

Restart all backends

Each backend will create its own row in the per-server tables on first connect. The vote-party counter is global, so the first backend to start gets the existing counter; subsequent ones see the same value.

Run /voteplus party on any backend to confirm — the counter should match across all of them.

Verifying the isolation works

The fastest sanity check:

Run /testvote YourName on Survival.
Open /vote on Survival → your vote count increased.
Open /vote on Skyblock → your vote count is unchanged.
Run /vote party on either server → the global counter incremented by 1.

If steps 2 and 3 give the same number, your server-id isn't being applied — double-check that the value differs between the two backends and that both are actually using storage: mysql, not SQLite.

Once a backend has been running with a given server-id, don't rename it. The rename creates a brand-new logical server in the database and the old player counters become orphaned. If you must rename one, run a SQL UPDATE against the per-server tables first to migrate the rows.