Metin2 log Veritabanı: Hangi Kayıtlar Tutulur, Nasıl Okunur?

log veritabanı, oyun çekirdeklerinin oyunda olanları yazdığı kayıt defteridir: eşya alma, düşürme, ticaret, pazar, artı basma, girişler, GM komutları, bağırmalar ve hile şüpheleri burada tutulur. db çekirdeği bu veritabanına dokunmaz; her oyun çekirdeği CONFIG'teki LOG_SQL bağlantısıyla kendisi ve oyunu bekletmeden, sıraya alarak yazar. Ne kadarının yazılacağını DB_LOG_LEVEL ayarı belirler.

Tablolar ve hangi olayın nereye yazıldığı Metin2'nin sunucu kodundan gelir; DB_LOG_LEVEL ise sunucu ayarıdır ve sunucudan sunucuya değişebilir. Beş veritabanının genel tanıtımı Metin2 veritabanları yazısında.

DB_LOG_LEVEL: kaç kayıt tutulur?

Satır hiç yazılmamışsa değer 3'tür. Yaygın paketlerin ortak ayar dosyası GENERAL_CONFIG'de DB_LOG_LEVEL: 1 yazılıdır; bu yüzden böyle bir sunucuda hile şüphesi tabloları boş kalır. Hile incelemesi yapılacaksa GENERAL_CONFIG'teki değer en az 2'ye çekilmelidir; bu dosya çekirdeklerin kendi CONFIG'inden sonra okunduğu için oradaki satır geçerli olur. Seviye denetimi topluluk derlemelerine sonradan eklenmiştir; orijinal kod her kaydı yazar. CONFIG satırlarının listesi CONFIG ayarları yazısında.

Hangi olay hangi tabloya yazılır?

goldlog'un adı yanıltıcıdır: Yang değil, Gümüş Bar ve Altın Külçe gibi Yang külçelerinin pazar, ticaret ve görevle el değiştirmesini yazar. Yang hareketleri log tablosundadır. pcbang_loginlog, hackshield_log, vcard_log, GameTimeLog, hack_crc_log ve invalid_server_log eski bölgesel sistemlerden kalmıştır ve özel sunucularda boş durur.

log tablosu: eşya ve karakter olayları

Sık görülen olaylar:

Ticaretin ve pazarın oyundaki işleyişi güvenli ticaret yazısında.

Şikâyet ve hile incelerken nasıl kullanılır?

Log tablolarında hiç indeks yoktur; büyümüş bir log tablosunda her sorgu bütün tabloyu tarar ve dakikalar sürebilir. Bakım saatinde, yönetici kullanıcıyla bir kez indeks eklemek incelemeyi hızlandırır. MyISAM tabloyu indeks eklenirken kilitlediği için bu işlem sunucu kapalıyken yapılmalıdır:

ALTER TABLE log.log ADD INDEX idx_who_time (who, time), ADD INDEX idx_what (what);

"Eşyam kayboldu." Önce oyuncunun o eşyayla ilgili satırlarına bakılır, sonra eşyanın kimliği (what) izlenir. Kimlik eşyaya yaratıldığı anda verilir ve ticarette, pazarda ya da yere düşüp alındığında aynı kalır, bu yüzden eşyanın yolu tek sorguyla görülür. Yalnız artı basmada değişir: başarılı basmada yeni bir eşya yaratılır, eski kimliğin son satırı REMOVE (REFINE SUCCESS), yeni kimliğin ilk satırı aynı anda yazılan REFINE SUCCESS olur.

SELECT time, how, hint, ip, what FROM log.log
WHERE type = 'ITEM' AND who = 1234 AND vnum = 19
ORDER BY time DESC LIMIT 50;

SELECT time, who, how, hint FROM log.log
WHERE type = 'ITEM' AND what = 10456789 ORDER BY time;

"Dolandırıldım." İki karakter arasındaki ticaret EXCHANGE_GIVE ve EXCHANGE_TAKE satırlarında, büyük Yang aktarımları EXCHANGE_GOLD_* satırlarında görünür; ipucundaki karakter numarası karşı tarafı verir.

"Eşyam artı basarken yandı." refinelog denemeyi, basamağı ve sonucu yazar; sonuç ve şanslar yükseltme sistemi yazısındaki kurallarla karşılaştırılır.

GM'in ne yaptığı. command_log her GM komutunu karakter numarası, ad, IP ve tam komut satırıyla tutar; GM'in oluşturduğu eşyalar ayrıca log tablosunda GM olarak durur. GM yetkilerinin dağıtımı GM yapma yazısında.

Hile şüphesi. hack_log ve speed_hack oyunun şüphelendiği anları yazar ve DB_LOG_LEVEL en az 2 iken dolar. Konum eşitleme kayıtları ağ gecikmesinden de doğabilir; bir kayıt tek başına ceza gerekçesi değildir. Aynı zaman aralığındaki eşya, Yang ve giriş kayıtlarıyla birlikte değerlendirildiğinde anlam kazanır.

Kişisel veri, saklama süresi ve gizli bilgiler

Log veritabanı kişisel veri doludur. log, loginlog2, command_log, hack_log ve chat_log IP adresi tutar; shout_log bütün oyuncuların bağırmalarını, chat_log GM'lerin oyuncularla yaptığı fısıltı dahil konuşmaları saklar; hack_log hesap adlarını yazar. Türkiye'de bu tür veriler KVKK kapsamındadır: ne kadar süre tutulacağını bir saklama kuralına bağlamak, sitenin gizlilik metninde belirtmek ve erişimi yöneticilerle sınırlamak gerekir. Hesap verisinin güvenliği account tablosu yazısında.

Eski kayıtlar parça parça silinir; tek seferde milyonlarca satır silmek tabloyu uzun süre kilitler. Log tablolarında anahtar olmadığından güvenli güncelleme modu açıkken MySQL LIMIT'siz bir DELETE'e zaten izin vermez. Sorgu, etkilenen satır sayısı 0 olana kadar tekrarlanır:

DELETE FROM log.log WHERE time < DATE_SUB(NOW(), INTERVAL 90 DAY) LIMIT 100000;

Silinen satırların yeri MyISAM'da yeni kayıtlarla dolar; disk alanını hemen geri almak için bakım saatinde OPTIMIZE TABLE log.log; çalıştırılır. Tabloların kendisi düşürülmemelidir, yoksa oyun çekirdekleri o tabloya yazarken hata verir.

Gizli bilgi yalnız MySQL'de değildir. Oyun ve auth çekirdekleri, hata veren ya da yarım saniyeden uzun süren her sorguyu tam metniyle syserr ve syslog dosyalarına yazar. Auth'un giriş sorgusu hesap adını ve yazılan parolanın özetini içerdiği için bu dosyalarda parolaların özeti bulunabilir. MySQL'in kendi genel sorgu günlüğü açıksa aynı sorgular orada da birikir. Bu yüzden syserr ve syslog dosyaları forumda ya da destek isterken paylaşılmamalı, eski günlükler düzenli silinmeli ve dosyalar yalnız sunucuyu çalıştıran kullanıcı tarafından okunabilmelidir. Hata iletilerinin anlamı syserr mesajları yazısında.

Yaygın paketlerin yedek betiği log veritabanının yalnız yapısını alır, kayıtlarını almaz. Şikâyet incelemesinde gerekecek kayıtlar saklanacaksa ayrıca yedeklenmeli ve aynı saklama süresine bağlanmalıdır; yedek düzeni server yedekleme yazısında.