Database

SQLite (default)

Nothing to set up: the data lives in plugins/AdminControl/data.db. Good for one server. Back it up with the rest of the server folder while the server is stopped. To back it up while the server runs, copy the files with SQLite's own tool instead of the file manager: sqlite3 data.db ".backup data-backup.db".

MySQL or MariaDB

Use it for bigger servers or to share bans, mutes and the panel between several servers.

1. Create a database and a user:

   CREATE DATABASE admincontrol CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   CREATE USER 'admincontrol'@'%' IDENTIFIED BY 'a-long-random-password';
   GRANT ALL ON admincontrol.* TO 'admincontrol'@'%';
   

2. In config.yml:

   database:
     type: mysql
     mysql:
       host: db.example.com
       port: 3306
       database: admincontrol
       user: admincontrol
       password: "a-long-random-password"
       use-ssl: true
   

3. Restart the server. The tables are created on start.

A database other plugins already use (CoreProtect, LiteBans, LuckPerms in one database) works too: AdminControl's tables all start with ac_ and it leaves the others alone. A separate database is still the tidier choice.

Moving from SQLite to MySQL starts with an empty database: there is no copy tool in this version.

A server that used MySQL never moves to SQLite on its own: when config.yml asks for SQLite (or no longer says which database to use), AdminControl stays without a database and says so in the console, because a misread file would split the server off its network. To move it to SQLite on purpose (it starts empty), delete plugins/AdminControl/database-type and restart.

Some managed MySQL hosts (DigitalOcean, for one) turn on sql_require_primary_key. AdminControl turns it off for its own session while it creates its tables. If the host forbids even that, the server's log says so at start and nothing is created: set sql_require_primary_key to OFF for this database in the host's panel, or give the database user SESSION_VARIABLES_ADMIN, and restart.

Several servers, one database

Point every server at the same MySQL database. Punishments, players, the team, roles and settings are shared. A punishment given on one server is applied on the others within about 2 seconds (a ban or kick takes the player off the server they are on, a mute starts there); behind a Velocity proxy see Velocity network. The panel of any server shows the whole network: the servers, the players online on each, the reports of all servers and the statistics of each server, and its console, chat and announcements reach every server (see Network panel); give each server its own server-name. A change of the settings or the announcements made on one server reaches the others within a minute.

Tasks the panel sends to another server (a command, a chat message, clearing the chat, an announcement) wait in ac_server_tasks and are removed after a day. The console lines of a server that a panel watches stay in ac_console_lines for 10 minutes at most.

When the database is down

The server keeps running and the panel shows that the database is unavailable. Until it is back:

• joining players are checked against the bans kept in memory (read in full every 5 minutes): a banned player is refused, anyone else gets in, and the console logs checked against the in-memory list. Only when the list was never read (the database has been down since the server started) do players join without a ban check, and the console logs joins without a ban check for each of them;
• mutes stay enforced from the same list in memory;
• punishments cannot be given or lifted.

If the database cannot be reached when the server starts, AdminControl tries again every 30 seconds. If it goes down later, the connection comes back on its own once the database is up; a MySQL query that gets no answer for 2 minutes is given up, so a connection that died on the way does not hold AdminControl up. Keep the database on a reliable host, or use SQLite, if the ban check must never be skipped.