How the Metin2 DB Cache Architecture Works

The layer that actually manages player data on a Metin2 server is not the game core, as many assume, but the metin2 db cache process. When you move a character, pick up an item, or finish a quest, none of those actions go straight to MySQL. They first pass through an in-memory cache layer. In this article I walk through how the db process holds player data, when it writes to disk, and why this architecture is so widely used.

The multi-process Metin2 architecture

A classic Metin2 server is not a single program. It consists of at least three separate processes, each with its own job:

• auth — Handles login and account verification. It checks the username and password and issues a session key.
• db — The single gateway for all MySQL traffic. It loads player data into memory, caches it, and writes it back to the database periodically.
• game / core — The game itself. Movement, combat, quests, NPCs, and map logic run here. Larger servers run several core processes (channels).

The key point: the game cores never talk to MySQL directly. Every read and write request is sent to the db process over a custom TCP protocol. The db process answers those requests, queries MySQL when needed, and most of the time replies from the copy it already holds in memory.

Why does the db cache exist?

This extra layer might look like needless complexity at first. Its purpose, however, is very concrete: to shield MySQL from constant queries. Consider position, health, experience, and inventory data that hundreds of players change dozens of times per second. Writing every single change to the database immediately would be a load that the disk and InnoDB simply could not handle.

The db cache solves this as follows:

• When a player logs in, all of their data (character, inventory, quests, affects, safebox) is read from MySQL once and kept in memory.
• All in-game changes are made on this memory copy first — they do not hit the disk.
• Writes to the database are batched and performed at fixed intervals, plus on player logout.

The result: the number of writes reaching MySQL drops by thousands of times, while in-game operations respond at memory speed.

How is player data loaded into memory?

When a player selects a character, the db process gathers all of that character's data from the relevant tables. In Metin2, player data does not live in a single table; it is logically split:

• player — the base character (level, experience, location, stats)
• item — inventory, safebox, and equipped items
• quest — quest state and flags
• affect — active buff/debuff effects
• safebox and mall — storage and mall vault

These rows are merged in memory into a cache object tied to the character. As long as the player stays online, this object lives on; for every data query, the core consults this object instead of MySQL.

When is data written to disk?

The save logic is the most critical part of this architecture, because most player losses (item dupes, rollbacks, vanished items) originate here. Data is written to MySQL in three situations:

• Periodic save: at fixed intervals the db process scans the "dirty" (changed) records in memory and writes them to MySQL as UPDATE statements. This interval depends on configuration; it is typically a delay window of a few seconds.
• Save on logout: when a player leaves the game or the connection drops, all of that character's data is written to disk immediately and dropped from the cache.
• Immediate save on critical events: for sensitive operations such as creating currency or vault transactions, data may be written without waiting.

This is exactly why, if a server crashes unexpectedly (kill -9, hardware failure, OOM), all changes after the last periodic save are lost — which is why players experience a "rollback." The architecture's speed advantage is at the same time its biggest point of risk.

Communication between core and db

The conversation between the game core and db runs over a packet-based custom protocol. A core sends a packet like "load this player's data" or "update this item," the db process queues it, processes it, and sends the answer back. This structure ensures consistency from a single authoritative source (db) when several core processes share the same player pool.

On the configuration side the connection is usually set up with lines like these:

PLAYER_SQL: localhost player root password
COMMON_SQL: localhost common root password

# address of the db process on the core side
db_addr: 127.0.0.1
db_port: 15000

Here you see two separate databases: player (player-specific, constantly changing data) and common (read-only definition tables such as item_proto and mob_proto). The common data rarely changes, so it is heavily cached; the player data is what the db cache actually manages.

Tips for good db cache management

• Keep the save interval balanced: too long an interval raises rollback risk, too short an interval tires MySQL. Tune it to your server load.
• Monitor the db process: if db crashes, no data can be saved even if the game cores stay up. Always monitor process health.
• Use InnoDB: prefer InnoDB over MyISAM for player tables; it makes a difference for post-crash consistency and concurrent writes.
• Take backups: a regular mysqldump backup is the only safe way to offset the inevitable data loss within the periodic save window.

Frequently Asked Questions

Is player data lost if the db cache crashes?

All changes accumulated after the last periodic save are lost. If the db process shuts down cleanly (graceful shutdown), it flushes the in-memory data to disk; on a sudden crash (kill -9) only the data up to the last save point is safe.

Why doesn't the core connect to MySQL directly?

For performance and consistency. A single db process both batches the write load to protect MySQL and acts as the one authoritative data source across multiple cores, preventing data conflicts.

What is the difference between the player and common databases?

player holds the constantly changing data that belongs to the player (character, items, quests) and is managed by the db cache. common contains rarely changing definition tables such as item_proto and mob_proto and is mostly read.

Are you facing data loss, rollbacks, or performance problems on your Metin2 server? Let's review your db cache configuration and database architecture together. Get in touch with me.