Günlük Yeniden Yürütme Hizmeti kullanarak VERITABANLARını SQL Server'dan geçirme - Azure SQL Yönetilen Örneği

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

Bu makalede, Günlük Yeniden Yürütme Hizmeti (LRS) kullanılarak veritabanlarının Azure SQL Yönetilen Örneği nasıl geçirilerek anlatılıyor. LRS, SQL Server günlük gönderim teknolojisini temel alarak Azure SQL Yönetilen Örneği için kullanılabilen ücretsiz bir bulut hizmetidir.

Aşağıdaki kaynaklar desteklenir:

• 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)

Önkoşullar

Başlamadan önce, hem SQL Server örneğiniz hem de Azure için bu bölümdeki gereksinimleri göz önünde bulundurun. Geçişin başarılı olduğundan emin olmak için sınırlamaları ve en iyi yöntemler bölümlerini dikkatle gözden geçirin.

SQL Server

SQL Server için aşağıdaki gereksinimleri karşıladığınızdan emin olun:

• SQL Server 2008 ile 2022 sürümleri.
• SQL Server veritabanınız tam kurtarma modelini kullanıyor (zorunlu).
• Veritabanlarının tam yedeklemesi (bir veya birden çok dosya).
• Değişiklik yedeği (bir veya birden çok dosya).
• Günlük yedeklemesi (işlem günlüğü dosyası için bölünmez).
• SQL Server 2008 ile 2016 sürümleri için yerel olarak bir yedekleme alın ve Azure Blob Depolama hesabınıza el ile yükleyin.
• SQL Server 2016 ve üzeri için, yedeklemenizi doğrudan Azure Blob Depolama hesabınıza taşıyabilirsiniz.
• Yedeklemeler için etkinleştirilmiş olmak CHECKSUM gerekli olmasa da, istemeden bozuk bir veritabanının geçirilmesini önlemek ve daha hızlı geri yükleme işlemleri için kesinlikle önerilir.

Azure

Azure için aşağıdaki gereksinimleri karşıladığınızdan emin olun:

• PowerShell Az.SQL modülü sürüm 4.0.0 veya üzeri (Azure Cloud Shell aracılığıyla yüklenir veya erişilir).
• Azure CLI sürüm 2.42.0 veya üzeri (yüklü).
• Sağlanan Azure Blob Depolama kapsayıcısı.
• Blob Depolama kapsayıcısı için oluşturulan ve Read izinlerine sahip List paylaşılan erişim imzası (SAS) güvenlik belirteci veya kapsayıcıya erişebilen yönetilen kimlik. ve değerinden ReadList daha fazla izin verilmesi LRS'nin başarısız olmasına neden olur.
• Tek bir veritabanı için yedekleme dosyalarını düz dosya yapısı (zorunlu) kullanarak depolama hesabındaki ayrı bir klasöre yerleştirin. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.

Azure RBAC izinleri

LRS'nin sağlanan istemciler aracılığıyla çalıştırılması için aşağıdaki Azure rol tabanlı erişim denetimi (RBAC) rollerinden biri gerekir:

• SQL Yönetilen Örnek Katkıda Bulunanı rolü
• Aşağıdaki izne sahip bir rol: Microsoft.Sql/managedInstances/databases/*

En iyi yöntemler

LRS kullanırken aşağıdaki en iyi yöntemleri göz önünde bulundurun:

• Veritabanlarınızın SQL Yönetilen Örneği geçirilmeye hazır olduğunu doğrulamak için Data Migration Yardımcısı çalıştırın.
• Tek bir dosya kullanmak yerine tam ve değişiklik yedeklemelerini birden çok dosyaya bölün.
• Ağ aktarım hızlarına yardımcı olmak için yedekleme sıkıştırmasını etkinleştirin.
• Her zaman en son yayımlanan cmdlet'leri kullanacak şekilde güncelleştirileceği için, PowerShell veya CLI betiklerini çalıştırmak için Cloud Shell kullanın.
• Geçişin gecikmesini veya kesintiye uğramasını önlemek için sistem güncelleştirmelerinin geçiş penceresinin dışında belirli bir gün ve saatte zamanlanması için bir bakım penceresi yapılandırın.
• Tek bir LRS geçiş işini en fazla 30 gün içinde tamamlamayı planlayın. Bu zaman çerçevesinin sona ermesi üzerine LRS işi otomatik olarak iptal edilir.
• Bozuk bir veritabanını istemeden geçirmeyi önlemek ve daha hızlı bir veritabanı geri yüklemesi için yedeklerinizi alırken etkinleştirin CHECKSUM . SQL Yönetilen Örneği olmadan CHECKSUMyedeklemelerde temel bir bütünlük denetimi gerçekleştirse de, her türlü bozulmanın yakalanması garanti değildir. ile CHECKSUM yedeklemeleri almak, SQL Yönetilen Örneği geri yüklenen yedeklemenin bozuk olmadığından emin olmak için tek yoldur. Veritabanının geri yükleme süresini artırmadan CHECKSUM yedeklemelerde temel bütünlük denetimi.
• İş Açısından Kritik hizmet katmanına geçiş yaparken, veritabanları ikincil çoğaltmalara dağıtılırken tam geçişten sonra veritabanı kullanılabilirliğindeki gecikme süresini uzatın. Özellikle en düşük kapalı kalma süresi gereksinimlerine sahip büyük veritabanları için öncelikle Genel Amaçlı hizmet katmanına geçmeyi ve ardından İş Açısından Kritik hizmet katmanına yükseltmeyi veya verilerinizi geçirmek için Yönetilen Örnek bağlantısını kullanmayı göz önünde bulundurun.
• Geri yüklemek için binlerce veritabanı dosyasını karşıya yüklemek, aşırı geçiş sürelerine ve hatta başarısızlığa neden olabilir. Geçiş işlemini hızlandırmak ve başarılı olduğundan emin olmak için veritabanlarını daha az dosyada birleştirin.
• Tam geçiş süresini en aza indirmek ve hata riskini azaltmak için son yedeklemenizin mümkün olduğunca küçük olduğundan emin olun.

Bakım penceresi yapılandırma

SQL Yönetilen Örneği için sistem güncelleştirmeleri, devam eden veritabanı geçişlerinden önceliklidir.

Geçiş, hizmet katmanına göre farklı şekilde etkilenir:

• Genel Amaçlı hizmet katmanında, bekleyen tüm LRS geçişleri yalnızca güncelleştirme uygulandıktan sonra askıya alınır ve sürdürülür. Bu sistem davranışı, özellikle büyük veritabanları için geçiş süresini uzatabilir.
• İş Açısından Kritik hizmet katmanında, bekleyen tüm LRS geçişleri iptal edilir ve güncelleştirme uygulandıktan sonra otomatik olarak yeniden başlatılır. Bu sistem davranışı, özellikle büyük veritabanları için geçiş süresini uzatabilir.

Veritabanı geçişleri için öngörülebilir bir süre elde etmek için, sistem güncelleştirmelerini belirli bir gün ve saat için zamanlayacak bir bakım penceresi yapılandırmayı ve belirlenen bakım penceresi zaman çerçevesinin dışında geçiş işlerini çalıştırmayı ve tamamlamayı göz önünde bulundurun. Örneğin, Pazartesi günü başlayan bir geçiş için, pazar günü özel bakım pencerenizi geçişi tamamlamak için en fazla süre tanıyacak şekilde yapılandırın.

Bakım penceresi yapılandırmak gerekli değildir, ancak büyük veritabanları için kesinlikle önerilir.

Birden çok veritabanını geçirme

Aynı Azure Blob Depolama kapsayıcısını kullanarak birden çok veritabanını geçiriyorsanız, farklı veritabanları için yedekleme dosyalarını kapsayıcının içindeki ayrı klasörlere yerleştirmeniz gerekir. Tek bir veritabanı için tüm yedekleme dosyaları, veritabanı klasörünün içindeki düz dosya yapısına yerleştirilmelidir ve klasörler iç içe yerleştirilemiyor. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.

Aşağıda, Azure Blob Depolama kapsayıcısının içindeki bir klasör yapısı örneği ve LRS kullanarak birden çok veritabanını geçirmek için gereken bir yapı verilmiştir.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Depolama hesabı oluşturma

SQL Server örneğin ve SQL Yönetilen Örneği dağıtımınız arasında yedekleme dosyaları için aracı depolama alanı olarak bir Azure Blob Depolama hesabı kullanırsınız. Depolama hesabı içinde yeni bir depolama hesabı ve blob kapsayıcısı oluşturmak için:

1. Depolama hesabı oluşturma.
2. Depolama hesabının içinde bir blob kapsayıcısı oluşturun.

Azure depolamayı güvenlik duvarının arkasında yapılandırma

Bir güvenlik duvarının arkasında korunan Azure Blob depolamanın kullanılması desteklenir, ancak ek yapılandırma gerektirir. Azure Güvenlik Duvarı açıkken Azure Depolama'ya okuma/yazma erişimini etkinleştirmek için, MI alt ağ temsilcisini ve Depolama hizmeti uç noktasını kullanarak SQL yönetilen örneğinin alt ağını depolama hesabının güvenlik duvarı kurallarına eklemeniz gerekir. Depolama hesabı ve yönetilen örnek aynı bölgede veya iki eşleştirilmiş bölgede olmalıdır.

Azure depolama alanınız bir güvenlik duvarının arkasındaysa SQL yönetilen örneği hata günlüğünde aşağıdaki iletiyi görebilirsiniz:

Audit: Storage access denied user fault. Creating an email notification:

Bu, SQL yönetilen örneği için denetimin depolama hesabına denetim günlükleri yazamadığını bildiren bir e-posta oluşturur. Bu hatayı görürseniz veya bu e-postayı alırsanız, güvenlik duvarınızı yapılandırmak için bu bölümdeki adımları izleyin.

Güvenlik duvarını yapılandırmak için şu adımları izleyin:

1. Azure portalında yönetilen örneğinize gidin ve alt ağı seçerek Alt Ağlar sayfasını açın.

   

2. Alt ağlar sayfasında alt ağın adını seçerek alt ağ yapılandırma sayfasını açın.

   

3. Alt ağ temsilcisi altında, Hizmet alt ağından hizmete temsilci seç açılan menüsünden Microsoft.Sql/managedInstances'ı seçin. İzinlerin yayılması için yaklaşık bir saat bekleyin ve ardından Hizmet uç noktaları'nın altında Hizmetler açılan listesinden Microsoft.Storage'ı seçin.

   

4. Ardından Azure portalında depolama hesabınıza gidin, Güvenlik + ağ altında Ağ'ı seçin ve ardından Güvenlik duvarları ve sanal ağlar sekmesini seçin.

5. Depolama hesabınızın Güvenlik duvarları ve sanal ağlar sekmesinde + Var olan sanal ağı ekle'yi seçerek Ağ ekle sayfasını açın.

   

6. Açılan menülerden uygun aboneliği, sanal ağı ve yönetilen örnek alt ağını seçin ve ardından SQL yönetilen örneğinin sanal ağını depolama hesabına eklemek için Ekle'yi seçin.

Blob Depolama hesabınızda kimlik doğrulaması

Azure Blob Depolama hesabınıza erişmek için SAS belirteci veya yönetilen kimlik kullanın.

Yönetilen örnek depolama erişiminizi doğrulama

Yönetilen örneğinizin Blob Depolama hesabınıza erişebildiğini doğrulayın.

İlk olarak, gibi full_0_0.bakherhangi bir veritabanı yedeğini Azure Blob Depolama kapsayıcınıza yükleyin.

Ardından yönetilen örneğinize bağlanın ve yönetilen örneğinizin kapsayıcıdaki yedeklemeye erişip erişemeyeceğini belirlemek için örnek bir test sorgusu çalıştırın.

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

Yedeklemeleri Blob Depolama hesabınıza yükleme

Blob kapsayıcınız hazır olduğunda ve yönetilen örneğinizin kapsayıcıya erişebildiğini onayladıktan sonra yedeklemelerinizi Blob Depolama hesabınıza yüklemeye başlayabilirsiniz. Şunlardan birini yapabilirsiniz:

• Yedeklerinizi Blob Depolama hesabınıza kopyalayın.
• Ortamınız izin veriyorsa (SQL Server 2012 SP1 CU2 ve SQL Server 2014 sürümlerinden başlayarak) BACKUP TO URL komutunu kullanarak SQL Server'dan doğrudan Blob Depolama hesabınıza yedek alın.

Mevcut yedeklemeleri Blob Depolama hesabınıza kopyalama

SQL Server'ın önceki bir sürümündeyseniz veya ortamınız doğrudan bir URL'ye yedeklemeyi desteklemiyorsa, yedeklerinizi normalde yaptığınız gibi SQL Server örneğinize alın ve ardından Blob Depolama hesabınıza kopyalayın.

SQL Server örneğinde yedek alma

Günlük yedeklemelerine izin vermek için tam kurtarma modeline geçirmek istediğiniz veritabanlarını ayarlayın.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

Veritabanınızın tam, değişiklik ve günlük yedeklemelerini yerel depolama alanına el ile yapmak için aşağıdaki örnek T-SQL betiklerini kullanın. CHECKSUM gerekli değildir, ancak bozuk bir veritabanının geçirilmesini önlemek ve daha hızlı geri yükleme süreleri için önerilir.

Aşağıdaki örnek, yerel diske tam veritabanı yedeklemesi alır:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Aşağıdaki örnek, yerel diske değişiklik yedeği alır:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Aşağıdaki örnek, yerel diske bir işlem günlüğü yedeklemesi alır:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Yedeklemeleri Blob Depolama hesabınıza kopyalama

Yedeklemeleriniz hazır olduktan ve LRS kullanarak veritabanlarını yönetilen örneğe geçirmeyi başlatmak istiyorsanız, mevcut yedeklemeleri Blob Depolama hesabınıza kopyalamak için aşağıdaki yaklaşımları kullanabilirsiniz:

• AzCopy'yi indirip yükleyin.
• Azure Storage Explorer'ı indirin ve yükleyin.
• Azure portalında Depolama Gezgini kullanın.

Yedekleri doğrudan Blob Depolama hesabınıza alma

SQL Server'ın desteklenen bir sürümündeyseniz (SQL Server 2012 SP1 CU2 ve SQL Server 2014'ten başlayarak) ve şirket ve ağ ilkeleriniz buna izin veriyorsa, yerel SQL Server URL'ye YEDEKLEME seçeneğini kullanarak SQL Server'dan doğrudan Blob Depolama hesabınıza yedek alabilirsiniz. 'yi kullanabiliyorsanız BACKUP TO URLyerel depolamaya yedeklemeler almanız ve bunları Blob Depolama hesabınıza yüklemeniz gerekmez.

Yerel yedeklemeleri doğrudan Blob Depolama hesabınıza aldığınızda, depolama hesabında kimlik doğrulaması yapmanız gerekir.

SAS belirtecini SQL Server örneğine aktaran bir kimlik bilgisi oluşturmak için aşağıdaki komutu kullanın:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

SAS belirteçleriyle çalışan ayrıntılı yönergeler için SQL Server ile Azure Blob Depolama kullanma öğreticisini gözden geçirin.

SQL Server örneğinizin kimliğini Blob Depolama ile doğrulamak için kimlik bilgilerini oluşturduktan sonra yedeklemeleri doğrudan depolama hesabına almak için URL'ye YEDEKLE komutunu kullanabilirsiniz. CHECKSUM önerilir, ancak gerekli değildir.

Aşağıdaki örnek, BIR URL'ye tam veritabanı yedeklemesi alır:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Aşağıdaki örnek, BIR URL'ye değişiklik veritabanı yedeklemesi alır:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Aşağıdaki örnek, URL'ye bir işlem günlüğü yedeklemesi alır:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Azure'da oturum açın ve bir abonelik seçin

Azure'da oturum açmak için aşağıdaki PowerShell cmdlet'ini kullanın:

Login-AzAccount

Aşağıdaki PowerShell cmdlet'ini kullanarak yönetilen örneğinizin bulunduğu aboneliği seçin:

Select-AzSubscription -SubscriptionId <subscription ID>

Geçişi başlatma

LRS'yi başlatarak geçişi başlatın. Hizmeti otomatik tamamlama veya sürekli modda başlatabilirsiniz.

Otomatik tamamlama modunu kullandığınızda, belirtilen yedekleme dosyalarının sonuncusu geri yüklendiğinde geçiş otomatik olarak tamamlar. Bu seçenek, yedekleme zincirinin tamamının önceden kullanılabilir olmasını ve Blob Depolama hesabınıza yüklenmesini gerektirir. Geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez. Bu seçenek, komutun start son yedekleme dosyasının dosya adını belirtmesini gerektirir. Veri yakalamanın gerekli olmadığı pasif iş yükleri için bu modu öneririz.

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ş ancak el ile tam geçiş istendikten sonra tamamlanmıştır. Yedekleme zincirinin tamamına önceden sahip değilseniz ve geçiş devam ettikten sonra yeni yedekleme dosyaları eklemeyi planladığınızda sürekli mod geçişini kullanmanız gerekir. Veri yakalamanın gerekli olduğu etkin iş yükleri için bu modu öneririz.

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

LRS'i otomatik tamamlama modunda başlatma

Yedekleme zincirinin tamamının Azure Blob Depolama hesabınıza yüklendiğinden emin olun. Bu seçenek, geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez.

LRS'yi otomatik tamamlama modunda başlatmak için PowerShell veya Azure CLI komutlarını kullanın. parametresini kullanarak -LastBackupName son yedekleme dosyası adını belirtin. Belirtilen son yedekleme dosyasının geri yüklenmesi tamamlandıktan sonra hizmet otomatik olarak tam geçiş başlatır.

SAS belirtecini veya yönetilen kimliği kullanarak veritabanınızı depolama hesabından geri yükleyin.

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

LRS'i sürekli modda başlatma

İlk yedekleme zincirinizi Azure Blob Depolama hesabınıza yüklediğinizden emin olun.

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Geçiş işini betikleyin

LRS'yi sürekli modda başlatan PowerShell ve Azure CLI istemcileri zaman uyumlu olur. Bu modda PowerShell ve Azure CLI, api yanıtının işi başlatmadan önce başarılı veya başarısız olduğunu bildirmesini bekler.

Bu bekleme sırasında komut, denetimi komut istemine döndürmez. Geçiş deneyimini betik olarak kullanıyorsanız ve betiğin geri kalanına devam etmek için denetimi hemen geri vermek için LRS başlat komutuna ihtiyacınız varsa PowerShell'i anahtarla -AsJob arka plan işi olarak çalıştırabilirsiniz. Örneğin:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Bir arka plan işi başlattığınızda, işin tamamlanması uzun sürse bile iş nesnesi hemen geri döner. İş çalışırken oturumda kesintisiz olarak çalışmaya devam edebilirsiniz. PowerShell'i arka plan işi olarak çalıştırma hakkında ayrıntılı bilgi için PowerShell Başlangıç İşi belgelerine bakın.

Benzer şekilde, Linux'ta arka plan işlemi olarak bir Azure CLI komutu başlatmak için LRS start komutunun sonundaki ve işareti (&) kullanın:

az sql midb log-replay start <required parameters> &

Geçiş ilerleme durumunu izleme

Az.SQL 4.0.0 ve üzeri , ayrıntılı bir ilerleme raporu sağlar. Örnek çıktı için Yönetilen Veritabanı Geri Yükleme Ayrıntıları - Alma bölümünü gözden geçirin.

PowerShell aracılığıyla devam eden geçiş ilerlemesini izlemek için aşağıdaki komutu kullanın:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Azure CLI aracılığıyla devam eden geçiş ilerleme durumunu izlemek için aşağıdaki komutu kullanın:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

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.

Geçişi durdurma (isteğe bağlı)

Geçişi durdurmanız gerekiyorsa PowerShell'i veya Azure CLI'yı kullanın. Geçişin durdurulması yönetilen örneğinizdeki geri yükleme veritabanını siler, bu nedenle geçişin devamı mümkün olmaz.

PowerShell aracılığıyla geçiş işlemini durdurmak için aşağıdaki komutu kullanın:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Azure CLI aracılığıyla geçiş işlemini durdurmak için aşağıdaki komutu kullanın:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Geçişi tamamlama (sürekli mod)

LRS'yi sürekli modda başlatırsanız, yeni yedekleme dosyalarının oluşturulmasını önlemek için uygulamanızın ve SQL Server iş yükünüzün durduruldığından emin olun. SQL Server örneğinizdeki son yedeklemenin Azure Blob Depolama hesabınıza yüklendiğinden emin olun. Yönetilen örneğinizdeki geri yükleme ilerleme durumunu izleyin ve son günlük kuyruğu yedeklemesinin geri yüklendiğinden emin olun.

Yönetilen örneğinizde son günlük kuyruğu yedeklemesi geri yüklendiğinde, geçişi tamamlamak için el ile tam geçişi başlatın. Tam geçiş tamamlandıktan sonra veritabanı yönetilen örnekte okuma ve yazma erişimi için kullanılabilir hale gelir.

Geçiş işlemini PowerShell aracılığıyla LRS sürekli modunda tamamlamak için aşağıdaki komutu kullanın:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Azure CLI aracılığıyla LRS sürekli modunda geçiş işlemini tamamlamak için aşağıdaki komutu kullanın:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Sınırlamalar

LRS ile geçiş yaparken aşağıdaki sınırlamaları göz önünde bulundurun:

• Geçiş işlemi bitene kadar LRS aracılığıyla geri yüklenen veritabanlarını kullanamazsınız.
• Geçiş işlemi sırasında, geçirilen veritabanları SQL Yönetilen Örneği salt okunur erişim için kullanılamaz.
• Geçiş tamamlandıktan sonra geçiş işlemi sonlanır ve ek değişiklik yedeklemeleriyle sürdürülemez.
• Yalnızca veritabanı .bak, .logve .diff dosyaları LRS tarafından desteklenir. Dacpac ve bacpac dosyaları desteklenmez.
• Sistem güncelleştirmelerini belirli bir gün ve saatte zamanlamak için bir bakım penceresi yapılandırmanız gerekir. Zamanlanmış bakım penceresinin dışında geçişleri çalıştırmayı ve bitirmeyi planlayın.
• olmadan CHECKSUMalınan veritabanı yedeklemeleri:
  • bozuk veritabanlarını geçirme potansiyeline sahip olabilir.
  • geri yükleme işlemi, etkin veritabanı yedeklemelerinden CHECKSUM daha uzun sürer.
• LRS'nin kullandığı paylaşılan erişim imzası (SAS) belirteci tüm Azure Blob Depolama kapsayıcısı için oluşturulmalıdır ve yalnızca ve Read izinlerine sahip List olmalıdır. Örneğin, , Readve List izinleri verirsenizWrite, LRS ek Write izin nedeniyle başlatılamaz.
• Depolanan erişim ilkesi tanımlayarak ayarlanan izinlerle oluşturulan SAS belirteçlerinin kullanılması desteklenmez. SAS belirtecinin Okuma ve Listeleme izinlerini el ile belirtmek için bu makaledeki yönergeleri izleyin.
• Farklı veritabanları için yedekleme dosyalarını Blob Depolama hesabındaki ayrı klasörlere düz dosya yapısında yerleştirmeniz gerekir. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.
• Otomatik tamamlama modunu kullanıyorsanız, yedekleme zincirinin tamamının Blob Depolama hesabında önceden kullanılabilir olması gerekir. Otomatik tamamlama modunda yeni yedekleme dosyaları eklemek mümkün değildir. Geçiş devam ederken yeni yedekleme dosyaları eklemeniz gerekiyorsa sürekli modu kullanın.
• Tek bir veritabanı klasörü içeren tam URI yoluna işaret eden her veritabanı için LRS'yi ayrı olarak başlatmanız gerekir.
• Yedekleme URI yolu, kapsayıcı adı veya klasör adları, ayrılmış anahtar sözcükler içerdiğinden backup veya backups içermemelidir.
• Paralel olarak birden çok Günlük Yeniden Yürütme geri yüklemesini başlatırken, aynı depolama kapsayıcısını hedeflerken, her geri yükleme işlemi için aynı geçerli SAS belirtecinin sağlandığından emin olun.
• LRS, tek bir yönetilen örnek başına en fazla 100 eşzamanlı geri yükleme işlemini destekleyebilir.
• Tek bir LRS işi en fazla 30 gün boyunca çalıştırılabilir ve bundan sonra otomatik olarak iptal edilir.
• Güvenlik duvarının arkasında Bir Azure Depolama hesabı kullanmak mümkün olsa da ek yapılandırma gerekir ve depolama hesabı ile yönetilen örneğin aynı bölgede veya iki eşleştirilmiş bölgede olması gerekir. Daha fazla bilgi edinmek için Güvenlik duvarını yapılandırma'ya bakın.
• Paralel olarak geri yükleyebileceğiniz en fazla veritabanı sayısı, tek abonelik başına 200'dür. Bazı durumlarda destek bileti açarak bu sınırı artırmak mümkündür.
• Geri yüklemek için binlerce veritabanı dosyasını karşıya yüklemek, aşırı geçiş sürelerine ve hatta başarısızlığa neden olabilir. Geçiş işlemini hızlandırmak ve başarılı olduğundan emin olmak için veritabanlarını daha az dosyada birleştirin.
• Geçiş işleminin başında ve sonunda, yük devretme gerçekleşirse geçişin durdurulduğu ve veritabanı SQL Yönetilen Örneği'nden bırakıldığından geçiş işinin baştan el ile yeniden başlatılması gereken iki senaryo vardır:
  • İlk tam veritabanı yedeklemesi SQL Yönetilen Örneği’ne geri yüklenme sürecindeyken ve geçiş işi ilk kez başlatıldığında bir yük devretme gerçekleşirse, geçiş işinin baştan el ile yeniden başlatılması gerekir.
  • Geçiş tam olarak başlatıldıktan sonra bir hata geçişi gerçekleşirse, geçiş işinin baştan manuel olarak yeniden başlatılması gerekir. Kesinti süresini en aza indirmek ve kesinti süreci sırasında geçiş riskini azaltmak için son yedekleme dosyasının mümkün olduğunca küçük olduğundan emin olun.

İş Açısından Kritik hizmet katmanına geçişle ilgili sınırlamalar

İş Açısından Kritik hizmet katmanındaki bir SQL Yönetilen Örneği geçiş yaparken aşağıdaki sınırlamaları göz önünde bulundurun:

• Büyük veritabanları geçirilirken, veritabanları İş Açısından Kritik hizmet katmanının ikincil çoğaltmalarına dağıtılırken tam geçiş sonrasında veritabanları kullanılamadığı için önemli bir kapalı kalma süresi yaşanabilir. Geçici çözümler, daha uzun tam geçiş bölümünde listelenmiştir.
• Geçiş planlanmamış bir yük devretme, sistem güncelleştirmesi veya güvenlik yaması tarafından kesintiye uğrarsa geçiş en baştan otomatik olarak yeniden başlatılır ve son dakika sürprizleri olmadan öngörülebilir bir geçiş planlamayı zorlaştırır.

İş Açısından Kritik hizmet katmanında daha uzun tam geçiş

İş Açısından Kritik hizmet katmanındaki bir SQL Yönetilen Örneği geçiş gerçekleştiriyorsanız, veritabanları ikincil çoğaltmalara dağıtılırken birincil çoğaltmada çevrimiçi olmalarındaki gecikmeyi hesaba katabilirsiniz. Bu özellikle daha büyük veritabanları için geçerlidir.

İş Açısından Kritik hizmet katmanındaki bir SQL Yönetilen Örneği geçişin tamamlanması Genel Amaçlı hizmet katmanından daha uzun sürer. Azure'a tam geçiş tamamlandıktan sonra, veritabanları birincil çoğaltmadan üç ikincil çoğaltmaya dağıtılana kadar kullanılamaz ve bu da veritabanınızın boyutuna bağlı olarak uzun sürebilir. Veritabanı ne kadar büyük olursa, ikincil çoğaltmalara daha uzun bir şekilde tohumlama işlemi birkaç saate kadar sürebilir.

Tam geçiş tamamlandığında veritabanlarının kullanılabilir olması önemliyse aşağıdaki geçici çözümleri göz önünde bulundurun:

• Önce Genel Amaçlı hizmet katmanına geçin ve ardından İş Açısından Kritik hizmet katmanına yükseltin. Hizmet katmanınızı yükseltmek, veritabanlarınızı yükseltme işleminin son adımı olarak kısa bir yük devretmeye kadar çevrimiçi tutan çevrimiçi bir işlemdir.
• Tam geçişten sonra veritabanlarının kullanılabilir olmasını beklemek zorunda kalmadan İş Açısından Kritik bir örneğe çevrimiçi geçiş için Yönetilen Örnek bağlantısını kullanın.

LRS sorunlarını giderme

LRS'yi başlattıktan sonra, devam eden işlemin durumunu görmek için aşağıdaki izleme cmdlet'lerinden birini kullanın:

• PowerShell için: get-azsqlinstancedatabaselogreplay
• Azure CLI için: az_sql_midb_log_replay_show

Başarısız bir işlemle ilgili ayrıntıları gözden geçirmek için:

• PowerShell için: Get-AzSqlInstanceOperation
• Azure CLI için: az sql mi op show

LRS bir süre sonra başlatılamazsa ve hata alırsanız en yaygın sorunları denetleyin:

• Yönetilen örneğinizdeki mevcut bir veritabanı, SQL Server örneğinizden geçirmeye çalıştığınız veritabanıyla aynı ada sahip mi? Veritabanlarından birini yeniden adlandırarak bu çakışmayı çözün.
• SAS belirteci için izinler salt okunur ve listeleniyor mu? ve değerinden ReadList daha fazla izin verilmesi LRS'nin başarısız olmasına neden olur.
• Soru işaretinden ()? sonra LRS için SAS belirtecini, şuna benzeyen sv=2020-02-10...içerikle kopyaladınız mı?
• SAS belirteci geçerlilik süresi, geçişi başlatma ve tamamlama zaman penceresi için uygun mu? SQL Yönetilen Örneği dağıtımınız ve SAS belirteciniz için kullanılan farklı saat dilimleri nedeniyle uyuşmazlıklar olabilir. SAS belirtecini yeniden oluşturmayı ve geçerli tarihten önceki ve sonraki zaman penceresinin belirteç geçerliliğini genişletmeyi deneyin.
• Aynı depolama kapsayıcısını hedefleyen birden çok Günlük Yeniden Yürütme geri yüklemesini paralel olarak başlatırken, her geri yükleme işlemi için aynı geçerli SAS belirtecinin sağlandığından emin olun.
• Veritabanı adı, kaynak grubu adı ve yönetilen örnek adı doğru yazıldı mı?
• LRS'yi otomatik tamamlama modunda başlattıysanız, belirtilen son yedekleme dosyası için geçerli bir dosya adı var mıydı?
• Yedekleme URI'sinin yolu veya backupanahtar sözcüklerini backups içeriyor mu? veya kullanan backupbackups kapsayıcıyı veya klasörleri ayrılmış anahtar sözcükler olarak yeniden adlandırın.

Sonraki adımlar

• Bağlantı özelliğini kullanarak Azure SQL Yönetilen Örneği geçiş hakkında daha fazla bilgi edinin.
• SQL Server'dan Azure SQL Yönetilen Örneği geçiş hakkında daha fazla bilgi edinin.
• SQL Server ile SQL Yönetilen Örneği arasındaki farklar hakkında daha fazla bilgi edinin.
• Azure'a geçirilen iş yüklerini maliyetlendirmeye ve boyutlandırmaya yönelik en iyi yöntemler hakkında daha fazla bilgi edinin.