Конфигуриране на доставка на регистрационни файлове на SQL Server

Тази статия обяснява стъпка по стъпка процеса на внедряване на доставката на SQL Server Log. Това е решението за аварийно възстановяване на ниво база данни, което е лесно за настройка и поддръжка.

Доставката на дневника включва три стъпки:

Генерирайте архива на регистрационния файл в основната база данни.
Копирайте архива в мрежовото местоположение или конкретната директория на вторичния сървър.
Възстановете архива на регистрационния файл на вторичния сървър.

Технологията за доставка на журнали изпълнява стъпките, описани по-горе, като използва задания на агент на SQL Server. По време на процеса на конфигуриране, съветникът за доставка на регистрационни файлове създава тези задания на първични и вторични сървъри.

Доставката на трупи може да бъде в два работни режима.

Режим за възстановяване . Заданието SQL възстановява резервните копия на регистрационния файл на транзакциите във вторичната база данни. Състоянието на базата данни е ВЪЗСТАНОВЯВА се , и не е достъпен.

Режим на готовност . Заданието SQL възстановява резервните копия на регистрационните файлове на транзакциите във вторичната база данни, но базата данни може да остане в режим само за четене. Следователно потребителите могат да извършват операции за четене върху него. С тази опция можем да разтоварим приложението за отчитане.

Забележка:Режимът на готовност има недостатък:базата данни не е налична по време на изпълнение на заданието за възстановяване. Всички потребители, свързани към базата данни, трябва да прекъснат връзката по време на този процес. В противен случай задачата за възстановяване може да се забави .

Основният недостатък на доставката на дневници е липсата на поддръжка за автоматично преминаване при отказ. За да извършите отказ, трябва да изпълните следните стъпки:

Генерирайте резервно копие на tail-log и го копирайте на вторичен сървър на база данни.
Спрете всички задачи за доставка на регистрационни файлове на основния сървър.
Възстановете регистрационния файл на вторичния сървър.

Този процес може да забави наличността на вторичната база данни.

Сега пристъпваме към стъпка по стъпка проверка на процеса на внедряване. На първо място, ние подготвихме работната станция, като я настроихме по следния начин:

Име на сървъра	Роля
SQL01	Основен сървър
SQL02	Вторичен сървър
iSCSI\SQL2017	Сървър за наблюдение
\\domain\Log Shipping Backups	Мрежово споделяне за копиране на резервните копия

Конфигуриране на основния сървър

SQL01 действа като първичен сървър и базата данни. Ще настроим доставката на регистрационни файлове между базата данни AdventureWorks2017.

За да конфигурирате доставката на регистрационни файлове, свържете се с SQL01 екземпляр:

Отворете SQL Server Management Studio
Разгъване на базата данни
Щракнете с десния бутон върху AdventureWorks2017
Задръжте курсора на мишката върху Задачи
Щракнете върху дневниците на транзакциите за доставка.

Свойства на базата данни диалогов прозорец се отваря.

За да активирате доставката на дневници, щракнете върху Активиране на това като основна база данни в конфигурация за доставка на дневници опция.

За да конфигурирате графика за архивиране на регистрационни файлове за транзакции за доставка на регистрационни файлове, щракнете върху Настройки за архивиране .

Отваря се диалогов прозорец „Настройки за архивиране на журнала на транзакциите“.

В диалоговия прозорец посочете мрежовия дял, където искате да копирате резервните копия на регистрационния файл на транзакциите – Мрежовият път до папката за архивиране текстово поле. Можете да определите периода на запазване на резервното копие в Изтриване на файлове, по-стари от посочено в текстовото поле. Ако заданието за архивиране не успее или архивният файл не се появи за времето, посочено в текстовото поле, SQL Server подава сигнал.

При доставката на регистрационни файлове SQL Server копира резервните копия на регистрационните файлове в споделената мрежа. Помощникът автоматично създава задание за архивиране по време на процеса на внедряване. Той също прави график автоматично, но можете да го промените, като щракнете върху бутона График.

В моя случай промених името на заданието за архивиране, за да го идентифицирам. Името на заданието е LogShipping_Backup_AdventureWorks2017 .

Не направих никакви промени в графика на заданията и настройките за компресиране на архивиране.

Конфигуриране на вторичния сървър

За да добавите вторичния сървър и база данни, щракнете върху „Добавяне“ в Свойства на базата данни диалогов прозорец.

Диалогов прозорец с име Настройки на вторична база данни ще отвори. Трябва да се свържем с вторичния сървър на база данни. За да направите това, щракнете върху „Добавяне“.

Отваря се диалогов прозорец. Въведете името на сървъра и щракнете върху Свързване :

Конфигурация на вторични настройки на базата данни

Инициализирайте вторична база данни

В раздела за инициализиране на вторична база данни можете да настроите някоя от следните три опции за възстановяване на базата данни:

Ако базата данни не съществува на вторичния сървър, можете да генерирате пълно архивиране и да го възстановите на вторичния сървър. В този сценарий можете да използвате първата опция.
Ако има пълно архивиране на базата данни, генерирано от други задачи за архивиране, или вече имате такова, можете да го възстановите на вторичния сървър. В този сценарий можете да изберете втората опция.
Ако сте възстановили вторичната база данни със състояние NORECOVERY, можете да изберете третата опция.

Копиране на файлове

В Копиране на файлове раздел, можете да посочите дестинационната директория за местоположението на копираните архивни файлове. Там е дефиниран и срокът на съхранение.

Помощникът създава SQL задание за копиране на файлове в целевата директория. Папката местоназначение за архивиране е \\domain\Log Shipping Backups. Името на заданието за копиране е LogShipping_Copy_SQL01_AdventureWorks2017 .

Възстановяване на регистрационния файл на транзакциите

В Регистъра на транзакциите за възстановяване раздел, можете да посочите режима на база данни. Ако искате да запазите базата данни в режим само за четене, изберете Режим на готовност или изберете Без режим на възстановяване .

В тази демонстрация запазваме състоянието на базата данни като NORECOVERY. Можете да зададете забавяне на възстановяването на архива и да конфигурирате сигнали за архиви, които не са възстановени в рамките на определен интервал. В нашия случай не използваме настройки по подразбиране.

Името на заданието за възстановяване е LogShipping_Restore_SQL01_AdventureWorks2017.

След като конфигурацията е готова, щракнете върху OK, за да запазите промените.

Както виждате, вторичният сървър и базата данни са добавени в „Решетка на екземпляри на вторичен сървър и бази данни ” в Свойства на базата данни екран.

Конфигуриране на екземпляр за наблюдение

Ако искате да конфигурирате екземпляр на монитор на сървъра, поставете отметка за Използване на екземпляр на сървър за монитор . За да добавите екземпляра на монитора, щракнете върху Настройки .

Ще използваме екземпляр iscsi\SQL2017 като сървър за наблюдение на доставката на журнали.

В Настройка за наблюдение на доставката на журнал диалогов прозорец, посочете името в Монитор на сървърния екземпляр текстово поле.

Използваме sa акаунт, за да наблюдавате доставката на дневника. Следователно трябва да предоставите sa като потребителско име и парола. Можете също да посочите периода на запазване на сигналите за наблюдение и хронологията.

Тук използваме настройките по подразбиране. Името на заданието за предупреждение е LogShipping_Alert_iscsi\sql2017 .

Щракнете върху OK, за да запазите конфигурацията и да затворите диалоговия прозорец.

Можете да генерирате T-SQL скрипт за цялата конфигурация, като щракнете върху Конфигурация на скрипт бутон. Копирайте конфигурационния скрипт в клипборда или файла или го отворете в нов прозорец на редактора на заявки.

Не искаме да скриптираме действието. Можете да игнорирате тази стъпка.

Щракнете върху OK, за да запазите конфигурацията за доставка на регистрационни файлове и процесът ще започне:

След като доставката на регистрационни файлове е конфигурирана, можете да видите диалоговия прозорец за успех:

Тестване на сценарий при отказ

USE [AdventureWorks2017]
GO
CREATE TABLE [Person](
	[BusinessEntityID] [int] NOT NULL,
	[PersonType] [nchar](2) NOT NULL,
	[NameStyle] [dbo].[NameStyle] NOT NULL,
	[Title] [nvarchar](8) NULL,
	[FirstName] [dbo].[Name] NOT NULL,
	[MiddleName] [dbo].[Name] NULL,
	[LastName] [dbo].[Name] NOT NULL,
	[Suffix] [nvarchar](10) NULL,
	[EmailPromotion] [int] NOT NULL,
	[ModifiedDate] [datetime] NOT NULL,
 CONSTRAINT [PK_Person_BusinessEntityID] PRIMARY KEY CLUSTERED 
(
	[BusinessEntityID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

Изпълнете следната заявка, за да вмъкнете демонстрационни данни:

insert into [Person]([BusinessEntityID],[PersonType],[NameStyle],[Title],[FirstName] ,[MiddleName],[LastName] ,[Suffix] ,[EmailPromotion],[ModifiedDate]) 
select top 10 [BusinessEntityID],[PersonType],[NameStyle],[Title],[FirstName] ,[MiddleName],[LastName] ,[Suffix] ,[EmailPromotion],[ModifiedDate] 
from Person.Person

За да извършите отказ, направете резервно копие на tail-log на базата данни adventureworks2017. Изпълнете следната заявка:

Backup Log adventureworks2017 to disk='\\domain\LogShippingBackups\Tail_Log_Backup.trn' with norecovery

Свържете се към SQL02 (вторичен сървър) и възстановете резервното копие на опашния регистър, като използвате ВЪЗСТАНОВЯВАНЕ С ВЪЗСТАНОВЯВАНЕ. Изпълнете следния код:

RESTORE LOG [AdventureWorks2017] FROM  DISK = N'\\domain\LogShippingBackups\Tail_Log_Backup.trn' WITH  RECOVERY

След като архивирането на tail-log се възстанови успешно, изпълнете заявката, за да проверите дали данните са копирани на вторичния сървър:

Select * from person

Изход на заявка:

Както виждате, данните се възстановяват на вторичния сървър.

Заключение

В тази статия сме обяснили процеса на доставка на регистрационни файлове на SQL Server и как да го конфигурирате. Ние също така демонстрирахме стъпка по стъпка процеса на преодоляване при отказ на доставката на регистрационните файлове.