Bir siteyi yeni sunucuya almak teknik olarak zor değildir; asıl zorluk ziyaretçinin bundan hiç haberi olmadan işin bitmesidir. Yanlış sıralanmış bir DNS değişikliği ya da eksik kopyalanan bir veritabanı, saatlerce süren 500 hatalarına ve kaybolan siparişlere dönüşebilir. Aşağıdaki yaklaşım, eski ve yeni ortamı bir süre paralel çalıştırarak geçişi görünmez kılmayı hedefler.

Taşımadan Önce Envanteri Çıkarın

Geçişe başlamadan önce mevcut ortamın tam bir resmini çıkarmak, sonradan "bir şey eksik kaldı" paniğini önler. cPanel tabanlı bir kurulumda kontrol etmeniz gereken temel kalemler bellidir.

  • PHP sürümü ve eklentiler: Kaynak sunucuda php -v ve php -m çıktısını alın; hedefte aynı sürüm hattının (örneğin ea-php74 ya da ea-php82) kurulu olduğundan emin olun.
  • Veritabanı boyutu ve motoru: InnoDB mi MyISAM mı, kaç GB; bu, dump süresini ve kilit davranışını belirler.
  • Cron görevleri: crontab -l çıktısını saklayın; çoğu durumda yeni sunucuda elle yeniden tanımlanmaları gerekir.
  • SSL sertifikaları ve özel dosyalar: .htaccess kuralları, php.ini override'ları ve harici API anahtarları.

DNS TTL'ini Önceden Düşürün

Kesintisiz geçişin en kritik adımı taşıma günü değil, ondan birkaç gün önce atılır. Alan adınızın A ve CNAME kayıtlarındaki TTL değerini taşımadan en az 24-48 saat önce düşürün. Varsayılan olarak 3600 veya 14400 saniye olan TTL'i 300 saniyeye çekmek, propagasyon süresini dakikalar mertebesine indirir.

; Taşımadan birkaç gün önce
www    300    IN    A    192.0.2.10
@      300    IN    A    192.0.2.10

; Geçiş tamamlanıp doğrulandıktan sonra tekrar yükseltin
www    3600   IN    A    198.51.100.20

TTL'i geçiş bittikten sonra eski değerine geri almayı unutmayın; sürekli 300 saniyede tutmak çözümleyici trafiğini gereksiz artırır.

Veriyi Tutarlı Şekilde Kopyalayın

Dosyalar ve veritabanı iki ayrı problem. Statik dosyalar için rsync idealdir, çünkü tekrar çalıştırıldığında yalnızca değişenleri aktarır:

rsync -avz --delete -e ssh \
  /home/kullanici/public_html/ \
  root@yenisunucu:/home/kullanici/public_html/

Veritabanı için ilk büyük dökümü alıp aktarın, ardından cutover anında yalnızca farkı veya küçük bir tablo grubunu yeniden senkronize edin:

mysqldump --single-transaction --quick --routines \
  -u root -p veritabani_adi | gzip > site.sql.gz

--single-transaction parametresi InnoDB tablolarını kilitlemeden tutarlı bir anlık görüntü alır; bu sayede döküm sürerken site yazma almaya devam edebilir.

Çift Yayın Penceresi Kurun

Asıl sihir burada. DNS'i hemen değiştirmek yerine yeni sunucuyu önce hosts dosyanız üzerinden doğrulayın. Yerel makinenizde /etc/hosts dosyasına hedef IP'yi yazıp siteyi sanki yayına geçmiş gibi gezin:

# /etc/hosts
198.51.100.20    example.com www.example.com

Bu yöntemle ödeme akışını, form gönderimlerini ve oturum açmayı gerçek alan adı üzerinden ama yalnızca siz görürken test edersiniz. Her şey yolundaysa DNS'i değiştirirsiniz ve düşük TTL sayesinde ziyaretçiler dakikalar içinde yeni sunucuya akmaya başlar. Eski sunucuyu hemen kapatmayın; çözümleyici önbellekleri tamamen boşalana kadar en az 24 saat ayakta tutun.

Oturumları ve Önbelleği Yönetin

Çoğu kesinti, dosyalar ve veritabanı doğru kopyalandığı halde uygulama katmanındaki ayarların unutulmasından doğar. WordPress, OpenCart ya da WHMCS gibi sistemlerde sabitlenmiş URL'ler, eski sunucunun yolunu işaret eden önbellek dosyaları sorun çıkarır. Geçişten hemen sonra uygulama önbelleğini ve nesne önbelleğini temizlemek iyi bir alışkanlıktır.

  • Dosya yolları: wp-config.php, config.php gibi dosyalarda kullanıcı adı ya da mutlak yol değişmişse güncelleyin.
  • Oturum depolama: Oturumlar dosya tabanlıysa eski /tmp içeriğini taşımayın; kullanıcılar yeniden giriş yapsın.
  • OPcache ve Redis: Yeni sunucuda derlenmiş kodu sıfırlamak için cachetool opcache:reset veya servis yeniden başlatması uygulayın.

Bir CDN ya da Cloudflare gibi bir önbellek katmanı kullanıyorsanız, geçiş sırasında "Development Mode" açmak veya tam purge yapmak, ziyaretçilere eski sunucunun önbelleklenmiş yanıtlarının dönmesini önler.

Cutover Sırası Neden Önemli

Yanlış sıra, dinamik sitelerde veri kaybının bir numaralı sebebidir. Geçiş anında eski sunucuya gelen yeni bir sipariş, yeni sunucuya kopyalanmadan eski sunucu kapatılırsa kaybolur. Bu riski en aza indirmek için aşağıdaki sırayı izleyin.

AdımEski SunucuYeni SunucuAmaç
1YayındaHazırlanıyorDosya ve ilk DB kopyası
2Salt-okunur moda alınırDoğrulanıyor (hosts)Yeni yazma engellenir
3Salt-okunurSon DB senkronuVeri farkı sıfırlanır
4BeklemeYayına alınır (DNS)Trafik yönlendirilir
5KapatılırTek yayınGeçiş tamamlanır

İkinci adımdaki kısa salt-okunur pencere genellikle birkaç dakika sürer ve e-ticaret gibi yazma-yoğun sitelerde veri tutarlılığını garanti eden tek güvenli yöntemdir. Statik veya nadiren güncellenen sitelerde bu adımı atlayabilirsiniz.

Doğru Hosting Planını Seçin

Geçişin pürüzsüz olması büyük ölçüde hedef ortamın kaynaklarıyla ilgilidir. Trafiği yüksek bir mağazayı, paylaşımlı kaynakların darboğaza girdiği bir pakete taşırsanız teknik olarak "kesintisiz" geçiş bile yavaşlık şikayetine dönüşür. İhtiyacınıza göre dengeli bir web hosting paketi seçerken CPU ve I/O limitlerini, kurumsal bir siteyi taşıyorsanız özellikle dikkate alın. Kişisel blog ya da küçük tanıtım siteleri için ise uygun fiyatlı web hosting çözümleri çoğu durumda fazlasıyla yeterli olur.

Bogahost Önerisi: Geçişi hafta sonu gece yarısı gibi trafiğin en düşük olduğu bir pencerede yapın ve cutover öncesi yeni sunucuda mutlaka tam bir yedek alın; bir aksilik olursa DNS'i geri çevirmek yerine elinizdeki snapshot'a dönmek çok daha hızlıdır.

Geçiş Sonrası Kontrol Listesi

Site yeni sunucuda açıldı diye iş bitmez. Aşağıdaki doğrulamaları sırayla yapın:

  • SSL zinciri: Tarayıcıda kilit ikonunu ve ara sertifikaları kontrol edin; openssl s_client -connect example.com:443 ile zinciri doğrulayın.
  • Mail kayıtları: MX, SPF ve DKIM kayıtlarının yeni sunucuyla uyumlu olduğundan emin olun; aksi halde giden e-postalar spam'e düşer.
  • Cron ve zamanlanmış görevler: Yeni ortamda yeniden tanımlandığını ve çalıştığını loglardan teyit edin.
  • 404 ve yönlendirmeler: .htaccess kurallarının taşındığını ve kalıcı linklerin bozulmadığını kontrol edin.

Özetle

Kesintisiz taşımanın özü, eski ve yeni ortamı bir süre yan yana çalıştırıp DNS'i ancak yeni sunucu tam doğrulandıktan sonra değiştirmektir. Düşürülmüş TTL, kısa bir salt-okunur pencere ve disiplinli bir cutover sırası bir araya geldiğinde, ziyaretçileriniz site adres değiştirdiğini hiç fark etmez. Acele etmeden, her adımı doğrulayarak ilerlemek bu işin tek kuralıdır.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
cPanel SSL hosting taşıma dns ttl cutover rsync mysqldump migration
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar