Çevrim içi bir topluluk, büyük WordPress sitesini ancak bakım aralığı başladığında kopyalamaya başlıyor. DNS TTL hâlâ bir gün, hedef gerçek veri hacmiyle hiç sınanmamış ve ziyaretçiler kademeli geçerken iki site de yeni yükleme kabul ediyor. Daha hızlı kopyalamak, birbirinden ayrılan iki veri geçmişini birleştiremez.
Kesintiyi azaltan asıl unsur hazırlıktır: hedefi önceden sınamak, değişmeyen verileri erken taşımak, yazma işlemlerinin hangi noktada duracağını belirlemek ve son aralığı yalnız kalan verilerle trafik geçişine ayırmak.
Bu konu ne anlama gelir?
Minimum kesintili taşımada hedef, trafik yönlendirilmeden önce hazırlanır; son kesinti yalnız ölçülmüş veri farkının aktarımına ayrılır. Kesinti yalnız sayfanın açılmaması değildir: içerik yayımlama, ödeme, form veya başka yazma işlemlerinin durduğu süre de buna dahildir.
Her aşamada hangi veritabanı ve dosya alanının esas olduğu açık olmalıdır. DNS, CDN, sertifikalar, kuyruklar, e-posta, webhook’lar, cache ve arka plan işleri için sorumlu kişiler ile test ölçütleri belirlenir.
Gerçekçi bir WordPress örneği
Bir üyelik sitesi medya kütüphanesini hafta içinde yeni sunucuya kopyalıyor ve güncel veritabanını test amacıyla geri yüklüyor. Geçişten önce DNS TTL düşürülüyor, veritabanı ile yüklemelerin değişim hızı ölçülüyor ve son senkronizasyon prova ediliyor.
Gerçek geçişte yazma işlemleri kısa süreli duruyor, kuyruklar boşaltılıyor, son veritabanı ve dosya farkı aktarılıyor. Eski site, kabul testleri bitene kadar salt okunur durumda korunuyor.
Neden önemlidir ve ne zaman kullanılır?
Uzun bakım aralığı kabul edilemiyorsa ve site değişiklikleri durdurulabiliyor, çoğaltılabiliyor veya sonradan eşleştirilebiliyorsa bu yöntem uygundur. Son veri farkı küçüldükçe yazma kesintisi de kısalır ve öngörülebilir hâle gelir.
Her site için doğru seçenek değildir. Hedef kapasitesi yetersizse, veri senkronizasyondan hızlı değişiyorsa veya güvenilir replikasyon olmadan iki sistemin de yazılabilir kalması gerekiyorsa planlı, daha uzun bir kesinti daha güvenli olabilir.
Yeni başlayanlar için anlaşılır yol
- Hedefte uyumlu PHP, veritabanı, web sunucusu, depolama, sertifika ve WordPress yapılandırmasını kurun.
- Güncel bir kopyayı geri yükleyin; gerçekçi veri hacmiyle giriş, içerik yayımlama, medya, formlar, zamanlanmış işler, e-posta ve entegrasyonları sınayın.
- Değişmeyen dosyaları önceden kopyalayın ve DNS TTL’yi zamanında düşürün. Son veritabanı ve yükleme farkının süresini ölçün.
- Geçişte yazmaları durdurun veya çoğaltın, kuyrukları boşaltın, son farkı aktarın ve kaynakla hedefteki kayıt sayılarını karşılaştırın.
- Trafiği sorumlu DNS, CDN veya proxy katmanından yönlendirin. Hedef onaylanana kadar kaynağı salt okunur tutun.
İleri teknik yol
Uygun sistemlerde veritabanı replikasyonu veya change data capture kullanın; dosya tarafında ise yalnız son değişen dosyaları aktarın ve silinecek öğeleri ayrıca gözden geçirin. Canary sırasında isteklerin hangi sunucuya gittiğini işaretleyin, hata ve gecikme eşiklerini izleyin; test yazmalarının yalnız bir kez kaydedildiğini doğrulayın.
Geri dönüş iki ayrı karardır: trafiği kaynağa yönlendirmek ve geçişten sonra yazılan veriyi ele almak. Bunun için yazma kaydı tutup senaryoyu prova edin. TTL, DNS önbelleğini etkiler; bütün istemcilerin geçtiğini garanti etmez.
Riskler, sık hatalar, yedekleme ve geri alma
Toplu kopyayı geçiş anında başlatmak, hedef test edilmeden DNS’i değiştirmek, son yüklemeleri veya kuyrukları unutmak ve iki siteyi birden yazılabilir bırakmak veri ayrışmasına ve kayba yol açar. Kullanıcıya özel cache’i önceden ısıtmak da gizlilik riski doğurur.
Tüm kabul aralığı tamamlanmadan kaynağı veya kurtarma paketini silmeyin. Sertifika ya da DNS sorumluluğu belirsizse, prova süreyi aşıyorsa, kayıt sayıları uyuşmuyorsa veya geri dönüş iki ayrı veri kaynağı yaratacaksa durun.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, hedefi hazırlamak ve sınamak için kullanılacak belirli bir WordPress dosya ve veritabanı kurtarma noktası oluşturabilir. Kapsamı açıkça seçin, paketi bağımsız bir hedefte saklayın ve hedef kapasitesini, uyumluluğu ve geri yükleme yolunu önceden sınayın.
Gerçek taşımada yedekleme, daha geniş geçiş planının bir parçasıdır. Değişmeyen veriler önceden aktarılmış olmalı; kontrollü aralıkta yalnız son veritabanı ve dosya değişiklikleriyle bekleyen işler aktarılmalı; bu noktadan sonra hangi sistemin yeni kayıt kabul edeceği açıkça belirlenmelidir. Trafik değişmeden önce kaynakla hedef karşılaştırılır.
Yedekleme Yöneticisi DNS yayılımını, veritabanı replikasyonunu, dış webhook’ları veya geçiş sonrası yazmalarla ilgili iş kararını yönetmez. Son doğrulanmış paketi ve kaynağı kabul bitene kadar koruyun; kurtarma noktasını, son senkronizasyon zamanını, yönlendirme sorumlusunu ve geri dönüşte uygulanacak veri planını kaydedin.
AIOWS Yedekleme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Site Taşıma: Yeni Sunucuya Güvenli Geçiş
- WordPress Taşıma Kontrol Listesi: Öncesi ve Sonrası
- Canlı Hizmetleri Tetiklemeden WordPress Sitesini Güvenle Klonlama
Sonuç ve önerilen yol
Hedefi gerçekçi verilerle sınayın, değişmeyen dosyaları önceden kopyalayın, DNS’i hazırlayın ve yazılabilir tek sistemi belirleyin. Son ölçülen veri farkını aktarıp trafiği kontrollü biçimde yönlendirin; kabul tamamlanana kadar kaynağı salt okunur durumda koruyun.
