L2 Server Database Setup: MySQL e MariaDB bem feitos

Um l2 server database setup bem feito é a diferença entre um mundo que sobrevive a um reinício e outro que perde contas, itens e dados de clã. O banco guarda todo o estado persistente de jogadores e mundo: contas, personagens, inventário, clãs, castelos e logs. NPCs, spawns e modelos de itens ficam no datapack. O game server pode ser reconstruído a partir do código em uma tarde, mas um esquema corrompido ou pela metade custa os jogadores. Este guia cobre a escolha do motor, uma instalação segura, o carregamento do esquema L2J, os ajustes que realmente importam e as falhas que aparecem no caminho.

MariaDB ou MySQL: escolha um e combine com o pack

O L2J é compatível com MySQL 8.0 e superior, mas o projeto recomenda MariaDB. O esquema do L2J roda nos dois, ambos funcionam com um driver JDBC e os dois servem em produção quando configurados com cuidado. Por dentro não são idênticos, então escolha um, use o conector que o seu pack traz e não instale um segundo motor porque um tutorial usou o outro.

Verifique qual driver o seu pack inclui antes de instalar qualquer coisa. Um pack feito para um conector pode conectar ao outro motor em muitos casos, mas a sintaxe da URL e alguns padrões mudam. Chutar aqui gera erros de conexão que parecem problema de senha.

Instale e proteja o motor

No Windows, o instalador do MariaDB ou MySQL cria o serviço, o diretório de dados e a conta root. No Debian ou Ubuntu, o pacote faz o mesmo e inicia o serviço. Nos dois casos, rode a etapa de instalação segura logo após uma instalação limpa.

• Defina uma senha de root que você não reutilize em nenhum outro lugar.
• Remova usuários anônimos e o banco de dados de teste.
• Bloqueie o login remoto de root.
• Recarregue as tabelas de privilégios para que as mudanças valham na hora.

Em muitos pacotes Linux, a conta root se autentica pelo socket local em vez de senha. Isso é um recurso de segurança, não um defeito. Significa que a linha de comando funciona e que uma conexão remota de root não, e explica o primeiro "access denied" que confunde todo administrador novo.

Mantenha o servidor amarrado ao localhost. Se o game server roda na mesma máquina, não há motivo para a porta 3306 responder à internet, e scanners automáticos encontram portas de banco expostas rapidamente.

Crie o usuário e o banco de dados

Não rode o game server como root. Crie uma conta dedicada, dê a ela exatamente o que precisa e use uma senha longa o bastante para não ser adivinhada. Uma configuração mínima é assim:

1. Crie o banco, por exemplo l2jdb.
2. Crie um usuário como l2j, restrito a localhost quando o servidor é local.
3. Conceda privilégios apenas nesse banco, não em tudo.
4. Recarregue os privilégios e teste o login pela linha de comando.

Alguns tutoriais dão permissões totais com um host curinga. É prático em uma máquina de teste temporária e um mau hábito em um servidor ao vivo. Se o banco está em outra máquina, restrinja o host àquele endereço privado e filtre a porta entre os dois hosts.

Carregue o esquema do L2J

O L2J moderno traz uma CLI que instala os arquivos SQL para você, incluindo tabelas custom e de mods. Packs antigos esperam que você importe à mão os SQL de login e game pelo phpMyAdmin, HeidiSQL ou linha de comando. Os dois métodos funcionam, mas a ordem importa.

1. Instale primeiro o esquema de login e depois o de game.
2. Use o modo de instalação completa em um banco novo, não o modo de atualização.
3. Confirme o número de tabelas em vez de confiar na barra de progresso.
4. Verifique se existem tanto a tabela de contas quanto as de personagens.

Se o game server inicia mas o login server recusa conexões, um esquema pela metade é uma das primeiras coisas a checar. Os dois serviços usam tabelas diferentes, e um conjunto incompleto quebra só parte do stack.

Aponte o servidor para o banco

Os dados de conexão ficam na pasta de configuração do login server e de novo na do game server. São arquivos separados, e os dois precisam do mesmo host, porta, nome de banco, usuário e senha. Editar um e esquecer o outro é o erro de configuração mais comum.

Depois de uma mudança, reinicie os serviços na ordem: banco, login server e game server. O game server se registra no login server, então iniciá-los ao contrário pode deixar o mundo fora da lista até o game server reconectar, mesmo com os dois processos rodando.

Ajustes que realmente importam

Os valores padrão foram pensados para instalações pequenas de teste. Em um servidor vivo, poucos valores fazem quase todo o trabalho:

• Buffer pool: dê ao InnoDB uma boa parte da RAM em um host dedicado só ao banco, normalmente entre metade e dois terços. Ele guarda dados e índices, e um buffer frio é a razão habitual de os primeiros minutos após um reinício parecerem lentos.
• Conexões: suba o limite acima do tamanho do pool do seu pack, com margem para ferramentas de administração e backups.
• Durabilidade contra velocidade: o ajuste de gravação do log troca um pequeno risco de perder o último segundo de commits por escritas mais rápidas. Mantenha o valor seguro em uma economia viva a menos que você entenda a troca.
• Resolução de nomes: desligar as consultas DNS reversas com skip_name_resolve acelera as conexões, mas o MySQL passa a comparar permissões por endereço IP em vez de nome de host. Se ativar, crie o usuário para o IP do cliente ou para localhost quando a conexão usar o socket.
• Charset: mantenha o charset que o pack traz. Converter um banco vivo para outra collation é uma migração, não uma caixa de seleção.

Mude um ajuste por vez e reinicie de forma limpa. Duas mudanças juntas não ensinam nada quando o desempenho melhora ou piora.

Backups e testes de restauração

Um backup que você nunca restaurou é uma esperança, não um backup. Faça um dump lógico com uma captura consistente, comprima e copie para fora da máquina em um cronograma fixo.

• Exporte o banco inteiro, não só as tabelas de personagens.
• Inclua rotinas e triggers se o seu pack usar.
• Guarde vários dias de dumps e pelo menos uma cópia em outro armazenamento.
• Restaure em um banco de testes uma vez por mês e confira um login de personagem.

Antes de cada patch ou migração, faça um dump manual e etiquete com a versão. A rotina automática protege de falha de hardware, mas a captura manual é o que salva você da sua própria atualização.

Erros comuns e o que significam

Um banco de dados em que dá para confiar

Mantenha simples e sem surpresas: um motor, um usuário dedicado, um esquema instalado por inteiro, uma porta só local e um plano de dumps testado. Essa configuração não ganha discussão de arquitetura, mas mantém o seu mundo de pé entre patches, quedas e alguma noite ruim.

Quando o servidor estiver estável, o próximo problema são os jogadores. Publique o seu mundo pelo formulário de listagem gratuita ou use o posicionamento VIP para se destacar no diretório de servidores.