Çoğu kişi veritabanı taşımasını şöyle sanır: gece geç bir saatte dump al, yeni sunucuya yükle, alan adını çevir, sabah kalktığında her şey yerinde. Bu yöntem yıllarca işe yaradı çünkü siteler küçüktü ve gece gerçekten sakindi. Ama e-pin ve dijital ürün satan bir işletmede gece diye bir şey yok. Oyun içi bakiyeyi 03.40'ta yükleyen müşteri de var, sabaha karşı stok tamamlayan bayi de. Sen dump alırken yeni sipariş düşer; yükleme bittiğinde o sipariş eski veritabanında kalır ve kimse fark etmez.
Bu yazıda taşımayı bir kopyalama işi gibi değil, bir senkronizasyon işi gibi ele alacağız. Doğru kurgulandığında kullandığın e-pin satış scripti için gerçek kesinti süresi bir iki dakikaya iner, hatta tek bir sipariş kaybetmeden tamamlayabilirsin. Yanlış kurgulandığında ise haftalar sonra "ödemem düştü ama kod gelmedi" mesajlarıyla uğraşırsın. Aradaki fark birkaç teknik detay ve sıkı bir sıralama.
"Gece 03.00'te Taşırız" Cümlesi Neden Artık Çalışmıyor?
Klasik gece taşıması, kesintiyi kullanıcıya göstermeme umuduna dayanır. Oysa problem kesintinin görünmesi değil, o aralıkta yazma işlemlerinin kaybolması. E-pin işinde yazma yoğunluğu çok yüksektir: her sipariş, her bakiye hareketi, her teslim edilen kod, her bayi iskonto kaydı bir yazma işlemi. Dump aldığın andan yeni sunucunun trafiği almaya başladığı ana kadar geçen her saniye, potansiyel olarak kaybolan bir kayıt demektir.
Bu yüzden modern yaklaşım şu: dump alma ile geçiş arasındaki boşluğu kapatmaya çalışmak yerine, o boşluğu yönetmek. Ya yazmayı kontrollü biçimde durdurursun, ya da iki veritabanını kısa süre boyunca senkron tutarsın. Üçüncü bir seçenek yok; umut etmek bir strateji değil.
Bakım Moduna Almak mı, Delta Senkronu mu? Hangisi Sana Uygun?
İlk yol dürüst ve basittir: siteyi iki dakikalık bir bakım moduna alırsın, ödeme geçidi bildirimlerini kuyruğa düşürecek şekilde yapılandırırsın, son dump'ı alırsın, yükler ve açarsın. Kayıp sıfır olur, kesinti kısa ama görünür olur. Günde yüz siparişin altındaysan bu yol fazlasıyla yeterli ve en az riskli olanıdır.
İkinci yol biraz emek ister: taşımadan saatler önce büyük dump'ı yeni sunucuya alırsın, sonra sadece o andan itibaren değişen kayıtları, yani deltayı, geçiş dakikasında ikinci küçük bir dump ile aktarırsın. Bunun için tablolarının güncellenme zamanı tutan bir alana sahip olması veya işlem kayıtlarını okuyabilmen gerekir. Kesinti neredeyse sıfıra iner, karşılığında hata payı artar. Hangi yolu seçersen seç, kararı taşıma gecesi değil, bir hafta önce ver.
| Yöntem | Tahmini kesinti | Veri kaybı riski | Kime uygun |
|---|---|---|---|
| Kısa bakım modu + tek dump | 2-10 dakika | Yok | Günlük 100 siparişe kadar |
| Büyük dump + delta aktarımı | 60-120 saniye | Düşük | Yoğun ve sürekli satış |
| Replikasyon ile canlı senkron | Neredeyse yok | Çok düşük | Teknik desteği olan ekipler |
| Salt okunur mod + sonra yazma açma | 5-15 dakika | Yok | Bayi ağırlıklı yapılar |
| Plansız "gece dump'ı" | Belirsiz | Yüksek | Hiç kimseye |
DNS TTL'i Küçültmeyi Unutan Kaç Kişi Sipariş Kaybetti?
Taşımanın en sinsi tarafı şudur: alan adını yeni sunucuya yönlendirdiğinde herkes aynı anda yeni sunucuya gitmez. Eski kaydı önbelleğinde tutan sağlayıcılar bir süre daha eski veritabanına yazmaya devam eder. Yani iki veritabanın da aynı anda sipariş almaya devam eder ve sen sadece birini yeni sayarsın. Diğerine düşen siparişler sessizce kaybolur.
Çözüm basit ama zamanlaması kritik: taşımadan en az 24 saat önce alan adının TTL değerini 300 saniyeye, mümkünse 60 saniyeye düşür. Geçişten sonra eski sunucuyu hemen kapatmak yerine, oradaki uygulamayı salt okunur bakım sayfasına çevir. Böylece geç kalan ziyaretçi sipariş veremez, sadece bilgilendirilir. Kayıp yerine küçük bir rahatsızlık yaşarsın; bu çok iyi bir takas.
Taşıma sonrası ortaya çıkan sorunların kaynağı
- Geçiş penceresinde kaybolan yazmalar 40%
- Karakter seti ve zaman dilimi farkı 30%
- Ödeme bildirimi ve cron kopması 20%
- İzin ve yol yapılandırması 10%
Karakter Seti ve Zaman Dilimi: Fark Etmesi Haftalar Süren Sessiz Veri Katili
Taşıma teknik olarak sorunsuz görünür, site açılır, siparişler akar. Sonra bir gün bir müşteri adının "Gülşah" değil "GülÅah" yazıldığını görürsün. Sebep, kaynak veritabanının bir karakter setiyle, hedefin başka bir setle kurulmuş olmasıdır. Bu hata geriye dönük düzeltilebilir ama zahmetlidir, çünkü bozulma veriye yazılmıştır.
Aynı tuzak zaman diliminde de var. Yeni sunucu farklı bir saat diliminde çalışıyorsa sipariş saatleri kayar; kampanya raporları, bayi hakediş hesapları ve otomatik teslim zaman aşımları birbirine girer. Taşıma öncesi kaynak ve hedefte şu üçünü karşılaştır: veritabanı karakter seti ve karşılaştırma kuralı, sunucu saat dilimi, uygulama tarafındaki tarih ayarı. İyi yazılmış bir dijital ürün satış yazılımı bu değerleri tek yerden okur; kötü yazılmış olan her modülde ayrı varsayar.
Kritik tabloların satır sayısını bir kâğıda not et; yüklemeden sonra aynı sayıları tekrar al. İki liste birbirini tutmuyorsa geçişi ilerletme, geri dön. Bu tek kontrol, aylar sürebilecek bir veri karmaşasını baştan keser.
Ödeme Bildirimleri ve Cron'lar Geçişte Neden Kopar?
Veritabanı taşımasını düşünürken çoğu işletme sahibi yalnızca tablolara odaklanır, ama sisteme dışarıdan gelen çağrılar da taşınmalıdır. Ödeme sağlayıcıları başarılı ödemeyi sana bir bildirim adresiyle haber verir. Bu adres eski sunucuya bakıyorsa ve eski sunucu kapatılmışsa, para tahsil edilir ama sipariş hiçbir yerde tamamlanmaz. Müşteri haklı olarak sinirlenir, sen de neden olduğunu bulmak için saatler harcarsın.
Zamanlanmış görevler de aynı sepette. Otomatik teslim kuyruğu, stok uyarısı, bayi bakiye mutabakatı, kur güncellemesi; hepsi cron'a bağlıdır. Yeni sunucuda cron tanımlanmazsa site açıktır ama kalbi atmıyordur. Geçiş listene mutlaka şu üç maddeyi ekle: ödeme bildirim adreslerini güncelle, cron satırlarını birebir taşı, ilk saatte tüm görevlerin en az bir kez çalıştığını günlüklerden doğrula.
Geri Dönüş Düğmesi Olmayan Taşıma Kumardır: Rollback Planı
Her taşımanın bir geri dönüş planı olmalı ve bu plan tek cümleyle ifade edilebilmeli: "Şu saate kadar yeşil ışık almazsam, TTL kısa olduğu için alan adını eski sunucuya çeviriyorum ve o aradaki siparişleri şu dosyadan aktarıyorum." Bu cümleyi kuramıyorsan taşımaya hazır değilsin. Geri dönüşün mümkün olması için eski sunucuyu en az 72 saat silmeden bekletmen şart.
Kullandığın e-pin yazılımı taşımayı ne kadar kolaylaştırıyorsa riskin o kadar azalır. Yapılandırmanın tek dosyada toplanması, veritabanı bağlantısının ortam değişkeniyle yönetilebilmesi, lisansın alan adı değişiminde kilitlenmemesi bu işin yarısını halleder. Pinova'nın yapısını bu gözle incelemek istersen özellikler bölümüne, lisans ve destek kapsamı için fiyat tarafına bakabilirsin.
| Geçiş adımı | Zamanlama | Doğrulama ölçütü |
|---|---|---|
| TTL düşürme | Geçişten 24 saat önce | Kayıt 300 saniye veya altı |
| Hedef sunucu hazırlığı | 2 gün önce | PHP sürümü ve eklentiler eşit |
| Karakter seti eşleme | 2 gün önce | Kaynak ve hedef aynı |
| Büyük dump aktarımı | Geçişten önce | Tablo ve satır sayıları eşit |
| Bakım modu / yazma durdurma | Geçiş anı | Yeni sipariş üretilmiyor |
| Delta aktarımı | Geçiş anı | Son sipariş numarası aynı |
| Ödeme bildirim adresleri | Geçişten hemen sonra | Test ödemesi tamamlanıyor |
| Cron doğrulaması | İlk 60 dakika | Her görev günlüğe yazdı |
| Eski sunucuyu bekletme | 72 saat | Salt okunur, silinmedi |
Taşıması kolay bir altyapı, kesintisiz büyüme demektir
Sunucu değiştirmek bir kriz olmak zorunda değil. Pinova'nın yapılandırma ve lisans yapısını kendi taşıma senaryonla değerlendir.
Taşıma sırasında siteyi kapatmam şart mı?
Şart değil ama en güvenli yol kısa bir bakım modudur. İki dakikalık kontrollü kesinti, haftalar sonra ortaya çıkacak kayıp siparişlerden çok daha ucuza gelir. Yoğun satış yapıyorsan delta aktarımıyla bu süreyi bir dakikanın altına indirebilirsin.
Eski sunucuyu ne zaman kapatabilirim?
En az 72 saat bekle. Bu süre boyunca uygulamayı salt okunur bakım sayfasına çevir ki geciken ziyaretçiler sipariş veremesin. Kayıtları ve günlükleri de indirmeden hiçbir şeyi silme.
Karakter bozulmasını taşımadan sonra düzeltebilir miyim?
Düzeltilebilir ama zahmetlidir, çünkü bozulma veriye yazılmıştır. Doğru yol, taşıma öncesinde kaynak ve hedef veritabanının karakter setini ve karşılaştırma kuralını birebir eşitlemektir.
Ödemeler taşımadan sonra neden tamamlanmıyor?
Büyük olasılıkla ödeme sağlayıcısındaki bildirim adresi hâlâ eski sunucuya bakıyor. Geçişten hemen sonra bu adresleri güncelle ve küçük tutarlı bir test ödemesiyle akışın uçtan uca çalıştığını doğrula.
Kesintisiz taşıma bir şans işi değil, sıralama işidir: TTL'i önceden düşür, karakter setini eşitle, yazmayı kontrol altına al, deltayı aktar, bildirimleri ve cron'ları doğrula, eski sunucuyu bekletmeye devam et. Bu sıralamayı bir kez yazılı hâle getirdiğinde her taşıma tekrarlanabilir bir rutine dönüşür. Kendi senaryonu kurgularken panel tarafının nasıl çalıştığını görmek istersen canlı demo üzerinden gezinip kontrol listeni ona göre şekillendirebilirsin.