Skip to main content
Rep Pro Redis sync is network proof, not the reason to buy. Buy Pro for evidence, anti-farm, and trust tiers. Use Redis when those scores must stay cache-fresh across backends. It keeps reputation scores consistent across a multi-server network in near real time. It does not replace MySQL — both are required.

Requirements

  • Rep Pro with a valid REP_PRO license key
  • Shared MySQL on every backend (storage.method: mysql, same database)
  • Redis reachable from every backend
  • pro-settings.redis-sync: true
Core MySQL alone shares reputation data but each server caches records locally. Redis sync invalidates those caches instantly when any server changes a score. See Installation for the difference.

How it works

Redis sync uses a cache invalidation model — not full payload replication.
  1. All servers read and write reputation through shared MySQL (source of truth).
  2. Each server keeps a local in-memory cache of player records for performance.
  3. When any server changes a player’s score, it:
    • Writes the update to MySQL
    • Publishes an invalidation message on a Redis pub/sub channel
  4. Other servers receive the message, drop that player from their local cache, and fetch fresh data from MySQL on the next access.
Rep does not send score payloads over Redis. Only a lightweight “this UUID changed” signal is published. This keeps messages small and avoids race conditions between servers.

Configuration

plugins/Rep/config.yml
Point every Rep Pro backend at the same MySQL database and same Redis instance.

Manual cache flush

If caches drift or you need a full refresh after maintenance:
Both commands require rep.admin.redissync. They flush the local cache on the executing server and broadcast invalidation to all connected backends.

Troubleshooting

  • Rep Pro — license and overview
  • Installation — MySQL setup and Core vs Pro storage notes
  • Commands/rep redis flush permission details