Olağanüstü durum kurtarma

Azure Databricks için olağanüstü durum kurtarma (DR), bölgesel bir kesinti birincil dağıtımınızı çevrimdışına aldığında ekiplerinizin çalışmaya devam etmesi için çalışma alanlarını, verileri ve yapılandırmaları bulut bölgeleri arasında çoğaltır. Tam bir DR planı yalnızca Azure Databricks değil, bağlandığı veri kaynaklarını, alım araçlarını, BI araçlarını ve zamanlayıcıları da kapsar.

Bu sayfada bölgeler arası DR çözümü tasarlamak ve çalıştırmak için ihtiyacınız olan kavramlar, stratejiler, araçlar ve test yordamları yer alır.

DR planlamada yeni misiniz? RPO ve RTO tanımları için Olağanüstü durum kurtarma sektörü terminolojisiyle başlayın.

Önemli

Yönetilen olağanüstü durum kurtarmayı kullanın. Azure Databricks AWS ve Azure üzerinde bölgeler arası DR için yönetilen olağanüstü durum kurtarma önerir. Unity Catalog meta verilerini, yönetilen tablo verilerini ve çalışma alanı varlıklarını sürekli olarak çoğaltır, yük devretme sonrasında da geçerliliğini koruyan sabit bir URL sağlar ve hesap konsolundan yük devretmeyi tetiklemenize olanak tanır. Yazılması veya bakımının yapılması gereken replikasyon betikleri yok. Bu sayfadaki kendin yap kılavuzunu yalnızca yönetilen DR tarafından çoğaltılmayan kaynaklar için ya da etkin-etkin topolojilere, bulutlar arası çoğaltmaya veya çoğaltma işlem hattı üzerinde ayrıntılı düzeyde denetime ihtiyacınız varsa kullanın.

Bölge içi yüksek kullanılabilirlik garantileri

Bu sayfanın geri kalanı bölgeler arası DR'yi kapsar, ancak Azure Databricks aynı zamanda tek bir bölge içinde yüksek kullanılabilirlik (HA) sağlar. Önce bu garantileri anlayın. Ayrı bir DR stratejisine ihtiyacınız olup olmadığını belirler.

HA ve DR farklı sorunları çözer:

HA , bir bölgenin içinde kullanılabilirlik alanı (AZ) yedekliliğini kullanır. Bir bölge başarısız olursa hizmetler diğerlerinde çalışmaya devam eder.
DR , bölgeler arası çoğaltma kullanır. Başka bir bölgede ikincil Azure Databricks çalışma alanları çalıştırır, verileri ve yapılandırmaları bu çalışma alanlarına çoğaltır, ardından bölgesel bir kesinti sırasında yük devretme gerçekleştirirsiniz.

Çok bölgeli DR'ye ihtiyacınız yoksa Azure Databricks HA yeterli olabilir. HA, bölgeler arası karmaşıklığı önler ancak bölgenin tamamını etkileyen bir kesintiye karşı koruma sağlamaz. DR için yalnızca HA'ya güveniyorsanız bulut bölgenizin ayrımını ve yedekliliğini doğrulayın.

Bölge içi HA garantileri, kontrol düzlemini ve işlem düzlemini kapsar.

Azure Databricks kontrol düzleminin kullanılabilirliği

Azure Databricks kontrol düzlemi bölge hatalarına dayanıklıdır ve bölge hatasından sonra yaklaşık 15 dakika içinde otomatik olarak kurtarılır. Normal bölge hatası testi bunu doğrular.

Durum bilgisi olmayan tüm denetim düzlemi hizmetleri, hizmeti devre dışı bırakmadan tek tek VM'leri veya tüm bölgedeki tüm VM'leri kaybedebilir. Çalışma alanı verileri, bölgedeki bölgeler arasında çoğaltılan veritabanlarında depolanır. Databricks Runtime görüntülerini sunan depolama hesapları da bölge içinde yedeklidir ve tüm bölgelerde, birincil depolama hesabı devre dışı kaldığında devreye giren ikincil depolama hesapları bulunur.

Uyarı

Yukarıdaki denetim düzlemi garantileri, Azure Databricks yönetilen altyapı için geçerlidir. İşlem düzlemi bölge yedekliliğinden siz sorumlusunuz; buna, örneğin, çalışma alanının kök deposu için bölge yedekli depolama seçmek ve kullanılabilirlik bölgelerine yayılan örnek havuzları kullanmak dahildir.

Bazı Azure bölgeleri, eşleştirilmiş bir bölgede dağıtılan bir denetim düzlemi kullanır. Bkz. Azure Databricks bölgeleri.

Bölge hatası dayanıklılığı en fazla bir bölgenin kapanmasını destekler ve yalnızca birden çok bölgeyi destekleyen Azure bölgelerde kullanılabilir.

İşlem düzleminin kullanılabilirliği

Çalışma alanı kullanılabilirliği, denetim düzleminin kullanılabilirliğine bağlıdır.

Depolama hesabı Alanlar arası yedekli depolama (ZRS) veya Coğrafi alanlar arası yedekli depolama (GZRS) ile yapılandırılmışsa DBFS kök verileri etkilenmez. Varsayılan değer Coğrafi olarak yedekli depolamadır (GRS).

Küme düğümleri, kalan bölgelerde yeterli kapasite olduğu varsayılarak Azure işlem sağlayıcısından düğümler istenerek farklı kullanılabilirlik alanlarından çekilir. Bir düğüm kaybolursa, küme yöneticisi, kullanılabilir AZ'lerden çektikleri yedek düğümleri Azure işlem sağlayıcısından talep eder. İstisna, sürücü düğümünün kaybolduğu durumdur. Bu durumda, küme yöneticisi işi ve kümeyi yeniden başlatır.

Çoklu AZ desteğini onaylamak için Azure bölgeleri listesine bakın. İşlem düzlemi çoklu AZ dayanıklılığı için bölgeye bağlı yedekli depolamayı kullanın.

Terminoloji

Dr'yi ekibinizle tartışırken bu tanımları tutarlı bir şekilde kullanın.

Bölge terminolojisi

Bu sayfada aşağıdaki bölge tanımları kullanılır:

Birincil bölge: Kullanıcıların günlük etkileşimli ve otomatik veri analizi iş yüklerini çalıştırdığı bölge.
İkincil bölge: BT ekiplerinin birincil bölge kesintisi sırasında iş yüklerini geçici olarak taşıdığı bölge.
Coğrafi olarak yedekli depolama: Kalıcı depolamanın bölgeler arasında asenkron çoğaltılması. Bulutunuzun belgelerine bakın:

Bölgeler arasında coğrafi olarak yedekli depolama (Azure).

Önemli

Azure Databricks kök depolamasını (örneğin, Azure Databricks’in her çalışma alanı için oluşturduğu ADLS’yi [6 Mart 2023’ten önce oluşturulan çalışma alanları için Azure Blob Depolama]) bölgeler arasında çoğaltmak için coğrafi olarak yedekli depolamaya güvenmeyin. Yönetilen tablo verilerini çoğaltmak için Delta Deep Clone kullanın; Delta dışı veriler içinse mümkünse önce Delta biçimine dönüştürün.

Dağıtım durumu terminolojisi

Bu sayfada aşağıdaki dağıtım durumu tanımları kullanılır:

Etkin dağıtım (bazen sık erişimli dağıtım olarak adlandırılır): Kullanıcılar bu dağıtıma bağlanır ve iş yüklerini çalıştırır. İşler ve veri akışları burada zamanlamaya göre çalıştırılır.
Pasif dağıtım (bazen soğuk dağıtım olarak da adlandırılır): Burada hiçbir süreç çalışmaz. BT ekipleri, kod, yapılandırma ve diğer Azure Databricks nesnelerinin dağıtımını otomatikleştirerek bunu hazır tutar. Pasif dağıtım yalnızca etkin dağıtım devre dışı bırakıldığında etkin hale gelir.

Önemli

Bir proje, ek dayanıklılık için farklı bölgelerde birden çok pasif dağıtım içerebilir.

Çoğu ekip, aynı anda tek bir etkin dağıtım çalıştırır; bu, aktif-pasif stratejisidir. Daha az yaygın olan active-active stratejisi, eşzamanlı iki etkin dağıtım kullanır.

Olağanüstü durum kurtarma sektörü terminolojisi

Ekibinizle şu iki sektör terimini tanımlayın:

Kurtarma noktası hedefi (RPO):Büyük bir olay sırasında hizmetinizin tolere edebildiği maksimum veri kaybı süresi. Bkz. RPO.

Azure Databricks birincil müşteri verilerinizi depolamaz. Bu, ADLS’de (6 Mart 2023’ten önce oluşturulan çalışma alanları için Azure Blob Depolama’da) veya sizin denetiminizdeki diğer sistemlerde bulunur. Azure Databricks denetim düzlemi bazı nesneleri (işler ve not defterleri gibi) depolar, bu nedenle Azure Databricks RPO bu nesnelerdeki değişikliklerin kaybedilebileceği en uzun süredir. ADLS'de (6 Mart 2023'te oluşturulan çalışma alanları için Azure Blob Depolama) ve denetlediğiniz diğer veri kaynaklarında müşteri verileriniz için RPO'yu tanımlamak sizin sorumluluğunuzdadır.
Kurtarma süresi hedefi (RTO):Olağanüstü durumdan sonra bir iş sürecinin geri yüklenmesi gereken en uzun süre. Bkz. RTO.

Olağanüstü durum kurtarma ve veri bozulması

DR çözümü veri bozulmalarını azaltmaz . Birincil bölgedeki bozuk veriler ikincil bölgeye çoğaltılır ve her iki bölgede de bozulur. Bu tür hataları azaltmak için Delta zaman yolculuğu, benzer araçlar veya veri yedekleme araçlarını kullanın.

Tipik kurtarma iş akışı

bir Azure Databricks DR senaryosu genellikle aşağıdaki gibi yürütülür:

Birincil bölgenizdeki kritik bir hizmete bir hata isabet eder: veri kaynağı, ağ veya Azure Databricks dağıtımının bağımlı olduğu başka bir bağımlılık.
Bulut sağlayıcınızla araştırmanız gerekir.
Bekleme süresi kabul edilemezse ikincil bölgenize geçiş yapmaya karar verirsiniz.
Aynı sorunun ikincil bölgenizi etkilemediğinden emin olun.
Yük devretme (ayrıntılı adımlar için bkz . Yük devretme testi):
1. Tüm çalışma alanı etkinliğini durdurun. Kullanıcılar iş yüklerini durdurur ve mümkün olduğunda son değişiklikleri yedekler. İşler durdurulur (kesinti bunları zaten başarısızlığa uğratmadıysa).
2. Yönlendirmeyi güncelleştirmek, bağlantıları ve ağ trafiğini yeniden yönlendirmek için ikincil bölge kurtarma yordamını çalıştırın.
3. Bağımlı sistemleri (BI araçları, zamanlayıcılar, üçüncü taraf tümleştirmeleri) ikincil çalışma alanına yönlendirin ve bağlantılarını yeniden etkinleştirin.
4. Test ettikten sonra ikincil bölgeyi çalışır durumda bildirin. Kullanıcılar artık etkin olan dağıtıma oturum açar ve siz zamanlanmış veya gecikmiş görevleri yeniden tetiklersiniz.
Birincil bölge sorunu azaltıldıktan sonra düzeltmeyi onaylayın.
Geri yükleme (ayrıntılar için bkz. Geri yüklemeyi test etme (failback)):
1. İkincil bölgedeki tüm çalışmaları durdurun.
2. Yönlendirmeyi yeniden geri almak için birincil bölge kurtarma prosedürünü çalıştırın.
3. Tüm yeni verileri birincil bölgeye geri çoğaltın. Çoğaltılması gerekenleri en aza indirin. Örneğin, ikincil dağıtımda çalışan salt okunur işler geri yazım gerektirmeyebilir.
4. Birincil bölge dağıtımını test edin.
5. Birincil bölgeyi aktif olarak belirtin ve üretim iş yüklerini yeniden başlatın.

Önemli

Bu adımlar sırasında bazı veri kayıpları oluşabilir. Kuruluşunuz için ne kadar kaybın kabul edilebilir olduğunu ve bunu nasıl azaltabileceğinizi tanımlayın.

1. Adım: İş gereksinimlerinizi anlama

Hangi veri hizmetlerinin kritik olduğunu belirleyin ve hedef RPO ve RTO'larını tanımlayın. Her sistemin gerçek dünya toleranslarını araştır.

DR, yük devretme ve yeniden çalışma, veri bozulması, veri yineleme (yanlış depolama konumuna yazma) ve yanlış bölgede değişiklik yapan kullanıcılar gibi gerçek maliyetleri ve riskleri taşır.

İşletmenizi etkileyen her Azure Databricks tümleştirme noktasını eşleyin ve planınızın kullandığı araçları ve iletişim kanallarını seçin.

Eşleme için tümleştirme noktaları

DR çözümünüzün etkileşimli işlemlere, otomatik süreçlere veya her ikisine de uyum sağlaması gerekiyor mu?
Hangi veri hizmetlerini kullanıyorsunuz? Bazıları şirket içinde olabilir.
Giriş verileri buluta nasıl ulaşıyor?
Bu verileri kim kullanıyor? Hangi işlemler onu aşağı akışta tüketir?
DR değişikliklerinden haberdar olması gereken üçüncü taraf entegrasyonlar var mı?

Planlama araçları ve iletişim

Yapılandırmanızı önceden tanımlayabilir ve DR çözümlerini doğal ve sürdürülebilir bir şekilde barındıracak şekilde modüler hale getirebilirsiniz.
DR yük devretme ve geri dönüş değişikliklerini iç ekiplere ve üçüncü taraflara (entegrasyonlar, alt sistem tüketicileri) bildiren iletişim araçları ve kanalları hangileridir? Onaylarını nasıl onaylarsınız?
Kurtarma tamamlanana kadar hangi hizmetleri (varsa) kapatırsınız?

2. Adım: İş gereksinimlerinizi karşılayan bir süreç seçin

Varsayılan olarak yönetilen olağanüstü durum kurtarma kullanın. Çalışma alanı çoğaltmasını, Unity Catalog meta verilerini, yönetilen tablo verilerini ve yük devretme orkestrasyonunu özel betiklere gerek kalmadan yönetir. Aşağıdaki DIY yönergelerini yalnızca bunun kapsamı dışında kalıyorsanız kullanın; örneğin, yönetilen DR’nin çoğaltmadığı kaynaklar, etkin-etkin topolojiler, bulutlar arası çoğaltma veya çoğaltma işlem hattı üzerinde ayrıntılı denetim gereksinimi söz konusuysa.

DIY çözümü doğru verileri kontrol düzlemi, işlem düzlemi ve veri kaynakları arasında çoğaltmalıdır. Yedekli çalışma alanları, farklı bölgelerdeki farklı denetim düzlemlerine karşılık gelir; bu nedenle bunları bir senkronizasyon aracı veya bir CI/CD iş akışı gibi betik tabanlı bir çözümle senkronize tutarsınız. Verilerin kendisi için çoğu ekip, bölgeler arasındaki tabloları kopyalamak için Azure Databricks işleri (genellikle zamanlanmış) veya Delta Deep Clone'ı kullanır. Verileri işlem düzlemi içinden (örneğin Databricks Runtime çalışanlarından) senkronize etmeniz gerekmez.

Sanal ağ ekleme özelliğini kullanıyorsanız (tüm abonelik ve dağıtım türlerinde kullanılamaz), Terraform gibi şablon tabanlı araçları kullanarak ağları her iki bölgede tutarlı bir şekilde dağıtın.

Gerektiğinde veri kaynaklarınızı bölgeler arasında çoğaltabilirsiniz.

DR çözümleri genellikle iki (veya daha fazla) çalışma alanı içerir. Tolerans göstermeniz gereken kesinti uzunluğuna, operasyonel çabaya ve birincil bölgeye yeniden çalışma maliyetine göre aşağıdaki stratejiler arasından seçim yapın.

Genel en iyi yöntemler

Genel en iyi uygulamalar

Başarılı bir DR planı için genel en iyi yöntemler şunlardır:

İşletme için kritik öneme sahip olan ve DR'de çalışması gereken süreçleri anlayın.
Hangi hizmetlerin dahil olduğunu, hangi verilerin işlendiğini, veri akışının ne olduğunu ve nerede depolandığını net bir şekilde belirleyin.
Hizmetleri ve verileri mümkün olduğunca yalıtın. Örneğin, DR verileri için özel bir bulut depolama kapsayıcısı oluşturun veya olağanüstü durum sırasında gereken Azure Databricks nesneleri ayrı bir çalışma alanına taşıyın.
Azure Databricks denetim düzleminde depolanmayan nesneler için birincil ve ikincil dağıtımlar arasındaki bütünlüğü korumak sizin sorumluluğundadır.
Veri kaynakları için, mümkün olduğunca verileri DR bölgelerinize çoğaltmak için yerel Azure araçlarını kullanın.

Uyarı

DBFS kök erişimi için kullanılan ADLS kökünde (6 Mart 2023'ten önce oluşturulan çalışma alanları için Azure Blob Depolama) veri depolamayın. DBFS kök depolama alanı, üretim müşteri verileri için desteklenmiyor. Azure Databricks, kitaplıkların, yapılandırma dosyalarının veya başlatma betiklerinin orada depolanmasını da önermez.

Aktif-pasif çözüm stratejisi

Bu bölüm en yaygın, en basit ve en uygun maliyetli olduğu için etkin-pasif stratejiye odaklanır. Etkin-pasif çözüm, etkin dağıtımınızdaki veri ve nesne değişikliklerini ikincil bölgedeki pasif dağıtıma eşitler. Bir DR olayı sırasında pasif dağıtım etkin hale gelir.

İki yaygın değişken:

Birleşik (kuruluş genelinde): Bir dizi etkin ve pasif dağıtım kuruluşun tamamını destekler.
Departmana veya projeye göre: Her etki alanı, ihtiyaçlarına göre uyarlanmış birincil ve ikincil bölgelere sahip kendi DR çözümünü korur.

Ayrıca, verileri veya Azure Databricks nesnelerini değiştirmeyen kullanıcı sorguları gibi salt okunur iş yükleri için pasif dağıtım da kullanabilirsiniz.

Etkin-etkin çözüm stratejisi

Etkin-etkin bir çözümde, tüm veri işlemleri her iki bölgede de her zaman paralel olarak çalışır. Operasyon ekibiniz, her işi ancak her iki bölgede de başarılı olduktan sonra tamamlandı olarak işaretlemelidir. Nesneler prodüksiyonda değiştirilemez ve geliştirme/hazırlık ortamından prodüksiyona uzanan katı CI/CD geçiş sürecine uymalıdır.

Aktif-aktif, en karmaşık stratejidir ve iş yükleri her iki bölgede de çalıştığı için daha maliyetlidir, ancak en düşük RTO ve RPO'yu sunar.

Active-active yapısını kurum genelinde veya departman bazında uygulayabilirsiniz. Her iş yükü için yinelenen çalışma alanına ihtiyacınız yoktur. Örneğin, geliştirme veya hazırlık çalışma alanlarını geliştirme işlem hattı üzerinden yeniden oluşturmak, bunları senkronize tutmaktan genellikle daha kolaydır.

Araçlarınızı seçin

Birincil ve ikincil bölgelerinizdeki çalışma alanları arasında verileri eşitlenmiş durumda tutmaya yönelik iki ana yaklaşım vardır:

Birincil bölgeden ikincilye kopyalayan eşitleme istemcisi: Eşitleme istemcisi üretim verilerini ve varlıkları birincil bölgeden ikincil bölgeye yönlendirir. Bu genellikle zamanlanmış olarak çalışır ve zamanlama sıklığı hedef RTO ve RPO'nuza bağlıdır.
Paralel dağıtım için CI/CD araçları: Üretim kodu ve varlıklar için, değişiklikleri üretim sistemlerine aynı anda her iki bölgeye de gönderen CI/CD araçlarını kullanın. Örneğin, kodu ve varlıkları hazırlama/geliştirme aşamasından üretime aktarırken, CI/CD sistemi bunu aynı anda her iki bölgede de kullanılabilir hale getirir. Temel fikir, Azure Databricks çalışma alanındaki tüm yapıtları kod olarak altyapı olarak ele almaktır. Çoğu yapıt hem birincil hem de ikincil çalışma alanlarına birlikte dağıtılabilirken, bazı yapıtların yalnızca bir DR olayından sonra dağıtılması gerekebilir. Araçlar için bkz . Otomasyon betikleri, örnekler ve prototipler.

İhtiyaçlarınıza bağlı olarak yaklaşımları birleştirebilirsiniz. Örneğin, not defteri kaynak kodu için CI/CD kullanın, ancak havuzlar ve erişim denetimleri gibi yapılandırmalar için eşitleme kullanın.

Aşağıdaki tabloda, her bir araç seçeneğiyle her veri türünün nasıl işleneceğini açıklanmaktadır.

Açıklama	CI/CD araçlarıyla işleme	Eşitleme aracıyla nasıl başa çıkılır
Kaynak kodu: paketlenmiş kitaplıklar için not defteri kaynak dışarı aktarmaları ve kaynak kodu	Hem birincil hem de ikincil olarak birlikte dağıtın.	Kaynak kodu birincilden ikincil koda eşitleyin.
Kullanıcılar ve gruplar	Git'te metadata'yı yapılandırma bilgisi olarak yönetin. Alternatif olarak, her iki çalışma alanı için de aynı kimlik sağlayıcısını (IdP) kullanın. Kullanıcı ve grup verilerini birincil ve ikincil dağıtımlara birlikte dağıtın.	Her iki bölge için SCIM veya başka bir otomasyon kullanın. El ile oluşturma önerilmez, ancak kullanılması gerekiyorsa her ikisi için de aynı anda yapılmalıdır. El ile kurulum kullanıyorsanız, iki dağıtım arasındaki kullanıcı ve grupların listesini karşılaştırmak için zamanlanmış bir otomatik işlem oluşturun.
Havuz yapılandırmaları	Git'teki şablonlar olabilir. Birincil ve ikincil yerlere eşzamanlı dağıtım yapın. Ancak, secondary’de `min_idle_instances`, DR olayına kadar sıfır olmalıdır.	API veya CLI kullanılarak ikincil bir çalışma alanına senkronize edildiklerinde, herhangi bir `min_idle_instances` ile oluşturulan havuzlar.
İş yapılandırmaları	Aynı iş tanımını her iki bölgeye de dağıtmak için Databricks Varlık Paketlerini ortam başına hedeflerle (örneğin `prod` ve `dr`) kullanın. İkincil dağıtım için eşzamanlılığı sıfır olarak ayarlayın; böylece iş hazırlanır ancak çalışmaz. İkincil dağıtım etkin hale geldikten sonra eşzamanlılık değerini değiştirin.	İşler bir nedenden dolayı var olan `<interactive>` kümelerde çalıştırılırsa, eşitleme istemcisinin ikincil çalışma alanında karşılık gelen `cluster_id` ile eşleşmesi gerekir.
Erişim denetim listeleri (ACL’ler)	Git'teki şablonlar olabilir. Not defterleri, klasörler ve kümeler için birincil ve ikincil dağıtımlara birlikte dağıtın. Ancak, DR olayına kadar işlerin verilerini tutun.	İzinler API'si kümeler, işler, havuzlar, not defterleri ve klasörler için erişim denetimleri ayarlayabilir. Eşitleme istemcisinin, ikincil çalışma alanındaki her nesneyi karşılık gelen nesne kimlikleriyle eşlemesi gerekir. Databricks, erişim denetimlerini çoğaltmadan önce bu nesneleri eşitlerken birincil çalışma alanından ikincil çalışma alanına nesne kimliklerinin eşlemini oluşturmanızı önerir.
Kitaplıklar	Kaynak koduna ve küme/iş şablonlarına ekleyin.	Merkezi depolardan, DBFS'den veya bulut depolamadan özel kitaplıkları eşitleyin (bağlanabilir).
Küme başlatma betikleri	İsterseniz kaynak koduna ekleyin.	Daha basit eşitleme için, başlangıç betiklerini birincil çalışma alanında ortak bir klasörde veya mümkünse küçük bir klasör kümesinde depolayın.
Bağlama noktaları	Yalnızca not defteri tabanlı işler veya Komut API'si aracılığıyla oluşturulduysa kaynak koduna ekleyin.	Azure Data Factory (ADF) etkinlikleri olarak çalıştırabileceğiniz işleri kullanın. Çalışma alanlarının farklı bölgelerde olması durumunda depolama uç noktalarının değişebileceğini unutmayın. Bu, veri DR stratejinize de çok bağlıdır.
Tablo meta verileri	Unity Kataloğu nesneleri (kataloglar, şemalar, tablolar, birimler ve izinler) için Databricks Terraform sağlayıcısı veya Databricks Varlık Paketleri ile birlikte dağıtın. Eski Hive metaveri deposu tabloları için, notebook tabanlı işler veya Command API aracılığıyla oluşturulduysa kaynak koduyla birlikte CREATE TABLE ifadelerini ekleyin.	Unity Kataloğu nesneleri için sistem tablolarından kaynak meta verileri okuyun veya `information_schema`Databricks SDK'sını kullanarak ikincil çalışma alanına çoğaltın. Eski Hive meta veri deposu tabloları için Spark Katalog API'sini kullanarak veya not defteri veya `SHOW CREATE TABLE` betikler aracılığıyla meta veri depoları arasındaki meta veri tanımlarını karşılaştırın. Temeldeki depolama yolları bölge tabanlı olabilir ve meta veri deposu örnekleri arasında farklılık gösterebilir.
Sırlar	Yalnızca Komut API'si aracılığıyla oluşturulduysa kaynak koduna ekleyin. Bazı gizli içeriklerin birincil ve ikincil arasında değişmesi gerekebileceğini unutmayın.	Gizli bilgiler, API kullanılarak her iki çalışma alanında oluşturulur. Bazı gizli içeriklerin birincil ve ikincil arasında değişmesi gerekebileceğini unutmayın.
Küme yapılandırmaları	Git'teki şablonlar olabilir. Birincil ve ikincil dağıtımlara birlikte dağıtın, ancak ikincil dağıtımdakiler DR olayı gerçekleşene kadar sonlandırılmış durumda kalmalıdır.	Kümeler, API veya CLI kullanılarak ikincil çalışma alanıyla eşitlendikten sonra oluşturulur. Otomatik sonlandırma ayarlarına bağlı olarak isterseniz bunlar açıkça sonlandırılabilir.
Not defteri, iş ve klasör izinleri	Git'teki şablonlar olabilir. Birincil ve ikincil dağıtımlara eş zamanlı dağıtım.	İzinler API'sini kullanarak çoğaltın.

Bölgeleri ve birden çok ikincil çalışma alanını seçme

DR’nin ne zaman devreye gireceğini ve hangi ikincil bölgeye yük devredileceğini siz belirlersiniz. Ayrıca, normal işlemleri devam ettirmeden önce DR ortamını sabitlemek sizin sorumluluğundadır. Bu genellikle üretim ve DR için birden çok Azure Databricks çalışma alanı oluşturma ve ardından ikincil yük devretme bölgesi seçme anlamına gelir.

İkincil bölgenizi seçmeden önce, bağlı olduğunuz tüm kaynakların ve hizmetlerin (işlem türleri, ürünler, tümleştirmeler) orada kullanılabilir olduğunu onaylayın. Bazı Azure Databricks hizmetleri yalnızca belirli bölgelerde kullanılabilir.

Ayrıca veri çoğaltmayı ve VM türü kullanılabilirliğini denetleyin.

3. Adım: Çalışma alanlarını hazırlama ve tek seferlik kopyalama yapma

İlk olarak, seçtiğiniz ikincil bölgede ikincil bir Azure Databricks çalışma alanını (veya çalışma alanlarını) ve destekleyen meta veri deposunu ayağa kaldırabilirsiniz. Verileri veya varlıkları çoğaltabilmeniz için önce ikincil çalışma alanının birincil hesabı, bölgesi ve kimlik yapılandırmasını yansıtması gerekir.

Yönetilen olağanüstü durum kurtarma kullanıyorsanız, Azure Databricks bir yük devretme grubu oluşturduğunuzda kapsam içi katalogların ve çalışma alanı varlıklarının ilk önyüklemesini işler. Bu kaynaklar için tek seferlik bir kopya çalıştırmanız gerekmez. Yönetilen DR'nin çoğaltmadığı veri kaynakları veya varlıklar için bu bölümün geri kalanıyla devam edin.

Yönetilen DR kapsamının dışında çalışan bir üretim çalışma alanı için pasif dağıtımı etkin dağıtımla eşitlemek için tek seferlik bir kopya çalıştırın. Bu kopya şunu işler:

Veri çoğaltma: Bulut çoğaltma çözümü veya Delta Deep Clone kullanın.
Belirteç oluşturma: Oluşturulan belirteçlerle çoğaltmayı ve gelecekteki iş yüklerini otomatikleştirin.
Çalışma alanı çoğaltması: 4. Adım: Veri kaynaklarınızı hazırlama altındaki yöntemleri kullanarak çoğaltın. Çalışma alanı yapılandırmasını, verilerini ve AI/ML varlıklarını dışarı aktarma hakkında kapsamlı yönergeler için bkz. Çalışma alanı verilerini dışarı aktarma.
Çalışma alanı doğrulaması: Çalışma alanını ve işlemi, başarıyla çalıştıklarını ve beklenen sonuçları ürettiklerini doğrulamak için test edin.

Sonraki eşitlemeler ilk kopyadan daha hızlı çalışır ve araç günlükleriniz ne zaman ve ne zaman değiştiğini kaydeder.

4. Adım: Veri kaynaklarınızı hazırlama

Azure Databricks toplu işlem veya veri akışları kullanarak çok çeşitli veri kaynaklarını işleyebilir.

Veri kaynaklarından toplu işleme

Batch verileri genellikle çoğaltabileceğiniz veya başka bir bölgeye teslim ettiğiniz bir kaynakta bulunur.

Örneğin veriler genellikle belirli bir zamanlamaya göre bulut depolama alanına yüklenir. DR modunda, bu yüklemeleri ikincil bölge depolamanıza işaret edin ve iş yüklerini bu depolama alanından okuyacak ve bu depolamaya yazacak şekilde güncelleştirin.

Veri akışları

Veri akışını işlemek daha büyük bir zorluk. Akış verileri çeşitli kaynaklardan alınıp işlenebilir ve bir akış çözümüne gönderilebilir:

Kafka gibi mesaj kuyruğu
Veritabanı değişim verisi yakalama akışı
Dosya tabanlı sürekli işleme
Dosya tabanlı zamanlanmış işleme, tek seferlik tetikleyici olarak da bilinir.

Tüm bu durumlarda, veri kaynaklarınızı DR modunu işleyecek ve ikincil dağıtımınızı ikincil bölgenizde kullanacak şekilde yapılandırmanız gerekir.

Akış yazıcısı, işlenen veriler hakkında bilgi içeren bir kontrol noktası depolar. Bu denetim noktası, akışın başarıyla yeniden başlatılmasını sağlamak için yeni bir konuma değiştirilmesi gereken bir veri konumu (genellikle bulut depolaması) içerebilir. Örneğin, denetim noktasının source altındaki alt klasör dosya tabanlı bulut klasörünü depolayabilir.

Bu denetim noktası zamanında çoğaltılmalıdır. Herhangi bir yeni bulut çoğaltma çözümüyle denetim noktası aralığını eşitlemeyi göz önünde bulundurun.

Kontrol noktası güncellemesi yazıcının bir işlevidir, dolayısıyla veri akışının alınması veya işlenmesi ve başka bir akış kaynağında depolanması için geçerlidir.

Akış iş yükleri için denetim noktalarının müşteri tarafından yönetilen depolama alanında yapılandırıldığından emin olun; böylece son hata noktasından iş yükü yeniden başlatma için ikincil bölgeye çoğaltılabilir. İkincil akış işlemini birincil işleme paralel olarak çalıştırmayı da seçebilirsiniz.

5. Adım: Çözümünüzü uygulama ve test edin

Yönetilen olağanüstü durum kurtarma kullanıyorsanız, kurulumunuzun uçtan uca çalıştığını doğrulamak için hesap konsolundan planlı bir yük devretme tetikleyebilirsiniz. Aynı prosedür hem DR testlerini hem de gerçek kesintileri kapsar. Bkz. Yük devretme ve geri devretme.

DR kurulumunuzu düzenli olarak test edin. Test edilmemiş bir DR planı genellikle ihtiyacınız olduğunda başarısız olur. Bazı ekipler varsayımları, alıştırma işlemlerini doğrulamak ve ekibi runbook'a alıştırmak için birkaç ayda bir zamanlamaya göre etkin bölgeler arasında geçiş yapabilir.

Önemli

DR çözümünüzü gerçek dünya koşullarında düzenli bir zamanlamaya göre test edin.

Testte eksik bir nesne veya şablon ortaya çıkarsa planınızı güncelleştirin: bağımlılığı kaldırın, ikincil çalışma alanına çoğaltın veya başka bir şekilde kullanılabilir hale getirin.

Kuruluş ve yapılandırma değişikliklerini de test edin. DR planınız dağıtım işlem hattınızı etkiler, bu nedenle ekibin neleri eşitlenmiş tutacaklarını bilmesi gerekir. DR çalışma alanlarını ayarladıktan sonra altyapınızın, işlerinizin, not defterlerinizin, kitaplıklarınızın ve diğer çalışma alanı nesnelerinizin ikincil bölgede kullanılabilir olduğunu onaylayın.

Değişiklikleri tüm çalışma alanlarına dağıtmak için standart iş süreçlerinizi ve yapılandırma işlem hatlarınızı genişletin. Çalışma alanları genelinde kullanıcı kimliklerini yönetin ve yeni çalışma alanları için iş otomasyonunu ve izlemeyi yapılandırın.

Yapılandırma araçlarınızdaki değişiklikleri planlayın ve test edin.

Planlama ve test için yapılandırma değişiklikleri

Aşağıdakilerin her biri için yük devretme için bir plan hazırlayın ve tüm varsayımları test edin:

Veri alımı: Veri kaynaklarınızın nerede olduğunu ve bu kaynakların verilerini nereden edindiği hakkında bilgi edinin. Mümkün olduğunda kaynağı parametreleştirin ve ikincil dağıtım ve bölge için ayrı bir yapılandırma şablonu kullanın.
Yürütme değişiklikleri: İşleri veya diğer eylemleri tetikleyen bir zamanlayıcınız varsa, ikincil dağıtım veya veri kaynaklarıyla çalışan ayrı bir zamanlayıcıya ihtiyacınız olabilir.
Etkileşimli bağlantı: REST API'lerinin, CLI araçlarının veya JDBC/ODBC gibi diğer hizmetlerin kullanımı için yapılandırma, kimlik doğrulaması ve ağ bağlantılarının bölgesel kesintilerden nasıl etkilenebileceğini göz önünde bulundurun.
Otomasyon değişiklikleri: Tüm otomasyon araçları için.
Çıkışlar: Çıkış verileri veya günlükleri oluşturan tüm araçlar için.
Aşağı akış değişiklikleri: Azure Databricks okuma veya yazma işlemleri gerçekleştiren BI araçları, panolar, zamanlayıcılar ve üçüncü taraf tümleştirmeleri için, bunları ikincil çalışma alanında yeniden belirlemeyi ve sahiplerine bildirmeyi planlayın.

Yük devretme testi

DR'yi birçok senaryo tetikleyebilir: sorunsuz biçimde kapatamadığınız bir durumda bulut ağında, bulut depolamada veya başka bir temel hizmette beklenmeyen bir kesinti; planlı bir kapatma ya da kesinti; hatta test döngünüzün bir parçası olarak bölgeler arasında periyodik geçiş bile.

Yük devretmeyi test etmek için sisteme bağlanın ve kapatma komutunu çalıştırın. Tüm işlerin tamamlandığını ve kümelerin sonlandırıldığını onaylayın.

Eşitleme istemcisi (veya CI/CD araçları), ilgili Azure Databricks nesnelerini ve kaynaklarını ikincil çalışma alanına çoğaltır. İkincil çalışma alanını etkinleştirmek için, işleminiz aşağıdakilerden bazılarını veya tümünü içerebilir:

Platformun güncel olduğunu doğrulamak için testler çalıştırın.
Birincil bölgedeki havuzları ve kümeleri devre dışı bırakın, böylece başarısız olan hizmet çevrimiçi olduğunda birincil bölge yeni verileri işlemeye başlamaz.
Veri kaynaklarınız için kurtarma işlemini çalıştırın (aşağıya bakın).
İlgili havuzları başlatın (veya ilgili bir sayıya yükseltin min_idle_instances ).
İlgili kümeleri başlatın (sonlandırılmamışsa).
İşlerin eşzamanlı yürütme ayarını değiştirin ve ilgili işleri başlatın. Bunlar tek seferlik çalıştırmalar veya düzenli çalıştırmalar olabilir.
Azure Databricks çalışma alanınız için URL veya etki alanı adı kullanan herhangi bir dış araç için yapılandırmaları yeni denetim düzlemini hesaba katma amacıyla güncelleştirin. Örneğin REST API'leri ve JDBC/ODBC bağlantıları için URL'leri güncelleştirin. Denetim düzlemi değiştiğinde Azure Databricks web uygulamasının müşteriye yönelik URL'si değiştiğinden kuruluşunuzun kullanıcılarına yeni URL'yi bildirin.

Kurtarma işlemi ayrıntıları

En son eşitlenen verilerin tarihini denetleyin. Bkz . Olağanüstü durum kurtarma sektörü terminolojisi. Bu adımın ayrıntıları, verileri nasıl eşitlediğinize ve benzersiz iş gereksinimlerinize bağlı olarak değişir.
Veri kaynaklarınızı kararlı hale getirerek bunların tümünün kullanılabilir olduğundan emin olun. Azure Cloud SQL gibi tüm dış veri kaynaklarını ve Delta Lake, Parquet veya diğer dosyaları dahil edin.
Akış geri yükleme noktanızı bulun. İşlemi oradan yeniden başlatacak şekilde ayarlayın ve olası yinelemeleri tanımlayıp ortadan kaldırmaya hazır bir işlem oluşturun (Delta Lake bunu kolaylaştırır).
Veri akışı işlemini tamamlayın ve kullanıcıları bilgilendirin.

Geri yüklemeyi test et (geri dönüş)

Geri yüklemeyi test edin (geriye dönüş)

Geri dönüş sürecinin kontrolü daha kolaydır ve bakım penceresinde yapılabilir. Aşağıdaki adımların bazılarını veya tümünü planlayın:

Ana bölgenin geri yüklendiğine dair onayı alın.
yeni verileri işlemeye başlamaması için ikincil bölgedeki havuzları ve kümeleri devre dışı bırakın.
İkincil çalışma alanında bulunan yeni veya değiştirilmiş varlıkları birincil dağıtıma geri eşitleyin. Yük devretme betiklerinizin tasarımına bağlı olarak, nesneleri ikincil (DR) bölgesinden birincil (üretim) bölgeye eşitlemek için aynı betikleri çalıştırmanız mümkün olabilir.
Yeni veri güncelleştirmelerini birincil dağıtıma geri eşitleyin. Veri kaybını önlemek için günlüklerin ve Delta tablolarının denetim izlerini kullanabilirsiniz.
DR bölgesindeki tüm iş yüklerini kapatın.
İşleri ve kullanıcıların URL'sini birincil bölgeye değiştirin ve aşağı akış bağlantılarını (BI araçları, zamanlayıcılar, üçüncü taraf tümleştirmeleri) yeniden bu bölgeye geri yerleştirin.
Platformun güncel olduğunu doğrulamak için testler çalıştırın.
İlgili havuzları başlatın (veya ilgili bir sayıya yükseltin min_idle_instances ).
İlgili kümeleri başlatın (sonlandırılmamışsa).
İşler için eşzamanlı yürütmeyi değiştirin ve ilgili işleri başlatın. Bunlar tek seferlik çalıştırmalar veya düzenli çalıştırmalar olabilir.
Gerekirse, gelecekteki DR için ikincil bölgenizi yeniden yapılandırın.

Otomasyon betikleri, örnekler ve prototipler

AWS ve Azure için yönetilen olağanüstü durum kurtarma, çalışma alanını ve yönetilen tablo çoğaltmasını özel otomasyon olmadan işler. Aşağıdaki referanslar yalnızca yönetilen DR kapsamı dışında bir kendin yap (DIY) çözümü oluşturuyorsanız geçerlidir.

DIY DR işlem hatlarında, çalışma alanı varlıklarını kod olarak yönetmek ve birincil ve ikincil bölgelere birlikte dağıtmak için Databricks Terraform sağlayıcısını kullanın.

Azure Databricks'i Azure Data Factory'den yönetiyorsanız, ilgili ADF işlem hatlarını ikincil çalışma alanına eşlenen bağlı hizmeti işaret edecek şekilde çoğaltın.

Ek kaynaklar

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-06-24