Azure SQL Yönetilen Örneği ile Günlük Tekrar Yürütme Hizmetine Genel Bakış

Şunlar için geçerlidir:Azure SQL Yönetilen Örnek

Bu makale, veritabanlarını SQL Server'dan Azure SQL Yönetilen Örneği'ne geçirmek için kullanabileceğiniz Günlük Yeniden Yürütme Hizmeti'ne (LRS) genel bir bakış sunar. LRS, Azure SQL Yönetilen Örnek için kullanılabilen ücretsiz bir bulut hizmetidir ve SQL Server günlük aktarım teknolojisine dayalıdır.

Not

Artık Azure Arc tarafından etkinleştirilen SQL Server örneğinizi doğrudan Azure portalı üzerinden Azure SQL Yönetilen Örneği'ne geçirebilirsiniz. Daha fazla bilgi için bkz. Azure SQL Yönetilen Örneğine Geçiş.

LRS standart SQL Server yedekleme dosyalarını geri yüklediğinden, bu dosyayı kullanarak herhangi bir yerde barındırılan SQL Server'dan (şirket içi veya herhangi bir bulut) Azure SQL Yönetilen Örneği'ne geçirebilirsiniz.

LRS ile geçişinizi başlatmak için Günlük Yeniden Yürütme Hizmeti kullanılarak SQL Server'dan veritabanlarının nasıl taşındığını gözden geçirin.

Önemli

Veritabanlarını İş Açısından Kritik hizmet katmanına geçirmeden önce, Genel Amaçlı hizmet katmanı için geçerli olmayan bu sınırlamaları göz önünde bulundurun.

Günlük Yeniden Yürütme Hizmeti ne zaman kullanılır?

Azure Veritabanı Geçiş Hizmeti, Azure Data Studio için Azure SQL geçiş uzantısı ve LRS'lerin tümü aynı temel geçiş teknolojisini ve API'leri kullanır. LRS ayrıca şirket içi SQL Server örnekleri ile SQL Yönetilen Örneği dağıtımları arasında karmaşık özel geçişler ve karma mimariler sağlar.

geçiş için Azure Veritabanı Geçiş Hizmeti veya Azure SQL uzantısını kullanamıyorsanız, SQL Yönetilen Örneği veritabanı geçişlerini el ile oluşturmak ve yönetmek için LRS'yi doğrudan PowerShell, Azure CLI cmdlet'leri veya API'lerle kullanabilirsiniz.

Aşağıdaki durumlarda LRS kullanmayı göz önünde bulundurun:

• Veritabanı geçiş projeniz için daha fazla denetime ihtiyacınız var.
• Geçiş sürecinin kesintisiz gerçekleşmesi sırasında kesinti süresi için tolerans yoktur.
• Veritabanı Geçiş Hizmeti çalıştırılabilir dosyasını ortamınıza kuramazsınız.
• Veritabanı Geçiş Hizmeti yürütülebilir dosyasının, veritabanı yedeklerine dosya erişimi yoktur.
• Ortamınıza Azure SQL geçiş uzantısını yükleyemezsiniz veya veritabanı yedeklemelerinize erişemezsiniz.
• Konak işletim sistemine veya yönetici ayrıcalıklarına erişiminiz yok.
• Ortamınızdan Azure'a ağ bağlantı noktalarını açamazsınız.
• Ortamınızda ağ sınırlaması veya ara sunucu engelleme sorunları var.
• Yedeklemeler, TO URL seçeneği aracılığıyla doğrudan Azure Blob Depolama hesaplarına depolanır.
• Diferansiyel yedekler kullanmanız gerekir.

LRS standart SQL Server yedekleme dosyalarını geri yükleyerek çalıştığından, herhangi bir kaynaktan geçişleri destekler. Aşağıdaki kaynaklar test edilmiştir:

• Şirket içi/kutulu SQL Server
• Sanal Makinelerde SQL Server
• Amazon EC2 (Elastik İşlem Bulutu)
• SQL Server için Amazon RDS (İlişkisel Veritabanı Hizmeti)
• Google Compute Engine
• SQL Server için Cloud SQL - GCP (Google Cloud Platform)
• SQL Server için Alibaba Cloud RDS

Listelenmemiş bir kaynaktan geçiş sırasında beklenmeyen sorunlarla karşılaşırsanız yardım için bir destek bileti açın.

Not

• LRS, SQL yönetilen örneklerinde değişiklik yedeklemelerini geri yüklemenin tek yöntemidir. Yönetilen örneklerde diferansiyel yedeklemeleri el ile geri yüklemek veya modu T-SQL yardımıyla el ile ayarlamak mümkün değildir.

LRS nasıl çalışır?

Veritabanlarını LRS ile buluta geçirmek için özel bir çözüm oluşturmak için, bu bölümün ilerleyen bölümlerindeki diyagram ve tabloda gösterildiği gibi çeşitli düzenleme adımları gerekir.

Geçiş, SQL Server'da veritabanı yedeklemeleri almak ve yedekleme dosyalarını bir Azure Blob Depolama hesabına kopyalamaktan oluşur. LRS tam, günlük ve değişiklik yedeklemelerini destekler. Ardından Azure Blob Depolama hesabından SQL Yönetilen Örnek üzerine yedek dosyaları geri yüklemek için LRS bulut hizmetini kullanırsınız. Blob Depolama hesabı, SQL Server ile SQL Yönetilen Örneği arasında yedekleme dosyaları için ara depolama işlevi görür.

LRS, tam yedekleme geri yüklendikten sonra ekleyeceğiniz diferansiyel veya log yedeklemeleri için Blob Depolama hesabınızı izler. LRS, daha sonra bu yeni dosyaları otomatik olarak geri yükler. Yedekleme dosyalarının SQL Yönetilen Örneği'ne geri yüklenme ilerlemesini izlemek ve gerekirse işlemi durdurmak için hizmeti kullanabilirsiniz.

LRS, yedekleme dosyaları için belirli bir adlandırma kuralı gerektirmez. Azure Blob Depolama hesabına yerleştirilen tüm dosyaları tarar ve yedekleme zincirini yalnızca dosya üst bilgilerini okuyarak oluşturur. Veritabanları, geçiş işlemi sırasında geri yükleme durumundadır. LRS, veritabanlarını NORECOVERY modunda geri yükler, böylece geçiş işlemi bitene kadar iş yüklerini okumak veya yazmak için kullanılamazlar.

Birkaç veritabanını geçiriyorsanız şunları yapmanız gerekir:

• Her veritabanı için yedekleme dosyalarını Blob Depolama hesabındaki ayrı bir klasöre düz dosya yapısında yerleştirin. Örneğin, ayrı veritabanı klasörleri kullanın: blobcontainer/database1/files, blobcontainer/database2/files vb.
• İç içe klasör yapısı desteklenmediğinden, veritabanı klasörlerinin içinde iç içe klasörleri kullanmayın. Örneğin blobcontainer/database1/subfolder/files gibi alt klasörleri kullanmayın.
• LRS’yii her veritabanı için ayrı olarak başlatın.
• Blob Depolama hesabındaki veritabanı klasörlerini ayırmak için farklı URI yolları belirtin.

CHECKSUM Yedeklemeler için etkinleştirilmesi gerekli olmasa da, bunu kesinlikle öneririz. SQL Yönetilen Örneği, CHECKSUM olmadan geri yüklenen ve CHECKSUM özelliği etkin değilken gerçekleştirilen yedeklemelerde bütünlük denetimi yaptığı için, veritabanlarının geri yüklenmesi daha uzun sürer.

Daha fazla bilgi için bkz. Günlük Yeniden Yürütme Hizmeti'ni kullanarak veritabanlarını SQL Server'dan geçirme.

Dikkat

Bozuk bir veritabanını Azure'a geri yükleme riski taşıdığından, SQL Server'da CHECKSUM etkinleştirilmişken yedekleme yapmak şiddetle önerilir.

Otomatik tamamlama ve sürekli mod geçişi karşılaştırması

LRS'i otomatik tamamlama veya sürekli modda başlatabilirsiniz.

Yedekleme zincirinin tamamı önceden oluşturulmuşsa ve geçiş başladıktan sonra daha fazla dosya eklemeyi planlamıyorsanız otomatik tamamlama modunu kullanın. Bu geçiş modu, veri yakalama gerektirmeyen pasif iş yükleri için önerilir. Tüm yedekleme dosyalarını Blob Depolama hesabına yükleyin ve otomatik tamamlama modu geçişini başlatın. Son belirtilen yedekleme dosyası geri yüklendiğinde geçiş otomatik olarak tamamlanır. Geçirilen veritabanı SQL Yönetilen Örneği'ne okuma/yazma erişimi için kullanılabilir hale gelir.

Geçiş devam ederken yeni yedekleme dosyaları eklemeye devam etmek istiyorsanız sürekli modu kullanın. Veri yakalama gerektiren etkin iş yükleri için bu modu öneririz. Şu anda kullanılabilir yedekleme zincirini Blob Depolama hesabına yükleyin, geçişi sürekli modda başlatın ve gerektiğinde iş yükünüzden yeni yedekleme dosyaları eklemeye devam edin. Sistem, Azure Blob Depolama klasörünü düzenli aralıklarla tarar ve bulduğu tüm yeni günlük veya değişiklik yedekleme dosyalarını geri yükler.

Tam geçişe hazır olduğunuzda SQL Server örneğinizdeki iş yükünü durdurun, son yedekleme dosyasını oluşturun ve karşıya yükleyin. Son yedekleme dosyasının geri yüklendiğinden emin olmak için, log kuyruğu yedeklemesinin SQL Yönetilen Örneği'nde geri yüklendi olarak gösterildiğini doğrulayın. Ardından, manuel geçişi başlatın. Son tam geçiş adımı, veritabanının erişilebilir hale gelmesini ve SQL Managed Instance'ta okuma/yazma erişimine açık olmasını sağlar.

LRS, otomatik tamamlama veya manuel geçiş yoluyla durdurulduktan sonra, SQL Yönetilen Örneği'nde çevrimiçi hale getirdiğiniz bir veritabanı için geri yükleme işlemine devam edemezsiniz. Örneğin, geçiş tamamlandıktan sonra çevrimiçi veritabanı için daha fazla değişiklik yedeği geri yükleyemezsiniz. Geçiş tamamlandıktan sonra daha fazla yedekleme dosyasını geri yüklemek için veritabanını yönetilen örnekten silmeniz ve geçişi baştan yeniden başlatmanız gerekir.

Geçiş iş akışı

Bu bölümdeki görüntüde tipik bir geçiş iş akışı gösterilirken tabloda adımlar özetlenmiştir.

Otomatik tamamlama modunu yalnızca tüm yedekleme zinciri dosyaları önceden kullanılabilir olduğunda kullanın. Veri yakalama gerektirmeyen pasif iş yükleri için bu modu öneririz.

Yedekleme zincirinin tamamına önceden sahip değilseniz ve geçiş devam ettikten sonra yeni yedekleme dosyaları eklemeyi planlıyorsanız sürekli mod geçişini kullanın. Veri yakalama gerektiren etkin iş yükleri için bu modu öneririz.

Operasyon	Ayrıntılar
1. VERITABANı yedeklemelerini SQL Server örneğinden Blob Depolama hesabına kopyalayın.	AzCopy veya Azure Depolama Gezgini kullanarak SQL Server örneğinden Blob Depolama kapsayıcısına tam, farklı ve günlük yedeklerini kopyalayın. Herhangi bir dosya adını kullanın. LRS belirli bir dosya adlandırma kuralı gerektirmez. Birkaç veritabanını geçirirken her veritabanı için ayrı bir klasör kullanın.
2. Bulutta LRS'yi başlatın.	Hizmeti PowerShell (start-azsqlinstancedatabaselogreplay) veya Azure CLI (az_sql_midb_log_replay_start cmdlet'leri) ile başlatın. Otomatik tamamlama veya sürekli geçiş modu arasında seçim yapın. Blob Depolama hesabındaki bir yedekleme klasörüne işaret eden her veritabanı için LRS'yi ayrı olarak başlatın. Hizmet başlatıldığında Blob Depolama kapsayıcısından yedekleri alır ve bunları SQL Yönetilen Örneğe geri yüklemeye başlar. LRS'yi otomatik tamamlama modunda başlattığınızda, belirtilen son yedekleme dosyası aracılığıyla tüm yedeklemeleri geri yükler. Tüm yedekleme dosyalarını önceden yüklemeniz gerekir ve geçiş devam ederken yeni yedekleme dosyası ekleyemezsiniz. Bu mod, veri yakalama gerektirmeyen pasif iş yükleri için önerilir. LRS'yi sürekli modda başlattığınızda, başlangıçta karşıya yüklediğiniz tüm yedeklemeleri geri yükler ve ardından klasöre yüklediğiniz tüm yeni dosyaları izler. Hizmet, günlük sıra numarası (LSN) zincirine göre günlükleri işlemeye devam eder, ta ki el ile durdurulana kadar. Veri yakalama gerektiren etkin iş yükleri için bu modu öneririz.
2.1. İşlemin ilerleme durumunu izleme.	PowerShell (get-azsqlinstancedatabaselogreplay) veya Azure CLI (az_sql_midb_log_replay_show cmdlet'leri) ile devam eden geri yükleme işleminin ilerleme durumunu izleyin. Başarısız bir istekle ilgili ek ayrıntıları izlemek için Get-AzSqlInstanceOperation PowerShell komutunu veya az sql mi op show Azure CLI komutunu kullanın.
2.2. Gerekirse işlemi durdurun (isteğe bağlı).	Geçiş işlemini durdurmanız gerekiyorsa PowerShell (stop-azsqlinstancedatabaselogreplay) veya Azure CLI (az_sql_midb_log_replay_stop) kullanın. İşlemin durdurulması, SQL Yönetilen Örneği'ne geri yüklediğiniz veritabanını siler. Bir işlemi durdurduktan sonra, veritabanı için LRS'yi sürdüremezsiniz. Geçiş işlemini baştan yeniden başlatmanız gerekir.
3. Hazır olduğunuzda buluta geçin.	LRS'yi otomatik tamamlama modunda başlatırsanız, belirtilen son yedekleme dosyası geri yüklendikten sonra geçiş otomatik olarak tamamlanır. LRS'yi sürekli modda başlatırsanız uygulamayı ve iş yükünü durdurun. Son günlük kuyruğu yedeklemesini alın ve Azure Blob Depolama dağıtımına yükleyin. SQL yönetilen örneğinde son günlük kuyruğu yedeklemesinin geri yüklendiğinden emin olun. Bir LRS işlemi başlatıp PowerShell (complete) veya Azure CLI (az_sql_midb_log_replay_complete) kullanarak geçişi tamamlayın. Bu işlem, LRS'yi durdurur ve SQL Yönetilen Örneği'nde okuma/yazma iş yükleri için veritabanını çevrimiçi hale getirir. Uygulama bağlantı dizesini, SQL Server örneğinden SQL Yönetilen Örneği'ne yönlendirin. Uygulamanızdaki el ile bağlantı dizesi değişiklik yoluyla veya otomatik olarak (örneğin, uygulamanız bir özellikten veya veritabanından bağlantı dizesi okuyabiliyorsa) bu adımı kendiniz düzenlemeniz gerekir.

Önemli

Geçişten sonra, İş Açısından Kritik hizmet katmanına sahip SQL Yönetilen Örneği, kullanılabilirlik grubu için üç ikincil çoğaltmanın eklenmesi gerektiğinden Genel Amaçlı'dan önemli ölçüde daha uzun sürebilir. İşlem süresi, verilerin boyutuna bağlıdır. Daha fazla bilgi için bkz . Yönetim işlemleri süresi.

Büyük veritabanlarını taşıma

Boyutu birkaç terabayt olan büyük veritabanlarını geçiriyorsanız aşağıdaki noktaları göz önünde bulundurun:

• LRS'ye ait tek bir işin maksimum çalışma süresi 30 gündür. Bu süre dolduğunda iş otomatik olarak iptal edilir.
• Uzun süre çalışan işler için sistem güncelleştirmeleri geçiş işlerini kesintiye uğratabilir ve uzatabilir. Planlı sistem güncelleştirmelerini zamanlamak için bir bakım penceresi kullanmanızı kesinlikle öneririz. Geçişinizi zamanlanmış bakım penceresi çevresinde planlayın.
• Sistem güncelleştirmeleri tarafından kesilen geçiş işleri Genel Amaçlı SQL yönetilen örnekleri için otomatik olarak askıya alınıp sürdürülür, ve İş Açısından Kritik SQL yönetilen örnekleri için yeniden başlatılır. Bu güncelleştirmeler geçişinizin zaman çerçevesini etkiler.
• Altyapınız yeterli ağ bant genişliğine sahipse SQL Server yedekleme dosyalarınızın Blob Depolama hesabına yükleme hızını artırmak için birden çok iş parçacığıyla paralelleştirme kullanmayı göz önünde bulundurun.

Geçişi başlatma

LRS'yi başlatarak geçişi başlatın. Hizmeti otomatik tamamlama veya sürekli modda başlatabilirsiniz. Belirli ayrıntılar için Günlük Yeniden Yürütme Hizmeti'ni kullanarak veritabanlarını SQL Server'dan geçirme bölümünü gözden geçirin.

• Otomatik tamamlama modu. Otomatik tamamlama modunu kullandığınızda, belirtilen yedekleme dosyalarının sonuncusu geri yüklendiğinde geçiş otomatik olarak tamamlanır. Bu seçenek:

  • Yedekleme zincirinin tamamının önceden kullanılabilir olmasını ve Azure Blob Depolama hesabına yüklenmesini gerektirir.
  • Geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez.
  • Başlat komutunun son yedekleme dosyasının dosya adını belirtmesini gerektirir.

  Veri yakalamanın gerekli olmadığı pasif iş yükleri için otomatik tamamlama modunu kullanmanızı öneririz.

• Sürekli mod. Sürekli modu kullandığınızda, hizmet Azure Blob Depolama klasörünü sürekli tarar ve geçiş devam ederken eklenen tüm yeni yedekleme dosyalarını geri yükler.

  Geçiş yalnızca manuel geçiş isteğinde bulunduktan sonra tamamlanır.

  Yedekleme zincirinin tamamına önceden sahip değilseniz ve geçiş devam ettikten sonra yeni yedekleme dosyaları eklemeyi planlıyorsanız sürekli mod geçişini kullanın.

  Veri yakalamanın gerekli olduğu etkin iş yükleri için sürekli mod kullanmanızı öneririz.

En fazla 30 gün içinde tek bir LRS geçiş işini bitirmeyi planlayın. Bu süre dolduğunda LRS işi otomatik olarak iptal edilir.

Not

Birden çok veritabanını geçirirken, her veritabanının kendi klasöründe olması gerekir. LRS'yi her veritabanı için ayrı olarak başlatın ve Azure Blob Depolama kapsayıcısının tam URI yoluna ve tek tek veritabanı klasörüne işaret edin. Veritabanı klasörlerinin içindeki iç içe klasörler desteklenmez.

LRS sınırlamaları

Bilgi için LRS kullanırken sınırlamaları gözden geçirin.

İlgili içerik

• Günlük Yeniden Yürütme Hizmeti'ni kullanarak VERITABANLARını SQL Server'dan geçirme
• Yönetilen Örnek bağlantısına genel bakış
• LRS'i Yönetilen Örnek bağlantısıyla karşılaştırma
• Veritabanlarını SQL Server'dan SQL Yönetilen Örneğine geçirme
• SQL Server ile SQL Yönetilen Örneği arasındaki farklar
• Azure'a geçirilen iş yüklerini maliyetlendirmeye ve boyutlandırmaya yönelik en iyi yöntemler