CoreProtect, Database Migration to MySQL

Why Migrate CoreProtect to MySQL

CoreProtect ships with SQLite as its default database engine. For small servers with fewer than 20 concurrent players, SQLite works fine. Once your server grows, the single-file database starts causing problems: lookup commands lag, rollbacks take longer, and the database file can balloon past several gigabytes. A coreprotect mysql migration moves all that data into a proper database server that handles concurrent reads and writes far more efficiently.

MySQL (or MariaDB) stores data in a structured, indexed format that scales with your server. Lookups that took 10 seconds on SQLite often finish in under a second on MySQL, especially when you have millions of logged blocks. If you have already considered switching your other plugins to MySQL, see our general SQLite to MySQL migration guide for the broader picture.

Prerequisites

• A running MySQL 8.0+ or MariaDB 10.6+ instance (local or remote)
• CoreProtect 22.4 or newer installed on your Paper/Spigot server
• Root or admin access to your MySQL server to create databases and users
• A recent backup of your server files

Step 1: Create the MySQL Database and User

Log into your MySQL instance and create a dedicated database for CoreProtect:

mysql -u root -p

CREATE DATABASE coreprotect CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'coreprotect'@'localhost' IDENTIFIED BY 'strong_password_here';
GRANT ALL PRIVILEGES ON coreprotect.* TO 'coreprotect'@'localhost';
FLUSH PRIVILEGES;

If your MySQL server runs on a different machine than your Minecraft server, replace 'localhost' with the Minecraft server's IP address or use '%' for any host (less secure, use with caution).

Step 2: Update CoreProtect config.yml

Stop your Minecraft server, then open plugins/CoreProtect/config.yml. Change the database section from SQLite to MySQL:

# config.yml (CoreProtect)
use-mysql: true
table-prefix: co_
mysql-host: localhost
mysql-port: 3306
mysql-database: coreprotect
mysql-username: coreprotect
mysql-password: strong_password_here

The table-prefix keeps CoreProtect tables organized if you share the database with other plugins. A coreprotect mysql migration only requires these six lines to switch engines.

Step 3: Migrate Existing Data

CoreProtect does not automatically transfer SQLite data to MySQL when you flip the config. Your existing rollback history will be lost unless you export it. The community tool coreprotect-migrate handles this, or you can use a Python script to dump the SQLite data and import it:

# Export SQLite tables to SQL dump
sqlite3 plugins/CoreProtect/database.db .dump > coreprotect_dump.sql

# Clean up SQLite-specific syntax for MySQL compatibility
sed -i 's/INTEGER PRIMARY KEY AUTOINCREMENT/INT AUTO_INCREMENT PRIMARY KEY/g' coreprotect_dump.sql
sed -i 's/PRAGMA.*;//g' coreprotect_dump.sql
sed -i '/^BEGIN TRANSACTION/d; /^COMMIT/d' coreprotect_dump.sql

# Import into MySQL
mysql -u coreprotect -p coreprotect < coreprotect_dump.sql

This process can take several minutes for large databases. Do not start the Minecraft server until the import finishes.

Step 4: Verify and Start

Start your server and run a CoreProtect lookup to confirm the migration worked:

/co lookup t:1h r:10

If the lookup returns results, your migration is complete. Check the server console for any connection errors. Common issues include wrong credentials, MySQL not allowing remote connections, or the firewall blocking port 3306.

Performance Tuning

After migrating, tweak your MySQL configuration for CoreProtect's write-heavy workload:

# /etc/mysql/conf.d/coreprotect.cnf
[mysqld]
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
innodb_flush_log_at_trx_commit = 2
max_connections = 50

Setting innodb_flush_log_at_trx_commit to 2 reduces disk I/O significantly. You lose at most one second of data on a MySQL crash, which is acceptable for block logging. For detailed rollback workflows after migration, check the CoreProtect rollback guide.

Backup the Old SQLite Database

After confirming the MySQL migration works, keep a copy of the original database.db file for at least 30 days. If anything goes wrong with the new setup, you can revert by setting use-mysql: false in CoreProtect's config and restarting. Having the old database on hand makes rollback painless.

Summary

A coreprotect mysql migration takes about 15 minutes of active work and dramatically improves lookup and rollback performance on busy servers. Create the database, update six config lines, transfer your old data, and verify with a test lookup. Once running on MySQL, CoreProtect handles millions of records without breaking a sweat.

See it live: Astroworld MC, IP play.astroworldmc.com, Java + Bedrock.