Araç seçimi ve geçiş modeli için karar ölçütlerini analiz etme

Tamamlandı

Geçiş yöntemleri ve araç seçenekleri seçeneklerini incelediğimize göre, PostgreSQL için Azure Veritabanı Esnek Sunucuya geçişlerimizi yürütmek için göz önünde bulundurmamız gereken karar verme ölçütlerini keşfedebiliriz. Seçimlerimizi yapmamıza yardımcı olan üç ana ölçüt: Kapalı kalma süresi, Kaynak veritabanı konumu ve Özelleştirilebilirlik.

Kesinti süresi

Kapalı kalma süresi, geçiş etkinliklerinin önemli bir modeldir ve paydaşlar tarafından kabul edilebilir süre, çevrimdışı veya çevrimiçi geçiş etkinliği gerçekleştirmemiz gerekip gerekmediğine karar vermemize yardımcı olur.

Normalde, etkinlik için uygun değişiklik denetimlerinin ve ilişkili idarenin tamamlandığından emin olmak için geçiş etkinlikleri önceden iyi planlanır. Bu planlama, önemli paydaşların sistemin ne kadar süreyle çevrimdışı olabileceğini anlamasını sağlayan bir iletişim kutusu sağlar. Bu durumda, tahmini minimum ve maksimum kapalı kalma süreleri belirleyebileceğiniz farklı seçenekler için ne kadar sürdüğünü bilmeniz önerilir.

Uygulama kesintisi gerçekleştirmek için gereken en düşük kapalı kalma süresini ayarlamak çok önemlidir. Sonuç olarak, bu süre çevrimiçi (veya en düşük kapalı kalma süresi) geçiş etkinliğinde bile sistemi çevrimdışına almanız gereken tutardır. Uygulamanın karmaşıklığı bu zaman ölçeğini belirleyecek. Nispeten basit bir uygulama için bu işlem bir hizmeti durdurma, yapılandırma dosyasını güncelleştirme ve sonra yeniden açma durumu olabilir. Daha karmaşık ortamlarda, birden çok sunucu ve uygulama katmanı varsa bu işlem çok daha uzun sürebilir.

Çevrimiçi veya çevrimdışı geçiş etkinlikleri için gereken süreyi anlamak, kapalı kalma süresiyle ilgili bir sonraki önemli öğedir. Bu bir çevrimdışı geçişse, verileri kaynaktan hedefe ayıklamak, aktarmak ve yüklemek için geçen süre, doğrulama ve doğrulamanın ardından kapalı kalma sürenizdir. Bu kapalı kalma süresi, uygulamayı/iş yükünü kapatma süresi ile uygulamayı/iş yükünü yeniden açmak için geçen süre arasında kısaltılır.

Çevrimiçi (en düşük kapalı kalma süresi) geçişleriyse, kapalı kalma süresi, uygulama kapatıldıktan sonra kaynaktan hedefe yapılan son değişiklikleri eşitlemek için gereken süredir. Uygulama/iş yükünü yeniden yapılandırmadan ve etkinleştirmeden önce bu kapalı kalma süresine, doğrulama ve doğrulama etkinliklerine ekleyin.

Bu bilgilere sahip olduktan sonra, uygulanabilir seçeneklerimizin ne olduğunu belirlemeye yardımcı olmak için geçişin teknik öğelerine bakabiliriz.

Kaynak veritabanı konumu

Belirli bir yapılandırma için geçerli olabilecek kısıtlamalar nedeniyle geçirilecek veritabanlarının kaynak konumu bir rol oynar.

Şirket içi veya Azure dışı kaynaklar

Şirket içi veya Azure dışındaki bir veritabanı için temel kısıtlama genellikle kaynak ve hedef arasındaki ağ bağlantısıdır. Burada dikkate alınması gereken üç nokta bant genişliği, gecikme süresi ve veri hacmidir. Bu noktaları anladıktan sonra, hangi geçiş türünün uygulanabilir olduğu konusunda bilinçli bir karar verebiliriz.

Geçirilecek çok büyük miktarda verimiz ve orantılı olarak az miktarda bant genişliğimiz varsa, basit bir döküm ve geri yükleme işlemi büyük olasılıkla uygun olmayacaktır. Büyük miktarda veri ve büyük miktarda bant genişliğine sahipsek bu daha az sorun oluşturur.

Benzer şekilde, veri eşitlemenin gerçekleşeceği çevrimiçi bir geçişse gecikme, önemli faktörlerden biridir. Gecikme süresi yüksekse, eşitleme işleminin tamamlanması aşırı uzun sürdüğünden sistem performansı üzerinde olumsuz etkiler olabilir.

Diğer bulut sağlayıcılarından geçiş yaparken de dikkate alınması gereken önemli faktörlerden biri, veri çıkışı için ücretlendirilip ücretlendirilmediğidir. Öyleyse, aktarılan verilerin fiziksel ayak izini en aza indirebilmek dikkate alınması gereken bir konu olabilir. Böyle durumlarda sıkıştırma teknolojisi, eşitleme için kullanılan dökümler veya veri akışları için önemli olabilir.

Diğer Azure tabanlı hizmetler

Diğer Azure tabanlı hizmetlerden PostgreSQL için Azure Veritabanı Esnek Sunucu'ya geçiş yapmak istediğiniz durumlar olacaktır. Bu kaynak veritabanları Azure VM'lerinde, kapsayıcılarında veya büyük olasılıkla Tek Sunucuda PostgreSQL için Azure Veritabanı olabilir. Öyleyse, keşfedilecek farklı noktalar vardır ancak aynı zamanda bu senaryolar için Azure hizmetlerindeki iyileştirmelerden yararlanmaya yönelik çeşitli fırsatlar da vardır.

Customizability

Dikkat edilmesi gereken son nokta, ne kadar özelleştirme gerektiği veya ne kadar istenildiğidir. Bu önemli nokta, veri çoğaltmayı desteklemek için kaynak veritabanı yapısını değiştirme gereksiniminin biçimini alabilir; alternatif olarak, betik oluşturma yoluyla otomatikleştirmenin ne kadar kolay olduğu anlamına gelebilir.

pg_dump ve pg_restore aracılığıyla veritabanının çevrimdışı geçişini otomatikleştirmek, ancak aynı zamanda döküm dosyalarının sıkıştırması ve sıkıştırmasını açma dahil olmak üzere iyi bir örnek olabilir.

Karar verme

Bu bilgilerin tümünü toplama sürecini tamamladığımıza göre, paydaşlarla birlikte çalışarak belirli bir senaryo için en iyi seçeneği belirleyebiliriz. Hangi metodoloji ve teknolojinin kullanılacağına karar verirken yalnızca iş paydaşlarıyla değil, teknik paydaşlarla da çalışmak önemlidir. Bu işbirliği, işletmenin personel, kaynak veya teknoloji kısıtlamaları nedeniyle teknik ekibin teslim edecek durumda olmadığı en düşük kapalı kalma süresi geçişine neden olduğu bir durumdan kaçınmaya yardımcı olur.

Burada önemli olan beklentileri yönetmek ve açık ve dürüst bir iletişim kutusuna sahip olmaktır. İşletmenin veritabanı geçişini teslim eden teknik ekiplerin dışında yer alan doğrulama görevlerinin sahipliğini aldığından emin olmak da önemlidir. Bu doğrulama, veri tutarlılığı ve doğrulama denetimleri ile kullanıcı deneyimi testlerini içerebilir.