Siteyi açıyorsun, hosting panelini açıyorsun ve iki düğme arasında sıkışmışsın: «Yükselt» ve «Taşı». Planı değiştirmen gerektiğini biliyorsun çünkü ya disk alanı doldu, ya inode sayısı sınırı aştı, ya da her gece saat on ikide site uykuya dalıyor çünkü planın RAM'i yetmiyor. Gerçek soru hangi planın daha iyi olduğu değil; soru şu: hosting planı yükseltmesini hangi sırayla yapmalısın ki alışverişin ortasındaki kullanıcı beyaz sayfa görmesin.
İlk yaptığım şey nedeni hisle değil, sayıyla belirlemek. Sorunun inode olduğundan şüpheleniyorsan basit bir komutla sayabilirsin:
find ~ -type f | wc -l
find ~ -type d | wc -lBu iki sayının toplamını planın sınırıyla karşılaştır. Sınıra yaklaştıysan yükseltme sadece zaman kazandırır; asıl sorun genellikle eski önbellekler, hostingin kendi üzerindeki yedek sürümleri veya birikmiş session dosyalarıdır. Sayımın ayrıntıları ve neyin inode tükettiği hostingde inode sınırı sayfasında yer alıyor ve beş dakikalık okumaya değer, çünkü o olmadan daha pahalı bir plan satın alıp iki hafta sonra aynı sınıra takılabilirsin.
Hosting planı yükseltmesi neden aynı sunucuda neredeyse kesintisizdir
Yeni plan aynı sunucuda ve aynı bölümde olduğunda taşıma sadece bir kota (quota) değişikliği ve web sunucusu yapılandırmasının yeniden yazılmasıdır. Dosyalar yer değiştirmez. DNS değişmez. SSL'e dokunulmaz. Bu durumda gerçek downtime genellikle 60 saniyenin altındadır ve çoğu PHP-FPM ile web sunucusunun yeniden yüklenmesiyle geçer.
Ama yeni plan başka bir sunucudaysa hikâye tamamen değişir. Burada tam bir göçün var: dosya kopyalama, veritabanı dump ve restore, cron'ların yeniden ayarlanması ve hepsinden önemlisi A kaydının TTL'ini bekleme. İşte burada siteler saatlerce kapalı kalır ve kimse nedenini anlamaz.
Her şeyden önce: TTL'i taşımadan sonra değil, önce düşür
Burada hata yapılıyor. Çoğu kişi önce taşımayı yapar, sonra A kaydının TTL'inin 86400 saniye (24 saat) olduğunu hatırlar. Sonuç şu olur: yeni site hazırdır ama kullanıcıların bir kısmı tam bir gün boyunca hâlâ eski sunucuya gider. Eski sunucuyu kapatmışsan bağlantı hatası görürler ve sen DNS'in sorunlu olduğunu düşünürsün.
Doğru sıra şudur: taşımadan en az 24 ila 48 saat önce A kaydının TTL'ini 300 saniyeye (5 dakika) düşür. Eski TTL'in süresi dolana kadar bekle. Sonra taşımayı yap. Her şeyin kararlı olduğundan emin olduktan sonra TTL'i eski değerine geri döndür.
| Kayıt | Taşımadan önce | Taşıma sırasında | Sabitlendikten sonra |
|---|---|---|---|
| A / AAAA | 300 | 300 | 3600 veya 86400 |
| MX | Dokunma | Dokunma | Dokunma |
| CNAME (www) | 300 | 300 | 3600 |
Hosting taşıması sırasında MX kaydını değiştirme. E-posta aynı alan adındaysa, işin ortasında MX değiştirmek e-postaların birkaç saat kaybolmasına ve kuyrukta beklemesine neden olur. E-postayı ayrı ve başka bir pencerede taşı.
Düşük trafikli pencerede işlerin tam sırası
Zaman penceresini alışkanlığa göre değil, kendi istatistiklerine göre seç. Sitenin trafiği Tahran saatiyle sabah 3 ile 5 arasında en düşükse o aralığı al. Sitenin yabancı kitlesi varsa bu aralık yanlıştır ve 10 ile 12 UTC saatlerini seçmelisin. Saatlik ziyaret raporuna bir bakmak yeterli.
- Tam yedek al ve onu başka bir yerde sakla. Aynı hostingde değil. tar.gz dosyasını ve veritabanı dump'ını indir ve boyutlarını kontrol et. Boyutu sıfır olan yedek, yedek değildir.
- Yeni plandaki PHP ve MySQL sürümlerini not al. Siten PHP 7.4'teyse ve yeni plan varsayılan olarak 8.2'ye sahipse, taşımadan önce uyumluluğu test et. Mevcut eklentilerin listesi ve test yöntemi hostingde PHP eklentilerini kontrol etme sayfasında açıklanmıştır.
- Siteyi hedefte ayağa kaldır ama henüz DNS'i değiştirme. Kendi sistemindeki hosts dosyasını düzenleyerek veya geçici bir subdomain ile yeni siteyi test et. Bu adım, hataların %90'ının bulunduğu yerdir.
- Veritabanını dump et ve restore et.
mysqldump --single-transaction --routines --triggersile al ki InnoDB tabloları işin ortasında kilitlenmesin. - DNS'i değiştir. Artık TTL düşük olduğu için yayılma birkaç dakikada gerçekleşir.
- Eski sunucuyu en az 72 saat açık tut. Sadece emin olmak için. Sonra kapat.
Üçüncü adımı ciddiye al. Test etmeden DNS'i değiştirir ve sonra imagick eklentisinin yeni planda kurulu olmadığını fark edersen, geri dönmek zorunda kalırsın ve bu sefer sitende gerçek kullanıcılarla birlikte.
Gerçek taşımalarda çok gördüğüm bir nokta
wp-config.php dosyasını veya eşdeğerini unutuyorlar. Site açılır, ana sayfa yüklenir ama veritabanına ihtiyaç duyan her sayfa «Error establishing a database connection» hatası verir. Nedeni, yapılandırma dosyasındaki veritabanı bağlantı bilgilerinin hâlâ eski sunucuyu işaret etmesi veya yeni plandaki veritabanı kullanıcı adının öncekinden farklı olmasıdır. Bu hatayı hata günlüğünde de görürsün ama çoğu kişi sadece web sunucusu günlüğüne bakar ve hiçbir şey bulamaz.
İkinci durum: mutlak yollar. Yapılandırmada veya veritabanında /home/olduser/public_html yolu sabit kodlanmışsa, kullanıcı adının değiştiği yeni planda her şey kırılır. Taşımadan önce veritabanında basit bir aramayla bul ve düzelt.
Yükseltmenin işe yaramadığı ve özel sunucuya geçmen gereken durum
Az söylenen gerçek bir sınırlama var: Sitenin CPU tüketimi sürekli olarak planın payının üzerindeyse, hosting planı yükseltmesi sadece sınırı biraz yükseltir ve iki ay sonra aynı duvara tekrar çarparsın. İşareti şudur: kaynak raporunda CPU tüketimi yoğun saatlerde sınıra yapışır ve yükseltmeden sonra da aynı desen tekrarlanır.
Bu durumda iki yolun var. Ya mimariyi optimize edersin (sayfa önbelleği, nesne önbelleği, ağır işlemleri kullanıcı isteği yolundan ayırma) ya da paylaşımlı sınırın olmadığı bir özel sunucuya geçersin. Benim tercihim: önce optimizasyon, çünkü maliyeti daha düşük ve sonucu her planda kalır. Optimizasyondan sonra hâlâ sınıra takılıyorsan o zaman özel sunucuya git. Tersi, aynı sorun için daha fazla para ödemek demektir.
Site WordPress ise ve sadece trafik arttıysa, genellikle doğru bir sayfa önbelleğiyle CPU tüketimi yarıya kadar düşer. Bunu herhangi bir satın alma kararından önce test et.
Taşımadan sonra neleri kontrol etmelisin
Bunları kontrol etmedikçe taşıma bitmemiştir:
- SSL sertifikası ana alan adında ve
www'da geçerli ve son kullanma tarihi doğru. HTTPS yönlendirmesi döngüye girdiyse, hostingde SSL kurulumu kılavuzu sorunu tam olarak açıklar. - Cron job'lar yeni planda oluşturulmuş. Bu çok unutulur ve bir hafta sonra otomatik yedeğin çalışmadığını fark ederler.
- İşlemsel e-postalar (iletişim formu, şifre sıfırlama) gerçekten gönderiliyor. Sadece ayarlara bakmakla değil, gerçek bir test gönder.
- TTL'i eski değerine geri döndür.
DNS yayılımını birkaç noktadan kontrol etmek için DNS ve ağ sorgulama aracı işi hızlandırır; birkaç farklı şehirden elle dig çekmene gerek yok. Ve nihai karardan önce planların davranışını bir test sitesiyle ölçmek istiyorsan, ücretsiz web yöneticisi araçları iyi bir başlangıç noktasıdır.
Zamanlama hakkında son bir not: E-ticaret siten varsa ve bir kampanyanın ortasındaysan, taşımayı ertele. Hiçbir düşük trafikli pencere, aktif bir kampanya kadar değerli değildir. Hosting planı yükseltmesi teknik bir iştir ama zamanlaması bir iş kararıdır.
Sık sorulan sorular
Hosting planı yükseltmesi ne kadar sürer ve site düşer mi?
Yeni plan aynı sunucudaysa genellikle bir dakikadan az ve hissedilir kesinti olmadan. Başka bir sunucudaysa gerçek süre dosya ve veritabanı boyutuna bağlıdır ve birkaç dakikadan birkaç saate kadar sürebilir; bu durumda kesintiyi TTL'i düşürerek ve DNS'i değiştirmeden önce hedefte test ederek en aza indirirsin.
Taşımadan sonra site neden hâlâ eski sunucuya gidiyor?
Çünkü A kaydının TTL'i taşımadan önce düşürülmedi ve kullanıcıların ile resolver'ların DNS önbelleği hâlâ eski değeri tutuyor. Önceki TTL'in süresi dolana kadar trafiğin bir kısmı eski hedefe gider. Çözüm, TTL'i taşımadan 24 ila 48 saat önce 300 saniyeye getirmektir.
Hosting taşıması sırasında MX'i de değiştirmeli miyim?
Hayır. Hosting taşıması sırasında MX kaydına dokunma, özellikle e-posta aynı alan adındaysa. İşin ortasında MX değiştirmek e-postaların birkaç saat kuyrukta beklemesine veya geri dönmesine neden olur. E-postayı ayrı bir zaman penceresinde ve site sabitlendikten sonra taşı.
Sorunun plandan mı yoksa site kodundan mı olduğunu nasıl anlarım?
Yoğun saatlerdeki kaynak raporuna bak. CPU ve RAM tüketimi sınıra yapışıyorsa ve aynı zamanda veritabanı yanıt süresi artmışsa, muhtemelen plan dardır. Kaynak tüketimi düşük ama site yavaş kalıyorsa, sorun genellikle kodda, ağır sorgularda veya önbellek eksikliğindedir ve plan yükseltmesi sadece maliyeti artırır.