O banco de dados é uma das partes mais críticas de um servidor Tibia OTServ. É nele que ficam contas, personagens, inventários, houses, guilds, deaths, bans, storages, VIPs, shops e várias informações usadas pelo site. Se o banco falha, o servidor pode até ficar online, mas jogadores não conseguem logar, itens somem, saves quebram e a administração perde controle. Em VPS, configurar MySQL ou MariaDB corretamente é essencial para estabilidade e segurança.
MySQL ou MariaDB
As duas opções são comuns em OTServ. MariaDB costuma ser leve e muito usado em ambientes Linux. MySQL tem ampla documentação e compatibilidade. O ponto principal é usar uma versão compatível com a sua base, com codificação correta, usuário próprio e backup frequente. Não escolha apenas por costume; veja a recomendação da distro, da source e do site usado, como Gesior, MyAAC ou outro AAC.
Criando database e usuário
Evite usar o usuário root do banco dentro do config do servidor. Crie um database exclusivo para o OTServ e um usuário com permissão apenas nesse database. Isso reduz danos caso algum arquivo de configuração vaze. Use senha forte, sem repetir senha da VPS ou do painel financeiro. Poucas pessoas devem ter acesso direto ao banco em produção.
CREATE DATABASE tibia;
CREATE USER 'tibia_user'@'localhost' IDENTIFIED BY 'senha_forte';
GRANT ALL PRIVILEGES ON tibia.* TO 'tibia_user'@'localhost';
FLUSH PRIVILEGES;Importando schema
A maioria das bases vem com um arquivo SQL inicial. Esse arquivo cria tabelas como accounts, players, player_items, guilds, houses e bans. Importe no database correto antes de iniciar o servidor. Se você importar no banco errado, o executável pode abrir, mas o login falhará. Se importar duas vezes, pode gerar duplicidade ou erro de tabela existente. Em servidor em produção, nunca rode SQL de update sem backup.
Config no servidor e no site
O OTServ e o site precisam apontar para o mesmo banco, mas com permissões bem pensadas. O arquivo de configuração do servidor geralmente define host, usuário, senha, database e porta. O site também terá seu arquivo próprio. Se um dos dois aponta para outro banco, o jogador cria conta no site e não consegue logar no jogo, ou o jogo salva personagem que o site não mostra.
Codificação e caracteres
Use codificação adequada para evitar problemas com nomes, acentos e textos. Muitos projetos usam utf8 ou utf8mb4. Evite misturar collations sem necessidade. Se nomes aparecem quebrados no site, ou queries falham com caracteres especiais, revise charset do database, tabelas e conexão.
Performance do banco
Com muitos jogadores, tabelas de items, deaths, logs e shop podem crescer muito. Disco NVMe ajuda, mas não resolve query ruim ou tabela gigante sem manutenção. Monitore tamanho do banco, faça limpeza controlada de logs antigos e revise índices quando houver lentidão. Evite scripts que gravam dados em excesso a cada segundo.
Segurança
Não exponha MySQL para a internet sem restrição. Se banco e servidor estão na mesma VPS, use localhost. Se o banco está em outra máquina, libere apenas o IP do servidor. Nunca publique dumps em links públicos. Dumps contêm contas, hashes, históricos e dados importantes do projeto.
Conclusão
MySQL ou MariaDB bem configurado é a base de um OTServ confiável. Use database próprio, usuário limitado, schema correto, backup antes de updates e monitoramento. Em VPS, você tem liberdade para ajustar tudo, mas também precisa proteger credenciais e testar restauração. Banco saudável significa menos perda de dados e menos crises com jogadores.
