ترحيل قواعد البيانات من SQL Server إلى SQL Managed Instance باستخدام Log Replay Service (معاينة)
ينطبق على:
مثيل Azure SQL المُدار
توضح هذه المقالة كيفية تكوين ترحيل قاعدة البيانات يدوياً من SQL Server 2008-2019 إلى Azure SQL Managed Instance باستخدام Log Replay Service (LRS) الموجود حالياً في المعاينة العامة. تعد LRS خدمة سحابية مجانية تم تمكينها لـAzure SQL Managed Instance استناداً إلى تقنية شحن سجل SQL Server.
تستخدم Azure Database Migration Service وLRS نفس تقنية الترحيل الأساسية وواجهات برمجة التطبيقات. يمكّن LRS أيضاً عمليات الترحيل المخصصة المعقدة وأساليب البناء المختلطة بين SQL Server المحلي وSQL Managed Instance.
متى يتم استخدام Log Replay Service
عندما لا يمكنك استخدام Azure Database Migration Service للترحيل، يمكنك استخدام LRS مباشرةً مع PowerShell أو Azure CLI cmdlets أو واجهات برمجة التطبيقات لإنشاء عمليات ترحيل قاعدة البيانات وتنظيمها يدوياً إلى SQL Managed Instance.
ضع في اعتبارك استخدام LRS في الحالات التالية:
- الحاجة إلى مزيد من التحكم في مشروع ترحيل قاعدة بياناتك.
- هناك القليل من التفاوت للتوقف أثناء الترحيل.
- لا يمكن تثبيت الملف القابل للتنفيذ Database Migration Service على بيئتك.
- لا يمتلك الملف القابل للتنفيذ Database Migration Service حق الوصول إلى الملفات لنسخ قاعدة البيانات الاحتياطية الخاصة بك.
- عدم إمكانية الوصول إلى نظام التشغيل المضيف أو عدم وجود امتيازات المسؤول.
- عدم إمكانية فتح منافذ شبكة الاتصال من بيئتك إلى Azure.
- توجد مشاكل تقييد الشبكة أو حظر الوكيل في بيئتك.
- يتم تخزين النسخ الاحتياطية مباشرة في Azure Blob Storage من خلال الخيار
TO URL. - يتعين عليك استخدام النسخ الاحتياطية التفاضلية.
ملاحظة
نوصي بأتمتة ترحيل قواعد البيانات من SQL Server إلى SQL Managed Instance باستخدام Database Migration Service. تستخدم هذه الخدمة نفس الخدمة السحابية LRS في النهاية الخلفية، مع تسجيل الشحن في وضع NORECOVERY. ضع في اعتبارك استخدام LRS يدوياً لتنظيم عمليات الترحيل عندما لا تدعم Database Migration Service السيناريوهات الخاصة بك بشكل كامل.
كيف تعمل هذه الميزة
يتطلب إنشاء حل مخصص لترحيل قواعد البيانات إلى السحابة باستخدام LRS عدة خطوات تنسيق، كما هو موضح في الرسم التخطيطي والجدول لاحقاً في هذا القسم.
يتكون الترحيل من عمل نُسخ احتياطية لقاعدة البيانات على SQL Server مع تمكين CHECKSUM، ونسخ ملفات النسخ الاحتياطي إلى Azure Blob Storage. يتم دعم النسخ الاحتياطية الكاملة والسجلات والتفاضلية. تُستخدم الخدمة السحابية LRS لاستعادة ملفات النسخ الاحتياطي من تخزين Azure Blob إلى مثيل SQL المُدار. Blob Storage هو تخزين وسيط بين SQL Server وSQL Managed Instance.
إن LRS يراقب Blob Storage لأي تفاضل جديد أو نسخ احتياطية للسجلات تمت إضافتها بعد استعادة النسخة الاحتياطية الكاملة. ثم يستعيد LRS هذه الملفات الجديدة تلقائياً. يمكنك استخدام الخدمة لمراقبة تقدم ملفات النسخ الاحتياطي التي تتم استعادتها إلى SQL Managed Instance وإيقاف العملية إذا لزم الأمر.
لا يتطلب LRS اصطلاح تسمية محدد لملفات النسخ الاحتياطي. يقوم بمسح جميع الملفات الموضوعة على Blob Storage وإنشاء سلسلة النسخ الاحتياطي من قراءة رؤوس الملفات فقط. قواعد البيانات في حالة استعادة أثناء عملية الترحيل. تتم استعادة قواعد البيانات في وضع NORECOVERY، لذلك لا يمكن استخدامها للقراءة أو الكتابة لأحمال العمل حتى تكتمل عملية الترحيل.
إذا كنت تقوم بترحيل عدة قواعد بيانات، فأنت بحاجة إلى:
- ضع ملفات النسخ الاحتياطي لكل قاعدة بيانات في مجلد منفصل على مساحة تخزين Azure Blob في بنية ملف ثابت. على سبيل المثال، استخدم مجلدات قاعدة بيانات منفصلة:
bolbcontainer/database1/files،blobcontainer/database2/files، إلخ. - لا تستخدم المجلدات المتداخلة داخل مجلدات قاعدة البيانات لأن هذه البنية غير مدعومة. على سبيل المثال، لا تستخدم المجلدات الفرعية:
blobcontainer/database1/subfolder/files. - بدء تشغيل LRS بشكل منفصل لجميع قواعد البيانات.
- حدد مسارات مختلفة لـURI لفصل مجلدات قاعدة البيانات على Azure Blob Storage.
يمكنك بدء LRS إما في وضع إكمال تلقائي أو الوضع مستمر. عند بدء تشغيله في وضع الإكمال التلقائي، يكتمل الترحيل تلقائياً عند استعادة آخر ملفات النسخ الاحتياطي المحددة. عند بدء تشغيل LRS في الوضع المستمر، ستستعيد الخدمة باستمرار أي ملفات نسخ احتياطي جديدة مضافة، ويكتمل الترحيل أثناء النقل اليدوي فقط.
نوصي بالقطع يدوياً بعد إظهار النسخة الاحتياطية النهائية لسجل الذيل على أنها مستعادة في SQL Managed Instance. تجعل الخطوة النهائية قاعدة البيانات تأتي عبر الإنترنت ومتاحة للقراءة والكتابة لاستخدامها في SQL Managed Instance.
بعد إيقاف LRS، إما تلقائياً من خلال الإكمال التلقائي أو يدوياً من خلال الترحيل الكلي، لا يمكنك استئناف عملية الاستعادة لقاعدة البيانات التي تم إحضارها عبر الإنترنت على SQL Managed Instance. على سبيل المثال، بمجرد اكتمال الترحيل، لن تتمكن من استعادة النسخ الاحتياطية التفاضلية الإضافية لقاعدة بيانات عبر الإنترنت. لاستعادة المزيد من ملفات النسخ الاحتياطي بعد اكتمال الترحيل، تحتاج إلى حذف قاعدة البيانات من المثيل المُدار وإعادة تشغيل الترحيل من البداية.
| التشغيل | التفاصيل |
|---|---|
| 1. نسخ النسخ الاحتياطية لقاعدة البيانات من SQL Server إلى Blob Storage. | نسخ النسخ الاحتياطي الكامل والتفاضلي والسجلات من SQL Server إلى حاوية Blob Storage باستخدامAzCopy أو Azure Storage Explorer. استخدم أي أسماء ملفات. لا يتطلب LRS اصطلاحاً محدداً لتسمية الملفات. استخدم مجلداً منفصلاً لكل قاعدة بيانات عند ترحيل عدة قواعد بيانات. |
| 2. بدأ LRS في السحابة. | يمكنك بدء الخدمة باستخدام PowerShell (start-azsqlinstancedatabaselogreplay) أو Azure CLI (az_sql_midb_log_replay_start cmdlets). ابدأ LRS بشكل منفصل لكل قاعدة بيانات تشير إلى مجلد نسخ احتياطي على Blob Storage. بعد بدء الخدمة، ستأخذ نُسخاً احتياطية من حاوية تخزين Blob وتبدأ في استعادتها إلى SQL Managed Instance. عند بدء التشغيل في الوضع المستمر، يستعيد LRS جميع النسخ الاحتياطية التي تم تحميلها في البداية ثم يراقب أي ملفات جديدة تم تحميلها إلى المجلد. ستعمل الخدمة باستمرار على تطبيق السجلات بناءً على سلسلة رقم تسلسل السجل (LSN) حتى يتم إيقافها يدوياً. |
| 2.1. مراقبة مدى تقدم العملية. | يمكنك مراقبة تقدم عملية الاستعادة باستخدام PowerShell (get-azsqlinstancedatabaselogreplay) أو Azure CLI (az_sql_midb_log_replay_show cmdlets). |
| 2.2. إيقاف العملية إذا لزم الأمر. | إذا كنت تريد إيقاف عملية الترحيل، فاستخدم PowerShell (stop-azsqlinstancedatabaselogreplay) أو Azure CLI (az_sql_midb_log_replay_stop). يؤدي إيقاف العملية إلى حذف قاعدة البيانات التي تقوم باستعادتها إلى SQL Managed Instance. بعد إيقاف عملية، لا يمكنك استئناف LRS لقاعدة بيانات. تحتاج إلى إعادة تشغيل عملية الترحيل من البداية. |
| 3. الترحيل الكلي إلى السحابة عندما تكون جاهزاً. | أوقف كلاً من التطبيق وحمل العمل. احصل على آخر نسخة احتياطية من سجل النسخ الاحتياطي وقم بتحميلها على Azure Blob Storage. أكمل عملية النقل ببدء عملية LRS complete باستخدام PowerShell (complete-azsqlinstancedatabaselogreplay) أو Azure CLI az_sql_midb_log_replay_complete. توقف هذه العملية LRS وتجلب قاعدة البيانات عبر الإنترنت لقراءة وكتابة أحمال العمل على SQL Managed Instance.إعادة تعيين سلسلة اتصال التطبيق من SQL Server إلى SQL Managed Instance. يتعين عليك تنظيم هذه الخطوة بنفسك، إما من خلال تغيير سلسلة الاتصال اليدوي في التطبيق الخاص بك، أو تلقائياً (على سبيل المثال، إذا كان التطبيق الخاص بك يمكنه قراءة سلسلة الاتصال من خاصية أو قاعدة بيانات). |
الشروع في العمل
ضع في الاعتبار المتطلبات الواردة في هذا القسم للبدء في استخدام LRS للترحيل.
SQL Server
تأكد من أن لديك المتطلبات التالية لـSQL Server:
- إصدارات SQL Server من 2008 إلى 2019
- نسخ احتياطي كامل لقواعد البيانات (ملف واحد أو عدة ملفات)
- نسخ احتياطي تفاضلي (ملف واحد أو عدة ملفات)
- سجل النسخ الاحتياطي (غير مقسم لملف سجل المعاملات)
- تم تمكين
CHECKSUMللنسخ الاحتياطية (إلزامي)
Azure
تأكد من أن لديك المتطلبات التالية لـAzure:
- إصدار الوحدة النمطية PowerShell Az.SQL 2.16.0 أو إصدار لاحق ( مثبت أو يمكن الوصول إليه من خلال Azure Cloud Shell)
- إصدار Azure CLI 2.19.0 أو أحدث (مثبت)
- تم توفير حاوية Azure Blob Storage
- رمز أمان مميز لتوقيع الوصول المشترك (SAS) مع أذونات القراءة والقائمة التي تم إنشاؤها لحاوية Blob Storage
أذونات Azure RBAC
يتطلب تشغيل LRS من خلال العملاء المقدمين أحد أدوار Azure التالية:
- دور مالك الاشتراك
- دور Managed Instance Contributor
- دور مخصص بالإذن التالي:
Microsoft.Sql/managedInstances/databases/*
المتطلبات
يرجى التأكد من استيفاء المتطلبات التالية:
- استخدام نموذج الاسترداد الكامل في SQL Server (إلزامي).
- استخدام
CHECKSUMللنسخ الاحتياطية على SQL Server (إلزامي). - ضع ملفات النسخ الاحتياطي لقاعدة بيانات فردية داخل مجلد منفصل في هيكل ملف ثابت (إلزامي). المجلدات المتداخلة داخل مجلدات قاعدة البيانات غير مدعومة.
- خطط لإكمال الترحيل في غضون 36 ساعة بعد بدء LRS (إلزامي). هذه فترة سماح يتم خلالها تأجيل تصحيحات البرامج التي يديرها النظام.
أفضل الممارسات
نوصي بأفضل الممارسات التالية:
- قم بتشغيل Data Migration Assistant للتحقق من أن قواعد البيانات جاهزة للترحيل إلى SQL Managed Instance.
- قسّم النسخ الاحتياطية الكاملة والتفاضلية إلى ملفات متعددة، بدلاً من استخدام ملف واحد.
- تمكين ضغط النسخ الاحتياطي للمساعدة في نقل سرعات الشبكة.
- استخدم Cloud Shell لتشغيل البرامج النصية PowerShell أو CLI، لأنه سيتم تحديثها دائماً إلى أحدث أوامر cmdlets التي تم إصدارها.
هام
- لا يمكنك استخدام قواعد البيانات التي تتم استعادتها من خلال LRS حتى تكتمل عملية الترحيل.
- لا يدعم LRS الوصول للقراءة فقط إلى قواعد البيانات أثناء الترحيل.
- بعد اكتمال الترحيل، يتم إنهاء عملية الترحيل ولا يمكن استئنافها مع النسخ الاحتياطية التفاضلية الإضافية.
خطوات الترحيل
للترحيل باستخدام LRS، اتبع الخطوات الواردة في هذا القسم.
إجراء نسخ احتياطية لقاعدة البيانات على SQL Server
يمكنك عمل نسخ احتياطية لقاعدة البيانات على SQL Server باستخدام أي من الخيارات التالية:
- قم بالنسخ الاحتياطي إلى وحدة تخزين القرص المحلي، ثم قم بتحميل الملفات إلى Azure Blob Storage، إذا كانت بيئتك تقيد النسخ الاحتياطية المباشرة إلى Blob Storage.
- قم بالنسخ الاحتياطي مباشرة إلى Blob Storage باستخدام الخيار
TO URLفي Transact-SQL (T-SQL)، إذا كانت البيئة والإجراءات الأمنية تسمح بذلك.
قم بتعيين قواعد البيانات التي تريد ترحيلها إلى وضع الاسترداد الكامل للسماح بالنسخ الاحتياطي للسجلات.
-- 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
لعمل نسخ احتياطية كاملة وتفاضلية وتسجيلية لقاعدة البيانات الخاصة بك يدوياً إلى التخزين المحلي، استخدم عينات البرامج النصية التالية من T-SQL. تأكد من تمكين الخيار CHECKSUM، لأنه إلزامي لـLRS.
يأخذ المثال التالي نسخة احتياطية كاملة من قاعدة البيانات إلى القرص المحلي:
-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
يأخذ المثال التالي نسخة احتياطية تفاضلية إلى القرص المحلي:
-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
يأخذ المثال التالي نسخة احتياطية لسجل العمليات إلى القرص المحلي:
-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO
إنشاء حساب تخزين
يتم استخدام تخزين Azure Blob كمخزن وسيط لملفات النسخ الاحتياطي بين SQL Server وSQL Managed Instance. لإنشاء حساب تخزين جديد وحاوية blob داخل حساب التخزين، اتبع الخطوات التالية:
- أنشئ حساب تخزين.
- أنشئ حاوية blob داخل حساب التخزين.
قم بنسخ النسخ الاحتياطية من SQL Server إلى Blob Storage
عند ترحيل قواعد البيانات إلى مثيل مُدار باستخدام LRS، يمكنك استخدام الطرق التالية لتحميل نُسخ احتياطية إلى تخزين Blob:
- خادم SQL Server الأصلي BACKUP TO URL
- AzCopy أو Azure Storage Explorer لتحميل النسخ الاحتياطية إلى حاوية البيانات الثنائية الكبيرة
- مستكشف التخزين في مدخل Microsoft Azure
ملاحظة
لترحيل قواعد بيانات متعددة باستخدام نفس حاوية تخزين Azure Blob، ضع جميع ملفات النسخ الاحتياطي لقاعدة بيانات فردية في مجلد منفصل داخل الحاوية. استخدم بنية الملف الثابت لكل مجلد قاعدة بيانات، حيث لا يتم دعم المجلدات المتداخلة.
عمل نسخ احتياطية من SQL Server مباشرة إلى Blob Storage
إذا كانت نُهج شركتك والشبكة تسمح بذلك، فخذ نسخاً احتياطية من SQL Server مباشرة إلى Blob Storage باستخدام خيار SQL Server الأصلي BACKUP TO URL. إذا كان بإمكانك استخدام هذا الخيار، فلن تحتاج إلى الاحتفاظ بنسخ احتياطية على وحدة التخزين المحلية وتحميلها على Blob Storage.
كخطوة أولى، تتطلب هذه العملية إنشاء رمز مصادقة SAS لـ Blob Storage ثم استيراد الرمز المميز إلى SQL Server. الخطوة الثانية هي عمل نسخ احتياطية باستخدام الخيار TO URL في T-SQL. تأكد من عمل جميع النسخ الاحتياطية مع تمكين الخيار CHEKSUM.
كمرجع، يقوم نموذج التعليمات البرمجية التالي بعمل نسخ احتياطية إلى Blob Storage. لا يتضمن هذا المثال إرشادات حول كيفية استيراد رمز SAS. يمكنك العثور على إرشادات مفصلة، بما في ذلك كيفية إنشاء واستيراد رمز SAS المميز إلى SQL Server، في البرنامج التعليمي استخدام Azure Blob Storage مع SQL Server.
يأخذ المثال التالي نسخة احتياطية كاملة لقاعدة البيانات إلى عنوان URL:
-- 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
يأخذ المثال التالي نسخة احتياطية تفاضلية لقاعدة البيانات إلى عنوان URL:
-- 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
يأخذ المثال التالي نسخة احتياطية لسجل الإجراءات إلى عنوان URL:
-- 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 Blob، يجب وضع ملفات النسخ الاحتياطي لقواعد بيانات مختلفة في مجلدات منفصلة داخل الحاوية. يجب وضع جميع ملفات النسخ الاحتياطي لقاعدة بيانات واحدة في بنية ملف ثابت داخل مجلد قاعدة بيانات، ولا يمكن دمج المجلدات، لأنها غير مدعومة.
يوجد أدناه مثال على بنية المجلد داخل حاوية تخزين Azure Blob المطلوبة لترحيل قواعد بيانات متعددة باستخدام LRS.
-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Do not use nested folders inside 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.
-- Do not use nested folders inside 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.
-- Do not use nested folders inside database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>
إنشاء رمز مصادقة Blob Storage SAS لـ LRS
يتم استخدام تخزين Azure Blob كمخزن وسيط لملفات النسخ الاحتياطي بين SQL Server وSQL Managed Instance. قم بإنشاء رمز مصادقة SAS لـLRS مع أذونات القائمة والقراءة فقط. يمكّن الرمز المميز LRS من الوصول إلى تخزين Blob ويستخدم ملفات النسخ الاحتياطي لاستعادتها إلى SQL Managed Instance.
اتبع هذه الخطوات لإنشاء الرمز المميز:
افتح Storage Explorer من مدخل Microsoft Azure.
قم بتوسيع حاويات Blob.
انقر بزر الماوس الأيمن فوق حاوية blob وحدد Get Shared Access Signature.
حدد الإطار الزمني لانتهاء صلاحية الرمز المميز. تأكد من أن الرمز المميز صالح طوال مدة الترحيل.
حدد المنطقة الزمنية للرمز المميز: UTC أو التوقيت المحلي.
هام
قد لا تتطابق المنطقة الزمنية للرمز المميز والمثيل المُدار. تأكد من أن رمز SAS لديه الصلاحية الزمنية المناسبة، مع مراعاة المناطق الزمنية. لحساب اختلافات المنطقة الزمنية، قم بتعيين الإطار الزمني للصلاحية FROM قبل بدء فترة الترحيل بوقت طويل، والإطار الزمني TO بعد توقع اكتمال الترحيل.
حدد أذونات قراءة وقائمة فقط.
هام
تجنب تحديد أي أذونات أخرى. إذا قمت بذلك، فلن يبدأ LRS. مطلب الأمان هذا حسب التصميم.
حدد Create.
يتم إنشاء مصادقة SAS مع صلاحية الوقت التي حددتها. أنت بحاجة إلى إصدار URI للرمز المميز، كما هو موضح في لقطة الشاشة التالية.
ملاحظة
لا يتم دعم استخدام رموز SAS المميزة التي تم إنشاؤها باستخدام أذونات تم تعيينها من خلال تحديد stored access policy في الوقت الحالي. اتبع الإرشادات الواردة في هذه المقالة لتحديد أذونات Read وList يدوياً لرمز SAS المميز.
نسخ المعلمات من الرمز المميز SAS
قبل استخدام رمز SAS لبدء تشغيل LRS، تحتاج إلى فهم هيكلها. يتكون عنوان URI لرمز SAS الذي تم إنشاؤه من جزأين منفصلين بعلامة استفهام (?)، كما هو موضح في هذا المثال:
الجزء الأول، بدءاً من https:// حتى علامة الاستفهام (?)، يُستخدم للمعلمة StorageContainerURI التي تتم تغذيتها كمدخل إلى LRS. يعطي معلومات LRS عن المجلد حيث يتم تخزين ملفات النسخ الاحتياطي لقاعدة البيانات.
الجزء الثاني، الذي يبدأ بعد علامة الاستفهام (?) ويمتد حتى نهاية السلسلة، هو المعلمة StorageContainerSasToken. هذا الجزء هو رمز المصادقة الفعلي الموقع، وهو صالح لمدة الوقت المحدد. لا يحتاج هذا الجزء بالضرورة أن يبدأ بـ sp= كما هو موضح في المثال. قد تختلف حالتك.
انسخ المعلمات على النحو التالي:
انسخ الجزء الأول من الرمز المميز، بدءاً من
https://حتى علامة الاستفهام (?). استخدمها كمعلمةStorageContainerUriفي PowerShell أو Azure CLI عند بدء LRS.
انسخ الجزء الثاني من الرمز المميز، بدءاً من علامة الاستفهام (
?) حتى نهاية السلسلة. استخدمها كمعلمةStorageContainerSasTokenفي PowerShell أو Azure CLI عند بدء LRS.
ملاحظة
لا تقم بتضمين علامة الاستفهام (?) عند نسخ أي جزء من الرمز المميز.
سجّل الدخول إلى Azure وحدد اشتراكاً
استخدم أمر PowerShell cmdlet التالي لتسجيل الدخول إلى Azure:
Login-AzAccount
حدد الاشتراك المناسب حيث يوجد المثيل المُدار باستخدام أمر PowerShell cmdlet التالي:
Select-AzSubscription -SubscriptionId <subscription ID>
بدء الترحيل
تبدأ الترحيل عن طريق بدء تشغيل LRS. يمكنك بدء الخدمة إما في وضع الإكمال التلقائي أو المستمر.
عند استخدام وضع الإكمال التلقائي، يكتمل الترحيل تلقائياً عند استعادة آخر ملفات النسخ الاحتياطي المحددة. يتطلب هذا الخيار أمر البدء لتحديد اسم ملف آخر ملف نسخ احتياطي.
عند استخدام الوضع المستمر، تستعيد الخدمة باستمرار أي ملفات نسخ احتياطي جديدة تمت إضافتها. يكتمل الترحيل فقط أثناء الانتقال اليدوي.
ملاحظة
عند ترحيل قواعد بيانات متعددة، يجب بدء تشغيل LRS بشكل منفصل لكل قاعدة بيانات تشير إلى مسار URI الكامل لحاوية تخزين Azure Blob ومجلد قاعدة البيانات الفردية.
ابدأ تشغيل LRS في وضع الإكمال التلقائي
لبدء LRS في وضع الإكمال التلقائي، استخدم أوامر PowerShell أو Azure CLI. حدد اسم ملف النسخ الاحتياطي الأخير باستخدام المعلمة -LastBackupName. عند استعادة آخر ملفات النسخ الاحتياطي المحددة، تبدأ الخدمة تلقائياً عملية الانتقال.
يبدأ مثال PowerShell التالي LRS في وضع الإكمال التلقائي:
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"
يبدأ مثال Azure CLI التالي LRS في وضع الإكمال التلقائي:
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"
ابدأ تشغيل LRS في الوضع المستمر
يبدأ مثال PowerShell التالي LRS في الوضع المستمر:
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"
يبدأ مثال Azure CLI التالي LRS في الوضع المستمر:
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"
عملاء PowerShell وCLI الذين يبدؤون LRS في الوضع المستمر متزامنون. هذا يعني أن العميل ينتظر استجابة API للإبلاغ عن النجاح أو الفشل في بدء المهمة.
أثناء هذا الانتظار، لن يعيد الأمر التحكم إلى موجه الأوامر. إذا كنت تبرمج الترحيل، وتحتاج إلى أمر بدء LRS لإعادة التحكم فوراً لمتابعة بقية البرنامج النصي، يمكنك تشغيل PowerShell كوظيفة في الخلفية باستخدام مفتاح -AsJob. على سبيل المثال:
$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob
عند بدء وظيفة في الخلفية، يعود كائن الوظيفة على الفور، حتى إذا كانت المهمة تستغرق وقتاً طويلاً للاكتمال. يمكنك الاستمرار في العمل في الجلسة دون مقاطعة أثناء تشغيل الوظيفة. للحصول على تفاصيل حول تشغيل PowerShell كوظيفة في الخلفية، راجع وثائق PowerShell Start-Job.
وبالمثل، لبدء أمر Azure CLI على Linux كعملية في الخلفية، استخدم علامة العطف (&) في نهاية أمر بدء تشغيل LRS:
az sql midb log-replay start <required parameters> &
هام
بعد بدء تشغيل LRS، يتم إيقاف أي تصحيحات للبرامج التي يديرها النظام لمدة 36 ساعة. بعد هذه النافذة، سيتوقف التصحيح الآلي التالي للبرنامج تلقائياً عن LRS. إذا حدث ذلك، فلا يمكنك استئناف الترحيل وتحتاج إلى إعادة تشغيله من البداية.
مراقبة تقدم الترحيل
لمراقبة تقدم الترحيل من خلال PowerShell، استخدم الأمر التالي:
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
لمراقبة تقدم الترحيل من خلال Azure CLI، استخدم الأمر التالي:
az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb
أوقف الترحيل
إذا كنت بحاجة إلى إيقاف الترحيل، فاستخدم PowerShell أو Azure CLI. يؤدي إيقاف الترحيل إلى حذف قاعدة بيانات الاستعادة في SQL Managed Instance، لذا لن يكون استئناف الترحيل ممكناً.
لإيقاف عملية الترحيل من خلال PowerShell، استخدم الأمر التالي:
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
لإيقاف عملية الترحيل من خلال Azure CLI، استخدم الأمر التالي:
az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb
أكمل الترحيل (الوضع المستمر)
إذا قمت بتشغيل LRS في الوضع المستمر، بعد التأكد من استعادة جميع النسخ الاحتياطية، فإن بدء الانتقال سيؤدي إلى إكمال الترحيل. بعد الانتقال، يتم ترحيل قاعدة البيانات وتكون جاهزة للوصول للقراءة والكتابة.
لإكمال عملية الترحيل في الوضع المستمر LRS من خلال PowerShell، استخدم الأمر التالي:
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"
لإكمال عملية الترحيل في الوضع المستمر LRS من خلال Azure CLI، استخدم الأمر التالي:
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
التقييدات
ضع في اعتبارك القيود التالية لـLRS:
- أثناء عملية الترحيل، لا يمكن استخدام قواعد البيانات التي يتم ترحيلها للوصول للقراءة فقط على مثيل SQL المُدار.
- يتم حظر تصحيحات البرامج المدارة من قبل النظام لمدة 36 ساعة بمجرد بدء تشغيل LRS. بعد انتهاء صلاحية هذه النافذة الزمنية، يتوقف تحديث صيانة البرنامج التالي عن LRS. سوف تحتاج إلى إعادة تشغيل ترحيل LRS من البداية.
- يتطلب LRS قواعد البيانات على SQL Server ليتم نسخها احتياطياً مع تمكين الخيار
CHECKSUM. - يجب إنشاء رمز SAS المميز الذي يستخدمه LRS لحاويةAzure Blob Storage بالكامل، ويجب أن يحتوي على أذونات Read وList فقط. على سبيل المثال، إذا منحت أذونات Readو List وWrite، فلن يتمكن LRS من البدء بسبب إذن Write الإضافي.
- لا يتم دعم استخدام رموز SAS المميزة التي تم إنشاؤها باستخدام أذونات تم تعيينها من خلال تحديد stored access policy في الوقت الحالي. اتبع الإرشادات الواردة في هذه المقالة لتحديد أذونات Read وList يدوياً لرمز SAS المميز.
- ملفات النسخ الاحتياطي التي تحتوي على الأحرف ٪ و$ في اسم الملف لا يمكن أن يستهلكها LRS. فكر في إعادة تسمية أسماء الملفات هذه.
- يجب وضع ملفات النسخ الاحتياطي لقواعد بيانات مختلفة في مجلدات منفصلة على Blob Storage في بنية ملف ثابت. المجلدات المتداخلة داخل مجلدات قاعدة البيانات الفردية غير مدعومة.
- يجب بدء تشغيل LRS بشكل منفصل لكل قاعدة بيانات تشير إلى مسار URI الكامل الذي يحتوي على مجلد قاعدة بيانات فردي.
- يمكن لـ LRS دعم ما يصل إلى 100 عملية استعادة متزامنة لكل مثيل مُدار فردي.
ملاحظة
إذا كنت تحتاج إلى أن تكون قاعدة البيانات يمكن الوصول إليها R / O أثناء الترحيل، وإذا كنت تحتاج إلى نافذة ترحيل أكبر من 36 ساعة، فالرجاء اعتبار ميزة الارتباط لـManaged Instance حلاً بديل للترحيل.
استكشاف الأخطاء وإصلاحها
بعد بدء تشغيل LRS، استخدم أمر cmdlet للمراقبة (PowerShell: get-azsqlinstancedatabaselogreplay أو Azure CLI: az_sql_midb_log_replay_show) لمعرفة حالة العملية. إذا فشل LRS في البدء بعد مرور بعض الوقت وظهرت لك رسالة خطأ، فتحقق من المشكلات الأكثر شيوعاً:
- هل توجد قاعدة بيانات موجودة في SQL Managed Instance لها نفس الاسم الذي تحاول ترحيله من SQL Server؟ قم بحل هذا التعارض عن طريق إعادة تسمية إحدى قواعد البيانات.
- هل تم إجراء النسخ الاحتياطي لقاعدة البيانات على SQL Server من خلال الخيار
CHECKSUM؟ - هل يتم منح الأذونات لقراءة الرمز المميز والقائمةفقط؟
- هل قمت بنسخ رمز SAS المميز لـ LRS بعد علامة الاستفهام (
?)، حيث يبدأ المحتوى على النحو التالي:sv=2020-02-10...؟ - هل ينطبق وقت صلاحية رمز SAS المميز على النافذة الزمنية لبدء الترحيل واستكماله؟ قد يكون هناك عدم تطابق بسبب المناطق الزمنية المختلفة المستخدمة لـ SQL Managed Instance والرمز المميز SAS. حاول إعادة إنشاء رمز SAS المميز وتمديد صلاحية الرمز المميز لنافذة الوقت قبل التاريخ الحالي وبعده.
- هل اسم قاعدة البيانات واسم مجموعة الموارد واسم المثيل المُدار مكتوباً بشكل صحيح؟
- إذا بدأت LRS في وضع الإكمال التلقائي، فهل تم تحديد اسم ملف صالح لآخر ملف نسخ احتياطي؟
الخطوات التالية
- تعرف على المزيد عن الترحيل إلى SQL Managed Instance باستخدام ميزة الارتباط.
- تعرف على المزيد عن الترحيل من SQL Server إلى مثيل SQL المُدار.
- تعرف على المزيد حول الاختلافات بين SQL Server وSQL Managed Instance.
- تعرف على المزيد حول أفضل الممارسات لتكلفة وحجم أعباء العمل التي تم ترحيلها إلى Azure.
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ