Running a server

Storage

storage:
  type: sqlite
  file: chorus.db
  mysql:
    host: localhost
    port: 3306
    database: chorus
    username: root
    password: ''
    pool-size: 8
    properties:
      useSSL: false
      characterEncoding: utf8

SQLite by default: one file in the plugin folder, nothing to configure, nothing to install.

For several servers sharing data, set type: mysql and fill in the mysql section. The same driver handles MySQL and MariaDB.

Changing the storage section needs a full restart, not /chorus reload — the connection pool is built once.

Nothing waits on the database#

Every query runs off the main thread, so the server never waits on it.

Balances are the one thing held in memory as well, because a priced command has to read one the instant it runs; changes are written back behind the scenes.

That is also why the imports need a restart to show their work: balances and warps are read into memory at startup.

The tables#

Table	Holds
`chorus_players`	Names, nicknames, addresses, first and last seen, where each player logged out
`chorus_homes`	Homes, their icons and when they were made
`chorus_locations`	Warps and spawn points, under different categories
`chorus_warp_details`	The per-warp settings `/warpset` writes
`chorus_balances`	Money, for the built-in ledger
`chorus_payments`	The `/paylog` history
`chorus_mail`	Letters
`chorus_ignores`	Who is ignoring whom
`chorus_player_flags`	The toggles that survive a session: `/tptoggle`, `/tpauto`, `/paytoggle`, `/msgtoggle`, `/rtoggle`, vanish, freeze
`chorus_kit_uses`	Kit cooldowns and claim counts
`chorus_inventory_backups`	The copies behind `/restore`
`chorus_pending_restores`	A restore waiting for an offline player to log in
`chorus_chest_shops`	Player shops
`chorus_powertools`	Commands tied to items
`chorus_notes`	Staff notes about players
`chorus_staff_log`	What staff have been doing
`chorus_schema_version`	How far each of the above has been brought up to date

Every table is prefixed chorus_, so the plugin can share a database with anything else.

Migrations#

CREATE TABLE IF NOT EXISTS makes a table appear, but it cannot add a column to a table that already exists. So each table is written as an ordered list of steps, and a server upgrading from an older release runs only the steps it has not seen.

chorus_schema_version records which steps are done. A step that fails rolls back and is not recorded, so it is tried again on the next start rather than being skipped for ever.

This is why upgrading is only ever "replace the jar": a release that adds a column adds it as a step.

Backing it up#

SQLite. Stop the server, copy plugins/ChorusCore/chorus.db. Copying it while the server runs can catch it mid-write; the plugin uses write-ahead logging, so there may also be chorus.db-wal and chorus.db-shm files beside it that belong to the same database.

MySQL. Whatever you already do for the rest of that server. mysqldump on the chorus_ tables is enough.

Worth doing before an import, before a purge, and before a version jump.

Moving from SQLite to MySQL#

There is no command for this. The tables are ordinary SQL, so any tool that copies tables between databases will do it — export the chorus_ tables from the SQLite file, import them into MySQL, then change storage.type and restart.

Do it with the server stopped, and keep the SQLite file until you are sure.

Point them all at the same MySQL database. Homes, balances, warps, mail and the rest are then the same everywhere.

Two things to know:

Balances are cached in memory per server. Money changed on one server is not seen by another until that player logs in there. For a network where players carry money between servers, a dedicated economy plugin with Vault is the better answer.
Chest shops belong to the world they are in, so two servers with different worlds do not collide. Two servers running the same world files are a different problem and not one this plugin solves.

Performance#

The default pool is 8 connections for MySQL and 1 for SQLite, which is what SQLite wants.

On a server large enough for this to matter, the queries worth knowing about are the ones that grow: the payment log, the mail, the inventory backups and the staff log. All four have a keep-days, and the backups additionally have keep-per-player — see Administration.