Yönetilen felaket kurtarma

Yönetilen olağanüstü durum kurtarma (DR) Azure Databricks dağıtımınızı ikincil bir bölgeye çoğaltır, böylece bölgesel bir kesintiden dakikalar içinde kurtulabilirsiniz. Azure Databricks çoğaltma işlem hattını, ikincil kataloglardaki çoğaltılan katalogların durumunu ve yük devretme işlemini yönetir. Çoğaltma betikleri yazmaz veya korumazsınız.

Genel DR kavramları ve en iyi yöntemler de dahil olmak üzere olağanüstü durum kurtarmaya el ile yaklaşım için bkz . Olağanüstü durum kurtarma.

Important

Yönetilen DR'ye erişim kısıtlıdır. Azure Databricks hesap ekibiniz aracılığıyla erişim için başvurun. Azure Databricks, kabul edildikten sonra hesabınızda yönetilen DR'ye olanak tanır.

Yönetilen olağanüstü durum kurtarma nedir?

Managed DR, halihazırda işlettiğiniz çalışma alanları ve meta depoların üzerine kurulur. Biri birincil bölgenizde, biri ikincil bölgenizde ve her bölgede bir meta veri deposu olmak üzere iki Azure Databricks çalışma alanı getirirsiniz. Yönetilen DR o zamanlar:

• Birincilden ikincile, seçtiğiniz kategorileri sürekli olarak kopyalar. Her iki kategori de bağımsız olarak isteğe bağlıdır: Unity Kataloğu meta verileri ve yönetilen tablo verileri ile not defterleri, işler, SQL ambarları, kümeler ve ACL'ler gibi çalışma alanı varlıkları.
• İstemcilerin, yeniden yapılandırma gerektirmeden yük devretme sonrasında çalışmaya devam etmesini sağlayan ve her zaman mevcut birincili işaret eden tek bir bağlantı dizesi olan isteğe bağlı sabit URL sağlar.
• Bir DR testi veya gerçek bir kesinti için istediğiniz zaman yük devretmeyi tetiklemenizi sağlar.

Çalışma alanı varlık kimlikleri bölgeler arasında korunur; bu nedenle bir çalışma alanı varlığına kimliğini kullanarak başvuran URL'ler yük devretmeden sonra da doğru şekilde çözümlenmeye devam eder.

Nelerin çoğaltıldığı

Yönetilen DR, her çoğaltma döngüsünde aşağıdakileri çoğaltabilir. Her iki kategori de isteğe bağlıdır, bu nedenle şunlardan birini veya her ikisini de etkinleştirebilirsiniz:

• Unity Kataloğu meta verileri ve verileri: Veri içeren Delta Lake'teki Unity Kataloğu tarafından yönetilen tablolar, dış tablolar ve birimler (yalnızca meta veriler), görünümler, işlevler ve tüm izin yetkilendirmeleri. Kataloğun yalıtım modu kopyalanır. Kaynak katalog açıksa, kopya açıktır. Kaynak yalıtılmışsa ve birincil çalışma alanına bağlıysa, replika da yalıtılmıştır ve ikincil çalışma alanına bağlıdır.
• Çalışma alanı varlıkları: Not defterleri, işler, SQL ambarları, kümeler, taslak AI/BI panoları, dosyaları ve klasörleri ve bunların ACL'leri. SQL ambarları STOPPED durumunda, kümeler ise TERMINATED durumunda çoğaltılır. İkincil sistemdeki iş zamanlamaları duraklatılmıştır.

Çoğaltılan nesnelerin sahipliği

Yönetilen DR, ikincil tarafta çoğaltılmış bir güvenli nesne (katalog, şema, tablo, görünüm, fonksiyon veya birim) oluşturduğunda, ilk sahip, çoğaltmayı çalıştıran Azure Databricks hizmet sorumlusu kimliğidir; çünkü Unity Catalog, sahipliği nesneyi oluşturan kimliğe atar. Yönetilen DR daha sonra çoğaltmanın sahipliğini, birincildeki ilgili güvenliği sağlanabilir nesnenin sahibine eşleşecek şekilde devreder.

Birincil veritabanındaki bir korunabilir nesnenin sahibi, hesaptan silinmiş bir kullanıcıysa, yönetilen DR sahipliği artık var olmayan bir güvenlik öznesine devredemez. Bu durumda, çoğaltılmış güvenli nesne sahibi olarak Azure Databricks hizmet sorumlusunu korur. Bu sorunu çözmek için, birincil içindeki güvenli hale getirilebilir dosyaya geçerli bir sahip atayın ve DR'nin bunu çoğaltmasına izin verin.

Requirements

• Hem birincil hem de ikincil bölgelerde Premium planındaki bir çalışma alanı.

• Görev Açısından Kritik çalışma alanı eklentisi her iki çalışma alanında da etkindir. Bkz. Her iki çalışma alanında da Görev Açısından Kritik'i etkinleştirme.
• Her iki çalışma alanında da sunucusuz işlem etkinleştirildi. Sunucusuz işlem, Unity Kataloğu etkin çalışma alanlarının çoğunda varsayılan olarak kullanılabilir. Bkz. Sunucusuz bilişime bağlanma.
• Çoğaltmayı planladığınız katalogların kullandığı her harici konum için TÜM AYRICALIKLAR içeren hesap yöneticisi rolü.
• Tüm çalışma alanlarının etkinleştirildiği hesap düzeyinde SSO ve scim aracılığıyla hesaba eşitlenen kimlikler sayesinde kullanıcılar, gruplar ve hizmet sorumluları her iki bölgede de bulunur.
• Sabit URL'ler için: Azure Databricks etki alanınız için sağlanan özel bir URL (hesap ekibinizle iletişime geçin) ve hesap düzeyinde OAuth.
• İkincil bölgede, aynı Azure Databricks hesabında ve birincil hesabınızla aynı bulutta ikincil çalışma alanı ve Unity Kataloğu meta veri deposu. İkincil çalışma alanı birincil ağ, Özel Bağlantı ve müşteri tarafından yönetilen anahtar yapılandırmasıyla eşleşmelidir. İkincil meta veri deposu, çoğaltılan kataloglarla adları paylaşan kataloglar içermemelidir. çalışma alanı varlık çoğaltması için, Azure Databricks ilk çoğaltma tamamlandığında ikincil çalışma alanında var olan kapsam içi varlıkları siler. Kapsam dışı varlıklar etkilenmez, bu nedenle ikincil çalışma alanının boş olması gerekmez.
• Birincil kataloglarınız tarafından başvuruda bulunan her biri için ikincil bölgede karşılık gelen dış konum ve depolama kimlik bilgileri. Yönetilen DR dış konumları veya depolama kimlik bilgilerini otomatik olarak çoğaltmaz; bunları ikincilde oluşturmanız gerekir.

İkincil çalışma alanının sunucusuz işlemi, bölgeler arası çoğaltma sırasında kaynak depolamadan okuma yaptığından, hem kaynak depolama hem de ikincil depolama, Azure Databricks sunucusuz ağ erişimine her iki yönde de izin vermelidir.

Kaynak depolama alanınıza veya DBFS köküne ağ erişimini kısıtlarsanız, kaynak depolama güvenlik duvarında ikincil bölgenin denetim düzlemi IP adreslerine ve ikincil DBFS güvenlik duvarında birincil bölgenin denetim düzlemi IP adreslerine de izin verin. Her bir bölgede izin verilmesi gereken denetim düzlemi IP adresleri için Azure Databricks denetim düzlemine gelen trafik bölümüne bakın.

• İkincil bölgede bulunan, ikincil depolama hesaplarında Depolama Blobu Verisi Katkıda Bulunanı rolüne sahip olan ve ikincil çalışma alanına depolama kimlik bilgisi olarak eklenen bir Azure Databricks Erişim Bağlayıcısı.
• sunucusuz işlemin özel uç noktalar üzerinden depolamaya ulaşabilmesi için ikincil bölgede, ikincil çalışma alanına atanmış bir Ağ Bağlantısı Yapılandırması (NCC). Bkz. Azure kaynaklarına özel bağlantı yapılandırma.
• Çoğaltılan kataloglarınızda başvurulan her kaynak ve ikincil depolama hesabı için özel uç noktalar. ADLS Gen2 depolaması için, her hesap için hem dfs hem de blob alt kaynakları adına bir özel uç nokta oluşturun. Bunları Azure portalında onaylayın.

Her iki çalışma alanında da Görev Açısından Kritik'i etkinleştirme

Yük devretme grubu oluşturmadan önce hem birincil hem de ikincil çalışma alanlarınızda Kritik Görev eklentisini etkinleştirin. Eklentinin etkinleştirildiği her çalışma alanındaki işlem kullanımı, Mission Critical ücreti üzerinden faturalandırılır. Geçerli fiyat için Azure Databricks hesap ekibinize başvurun.

1. Hesap konsolunda Çalışma Alanları'na ve ardından çalışma alanına tıklayın.
2. Eklentiler sekmesine tıklayın.
3. Görev Açısından Kritik kartında anahtarı açın ve onaylayın.

İkincil çalışma alanı için yineleyin.

İsteğe bağlı: kararlı URL

Azure Databricks kararlı URL'nin kullanılmasını önerir. Kararlı URL her zaman mevcut birincil çalışma alanına yönlendirildiğinden, bu URL üzerinden bağlanan istemcilerin yük devretmeden sonra yeniden yapılandırılması gerekmez. Özgün çalışma alanı URL'si, bu çalışma alanına doğrudan erişim için geçerli olmaya devam eder, ancak yük devretmeden sonra artık ikincil olan eski birincile işaret eder. Aşağıdaki aşağı akış istemcilerini özgün çalışma alanı URL'si yerine kararlı URL'ye işaret edin:

• Azure Databricks web kullanıcı arabirimi.
• SQL ambarlarına JDBC ve ODBC bağlantıları.
• Doğrudan REST API istekleri.

Kararlı URL’ler, ön uç (gelen) Özel Bağlantı ile desteklenir. Gelen Özel Bağlantı ile kararlı URL, standart çalışma alanı URL'si biçimi yerine kararlı bir bağlantı kimliğiyle özel URL'nizi kullanır.

Çoğaltmayı ayarlama

Yeni bir yük devretme grubu CREATING → INITIAL_REPLICATION → ACTIVE üzerinden geçer. İlk çoğaltma döngüsü, tüm kapsam içi verileri ikincil değere kopyalar. Büyük çalışma alanları için ilk çalışma alanı varlığı önyüklemesi iki haftaya kadar sürebilir. Bu bekleme tek seferliktir. İlk önyükleme tamamlandıktan sonra çoğaltma sürekli olarak çalışır.

Çoğaltma sırasında kapsam dahilindeki ikincil kataloglar salt okunurdur ve ikincil çalışma alanında işlem kaynakları kullanılamaz. İkincil bölgeye yazmadan doğrulama sorguları çalıştırmak için Azure Databricks ikincil bölgede ayrı bir salt okunur izleme çalışma alanı önerir.

Yük devretme grubu oluşturmak için:

1. Hesap konsolunda Dayanıklılık'a tıklayın.
2. Kararlı bir URL kullanmayı planlıyorsanız Kararlı URL'ler sekmesine ve ardından Kararlı URL oluştur'a tıklayın. Bir ad girin, geçerli birincil çalışma alanını seçin ve kararlı URL'yi oluşturun. Aşağı akış istemcilerini (JDBC, ODBC, Azure Databricks web kullanıcı arabirimi, doğrudan API istekleri) özgün çalışma alanı URL'si yerine kararlı URL'ye yönlendirin.
3. Yük devretme grupları sekmesine, ardından Yük devretme grubu oluştur'a tıklayın.
4. Formu doldurun:
   • Yük devretme grubu adı: Yük devretme grubu için seçtiğiniz ad.
   • Birincil çalışma alanı: Birincil çalışma alanınızdır.
   • İkincil çalışma alanı: İkincil bölgedeki çalışma alanı.
   • Çalışma alanı varlıklarını çoğaltma (isteğe bağlı): Varsayılan olarak kapalı. Not defterlerini, işleri, SQL ambarlarını, kümeleri, panoları, dosyaları ve klasörleri (ve bunların ACL'lerini) birincilden ikincilye çoğaltmak için açın. Her iki çalışma alanının da Görev Açısından Kritik eklentisinin etkinleştirilmesini gerektirir. Çalışma alanı varlık çoğaltmasını açarsanız, ilk çoğaltma tamamlandığında Azure Databricks ikincil içindeki mevcut kapsam içi varlıkları siler. Kapsam dışı varlıklar etkilenmez.
   • Kararlı URL (isteğe bağlı): 2. adımda oluşturduğunuz kararlı URL.
   • Çoğaltma kapsamı: Çoğaltılması gereken kataloglar. Bu alan kullanılabilir duruma gelmeden önce bir birincil çalışma alanı seçmelisiniz.
   • Depolama eşlemeleri: Çoğaltılan kataloglarınızın birincil bölgede kullandığı her dış konum için, depolama yolunu ikincil bölgede oluşturduğunuz ilgili dış konuma eşleyen bir girdi ekleyin (bkz . Gereksinimler). Ön ek eşleştirme için * öğesini joker karakter olarak kullanabilirsiniz.
5. Yük devretme grubu oluştur'a tıklayın.

Örneğin, bir Azure depolama eşlemesi ile abfss://data@primary.dfs.core.windows.net/*eşlenebilirabfss://data@secondary.dfs.core.windows.net/*.

Yönetilen DR tarafından oluşturulan kaynaklar

Bir yük devretme grubu oluşturduğunuzda, yönetilen DR çoğaltma işlem hattının bölgeler arasında veri kopyalamak için kullandığı yardımcı Unity Kataloğu kaynaklarını sağlar. Hem birincil hem de ikincil meta veri depolarında yönetilen DR şunları oluşturur:

• Diğer bölgedeki çalışma alanını işaret eden bir bağlantı .
• Çoğaltılan her katalog için bir yabancı katalog. Yabancı katalog, diğer bölgedeki ilgili kataloğa başvurur.

Bu kaynaklar, Katalog Gezgini'nde kendi kataloglarınızla birlikte görünür. Bunları, Azure Databricks olağanüstü durum kurtarma tarafından oluşturulup yönetildiklerini belirten yorumlarından tanıyabilirsiniz.

Important

Varsayılan olarak, bu kaynakları yalnızca bir meta veri deposu yöneticisi değiştirebilir veya silebilir. Yönetilen DR tarafından oluşturulan bağlantıları veya yabancı katalogları silmeyin. İkisinden herhangi birinin silinmesi, yük devretme grubu için çoğaltmayı bozar.

Sabit çalışma alanı kimliği

Bazı araçlar, Databricks Terraform sağlayıcısı ve DatabricksVarlık Paketleri dahil olmak üzere çalışma alanını URL'si yerine çalışma alanı kimliğine göre tanımlar. Her kararlı URL'nin, mevcut birincil çalışma alanına yönelen bir kararlı çalışma alanı kimliği vardır; bu nedenle bu araçlar yük devretmeden sonra etkin çalışma alanını hedeflemeye devam eder. Bir araç çalışma alanı kimliği istediğinde, normal bir çalışma alanı kimliğini kullanır gibi kararlı çalışma alanı kimliğini kullanın.

Kararlı çalışma alanı kimliğini bulmak için Databricks CLI ile hesabınızın kararlı URL'lerini listeleyin ve ilgili kararlı URL'nin alanını okuyun stable_workspace_id :

databricks api get /api/disaster-recovery/v1/accounts/<account-id>/stable-urls

Databricks Varlık Paketleri ve Terraform ile dağıtın

Databricks Varlık Paketleri (DABs) ve Databricks Terraform sağlayıcısı, çalışma alanı ana bilgisayar URL'si veya Azure Databricks hesabının özel URL'si ile çalışma alanı kimliğinin birleşimiyle bir çalışma alanını hedefler. Yük devretme işleminden sonra geçerli birincil öğeye dağıtmaya devam etmek için konağı, özgün çalışma alanı başına URL'nin değil, kararlı URL'nin konak bölümü olan özel URL'nize ayarlayın ve alanda workspace_id belirtin. Birlikte mevcut birincile yöneldikleri için CI/CD işlem hatlarınız, bir yük devretme işleminden sonra herhangi bir yapılandırma değişikliği gerektirmeden etkin çalışma alanına dağıtım yapmaya devam eder.

• Yeni dağıtımlar: İlk dağıtımdaki özel URL'yi ve kararlı çalışma alanı kimliğini kullanın.
• Mevcut dağıtımlar: Önceki Terraform projenizdeki durumu özel URL ve kararlı çalışma alanı kimliğiyle yapılandırılmış yeni bir projeye aktarın ve ardından önceki projeyi kaldırın. Mevcut bir projeyi yeniden belirlemeyin; dağıtım artık özgün çalışma alanı başına URL'de oluşturduğu kaynakları tanımaz, bu nedenle yeniden dağıtım bunları yok eder ve yeniden oluşturur.
• DAB'ler: çalışma alanı varlıklarının çoğaltılmasını yük devretme grubunda etkinleştirin. Paket dağıtım durumunu çalışma alanında depolar ve bu durum yalnızca çalışma alanı varlık çoğaltmasının bir parçası olarak yeni birincil öğeye ulaşır.

Note

Yük devretme işleminden sonra ilk yeniden dağıtım, yönetilen DR'nin çoğaltmadığı kaynakları yeniden oluşturur çünkü bunlar yeni birincil sunucuda mevcut değildir. Çoğaltılan kaynaklar yerinde bırakılır. Yönetilen DR'nin neleri çoğaltıp neleri çoğaltmadığı hakkında bilgi için Sınırlamalar bölümüne bakın.

Çoğaltmayı izleme

Yük devretme grupları sekmesi, her yük devretme grubunun geçerli durumunu, çoğaltma noktasını ve tüm etkin hataları gösterir. Olası durumlar:

State	Meaning
CREATING	Yük devretme grubu oluşturuluyor.
INITIAL_REPLICATION	İlk çoğaltma döngüsü devam ediyor. Yük devralma henüz kullanıma sunulmadı.
ACTIVE	Çoğaltma sabit durumda. Yük devretme kullanılabilir.
FAILING_OVER	Yük devri sürüyor.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED	İşlem tamamlanmadı. Rehberlik için yük devretme grubunun durum ayrıntılarını denetleyin.

Ayrıntı sayfasını açmak için bir yük devretme grubunun adını seçin. Çoğaltma sürekli çalışır, ancak çoğaltma noktası tüm kapsam içi kaynakların en son ne zaman birlikte kopyalandığını gösterir. Tek tek kaynaklar daha güncel olabilir, ancak çoğaltma noktasından sonraki tüm veriler ikincil kaynakta bulunamaz ve yük devretme sırasında kaybolabilir.

Geçmiş RPO eğilimlerini izlemek ve çoğaltmayı engelleyen hataları görmek için sistem tablosunu sorgula system.replication.states . Bkz. Çoğaltma sistemi tablo referansı. En yaygın hata sınıfları ve bunların nasıl çözüleceğini öğrenmek için bkz. Başvuru.

Yük devretme ve geri yükleme

Aynı prosedür, hem planlı yük devretmeyi (DR testleri, zamanlanmış bakım) hem de planlanmamış yük devretmeyi (bölgesel bir kesinti) kapsar. Geri geçiş yapmak için, prosedürü bölgeleri ters çevirerek yineleyin.

Yük devretmeyi tetiklediğinizde Azure Databricks:

• Kararlı URL'yi (ekliyse) yeni birincil bölgeye yönlendirir.
• Çoğaltma yönünü tersine çevirir.
• önceki birincilde iş zamanlamalarını askıya alır.
• Yük devretme grubunu FAILING_OVER üzerinden INITIAL_REPLICATION konumuna geçirir.

Yük devretmek için:

1. Ekibinize yedek sisteme geçişin başlamak üzere olduğunu bildirin.

2. Yalnızca planlı yük devretme için:

   1. Birincil çalışma alanında, çalışan tüm kümeleri sonlandırın ve tüm SQL ambarlarını durdurun.
   2. Birincil düğüme yapılan yazmaların durduğunu doğrulayın, ardından replikasyonun güncel duruma gelmesini bekleyin. Kontrol etmek için yük devretme grubunun ayrıntı sayfasını açın ve çoğaltma noktasının yazma işlemlerini durdurduğunuz zamandan birkaç saniye içinde olduğunu doğrulayın.

3. Hesap konsolunda, Dayanıklılık → Yük devretme grupları'na tıklayın, ardından yük devretme grubunun adına tıklayın.

4. Yedek sisteme geçiş'e tıklayın.

5. Yeni birincil bölgeyi seçin ve onaylayın. Yük devretme işlemi dakikalar içinde tamamlanır.

6. Yeni birincil düğümde, yük devrinden önce çalışmakta olan bilgi işlem örneğini başlatın. Çoğaltılan kümeler ve SQL ambarları, sırasıyla TERMINATED ve STOPPED durumlarında yeni birincile ulaşır.

7. Yeni birincilde ihtiyacınız olan iş zamanlamalarını manuel olarak yeniden başlatın. Önceki birincilin zamanlamaları zaten duraklatılmış durumda.

Kararlı URL aracılığıyla bağlanan istemciler yük devretme işleminden sonra çalışmaya devam ediyor. Hâlâ orijinal çalışma alanı URL’sini kullanan istemcileri, kararlı URL’ye veya yeni birincil çalışma alanının URL’sine yönlendirin.

Important

Planlanmamış bir yük devralma durumunda, son çoğaltma noktasından sonra birincil sunucuya yazılan veriler kaybolabilir. Herhangi bir kaybın RPO hedefiniz içinde olduğunu onaylayın.

İpucu

Yük devretme işlemini düzenli olarak, örneğin her çeyrekte bir, test edin; böylece ekibiniz gerçek bir kesinti yaşanmadan önce sürece aşina olur.

Yönetilen DR'yi yok etmek

1. Hesap konsolunda Dayanıklılık → Yük devretme grupları seçeneğine tıklayın, ardından yük devretme grubunun adına tıklayıp onu silin. Çalışma alanında bir yük devretme grubu etkin durumdayken Mission Critical'i kapatamazsınız.
2. Mission Critical ücretlendirmesini durdurmak için, her bir çalışma alanında Eklentiler sekmesinden Mission Critical'ı kapatın.

Sınırlamalar

Yönetilen DR aşağıdaki sınırlamalara sahiptir:

• Çoğaltılmayanlar: somutlaştırılmış görünümler, akış tabloları, Lakeflow işlem hatları, yönetilen volume verileri (meta veriler çoğaltılır), Unity Catalog ve çalışma alanı gizli anahtarları, ML modelleri, model sunma uç noktaları, vektör arama dizinleri, Delta paylaşımları, yayımlanmış AI/BI panoları (taslaklar çoğaltılır) ve Lakeflow işlem hatları dışındaki Spark Structured Streaming. Satır filtreleri veya sütun maskeleri olan tablolar ile ABAC etiketli kaynaklar, sistem tablosunda replikasyon başarısız oldu olarak işaretlenir ve siz kaynağı yük devretme grubunun kapsamından kaldırana kadar bu hatalar RPO’nun ilerlemesini engeller.
• Dış altyapılardan yönetilen tablo yazma işlemleri algılanabilirliği sınırlıdır. Yönetilen DR, Azure Databricks işlem kaynakları tarafından gerçekleştirilen yazma işlemleri sonucunda Unity Catalog tarafından yönetilen tablolardaki değişiklikleri algılar. Iceberg REST Kataloğu gibi açık API’ler aracılığıyla harici (Azure Databricks dışı) bir işleme altyapısından çoğaltılan yönetilen bir tabloya yapılan yazma işlemleri algılanmayabilir; bu nedenle bu yazma işlemleri ikincil ortama çoğaltılmayabilir ve yük devretme sırasında kaybolabilir. Yönetilen DR ile çoğaltılan tablolar için Azure Databricks işlem kaynağı üzerinden yazın.
• İkincil kapsam içi kataloglar salt okunurdur. Yalnızca okunur, yalnızca çoğaltılmış varlıklar için geçerlidir. Yine de yönetilen DR kapsamı dışındaki güvenliği sağlanabilir nesneler için kendi çoğaltmanızı yapılandırabilirsiniz. Bununla birlikte, yönetilen DR etkinken ikincil çalışma alanında hesaplama çalıştıramazsınız; bu da orada kendin yap bir çoğaltma işlem hattı işletme olanağını sınırlar.
• Unity Kataloğu güvenli hale getirilebilir olarak yeniden adlandırılması, ikincil katalogda silme ve yeniden oluşturma işlemini tetikler. Yönetilen tablolar için yeniden adlandırma, tablo verilerini bir sonraki döngüde yeniden çoğaltır. Sabit durumlu çoğaltma sırasında yeniden adlandırmaktan kaçının.
• UNDROP ikincile yayılmaz.
• Hesap başına en fazla 300 katalog.
• Hesap başına en fazla 100 yük devretme grubu.
• Yük devretme grubu başına en fazla 10 katalog.
• İlk çalışma alanı varlığı önyüklemesi, büyük çalışma alanları için 2 haftaya kadar sürebilir.

• Yönetilen DR ile kullanılan çalışma alanı depolama hesaplarında çalışma alanı depolama güvenlik duvarının kullanılması el ile yapılandırma gerektirir. Azure Databricks verileri çoğaltabilmesi için depolama güvenlik duvarında ilgili denetim düzlemi IP adreslerine izin vermelisiniz. Bkz . Gereksinimler.

Reference

Kaynak çoğaltılamadığında, yük devretme grubu sistem tablosunda bir hata sınıfı system.replication.states ve etkilenen kaynağı tanımlayan bir ileti gösterir. Aşağıdaki bölümler en yaygın hata sınıflarını ve bunların nasıl çözüleceğini kapsar. Altta yatan sorunu düzelttikten sonra çoğaltma otomatik olarak düzelir.

DR_MISSING_DEPENDENCY

Varlık, ikincilde var olmayan bir bağımlılığa başvurur, bu nedenle varlık çoğaltılamaz. Alt sınıf eksik bağımlılık türünü tanımlar ve , DR_MISSING_DEPENDENCY.CATALOG, .SCHEMAveya .TABLEolarak .RESOURCEgörünür. Çözüm hepsi için aynıdır.

1. Varlığın eksik bağımlılık nedeniyle birincilde de bozulmuş olup olmadığını denetleyin. Bu durumda, birincil varlıktaki varlığı düzeltin veya kaldırın.
2. Varlık birincil ortamda geçerliyse, bağımlılık ya herhangi bir yük devretme grubunun çoğaltma kapsamına dahil değildir ya da bu ya da başka bir yük devretme grubunun kapsamına dahildir ancak çoğaltılamamıştır. Bağımlılık kapsam dahilinde değilse, yük devretme grubunun çoğaltma kapsamını onu da içerecek şekilde düzenleyin. Bağımlılık zaten kapsam içindeyse, çoğaltılmasını engelleyen hata için system.replication.states’u denetleyin ve bu hatayı çözün.

DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Yönetilen DR, yük devretme grubunun depolama eşlemelerini varlığın kaynak depolama konumuna uygulayarak çoğaltılan varlıkların nereye yerleştirileceğine karar verir. Bir eşleme, bir konumla ya tam olarak eşleşebilir ya da alt yolları da kapsayan bir önek olarak eşleşebilir. Bu hata, eşlemenin kaynak depolama konumunu kapsamadığı anlamına gelir, bu nedenle yönetilen DR varlığın ikincil konumuna yerleştirileceği yeri belirleyemez. Dış tablolar ve volümler için eksik bir eşleme, aynı konum URI'sinin birincil ve ikincilde kullanıldığı anlamına gelir. İletideki storage_location, eşlenmemiş kaynak yoludur.

1. Hesap konsolunda Dayanıklılık → Yük devretme grupları bölümüne gidin ve yük devretme grubunu düzenleyin.
2. Depolama eşlemeleri'nin altında, iletideki kaynak konumu kapsayan bir eşleme ekleyin veya genişletin. Alt yolları kapsamak için bir ana yolu eşleyin ve önek eşleştirmesi için /* son ekini ekleyin. Bkz. depolama eşlemeleri.
3. İkincil meta veri deposundaki bir dış konumun eşlemenin hedef yolunu zaten kapsadığını onaylayın. Yük devretme grubu, hedefi mevcut bir dış konum altında olmayan bir eşlemeyi reddeder, bu nedenle mevcut değilse önce bu dış konumu oluşturun. Bkz. Unity Kataloğu'nu kullanarak bulut nesne depolamasına bağlanma.

DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Depolama eşlemesi, çoğaltılmış bir varlığı ikincildeki bir hedef yola eşledi; ancak ikincil meta veri deposundaki hiçbir dış konum bu yolu kapsamadığından Unity Catalog'un varlığın verilerini yerleştirebileceği bir konum yoktur. Mesajdaki storage_location, ortaya çıkarılan ikincil (hedef) yoldur.

Bu genellikle iki anlama gelebilir: ya daha önce yolu kapsayan bir dış konum kaldırılmış veya daraltılmıştır ya da yeni çoğaltılmış bir varlık, hiçbir dış konumun kapsamadığı ikincil bir yola karşılık geliyordur. İkinci durum, örneğin, depolama eşlemelerinizin hiçbirinin kapsamadığını bir depolama yolu altında birincil tabloda bir dış tablo oluşturduğunuzda gerçekleşir. Managed DR daha sonra tablonun orijinal yoluna geri döner; bu yol, ikincil meta veri deposundaki hiçbir dış konum tarafından kapsanmadığından verilerin yerleşeceği bir yer kalmaz.

1. İletinin storage_locationiçinden açığa çıkarılan ikincil yolu tanımlayın.
2. İkincil meta veri deposundaki hangi dış konumun bu yolu kapsaması gerektiğine karar verin: genişletebileceğiniz mevcut bir dış konum veya oluşturduğunuz yeni bir konum.
3. Ya yük devretme grubunun depolama eşlemelerini, yol zaten mevcut olan bir dış konum altında çözümlenecek şekilde ayarlayın ya da dış konumu (depolama kimlik bilgisiyle birlikte) oluşturup eşlemeyi onu işaret edecek şekilde genişletin. Bkz. Unity Kataloğu'nu kullanarak bulut nesne depolamasına bağlanma.

DR_INTERNAL_ERROR

Çoğaltma sırasında sistem tarafı hatası oluştu. Eylem gerekmez; sistem otomatik olarak kurtarılır. Sorun kendi kendine çözülmezse Azure Databricks desteğe başvurun.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Yönetilen DR, görünümü verilen erişim izinleriyle birlikte çoğaltır; ancak diğer kataloglardaki nesnelere referans veren bir görünüm için, görünüm sahibinin ikincil tarafta bu referans verilen nesnelere de erişimi olması gerekir, çünkü görünüm sahibinin ayrıcalıklarıyla çalışır. Bu hata, sahibinin ikincil tarafta bu erişime sahip olmadığı anlamına gelir; bu nedenle orada atıfta bulunulan nesnelerde bu erişimi tanımalısınız.

1. Görünümün başvurduğu nesneleri ve görünümün sahibini bulun. Başvurulan nesneler tanımda tam nitelikli catalog.schema.object adlar olarak görünür; yetkiler sahibine verilmelidir; bunu Katalog Gezgini'ndeki Owner alanından da okuyabilirsiniz.

   SHOW CREATE TABLE <catalog>.<schema>.<view>;
   

2. İkincil sunucuda, başvurulan her bir nesne üzerindeki sahibinin mevcut ayrıcalıklarını denetleyin. Bir tablonun okunması, kataloğunda USE CATALOG, şemasında USE SCHEMA ve tabloda SELECT gerektirir.

   SHOW GRANTS `<view_owner>` ON CATALOG <ref_catalog>;
   SHOW GRANTS `<view_owner>` ON SCHEMA <ref_catalog>.<ref_schema>;
   SHOW GRANTS `<view_owner>` ON TABLE <ref_catalog>.<ref_schema>.<ref_table>;
   

3. Referans verilen her nesnede, görünüm sahibine eksik olan ayrıcalıkları verin.

   GRANT USE CATALOG ON CATALOG <ref_catalog> TO `<view_owner>`;
   GRANT USE SCHEMA ON SCHEMA <ref_catalog>.<ref_schema> TO `<view_owner>`;
   GRANT SELECT ON TABLE <ref_catalog>.<ref_schema>.<ref_table> TO `<view_owner>`;
   

4. Görünümün başvurduğu her kataloğun, bir yük devretme grubunun çoğaltma kapsamına dahil edildiğini ve böylece ikincilde de mevcut olduğunu doğrulayın.

Daha fazla bilgi için bkz. Unity Kataloğu'nda ayrıcalıkları yönetme.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Bölgeler arası tablo-veri çoğaltması sırasında, ikincil çalışma alanının sunucusuz işlemi kaynak depolamadaki verileri okur ve depolama alanı ağ bağlantısını reddetti: depolama güvenlik duvarı veya ağ kuralı bunu engelledi veya gerekli bir özel uç nokta eksik veya onaylanmadı.

Kaynak ve ikincil depolama alanınızın, Gereksinimler bölümünde açıklandığı gibi sunucusuz Azure Databricks ağ erişimine izin vermekte olduğunu doğrulayın.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Yönetilen DR, verileri kopyalamak için ikincil çalışma alanında sunucusuz bilgi işlem kullanır ve burada sunucusuz bilgi işleme izin verilmez. Bu genellikle hesap veya çalışma alanı için sunucusuz seçeneğinin kapalı olduğu veya çalışma alanının uygun olmadığı anlamına gelir.

1. İkincil çalışma alanının uygun olduğunu onaylayın. Sunucusuz işlem, desteklenen bir bölgedeki Unity Kataloğu etkin çalışma alanlarında varsayılan olarak kullanılabilir. Bkz. Sunucusuz bilişime bağlanma.
2. Hesap genelinde devre dışı bırakma olup olmadığını denetleyin. Hesap konsolunda Ayarlar → Özellik etkinleştirme bölümüne gidin ve sunucusuz geçiş düğmesinin mevcut ve kapalı olup olmadığını denetleyin.
3. İhtiyacınız olan kapsam için sunucusuz özelliğini etkinleştirin. Uygun olan tüm çalışma alanlarını etkinleştirmek için hesap yöneticisi, hesap düzeyindeki sunucusuz geçişini etkinleştirir. Yalnızca ikincil çalışma alanını etkinleştirmek için hesap düzeyi geçişini kapalı bırakın ve çalışma alanı yöneticisinin çalışma alanının Önizlemeleri'nden sunucusuz özelliğini etkinleştirmesini sağlayın.
4. Açma/kapatma düğmesi yoksa veya etkinleştirmenize rağmen sunucusuz yine de çalışmıyorsa Azure Databricks hesap ekibinizle iletişime geçin.

DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Yönetilen DR, ikincil tarafta eşlenen hedef yolunda çoğaltılmış bir nesne oluşturduğunda Unity Catalog, yolun orada zaten mevcut olan depolamayla çakıştığını belirleyerek bu yolu reddeder; buna mevcut bir dış konum, önceki ya da kısmi bir kurulumdan kalmış bir korunabilir nesne, yönetilen bir konum veya çalışma alanının varsayılan (DBFS) depolaması dahildir.

1. Yolu neyin kapladığını belirleyin.

   Katalog Gezgini'nde dış konumlarınızı, yönetilen depolama konumlarınızı ve dış tablolar ile birimleri gözden geçirip yolu hedef yolu kapsayan veya onunla çakışan nesneyi bulun.

2. Çakışan nesnenin yolun sahibi olmaması gerekiyorsa onu kaldırın. Yaygın nedenlerden biri, önceki bir kurulumdan kalmış bir harici tablo veya harici birimdir; artık gerekli değilse silin. Eğer yolu kapsamaması gereken harici bir konumsa, kaldırın veya yeniden tanımlayın.

3. Aksi takdirde, yük devretme grubunun depolama eşlemesini ayrılmış ve çakışmayan bir hedef yoluna yeniden yönlendirin. Geniş bir bucket kökü yerine belirli bir alt yolu tercih edin ve çalışma alanının varsayılan depolama alanından (DBFS) kaçının.

DR_UNSUPPORTED_FEATURE

Varlık, yönetilen DR’nin desteklemediği bir özelliği kullanır. Alt sınıf desteklenmeyen özelliği tanımlar ve örneğin olarak DR_UNSUPPORTED_FEATURE.ABAC_POLICYgörünür. Bu hatayı düzeltmenin iki yolu vardır.

1. Desteklenmeyen özelliği birincil çalışma alanında bulunan varlıktan kaldırın.
2. Özelliği kaldıramıyorsanız, varlığı yük devretme grubunun çoğaltma kapsamı dışına çıkarmayı değerlendirin.

DR kavramları ve en iyi yöntemler için bkz . Olağanüstü durum kurtarma.