Metin2 Server Yedekleme ve Geri Yükleme

Metin2 sunucusunda yedeklenmesi gerekenler account, common ve player veritabanları, ihtiyaca göre log veritabanı ve srv1 altındaki sunucu dosyalarıdır. Asıl incelik zamanlamadadır: db çekirdeği karakter ve eşya değişikliklerini anında değil aralıklarla MySQL'e yazar, bu yüzden oyun açıkken alınan bir döküm oyunun o anki hâlini değil son kaydı içerir. Tam tutarlı yedek sunucu düzgün kapatıldıktan sonra alınır; her yedek şifrelenip başka bir yerde saklanır ve geri yüklenerek denenir.

Kayıt aralıkları ve kayıp hesapları db ve oyun çekirdeğinin kaynak kodundan, betik örnekleri paketin baks klasöründen alındı; conf.txt'de kayıt sürelerini değiştiren sunucularda süreler farklıdır.

Hangi veritabanları ve dosyalar yedeklenir?

Üç ayrıntı sık atlanır. Paketteki conf.txt'de PROTO_FROM_DB = 0 ve MIRROR2DB = 1 olduğu için MySQL'deki item_proto ve mob_proto yalnız bir yansıdır; asıl kaynak db klasöründeki txt dosyalarıdır (Metin2 veritabanları). Lonca amblemleri veritabanında değil, chan/mark klasöründe mark_index ve .tga dosyaları olarak durur (lonca amblemi). mob_exp gibi oran bayrakları player'daki quest tablosunda, krallık bonusları common'da tutulur; eski bir yedeği geri yüklemek oranları da o günkü hâline döndürür (oranlar ayarı).

Oyun açıkken alınan yedek neyi içerir?

db çekirdeği değişen bir karakter satırını, son yazmadan bu yana 420 saniye geçince; eşyaları 300, pazar fiyat hafızasını 540 saniye geçince MySQL'e yazar. Quest bayraklarını ve etkileri ise kendisine ulaştığı anda yazar. Oyun açıkken alınan döküm bu yüzden, db çekirdeği o anda çökseydi MySQL'de kalacak olan durumdur: karakterler en fazla yaklaşık 7, eşyalar 5 dakika geriden gelir ve aynı dökümde birbirinden farklı anlara ait satırlar bulunabilir. Süreler conf.txt'den değişir (db conf.txt).

Tablolar MyISAM olduğu için mysqldump seçenekleri de önemlidir:

• --single-transaction yalnız InnoDB tablolarında tutarlı döküm verir; MyISAM tabloları döküm sırasında değişmeye devam edebilir.
• Varsayılan --lock-tables her veritabanını ayrı kilitler; account ile player arasında tutarlılık sağlamaz.
• --lock-all-tables döküm boyunca genel okuma kilidi tutar. Tutarlıdır, ama döküm bitene kadar yazmalar bekler.

Kilitli bir döküm sürerken db çekirdeğinin olağan kayıtları kuyrukta bekler ve oyun sürer. Karakter açma ve silme gibi db'nin yanıtını beklediği yazmalar ise kilit kalkana kadar db çekirdeğinin bütün işini durdurur; girişler ve ışınlanmalar da bu sürede takılır. Sıcak dökümü en sakin saate koy, büyük log veritabanını oyun açıkken kilitle dökme.

Tutarlı (soğuk) yedek nasıl alınır?

Sunucu kapatılır, db önbelleği MySQL'e yazılır, sonra döküm alınır. İkinci adıma geçmeden db syslog'unda MainLoop exited, Starting cache flushing satırını ve db sürecinin çıktığını gör:

sh admin_panel.sh 2     # stop.py: önce oyun çekirdekleri, en son db
for vt in account common player; do
  mysqldump --defaults-extra-file=/home/yedek/.my.cnf --no-tablespaces $vt \
    | gzip -9 > /yedek/${vt}_$(date +%Y%m%d-%H%M).sql.gz
done
sh admin_panel.sh 1     # yeniden başlat

Parola komut satırına değil, yalnız yedek kullanıcısının okuyabildiği (600 izinli) bir seçenek dosyasına yazılır; komut satırındaki parola aynı makinedeki süreç listesinde görünebilir. Yedek için root yerine ayrı bir kullanıcı aç:

CREATE USER 'yedek'@'localhost' IDENTIFIED BY 'GucluBirParola';
GRANT SELECT, LOCK TABLES ON account.* TO 'yedek'@'localhost';
GRANT SELECT, LOCK TABLES ON common.* TO 'yedek'@'localhost';
GRANT SELECT, LOCK TABLES ON player.* TO 'yedek'@'localhost';
GRANT SELECT, LOCK TABLES ON log.* TO 'yedek'@'localhost';
GRANT RELOAD ON *.* TO 'yedek'@'localhost';  -- yalnız --lock-all-tables için

Kapatma sırası ve önbelleğin neden zorla kapatmayla kaybolduğu server kurulumu yazısında.

Paketteki yedek betiğinin tuzakları

sh admin_panel.sh 4 ve baks/db/Makefile kullanılacaksa şunları bilmek gerekir (klasörün yeri server dosyaları yazısında):

• Veritabanları ayrı ayrı ve oyun açıkken dökülür; yukarıdaki iki tutarlılık sorunu birlikte gelir.
• log veritabanının yalnız yapısı alınır (--no-data), hotbackup hiç alınmaz.
• Komut mysqldump ... | gzip -9 > dosya 2>> log.txt biçimindedir. Hata yönlendirmesi gzip'e bağlı olduğu için mysqldump başarısız olsa da küçük bir .gz dosyası oluşur ve hata log.txt'ye düşmez. Her dökümün son satırı -- Dump completed on ... olmalıdır; bu satırı ve dosya boyutunu kontrol et.
• recovery hedefi tarihsiz dosya adları bekler ve log'u yapı dökümünden yükler. mysqldump varsayılan olarak her tablodan önce DROP TABLE yazdığı için bu adım mevcut log kayıtlarını siler.
• wclean 7 günden eski yedekleri siler; geç fark edilen bir bozulmada temiz yedek kalmayabilir.
• MySQL root kullanıcısı ve parolası Makefile'da düz metin, komut satırında kullanılır.
• baks/fs yedeği önce clear.py'yi çalıştırır; her yedekte syslog, syserr, taşınmış eski günlükler ve usage.txt silinir, srv1 de çalışırken arşivlenir.

Zamanlama, saklama ve şifreleme

Aşağıdaki düzen bir örnektir; süreleri oyuncu sayına ve disk alanına göre seç:

Güncellemeden önce hangi dosyaların saklanacağı server güncelleme yazısında. En az bir kopya sunucunun ve barındırma firmasının dışında durmalıdır; disk arızası ya da kapanan bir hesap aynı makinedeki yedekleri de götürür.

Yedekler hassastır: account her hesabın parola özetini, silme kodunu ve e-postasını tutar, log IP adreslerini. Parola özeti tuzsuzdur, yani aynı parola her hesapta aynı özeti verir. Dökümü sıkıştırdıktan sonra bir açık anahtarla şifrele; özel anahtar sunucuda durmasın:

... | gzip -9 | gpg --encrypt --recipient YEDEK_ANAHTARI --output /yedek/player_$(date +%F).sql.gz.gpg

Yedek klasörünü yalnız yedek kullanıcısı okuyabilsin ve web sitesinin klasöründe durmasın.

Çökme anında neler kaybolur?

Bozuk işaretlenmiş bir tabloya giden sorguyu çekirdekler bırakmaz, syserr'e AsyncSQL: retrying yazarak tekrar tekrar dener. Elektrik kesintisinden sonra bu satırları görüyorsan önce tabloları onar.

Kaybolan veri, çekirdeklerin yeniden bağlanmasıyla geri gelmez. Geri alma mı yapılacağı, tazminat mı verileceği önceden yazılmış bir kurala göre seçilir (açılış planı).

Geri yükleme provası nasıl yapılır?

1. Ayrı bir makine ya da ayrı bir MySQL örneği kullan; provayı canlı veritabanında yapma.
2. Paketin sql/base dosyalarıyla beş veritabanını ve çekirdek kullanıcısını oluştur. Dökümler MySQL kullanıcılarını içermez; hotbackup boş da olsa bulunmalıdır, yoksa db çekirdeği açılmaz.
3. Dökümleri yükle: gunzip < player_TARIH.sql.gz | mysql player. Dökümü olduğu gibi yükle, araya karakter kümesini dönüştüren bir araç koyma.
4. Test kopyasının conf.txt ve CONFIG dosyalarını test veritabanına ve farklı portlara yönelt. Test kopyası canlı MySQL'e bağlanırsa iki db çekirdeği aynı tabloları birbirinin üstüne yazar.
5. Çekirdekleri aç; db'nin syserr'i temiz olmalı.
6. Test hesaplarıyla gir: karakter listesi, envanter, depo, Nesne Market deposu, lonca ve amblem.
7. SELECT COUNT(*) ile account, player ve item tablolarının satır sayılarını canlıdakiyle karşılaştır.
8. Geri yüklemenin ne kadar sürdüğünü not et; gerçek bir kesintide oyunculara söyleyeceğin süre budur.

Kısmi geri yükleme ve silinen karakter

Tek bir oyuncunun verisi için bütün sunucuyu geri alma. Yedeği ayrı bir adla açılan veritabanına yükle ve gereken satırları sunucu kapalıyken aktar. Sunucu açıkken aktarırsan, oyuncu çevrimiçiyse ya da çıkışından sonraki 10 dakika içindeyse db önbelleği aktardığın satırları ezer.

Silinen bir karakterde player_deleted yalnız karakter satırını tutar; envanter, ekipman, simya ve kemer eşyaları, quest bayrakları, etkiler ve lonca üyeliği silinir (karakter silme). Bunlar ancak silmeden önceki bir yedekte vardır.

Farklı anlara ait parçaları karıştırırken bağları unutma: depo ve Nesne Market deposu eşyaları hesap numarasına bağlıdır; bakiye (cash) account'ta, dışarıdan gönderilen eşyalar player'daki item_award'da durur. Yalnız player'ı geri alırsan yedekten sonra açılan hesaplar korunur, ama o arada harcanan bakiye geri gelmez.