Yapmaya çalıştığınız şeyle ilgili birçok potansiyel sorun var ve bildiğiniz gibi, hiçbir veri dinamik olarak depolanmazken sunucuyu çevrimdışına almak ve klonlamak en iyisi olacaktır.
Ancak, daha önce yaptığım gibi, yapmak istediğiniz şey tamamen mantıklı. Eğer kullanırsanız ddbaşka bir sürücüye veya başka bir sunucuya blok seviyesinde tam sunucuyu klonlayabilirsiniz. Bununla birlikte, yeni sunucuda bazı ek kurulumlar alacaktır ve muhtemelen diğerini ve yenisini açamayacaksınız. Bunu anlayabilmemiz için sunucu donanımınız ve yazılımınız hakkında birkaç şey bilmemiz gerekiyor.
İlk olarak, en iyi veri stratejisini belirlemek için nelerin düzenli olarak nelerin güncellediğini bilmek faydalı olacaktır. Dinamik olarak güncellenen ancak statik içeriğe sahip bir SQL sunucunuz var mı? Alternatif olarak, git içeriğinize sürekli veri güncellemeleri göndermek gibi bir alt sürüm sistemi üzerinde geliştiricilerden oluşan bir ekibiniz var mı? Neyin güncelleneceğine bağlı olarak, en iyi tam eylem yolunu belirleyecektir.
Örneğin, yalnızca düzenli olarak güncellenen SQL ise, bu sunucu şu şekilde canlıyken yeni bir sunucuya geçiş yapabilirsiniz:
dd tüm verileri yeni sunucu klonlamak için.- Yeni sunucuyu kurmaya başlayın, özellikle farklı bir donanımsa biraz çalışmak gerekebilir, ancak yine de sıfırdan kurulumdan daha hızlı olabilir.
- Ayrıca, ilk sunucu hala canlıyken canlı olarak ikinci sunucuda çalışmanız gerekiyorsa, aynı DNS'yi başka bir sunucuda kullanamayacağınız için bazı DNS değişiklikleri de alabilir.
- Yeni sunucu tamamlandıktan ve bağımsız olarak çalıştıktan sonra, orijinal sunucudaki sql sunucusunun son yedeğini alın ve yeni sunucuya alın.
Hiçbir veriyi kaçırmamanız için orijinal sunucunuzu geçici olarak çevrimdışı duruma getirmeniz gerekebilir. Alternatif olarak, sıfır kesinti süresine sahip olmak için ikinciyi canlı yapabilir, dns'i yeni sunucuya yönlendirebilir ve daha sonra dns girişlerini yeni sunucuda manuel olarak güncelleyebilirsiniz, böylece sıfır kesinti süresi olur. Bu, sql'yi yedekleyip yeni sunucuya geri yüklemek için birkaç dakikalık kesinti süresinden daha zahmetlidir, ancak sıfır kesinti süresi için gerekli olabilir .
Bu elbette sadece bir kullanım örneği olup, yapılandırmanıza ve çeşitli değişkenlere bağlı olarak, özel durumunuza göre taşıma için kendi stratejinizi oluşturmanız gerekebilir.
Diğer sorun sunucu donanım yapılandırmasıyla ilgilidir. Yeni sunucu, donanım olarak eski sunucu ile% 100 aynı mı? Öyleyse, kurulum daha kolaydır. Ancak, diğer taraftan, tamamen, tamamen farklı bir donanım yapılandırmasıysa, ikinci sunucuyu önceden ayarlamak, ardından tüm verilerinizi ve sql veritabanlarınızı yedeklemek için farklı bir strateji uygulamanız gerekebilir. ilk sunucuyu seçin ve yapılandırmayı istediğiniz gibi değiştirerek manuel olarak geçirin.
Sunucu geçişi kesinlikle önemsiz değildir ve başarılı bir hamle için, aynı sunuculara veya eldeki personele ilişkin derin bilgiye sahip olmanız gerekir. Her durumda, tam bir yedek almanız ve onu yerel bilgisayarınızda bile üçüncü bir kaynakta depolamanız önemle tavsiye edilir, böylece en kötü durum senaryosu gerçekleşirse (her iki sunucu da bozulur ve onarılamaz şekilde ölür) sunucularınızı yeniden oluşturmak için verilerinizin bir kopyası.
Bu yardımcı olur ve sunucu hamle iyi şanslar!