L2 Server Database Setup: MySQL y MariaDB bien hechos

Una l2 server database setup limpia es la diferencia entre un mundo que sobrevive a un reinicio y otro que pierde cuentas, objetos y datos de clan. La base guarda todo el estado persistente de jugadores y mundo: cuentas, personajes, inventario, clanes, castillos y logs. Los NPC, los spawns y las plantillas de objetos viven en el datapack. El game server se puede reconstruir desde el código en una tarde, pero un esquema corrupto o a medio instalar te cuesta los jugadores. Esta guía cubre la elección de motor, una instalación segura, la carga del esquema L2J, los ajustes que de verdad importan y los fallos que aparecen por el camino.

MariaDB o MySQL: elige uno y ajústalo al pack

L2J es compatible con MySQL 8.0 y superior, pero el proyecto recomienda MariaDB. El esquema de L2J funciona en ambos, los dos trabajan con un driver JDBC y ambos sirven en producción si se configuran con cuidado. Por dentro no son idénticos, así que elige uno, usa el conector que trae tu pack y no instales un segundo motor porque un tutorial usara el otro.

Comprueba qué driver incluye tu pack antes de instalar nada. Un pack hecho para un conector puede conectarse al otro motor en muchos casos, pero la sintaxis de la URL y algunos valores por defecto cambian. Adivinar aquí produce errores de conexión que parecen problemas de contraseña.

Instala y asegura el motor

En Windows, el instalador de MariaDB o MySQL crea el servicio, el directorio de datos y la cuenta root. En Debian o Ubuntu, el paquete hace lo mismo y arranca el servicio. En ambos casos, ejecuta el paso de instalación segura justo después de una instalación limpia.

• Pon una contraseña de root que no reutilices en ningún otro sitio.
• Elimina los usuarios anónimos y la base de datos de prueba.
• Prohíbe el login remoto de root.
• Recarga las tablas de privilegios para que los cambios se apliquen al momento.

En muchos paquetes de Linux, la cuenta root se autentica por el socket local en vez de por contraseña. Es una función de seguridad, no un fallo. Significa que la línea de comandos funciona y que una conexión remota de root no, y explica el primer momento de confusión con "access denied" que sufre todo administrador nuevo.

Mantén el servidor atado a localhost. Si el game server corre en la misma máquina, no hay motivo para que el puerto 3306 responda a internet, y los escáneres automáticos encuentran puertos de base de datos expuestos enseguida.

Crea el usuario y la base de datos

No ejecutes el game server como root. Crea una cuenta dedicada, dale exactamente lo que necesita y usa una contraseña lo bastante larga para que no se adivine. Una configuración mínima se ve así:

1. Crea la base de datos, por ejemplo l2jdb.
2. Crea un usuario como l2j, restringido a localhost cuando el servidor es local.
3. Concede privilegios solo sobre esa base, no sobre todo.
4. Recarga privilegios y prueba el login desde la línea de comandos.

Algunos tutoriales dan al usuario permisos totales con un host comodín. Es cómodo para una máquina de pruebas temporal y un mal hábito para un servidor en vivo. Si la base está en otra máquina, limita el host a esa dirección privada y filtra el puerto entre los dos hosts.

Carga el esquema de L2J

El L2J moderno incluye una CLI que instala los archivos SQL por ti, también las tablas custom y de mods. Los packs antiguos esperan que importes a mano los SQL de login y game con phpMyAdmin, HeidiSQL o la línea de comandos. Ambos métodos funcionan, pero el orden importa.

1. Instala primero el esquema de login y después el de game.
2. Usa el modo de instalación completa en una base nueva, no el modo de actualización.
3. Confirma el número de tablas en vez de confiar en la barra de progreso.
4. Comprueba que existen tanto la tabla de cuentas como las de personajes.

Si el game server arranca pero el login server rechaza conexiones, un esquema a medio instalar es una de las primeras cosas que revisar. Los dos servicios usan tablas distintas, y un conjunto incompleto rompe solo una parte del stack.

Apunta el servidor a la base de datos

Los datos de conexión están en la carpeta de configuración del login server y otra vez en la del game server. Son archivos separados, y ambos necesitan el mismo host, puerto, nombre de base, usuario y contraseña. Editar uno y olvidar el otro es el error de configuración más común.

Después de un cambio, reinicia ambos servicios en orden: base de datos, login server y game server. El game server se registra con el login server, así que arrancarlos al revés puede dejar el mundo fuera de la lista hasta que el game server se reconecte, aunque los dos procesos estén corriendo.

Ajustes que de verdad importan

Los valores por defecto están pensados para instalaciones pequeñas de prueba. En un servidor vivo, unos pocos valores hacen casi todo el trabajo:

• Buffer pool: da a InnoDB una parte grande de la RAM en un host dedicado solo a la base, normalmente entre la mitad y dos tercios. Cachea datos e índices, y un buffer frío es la razón habitual de que los primeros minutos tras un reinicio se sientan lentos.
• Conexiones: sube el límite por encima del tamaño del pool de tu pack, con margen para herramientas de administración y backups.
• Durabilidad frente a velocidad: el ajuste de volcado del log cambia un pequeño riesgo de perder el último segundo de commits por escrituras más rápidas. Mantén el valor seguro en una economía viva salvo que entiendas el intercambio.
• Resolución de nombres: desactivar las búsquedas DNS inversas con skip_name_resolve acelera las conexiones, pero MySQL pasa a comparar los permisos por dirección IP en vez de por nombre de host. Si lo activas, crea el usuario para la IP del cliente o para localhost cuando la conexión use el socket.
• Charset: conserva el charset que trae el pack. Convertir una base viva a otra colación es una migración, no una casilla.

Cambia un ajuste cada vez y reinicia limpiamente. Dos cambios a la vez no enseñan nada cuando el rendimiento mejora o empeora.

Backups y pruebas de restauración

Un backup que nunca has restaurado es una esperanza, no un backup. Haz un dump lógico con una instantánea consistente, comprímelo y cópialo fuera de la máquina con una periodicidad fija.

• Vuelca toda la base, no solo las tablas de personajes.
• Incluye rutinas y triggers si tu pack los usa.
• Guarda varios días de dumps y al menos una copia en otro almacenamiento.
• Restaura en una base de pruebas una vez al mes y comprueba un login de personaje.

Antes de cada parche o migración, haz un dump manual y etiquétalo con la versión. El plan automático te protege de un fallo de hardware, pero la instantánea manual es la que te salva de tu propia actualización.

Errores comunes y qué significan

Una base de datos en la que confiar

Mantenla pequeña y aburrida: un motor, un usuario dedicado, un esquema instalado completo, un puerto solo local y un plan de dumps probado. Esa configuración no gana discusiones de arquitectura, pero mantiene tu mundo en pie entre parches, caídas y alguna mala noche.

Cuando el servidor esté estable, el siguiente problema son los jugadores. Publica tu mundo con el formulario de listado gratuito o usa el posicionamiento VIP para destacar en el directorio de servidores.