If your private server for Metin2 — the MMORPG published by Gameforge 4D GmbH — still runs MariaDB 10.6, the clock has run out. According to the MariaDB Foundation's announcement, 10.6 reached its Community end of life on July 6, 2026, which means no more bug fixes, no more security fixes, and no more corrective releases for that branch. MariaDB 10.11, the next long-term-support series, is listed for maintenance until February 16, 2028 — roughly 19 additional months of coverage.
For a game server that stores account credentials, item data, and payment-adjacent records, running an unmaintained database is not a neutral choice. This article walks through the upgrade-versus-hold decision, the supported upgrade path, a Metin2-specific staging checklist, and why your rollback plan should be a logical dump rather than an in-place downgrade.
The support gap in concrete terms
| Series | Community support status (per mariadb.org) |
|---|---|
| MariaDB 10.6 | EOL July 6, 2026 — no further bug fixes, security fixes, or corrective releases |
| MariaDB 10.11 | Maintained until February 16, 2028 |
The practical consequence: any InnoDB bug, authentication vulnerability, or replication defect discovered in 10.6 after its EOL date will likely only be fixed in newer series. A Metin2 database is exposed through auth, game, and db cores that accept traffic from untrusted clients, so unpatched database bugs are a real attack surface, not a theoretical one.
Upgrade now or hold?
Our recommendation: upgrade production servers unless a staging test exposes a Metin2-specific incompatibility. Here is how the two options compare:
| Factor | Upgrade to 10.11 now | Hold on 10.6 |
|---|---|---|
| Remaining community security support | Until 2028-02-16 (~19 months more than 10.6) | None — EOL passed 2026-07-06 |
| Maintenance window | One planned window: backup, package swap, mariadb-upgrade, smoke tests. Measure the actual duration on your staging clone before scheduling production | None today, but risk of an unplanned emergency window later |
| Rollback complexity | Moderate — requires a verified logical dump taken before the upgrade | Not applicable until you eventually upgrade, when the same work is still required |
| Testing required | Full staging pass against a cloned database | None now, but the debt compounds: the eventual jump spans more versions |
Holding is only defensible as a short-term measure while you build and test a migration plan — not as a destination.
The supported 10.6 → 10.11 procedure
MariaDB's official upgrade guide states that on most servers upgrading from 10.6 should be painless, and the supported sequence is short:
- Back up everything first. Take a logical dump (mariadb-dump --all-databases --routines --events) and verify you can restore it somewhere else. Also snapshot your my.cnf.
- Stop MariaDB cleanly. Shut down your game, db, and auth cores first so no writes are in flight, then stop the database service.
- Replace the packages. Update your repository configuration for 10.11, uninstall the 10.6 packages, and install 10.11 using your platform's package manager.
- Review your my.cnf. The official guide documents options that were removed (such as innodb_log_write_ahead_size and wsrep_replicate_myisam) or had their defaults changed between the series; a removed option in your config can prevent 10.11 from starting at all.
- Start 10.11 and run mariadb-upgrade. This updates the system tables to the new version's expectations.
Metin2-specific staging checklist
Generic upgrade guides stop at "the server starts." A Metin2 server has its own failure surface because private-server forks ship different schemas, MySQL connectors, and source patches. Whether your particular server-file release works unchanged on 10.11 cannot be assumed — it has to be tested. Clone your production databases into a staging instance running 10.11 and verify, at minimum:
- Account authentication — the auth core connects and validates a login against the account database.
- Login and account queries — character select loads the correct character list and metadata.
- Player and item persistence — log in, move items, log out, and confirm the player and item tables reflect the changes after a core restart.
- Guild data — guild rosters, ranks, and guild land records load correctly.
- Safebox access — open, deposit, withdraw, and re-open the safebox.
- Locale tables — localized strings and quest-related lookups resolve without collation or encoding errors.
- Every core against the clone — start each game core, the db core, and auth against the 10.11 clone and watch the syslog/sysser output for failed SQL queries, not just crashes. Older cores built against legacy MySQL client libraries are a common source of silent query failures.
Why rollback means "restore a dump," not "downgrade in place"
MariaDB's documentation is explicit that downgrading is not officially supported between major versions: the privilege and status tables in the mysql schema change between most major versions, and storage-engine on-disk formats can change in ways that an older server cannot read. Once mariadb-upgrade has run against your data directory, treat the pre-upgrade state as unreachable except through your backup.
That is why the logical dump in step 1 is the actual rollback plan. A rollback-safe migration looks like this: dump, verify the dump restores cleanly on a scratch instance, upgrade, test — and if testing fails, reinstall 10.6 packages and restore the verified dump into a fresh data directory. Never plan to point old binaries at an upgraded data directory and hope.
Build-specific compatibility: test, don't trust
Build-specific claims — "server files X work on 10.11 unchanged" — are worthless without test records. If you rely on one, demand the evidence behind it: the exact MariaDB builds tested (from and to), storage engines in use, database size, mariadb-upgrade duration, core startup result, login result, and any failed SQL queries with their error output. We make no build-specific compatibility claims here, and you should treat any forum post that does — without logs — with suspicion. For ongoing results and related server-administration reporting, you can follow sourced Metin2 coverage on TOP OF GAMES.
Bottom line
MariaDB 10.6 is past community EOL; 10.11 buys you support into 2028 via a short, well-documented upgrade path. Take a verified logical dump, rehearse the upgrade on a clone, run the Metin2-specific checklist above, and schedule the production window once staging is clean. The only good reason to stay on 10.6 is a reproducible incompatibility you found in staging — and even then, it is a reason to fix the incompatibility, not to keep an unpatched database under your player data.