انتقال دیتابیس ریپلیکیت شده SQL Server

چگونه دیتابیس‌های ریپلیکیت شده SQL Server را با موفقیت منتقل کنیم؟

انتقال پایگاه‌های داده (Databases) در SQL Server یک کار رایج است، اما زمانی که با Replication (همگام‌سازی داده‌ها) سروکار داریم، این فرآیند پیچیده‌تر می‌شود. سیستم Replication در SQL Server به شدت به مسیرهای فیزیکی فایل‌های پایگاه داده وابسته است. این مقاله یک رویکرد جامع برای انتقال پایگاه‌های داده ریپلیکیت شده (Replicated Databases) ارائه می‌دهد، با تمرکز بر حفظ یکپارچگی Replication پس از جابجایی فایل‌ها.

چالش‌های انتقال دیتابیس ریپلیکیت شده

SQL Server ابزاری داخلی برای جابجایی آسان دیتابیس‌های ریپلیکیت شده ارائه نمی‌دهد. وقتی فایل‌های داده (MDF) و لاگ (LDF) را به یک مکان جدید منتقل می‌کنید، سیستم Replication همچنان انتظار دارد فایل‌ها را در مسیرهای قدیمی پیدا کند. این منجر به از کار افتادن Replication و بروز خطا می‌شود. برای رفع این مشکل، باید متادیتا (Metadata) مربوط به Replication را در دیتابیس‌های سیستمی (System Databases) SQL Server به‌روزرسانی کنیم.

سناریوی عملی: انتقال به درایو جدید

فرض کنید می‌خواهیم یک دیتابیس ریپلیکیت شده را از درایو D: به درایو E: منتقل کنیم. مراحل کلی برای جابجایی فایل‌های دیتابیس بدون در نظر گرفتن Replication به شرح زیر است:

1. توقف SQL Server Agent: این سرویس را برای جلوگیری از هرگونه فعالیت دیتابیس در طول جابجایی متوقف کنید.
2. یافتن مسیر فایل‌ها: مسیرهای کنونی فایل‌های .mdf و .ldf را شناسایی کنید.
3. آفلاین کردن دیتابیس: دیتابیس مورد نظر را آفلاین کنید تا فایل‌ها برای جابجایی آزاد شوند.
4. جابجایی فیزیکی فایل‌ها: فایل‌های .mdf و .ldf را به مسیر جدید منتقل کنید.
5. آنلاین کردن دیتابیس با مسیر جدید: دیتابیس را با اشاره به مسیرهای جدید فایل‌ها آنلاین کنید.
6. راه‌اندازی مجدد SQL Server Agent: سرویس را دوباره اجرا کنید.
7. اعتبارسنجی: از صحت عملکرد دیتابیس اطمینان حاصل کنید.

گام‌های دقیق برای جابجایی دیتابیس ریپلیکیت شده

اکنون به سراغ جزئیات می‌رویم، با در نظر گرفتن پیچیدگی‌های Replication. این فرآیند شامل به‌روزرسانی متادیتاهای داخلی SQL Server است.

۱. آماده‌سازی و شناسایی Publication/Subscription

قبل از هر چیز، نیاز داریم اطلاعات مربوط به Publication و Subscription دیتابیس مورد نظر را استخراج کنیم. این اطلاعات برای پیکربندی مجدد Replication ضروری است.

ابتدا، نام دیتابیس، Publisher (منتشرکننده)، و Subscriber (مشترک) را تعریف می‌کنیم:

DECLARE @DatabaseName AS SYSNAME = N'MyReplicatedDB';
DECLARE @PublisherName AS SYSNAME = N'MyPublisherServer';
DECLARE @SubscriberName AS SYSNAME = N'MySubscriberServer';
DECLARE @DistributionDB AS SYSNAME = N'distribution';

سپس، Publisher ID را از جدول سیستمی MSpublishers در دیتابیس توزیع‌کننده (Distributor Database) به دست می‌آوریم:

DECLARE @PublisherID AS INT;
SELECT @PublisherID = [ID] FROM [dbo].[MSpublishers] WHERE [publisher_name] = @PublisherName;

این اطلاعات به ما کمک می‌کند تا Publicationهای فعال روی دیتابیس مورد نظر را شناسایی کنیم.

۲. جدا کردن Replication از دیتابیس

برای اینکه بتوانیم فایل‌های دیتابیس را جابجا کنیم و سپس Replication را مجدداً پیکربندی کنیم، باید ابتدا ارتباط Replication فعلی را قطع کنیم. این کار با استفاده از sp_removedbreplication انجام می‌شود.

قبل از اجرای این دستور، اطمینان حاصل کنید که مالک دیتابیس (Database Owner) روی ‘sa’ تنظیم شده است، زیرا برخی از فرآیندهای Replication نیاز به این تنظیم دارند. اگر قبلاً ‘sa’ نیست، آن را تغییر دهید:

USE [@DatabaseName]; -- دیتابیس مورد نظر خود را اینجا قرار دهید
GO
EXEC sp_changedbowner 'sa';
GO

حالا Replication را از دیتابیس جدا می‌کنیم:

USE [@DatabaseName]; -- اطمینان حاصل کنید که در دیتابیس صحیح هستید
GO
EXEC sp_removedbreplication @dbname = @DatabaseName;
GO

۳. جابجایی فیزیکی فایل‌های دیتابیس

پس از جدا کردن Replication، اکنون می‌توانیم فایل‌های .mdf و .ldf را جابجا کنیم. این مرحله مشابه جابجایی یک دیتابیس غیر ریپلیکیت شده است.

ابتدا، SQL Server Agent را متوقف کنید.

سپس، دیتابیس را آفلاین کنید و مسیرهای فایل‌های داده و لاگ را مشخص کنید:

USE [master];
GO
ALTER DATABASE @DatabaseName SET OFFLINE WITH ROLLBACK IMMEDIATE;
GO

بعد، مسیرهای جدید را برای فایل‌های دیتابیس و لاگ تعیین کنید. برای یافتن logical_nameها و مسیرهای فعلی، می‌توانید از sys.master_files استفاده کنید.

-- Current paths and logical names (retrieve these from sys.master_files for your database)
-- SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID(@DatabaseName);

DECLARE @DataLogicalName AS SYSNAME = N'MyReplicatedDB'; -- نام منطقی فایل داده را جایگزین کنید
DECLARE @LogLogicalName AS SYSNAME = N'MyReplicatedDB_log'; -- نام منطقی فایل لاگ را جایگزین کنید

-- New paths for data and log files
DECLARE @NewDataPath AS NVARCHAR(MAX) = N'E:\NewSQLData\MyReplicatedDB.mdf';
DECLARE @NewLogPath AS NVARCHAR(MAX) = N'E:\NewSQLLogs\MyReplicatedDB_log.ldf';

ALTER DATABASE @DatabaseName MODIFY FILE (NAME = @DataLogicalName, FILENAME = @NewDataPath);
ALTER DATABASE @DatabaseName MODIFY FILE (NAME = @LogLogicalName, FILENAME = @NewLogPath);
GO

اکنون فایل‌های MyReplicatedDB.mdf و MyReplicatedDB_log.ldf را به صورت فیزیکی از مسیر قدیمی (مثلاً D:\SQLData\) به مسیر جدید (مثلاً E:\NewSQLData\) منتقل کنید.

در نهایت، دیتابیس را آنلاین کنید:

USE [master];
GO
ALTER DATABASE @DatabaseName SET ONLINE;
GO

پس از آنلاین شدن دیتابیس، SQL Server Agent را مجدداً راه‌اندازی کنید.

۴. پیکربندی مجدد Replication

این مهمترین بخش است، جایی که Replication را با مسیرهای جدید دیتابیس مجدداً برقرار می‌کنیم. این شامل بازسازی Publication و Subscriptionها است. برای این کار، شما نیاز دارید که تمام پارامترهای Publication، Articleها و Subscriptionهای اصلی را داشته باشید. توصیه می‌شود قبل از شروع، اسکریپت‌های موجود Replication را از طریق SSMS تولید کنید.

بازسازی Publication

ابتدا، اطلاعات مربوط به Publication قدیمی را استخراج کنید. ما نیاز به نام Publication و پارامترهای آن داریم. فرض کنید Publication شما ‘MyPublication’ نام دارد.

DECLARE @PublicationName AS SYSNAME = N'MyPublication';
DECLARE @ReplicationFrequency AS NVARCHAR(25) = N'continuous'; -- Or 'snapshot' for snapshot publications
DECLARE @RetentionDays AS INT = 14; -- Example retention period in days
DECLARE @AllowAnonymous AS BIT = 1;
DECLARE @EnabledForSQL AS BIT = 1;
DECLARE @SyncMethod AS NVARCHAR(20) = N'concurrent'; -- Options: 'concurrent', 'native', 'none', 'replication support only'
DECLARE @ReplicateDDL AS BIT = 1; -- 1 to replicate DDL changes, 0 otherwise
DECLARE @Description AS NVARCHAR(255) = N'Replication of MyReplicatedDB after move';

حالا، Publication را مجدداً ایجاد کنید. این دستور باید با پارامترهای دقیق Publication اصلی شما مطابقت داشته باشد:

USE [master];
GO
EXEC sp_addpublication
    @publication = @PublicationName,
    @replicate_ddl = @ReplicateDDL,
    @retention = @RetentionDays,
    @sync_method = @SyncMethod,
    @allow_anonymous = @AllowAnonymous,
    @enabled_for_sql = @EnabledForSQL,
    @repl_freq = @ReplicationFrequency,
    @description = @Description;
    -- Add any other specific parameters your original publication had here
GO

بازسازی Article ها

پس از ایجاد Publication، باید Articleها (جداول، Viewها، Stored Procedureها و … که در Replication قرار دارند) را مجدداً اضافه کنید. برای هر Article، باید از sp_addarticle استفاده کنید. این مثال برای یک جدول است:

DECLARE @ArticleName AS SYSNAME = N'MyTableArticle'; -- Name of the article
DECLARE @SourceOwner AS SYSNAME = N'dbo'; -- Schema owner of the source object
DECLARE @SourceObject AS SYSNAME = N'MyTable'; -- Name of the source object (e.g., table)
DECLARE @ArticleType AS NVARCHAR(20) = N'logbased'; -- e.g., 'logbased', 'view', 'proc schema and exec'
DECLARE @SchemaOption AS VARBINARY(8) = 0x000000000803509F; -- This is critical and specific to your article
DECLARE @DestinationTable AS SYSNAME = N'MyTable'; -- Destination table name on subscriber

USE [master];
GO
EXEC sp_addarticle
    @publication = @PublicationName,
    @article = @ArticleName,
    @source_owner = @SourceOwner,
    @source_object = @SourceObject,
    @type = @ArticleType,
    @schema_option = @SchemaOption,
    @destination_table = @DestinationTable;
    -- Add any other specific parameters your original article had here
GO

نکته مهم: مقدار @schema_option باید دقیقاً با مقدار اصلی Article شما مطابقت داشته باشد. این مقدار را می‌توانید از ستون schema_option در جدول MSarticles در دیتابیس distribution قبل از حذف Replication استخراج کنید.

بازسازی Subscription ها

در نهایت، Subscriptionهای مربوط به Publication را بازسازی کنید. برای هر Subscription، از sp_addsubscription استفاده کنید. این مثال برای یک Push Subscription است:

DECLARE @DestinationDB AS SYSNAME = N'MySubscriberDB'; -- Database name on the subscriber
DECLARE @SubscriptionType AS NVARCHAR(25) = N'Push'; -- 'Push' or 'Pull'
DECLARE @SyncType AS NVARCHAR(25) = N'automatic'; -- 'automatic' for initial snapshot, 'none' otherwise
DECLARE @Status AS NVARCHAR(25) = N'active'; -- 'active', 'inactive'
DECLARE @UpdateMode AS NVARCHAR(25) = N'read'; -- 'read', 'sync tran', 'queued tran'

USE [master];
GO
EXEC sp_addsubscription
    @publication = @PublicationName,
    @subscriber = @SubscriberName,
    @destination_db = @DestinationDB,
    @subscription_type = @SubscriptionType,
    @sync_type = @SyncType,
    @status = @Status,
    @update_mode = @UpdateMode;
    -- Add any other specific parameters your original subscription had here
GO

برای Snapshot Replication یا اگر پوشه snapshot شما جابجا شده است، ممکن است نیاز به به‌روزرسانی مسیر پوشه Snapshot نیز داشته باشید. این کار با sp_changepublication انجام می‌شود:

DECLARE @NewSnapshotFolder AS NVARCHAR(MAX) = N'E:\SQLSnapshots'; -- New path for the snapshot folder

USE [master];
GO
EXEC sp_changepublication
    @publication = @PublicationName,
    @property = N'snapshot_folder', -- Or 'alt_snapshot_folder' if using an alternate path
    @value = @NewSnapshotFolder;
GO

همچنین، ممکن است لازم باشد پوشه Snapshot را برای Articleها و Subscriber نیز تغییر دهید، اگر مسیرهای آنها نیز تغییر کرده باشد:

-- For a specific article if it uses an alternate snapshot folder
EXEC sp_changearticle
    @publication = @PublicationName,
    @article = @ArticleName,
    @property = N'alt_snapshot_folder',
    @value = @NewSnapshotFolder;
GO

-- For a specific subscriber if it uses an alternate snapshot folder
EXEC sp_changesubscriber
    @subscriber = @SubscriberName,
    @property = N'alt_snapshot_folder',
    @value = @NewSnapshotFolder;
GO

۵. راه‌اندازی و اعتبارسنجی Replication

پس از بازسازی تمام اجزای Replication، نیاز به راه‌اندازی مجدد Snapshot Agent و Log Reader Agent (برای Transactional Replication) و Distribution Agentها دارید. این عوامل باید Snapshot اولیه را تولید و توزیع کنند.

بررسی Replication Monitor در SQL Server Management Studio (SSMS) برای اطمینان از صحت عملکرد Replication و عدم وجود خطاها ضروری است. همچنین، می‌توانید با ایجاد تغییرات در Publisher و مشاهده بازتاب آن‌ها در Subscriber، صحت عملکرد را تأیید کنید.

نکات مهم و بهترین شیوه‌ها برای انتقال دیتابیس‌های SQL Server

• پشتیبان‌گیری کامل: همیشه قبل از شروع این فرآیند پیچیده، از تمام دیتابیس‌های مرتبط (Publisher, Distributor, Subscriber) پشتیبان‌گیری کامل (Full Backup) تهیه کنید. این یک قدم حیاتی برای بازیابی در صورت بروز مشکل است.
• مستندسازی دقیق: تمام تنظیمات فعلی Replication (مانند پارامترهای sp_addpublication، sp_addarticle، sp_addsubscription و تنظیمات Agentها) را قبل از حذف مستند کنید. این کار می‌تواند با استفاده از اسکریپت‌نویسی Replication از طریق SSMS انجام شود.
• زمان‌بندی مناسب: این عملیات را در یک پنجره نگهداری (Maintenance Window) با کمترین ترافیک سیستم و کاربران انجام دهید تا تاثیر آن بر عملکرد سیستم به حداقل برسد.
• تست در محیط غیرتولیدی: همیشه ابتدا این فرآیند را در یک محیط تست (Non-Production Environment) شبیه‌سازی و اعتبارسنجی کنید تا از عملکرد صحیح آن و عدم وجود عوارض جانبی اطمینان حاصل شود.
• بررسی مجوزها: اطمینان حاصل کنید که حساب‌های سرویس SQL Server و SQL Server Agent مجوزهای کافی برای دسترسی به مسیرهای فایل جدید (برای فایل‌های دیتابیس و پوشه‌های Snapshot) را دارند.

جمع‌بندی

انتقال دیتابیس‌های ریپلیکیت شده در SQL Server یک فرآیند چند مرحله‌ای است که نیاز به دقت، برنامه‌ریزی دقیق و درک عمیق از معماری Replication دارد. با پیروی از مراحل این راهنمای جامع، می‌توانید فایل‌های دیتابیس خود را جابجا کنید و Replication را با موفقیت مجدداً پیکربندی کنید. این رویکرد به شما کمک می‌کند تا از یکپارچگی داده‌ها و تداوم Replication پس از جابجایی اطمینان حاصل کنید. مستندسازی دقیق تنظیمات و تست کامل در محیط غیرتولیدی، کلید موفقیت در این عملیات حساس هستند.