The Database

The Default Needs Nothing

Out of the archive, the server uses SQLite: the database is a set of files in the db/ directory beside the server. There is no service to install, no user to create, no password to set, and no port to open. The server creates the files and applies the schema on first start.

This is the default because the most common reason a self-host attempt dies is the database step, and it is a step that buys most operators nothing. A server with twenty players is not constrained by its database engine.

When to Switch to MySQL

Switch when one of these is true, and not before:

• You are running a public server with enough players that you want proper backups, replicas, or someone else administering the database.
• You want to query the data live with the tooling you already have.
• You are running several games on one machine and would rather have one database service than several sets of files.

If none of those apply, the default is the right answer and will stay the right answer.

Switching

Both backends use one schema. There is no second set of tables to keep in step, because the SQLite form is derived from the MySQL one at run time.

1. Create the databases and a user. The archive’s database-mysql/ directory contains the schema files, and the first one creates the databases with the right names.

   mysql -u root -p < database-mysql/00_create_databases.sql

2. Point the server at it in settings.cfg:

   [database]
   DATABASE_PROVIDER   mysql
   DATABASE_HOST       127.0.0.1
   DATABASE_PORT       3306
   DATABASE_USERNAME   your_user
   DATABASE_PASSWORD   your_password

3. Restart. The server applies any missing schema itself, so you do not have to run the remaining files by hand.

Change the password. The archive ships with a placeholder, and a placeholder that reaches production is how a default credential becomes a real one.

What Is Stored Where

Two or three databases, depending on the game.

• The accounts database is shared by every game from this project on the same machine. One email and password gets you into all of them. Characters are not shared; the login is.
• The game database holds that game’s characters, items, and everything that changes while people play.
• A content database, for the RF games only, holds the static game data: monsters, items, shops, maps. It is imported once from data shipped in the archive and never written to at run time.

Backups

For SQLite, stop the server and copy the db/ directory. Copying it while the server is running can capture a half-written transaction, and the copy will look fine until the day you need it.

For MySQL, mysqldump as usual. The content database does not need backing up: it is imported from the archive and identical on every install of that version.

Whichever you use, back up before applying a new release, not after. The schema upgrade on start is one-way.