Storage

Choosing between SQLite, MySQL and MongoDB, what tables get created and what you need to back up.

Listings, payouts and transaction history all live in one database. Which one is up to you.

DATABASE:
  TYPE: SQLITE

Value	Use it for	Setup
`SQLITE`	A single server	None. One file
`MYSQL`	A network, or a database you already run	A database and a user
`MONGODB`	A network, document storage	A connection string

Changing TYPE needs a full server restart. /ah reload deliberately does not re-read it, because swapping backends at runtime would strand every in-flight query. Changing it also does not migrate your existing data. The old data stays where it is and the new backend starts empty.

An unknown TYPE falls back to SQLITE with a warning.

SQLite

DATABASE:
  TYPE: SQLITE
  SQLITE:
    FILE: "plugins/AT-AuctionHouse/auction.db"

The default, and the right answer for a single server. One file, no server to run, no credentials to manage.

FILE is relative to the server root. The parent folder is created for you.

SQLite cannot be shared between servers. If you want one auction house across a network, you need MySQL or MongoDB. See Cross-server.

MySQL

DATABASE:
  TYPE: MYSQL
  MYSQL:
    HOST: "localhost"
    PORT: 3306
    DATABASE: "auction"
    USER: "root"
    PASSWORD: "password"
    USE-SSL: false
    ALLOW-PUBLIC-KEY-RETRIEVAL: true

Key	What it does	Default
`HOST`	MySQL hostname	`localhost`
`PORT`	MySQL port	`3306`
`DATABASE`	Database name. It has to exist already	`auction`
`USER`	MySQL username	`root`
`PASSWORD`	MySQL password	`password`
`USE-SSL`	Encrypt the connection	`false`
`ALLOW-PUBLIC-KEY-RETRIEVAL`	Allow the driver to fetch the server's public key	`true`

The database has to exist. The plugin creates its own tables inside it but will not create the database itself.

The TLS keys

These two go together, and getting them wrong is the most common MySQL problem.

USE-SSL: false
ALLOW-PUBLIC-KEY-RETRIEVAL: true

This is the shipped default and it is what makes a plain setup work out of the box.

ALLOW-PUBLIC-KEY-RETRIEVAL only matters with caching_sha2_password, which is the MySQL 8 default authentication plugin, on an unencrypted connection. Without it, the driver cannot get the key it needs to authenticate and the connection is refused.

Leave it like this when the database is on the same machine or inside a network you control.

MongoDB

DATABASE:
  TYPE: MONGODB
  MONGODB:
    URI: "mongodb://localhost:27017"
    DATABASE: "auction"
    COLLECTION: "auction_listings"

Key	What it does	Default
`URI`	Standard connection string	`mongodb://localhost:27017`
`DATABASE`	Database name	`auction`
`COLLECTION`	Base collection name	`auction_listings`

Credentials, replica sets and mongodb+srv:// URIs all work in URI, including TLS options. There are no separate TLS keys for MongoDB because the connection string already carries them.

COLLECTION is a base name. Three more collections are derived from it, see below.

What gets created

Three tables, created automatically on the first start, on both SQLite and MySQL.

Table	Holds
`ah_listings`	Every listing, active or otherwise, with its serialized item, price, timestamps, status and originating server
`ah_transactions`	Completed sales: buyer, seller, item, price and timestamp
`ah_payouts`	The collection box. Money or an item owed to a player, with a claimed flag and a reason

Indexes are created alongside them. On MySQL a re-run of the index statements legitimately fails with "duplicate key name" and is ignored. Anything else is logged as a warning, because a missing index is a silent performance problem.

Backups

Back up whatever holds ah_listings, ah_transactions and ah_payouts, or their MongoDB equivalents. That is the whole of the plugin's live state.

Backend	What to back up
SQLite	The file named by `DATABASE.SQLITE.FILE`, by default `plugins/AT-AuctionHouse/auction.db`
MySQL	The database named by `DATABASE.MYSQL.DATABASE`
MongoDB	The database named by `DATABASE.MONGODB.DATABASE`

ah_payouts matters as much as ah_listings. It holds every item and every payment owed to a player who was offline or had no room. Restoring listings without payouts loses real player property.

Also worth keeping, though they are not live state:

config.yml
gui.yml
lang/ if you edited it or added a translation

Copy the SQLite file while the server is stopped, or use SQLite's own online backup. A plain file copy of an active database can catch it mid-write.

Drivers

Every driver is declared in plugin.yml and downloaded by the server at startup into an isolated classloader. Nothing to install by hand.

Only the driver matching your DATABASE.TYPE is ever initialised, so choosing SQLite does not load MySQL or MongoDB code, and two plugins can use different driver versions without clashing.

The first startup after installing the plugin, or after changing DATABASE.TYPE, needs network access to download the driver. Once cached, later startups are offline-safe.

How the data is kept correct

Every state change that moves value is a single conditional update rather than a read followed by a write.

Selling a listing flips it from active to sold in one statement that only matches if it is still active, so exactly one buyer wins a race and everyone else is told the listing is gone. Claiming from the collection box works the same way, so an item can be collected once and only once.

This holds across servers as well as within one, which is what makes cross-server mode safe.

Checking what is in use

/ah about

reports the platform, the storage backend actually in use, whether cross-server mode is on, and how many active listings are cached. It needs atauctionhouse.admin.

On this page