Site taşıma: kesintisiz geçiş için sıra ile yapılacaklar

Taşıma sırasında yaşanan kesintilerin neredeyse tamamı iki hatadan doğar: DNS'i her şey hazır olmadan çevirmek ve e-postayı unutmak. Doğru sırayla ilerlendiğinde ziyaretçinin taşınmadan haberi bile olmaz.

Taşımadan önce envanter çıkarın

Eski panelde ne olduğunu bilmeden taşıma yapılmaz. Şunları yazılı bir listeye dökün:

• Barındırılan alan adları ve alt alan adları.
• Veritabanları, kullanıcı adları ve bağlantı bilgileri.
• E-posta hesapları, yönlendirmeler ve otomatik yanıtlar.
• Zamanlanmış görevler (cron) ve çalıştırdıkları komutlar.
• Kullanılan PHP sürümü ve etkin eklentiler.
• SSL sertifikaları; Let's Encrypt kullanıyorsanız yeni sunucuda yeniden üretilecek.

Bu listedeki her satır, taşıma sonrası kontrol listenizin bir maddesidir.

Taşıma penceresini seçin

Kesintisiz geçiş mümkündür, ama sıfır veri farkı ancak site bir süre yazma almadığında mümkün olur. Pencereyi siteye göre seçin:

Adım 1: TTL değerini düşürün

Taşımadan en az 48 saat önce A ve MX kayıtlarının TTL değerini 3600'den 300 saniyeye indirin. TTL, dünyadaki DNS çözümleyicilerin cevabı ne kadar süre önbellekte tutacağını söyler. Yüksek TTL ile geçiş yaparsanız bazı ziyaretçiler saatlerce eski sunucuya gitmeye devam eder. TTL indirimi, eski değerin süresi dolduğunda etkili olur; bu yüzden önden yapılması şarttır.

Adım 2: Yeni sunucuya kurun, ama yayına almayın

Dosyaları ve veritabanını yeni sunucuya aktarın. Aktarımın sırası önemlidir: önce veritabanı dökümü alınır, ardından dosyalar kopyalanır. Arada içerik eklenirse fark oluşur; mümkünse taşıma penceresinde siteyi bakım moduna alın veya en düşük trafikli saati seçin.

Veritabanı dökümünü alırken tutarlılık için mysqldump --single-transaction kullanın. Aktarım sonrası yapılandırma dosyasındaki veritabanı sunucusu, kullanıcı adı ve parolayı yeni değerlerle güncelleyin.

Dosya aktarımını iki turda yapmak kesinti süresini dakikalara indirir. Birinci turu site canlıyken çalıştırın; gigabaytlarca yükleme klasörü o sırada kopyalanır:

rsync -az --delete /var/www/site/ yeni-sunucu:/var/www/site/

Siteyi bakım moduna aldıktan sonra aynı komutu bir kez daha çalıştırın. İkinci turda yalnız değişen dosyalar gider, genellikle saniyeler sürer. Veritabanı dökümünü ikinci turdan sonra alın; böylece dosyalar ile veri aynı ana ait olur.

Uygulama tarafında elle düzeltilecekler

Dosyaları kopyalamak tek başına yetmez. Taşımadan sonra hemen her projede şunlar bozulur:

• Mutlak dosya yolları. Eski panelde /home/eskikullanici/public_html olan yol yeni sunucuda başkadır. Önbellek, oturum ve yükleme klasörü ayarları buna takılır.
• Yeniden yazma kuralları. .htaccess yalnız Apache'de çalışır; nginx'e geçtiyseniz kurallar sunucu bloğuna yazılır. Taşıma sonrası iç sayfaların 404 vermesinin bir numaralı sebebi budur.
• PHP sürümü. Eski sunucuda 7.4 ile çalışan kod 8.3'te uyarı üretebilir. Hata günlüğünü açık tutup sitede bir tur gezin.
• Dış servis kayıtları. Ödeme sağlayıcısı, kargo entegrasyonu veya webhook adresleri eski IP'ye kilitliyse bildirimler sessizce düşer.

Adım 3: hosts dosyasıyla gerçek deneme

Bu, taşımanın en değerli adımıdır ve en sık atlanandır. Kendi bilgisayarınızın hosts dosyasına yeni sunucunun IP adresiyle alan adınızı yazarak, DNS'i hiç değiştirmeden yeni sunucuyu gerçek alan adıyla test edersiniz:

203.0.113.10 alanadiniz.com www.alanadiniz.com

Dosya Windows'ta C:\Windows\System32\drivers\etc\hosts, Linux ve macOS'ta /etc/hosts yolundadır. Şimdi sitede gerçek bir tur atın: ana sayfa, iç sayfalar, arama, iletişim formu, üyelik girişi, ödeme adımı, yönetici paneli. Görsellerin yüklendiğini ve karışık içerik uyarısı çıkmadığını doğrulayın.

Adım 4: E-postayı ayrı bir iş olarak planlayın

Taşımanın en riskli parçası e-postadır, çünkü kaybolan bir ileti geri gelmez. Sıra şöyle olmalı:

1. Yeni sunucuda tüm hesapları aynı adreslerle oluşturun.
2. Mevcut kutuları IMAP eşitlemesiyle aktarın; imapsync benzeri bir araç klasör yapısını korur.
3. MX kaydını çevirin.
4. Geçişten sonra en az bir hafta eski sunucudaki kutuları silmeyin; gecikmeli çözümleyicilerden gelen iletiler oraya düşmeye devam edebilir. Son bir eşitleme daha yapıp öyle kapatın.

Yeni sunucuda gönderim başlamadan önce SPF kaydını yeni sunucuyu içerecek şekilde güncelleyin ve DKIM anahtarını yeniden yayınlayın. Ayrıntısı e-posta teslimatı yazısında.

Adım 5: DNS'i çevirin ve izleyin

Her şey denendiyse A kaydını yeni IP'ye alın. İlk saat boyunca iki sunucunun da erişim kayıtlarını izleyin: trafiğin eskiden yeniye kaydığını göreceksiniz. Eski sunucuyu hemen kapatmayın; birkaç gün ayakta kalsın ve mümkünse üzerinde site çalışır durumda dursun. Böylece geç çözümleyen ziyaretçi hata sayfası değil, çalışan bir site görür.

Adım 6: Taşıma sonrası kontrol listesi

• SSL sertifikası yeni sunucuda geçerli mi, otomatik yenileme kurulu mu?
• http ve www yönlendirmeleri eskisiyle aynı mı?
• Cron görevleri yeni sunucuya taşındı mı ve çalışıyor mu?
• Arama motoru konsolunda tarama hatası artışı var mı?
• Dosya izinleri ve sahiplikleri doğru mu? Yükleme klasörüne yazılabiliyor mu?
• Yedekleme işi yeni sunucuda kuruldu mu?

En sık yapılan beş hata

1. TTL'i çevirme günü düşürmek. İndirim ancak eski TTL süresi dolduğunda etkili olur; aynı gün yapılan değişiklik hiçbir işe yaramaz.
2. Yanlış DNS bölgesini düzenlemek. A kaydını değiştirdiğinizi sanırsınız, ama alan adı kayıt firmasındaki ad sunucuları başka bir bölgeyi gösteriyordur. Hangi bölgenin canlı olduğunu DNS kayıtları yazısındaki yöntemle doğrulayın.
3. Yalnız ana sayfayı denemek. Taşımada kırılan şey neredeyse hiç ana sayfa olmaz; form, giriş veya ödeme adımı olur.
4. Eski sunucuyu aynı gün kapatmak. Geç çözümleyen ziyaretçiler ve gecikmeli e-postalar birkaç gün daha oraya gitmeye devam eder.
5. Yedeksiz başlamak. Taşımaya başlamadan önce eski sunucudan tam bir kopya alıp kendi bilgisayarınıza indirin. 3-2-1 kuralı en çok taşıma gününde işe yarar.

Geri dönüş planı

Beklenmedik bir sorun çıkarsa ne yapacağınıza taşımadan önce karar verin. TTL düşük olduğu için A kaydını eski IP'ye geri almak birkaç dakikada etkili olur — ama bu süre içinde yeni sunucuda oluşan siparişleri ve form kayıtlarını kaybedersiniz. Bu yüzden geri dönüş kararının ilk yarım saatte verilmesi gerekir; sonrasında ileriye doğru düzeltmek daha güvenlidir.

Büyük siteyi kısa kesintiyle taşımak: iki geçişli kopya

Birkaç gigabaytlık dosya ve büyük bir veritabanı taşırken asıl soru, sitenin ne kadar süre yazmaya kapalı kalacağıdır. Cevap, kopyayı ikiye bölmektir: ilk geçiş site açıkken her şeyi taşır, ikinci geçiş yalnız aradaki farkı. Kesinti, yalnız ikinci geçişin süresi kadardır.

Dosyalar: rsync'i iki kez çalıştırın

İlk geçiş site yayındayken yapılır ve uzun sürebilir; önemli değil:

rsync -aH --delete --stats eski-sunucu:/var/www/site/ /var/www/site/

Kesinti penceresinde siteyi bakım moduna alın ve aynı komutu tekrar çalıştırın. rsync bu kez yalnız değişen, eklenen ve silinen dosyaları işler. Deneme sunucumuzda 3.000 dosyalık, 60 MB'lık bir dizinle sınadık: ilk geçiş 3.000 dosyayı aktardı; ardından 30 dosyayı değiştirip bir dosya ekleyip bir dosya sildik. İkinci geçiş yalnız 31 dosyayı aktardı, bir dosyayı sildi ve 0,08 saniye sürdü. Gerçek bir sitede oran benzerdir: ilk geçiş saatler sürse bile ikinci geçiş genellikle dakikalar içinde biter.

Parametrelerin her birinin sebebi var: -a izinleri, sahipliği ve zaman damgalarını korur; -H sabit bağlantıları korur; --delete eski sunucuda silinen dosyaları yeni sunucudan da siler. Kaynak yolun sonundaki eğik çizgiye dikkat edin: site/ dizinin içeriğini, site dizinin kendisini kopyalar. Önce --dry-run ekleyerek neyin değişeceğini görün.

Veritabanı: tutarlı döküm, ara dosyasız aktarım

InnoDB tablolarında --single-transaction parametresi tabloları kilitlemeden tutarlı bir anlık görüntü alır; --quick büyük tabloları belleğe toplamadan satır satır akıtır. Dökümü diske yazmadan doğrudan yeni sunucuya akıtabilirsiniz:

mysqldump --single-transaction --quick --routines --triggers sitedb   | ssh yeni-sunucu mysql sitedb

Deneme sunucumuzda 200.000 satırlık bir tablonun dökülüp başka bir veritabanına yüklenmesi 6,6 saniye sürdü ve satır sayısı birebir tuttu. Veritabanı için de iki geçiş mantığı geçerlidir: ilk döküm prova içindir ve süreyi ölçmenizi sağlar; kesinti penceresinde site yazmaya kapalıyken son dökümü alırsınız. Döküm süresi kabul edilemeyecek kadar uzunsa, kopya (replica) kurup son anda yalnız rolü değiştirmek gerekir; bu, ayrı bir planlama işidir.

İki geçişten sonra kontrol listesindeki adımlara geçin: dosya sayısını iki tarafta karşılaştırın (find /var/www/site -type f | wc -l), birkaç tablonun satır sayısını sorgulayın ve hosts dosyasıyla son bir deneme yapmadan DNS'i çevirmeyin.

Bu yöntem ne zaman yetmez?

Anlatılan sıra, dökümü birkaç dakikada alınıp yüklenebilen veritabanları için tasarlanmıştır. Veritabanı onlarca gigabaytsa ya da site geçiş sırasında yazma almayı sürdürmek zorundaysa döküm–taşı–yükle döngüsü saatler sürer ve bakım modu kabul edilemez hale gelir. O noktada yöntem değişir: yeni sunucu eskinin replikası olarak kurulur, veri sürekli akar ve geçiş anında yalnız yazma hedefi çevrilir. Kesinti saatten dakikaya iner, ama iki sunucu arasında özel ağ erişimi ve ikili günlük (binlog) yapılandırması gerekir; hazırlığı taşımanın kendisinden uzun sürer. Ölçek buraya gelmediyse bu karmaşıklığa girmeyin.

Taşımayı kendiniz yapmak istemiyorsanız, mevcut paneliniz nerede olursa olsun barındırma paketlerimizde taşıma işini destek ekibimiz ücretsiz yürütüyor; sizden yalnız eski panel erişim bilgileri isteniyor.

Sık sorulan sorular