Глава 7. Моментальные снимки Сервера баз данных SQL

Microsoft остаётся верен своему утверждению предоставления основного механизма базы данных, который может быть высоко доступным 7 дней в неделю, 365 дней в году. Моментальные снимки вносят свой вклад в эту цель рядом способов:

Моментальный снимок базы данных это просто представление полной базы данных на определённый момент времени. Это не какая- то копия - по крайней мере, не некая полная копия при его первичном создании. (Я обсужу это дополнительно в некий момент времени.) Рисунок 7.1 отображает концепцию того, как некоторый моментальный снимок может быть создан из какой- то первоначальной базы данных в одном из экземпляров сервера SQL.

Такое представление определённого момента времени данных базы данных никогда не изменяется, даже не смотря на то, что сами данные (страницы данных) в имеющейся первичной базе данных (самом источнике этого моментального снимка базы данных) могут изменяться. Это реальный моментальный снимок в некий момент времени. Для некоторого моментального снимка всегда просто указать на страницы данных, которые присутствовали на тот момент времени, когда был создан данный моментальный снимок. Если в данной базе данных источнике обновляются некоторые данные, некая копия имевшейся первоначально страницы перемещается в новую цепочку страниц, имеющую название неполного файла (sparse file - разряженного файла) с применением технологии копирования-записью (copy-on-write). Рисунок 7.2 показывает необходимый неполный файл, который создаётся совместно с самой базой данных источником.

Некий моментальный снимок базы данных в действительности использует страницы данных самой базы данных, вплоть до того момента, пока эти страницы данных не обновятся (то есть, не изменятся любым образом). Как уже упоминалось ранее, если некая страница данных обновляется в самой исходной базе данных, первоначальная копия этой страницы данных (на которую ссылается имеющийся моментальный снимок базы данных) записывается в созданный цепочку страниц неполного файла который всё ещё продолжает предоставлять верные данные момента времени для определённого моментального снимка базы данных, который он обслуживает. Рисунок 7.3 иллюстрирует, что чем больше изменений данных (обновлений) происходит в самой базе данных источника, тем данный неполный файл становится всё больше и больше заполняясь старыми первоначальными страницами данных.

Со временем Неполный файл может содержать всю первоначальную базу данных, если все страницы данных в этой первичной базе данных были изменены. Как вы можете видеть из Рисунка 7.3, то какие страницы данных определённого моментального снимка базы данных применяются из оригинальной (исходной) базы данных, а какие страницы он использует из имеющегося неполного файла управляется ссылками в имеющемся системном каталоге для данного моментального снимка базы данных. Такая установка чрезвычайно эффективна и представляет основной прорыв в предоставлении данных всем прочим. Из- за применения технологии копирования-записью (copy-on-write) в процессе записи применяется определённая дополнительная нагрузка. Это один из самых критически важных факторов, который вам необходимо рассматривать при планировании применения моментальных снимков базы данных. Ничто не даётся бесплатно. Требуемые накладные расходы содержат копирование первоначальной страницы данных, запись этих скопированных данных в разряженный файл и последующее обновление метаданных в системном каталоге который управляет списком всех страниц данных моментального снимка базы данных. Благодаря такому совместному использованию страниц данных также должно быть ясно почему моментальные снимки базы данных должны находиться внутри того же самого экземпляра некоторого сервера SQL: И сама база данных источника, и моментальный снимок начинают с с одними и теми же страницами страницами данных и впоследствии расходятся по мере того, как страницы данных источника обновляются. Кроме того, когда создаётся некий моментальный снимок базы данных, сервер SQL откатывает назад все незавершённые транзакции для данного моментального снимка базы данных, только все зафиксированные транзакции являются частью вновь создаваемого снимка базы данных. И, как вы и можете ожидать от чего- то что совместно использует страницы данных, моментальные снимки базы данных становятся недоступными если сама исходная база данных становится недоступной (например, если она разрушена или отключена).

Конечно, имеются альтернативы для моментальных снимков базы данных, такие как репликация данных, отправка журнала и даже материализованные представления, но ничем не возможно настолько просто управлять и ничто нелььзя так просто применять как моментальные снимки базы данных.

С моментальными снимками базы данных обычно связаны следующие понятия:

Как иллюстрирует Рисунок 7.4, все применяющие моментальные снимки запросы данных просматривают и страницы данных самой исходной базы данных, и страницы данных его неполного файла в одно и то же время. Эти страницы данных всегда отражают все неизменные страницы данных того момента времени, когда был создан данный моментальный снимок.

Технология копирования-записью (copy-on-write), которую Microsoft впервые внедрил в сервере SQL 2005, является сердцевиной и возможностей зеркалирования базы данных, и моментального снимка базы данных. Данный раздел рассмотрит некое обычное транзакционное обновление пользователя данных в какой- то исходной базе данных.

Как вы можете увидеть из Рисунка 7.5, некая транзакция обновления инициируется для имеющейся базы данных AventureWorks (помеченный как A). После того как эти данные обновлены в странице даных имеющейся исходной базы данных и эти изменения записаны в её журнал транзакций (помечено как B), наша технология копирования-записью также копирует эту первоначальную страницу данных исходной базы данных в её неизменном состоянии в установленный неполный файл (также помеченный как B) и обновляет соответствующие ссылки страницы метаданных в данном системном каталоге (также помеченном как B) при данном перемещении.

Такая первоначальная страница данных всё ещё доступна для этого моментального снимка данных. Это вносит некоторые накладные расходы для любой исполняемой транзакции с изменениями, вставками или удалениями данных в такой исходной базе данных. После того как обозначенная технология копирования-записью завершит свои записи в текущий неполный файл, сама первоначальная транзакция обновления надлежащим образом фиксируется и выполнявшему данную транзакцию пользователю отправляется обратно уведомление подтверждения. (помечено как C).

Как уже упоминалось ранее, имеется ряд вариантов эффективного применения вами моментальных снимков. Каждый из них применяется с определённой целью, и каждый имеет определённые преимущества. После того как вы разложили по полочкам все упомянутые выше пределы и ограничения, вы можете рассмотреть эти способы применения. Давайте рассмотрим каждый из них в отдельности.

Рисунок 7.6

Чтобы вернуться к некоторому определённому интервалу моментального снимка, вы просто применяете команду RESTORE DATABASE со своим предложением FROM DATABASE_SNAPSHOT. Это является неким полным восстановлением базы данных; вы не можете ограничить его просто каким- то отдельным объектом базы данных. Кроме того, вы обязаны сбрость все прочие моментальные снимки базы данных, прежде чем вы сможете применить один из них для восстановления некоторой базы данных.

Как вы можете увидеть на Рисунке 7.6, если вы знаете в точности что вы желаете восстановить на уровнях имеющихся таблиц и строк, могут быть применены очень определённые предложения SQL, ссылающиеся на некоторый моментальный снимок. Вы можете просто применять предложения SQL (такие как предложение update - помеченное как A - или некоторое предложение insert) из одного из имеющихся снимков для выборочного применения только тех исправлений, которые, как вы уверены, необходимо восстановить (выполнить возврат). Другими словами, вы не восстанавливаете всю базу данных из имеющегося моментального снимка; вы применяете только некоторые из определённых данных с предложениями SQL и привносите в строки испорченных данных назад в соответствие с первоначальными значениями в данном моментальном снимке. Это происходит на уровне определённых строк и колонок и обычно требует немалого подробного анализа прежде чем оно может быть применено в промышленной базе данных.

Также имеется возможность применения некоторого моментального снимка для восстановления какой- то таблицы, которую кто- то внезапно сбросил. Существует некоторая небольшая потеря данных с момента выполнения последнего снимка, а он влечёт некое простое предложение insert into из самого последнего моментального снимка перед сбросом этой таблицы. Будьте внимательны при этом, просто также рассмострите само значение.

Вероятно, вы планируете для своей базы данных регулярные события, которые в результате приводят к некоторому виду массовых изменений, применяемых к большим порциям вашей базы данных. Если вы выполняете быстрый моментальный снимок базы данных перед таким типом изменений, вы на самом деле создаёте неплохую страховку для быстрого восстановления на случай, если вы не будете удовлетворены полученными результатами массового обновления. Рисунок 7.7 иллюстрирует данный тип техники безопасности.

Если вы не удовлетворены такой операцией полного обновления, вы можете применить RESTORE DATABASE из имеющегося снимка и вернуться к данному моменту. Либо, если вы удовлетворены некоторыми обновлениями, а некоторыми нет, вы можете воспользоваться предложением UPDATE для выборочного обновления (восстановления) определённых значений к их первоначальным значениям с помощью данного моментального снимка.

При тестировании и фазах QA вашего жизненного цикла разработки вам зачастую приходится проводить тестирование вновь и вновь. Это могут быть либо проверки лигики, либо тестирование производительности. Для целей тестирования и QA вы можете выполнять моментальные снимки некоторой тестируемой базы данных перед полным тестированием (для создания моментального снимка базового уровня базы данных), а затем вы можете возвращаться обратно к её первоначальному состоянию отмеченного момента с применением такого моментального снимка базового уровня. Рисунок 7.8 демонстрирует как просто это для бесхитростного создания некоторой ссылочной тестовой точки (или точки синхронизации) с помощью моментальных снимков базы данных.

Затем вы просто выполняете свои сценарии проверок или делаете некоторое тестирование вручную - столько сколько пожелаете - и затем быстро возвращаетесь к стартовой точке. После чего вы выполняете последующие проверки.

Если вам действительно требуется истинная отчётная база данных момента времени из которой вы можете выполнять отчёты для данного случая или повторяющиеся отчёты, зачастую эту цель некий моментальный снимок базы данных может обслуживать лучше чем доставка журнала или репликация данных. Ключом для определения того, когда вы можете применять такую технику моментального снимка базы данных яляется то, сможет ли нагрузка составления отчёта данного экземпляра сервера базы данных легко поддерживать такую рабочую нагрузку составления отчёта и будут ли воздействовать данные транзакции обновления обрабатываемой базы данных оказывать неблагприятное воздействие накладными расходами необходимых снимков базы данных для каждой транзакции. Рисунок 7.9 отображает самую обычную конфигурацию моментального снимка базы данных для подлежащих применению одного или более моментальных снимков базы данных.

Помните, что это снимок момента времени имеющейся исходной базы данных. Насколько часто вам потребуется создавать некий новый снимок это диктуется вашими требованиями составления отчётов для латентности данных (то есть, насколько древними эти данные могут быть в получаемых отчётах).

Если для улучшения своей доступности вы применяете зеркалирование базы данных, вы также можете создать некий моментальный снимок базы данных для такой зеркальной базы данных и выставлять такой снимок своим пользователям составления отчётов. Даже не смотря на то, что конкретная зеркальная база данных не может применяться ни для какого доступа вообще (она пребывает в постоянном состоянии обновления), сервер SQL допускает создавать для неё некий моментальный снимок (как это показано на Рисунке 7.10). Это очень мощная конфигурация в том, что некий моментальный снимок какого- то зеркала не оказывает воздействия на имеющуюся нагрузку самого основного сервера - что обеспечивает высокую производительность для самого основного сервера. Кроме того, когда полученный снимок базы данных изолирован на стороне своего сервера зеркала, получаемая производительность для тех пользователей, которые составляют отчёт, также более предсказуема, поскольку они не конкурируют с пользователями транзакций в отношении ресурсов своего основного сервера. (Я поясню зеркало базы данных позже в данной главе.) Единственная действительная проблема возникает только когда имеющейся основной сервер отрабатывает отказ на свою зеркальную базу данных. Тагда вы имеете и и пользователей транзакций, и пользователей отчётов, которые применяют один и тот же экземпляр сервера базы данных, и их производительность оказывает влияние друг на друга.

Возможны м решением данной ситуации было бы автоматический (или выполненный вручную) сброс имеющегося моментального снимка базы данных на таком сервере зеркала в случае когда он становится основным и создание некоторого нового моментального снимка на самом старом основном сервере, если он доступен (теперь он является зеркалом). Затем вы кажете всем пользователям отчётов на этот новый снимок базы данных. Данная задача достаточно просто может быть выполнена некотором прикладном уровне сервера. Данное решение в основном обратно подходу конфигурации составления отчётов основной/ зеркальный, который всегда пытается получить тот применяемый для отчётов моментальный снимок базы данных, который находится на сервере, являющемся зеркалом. Действительно, вы никогда не хотите иметь активные моментальные снимки базы данных и на основном сервере, и на сервере зеркала в одно и то же время. Это бы создало очень много накладных расходов для обоих серверов. Вы хотите только те моментальные снимки, которые находятся на сервере зеркала. (Я обсужу слегка больше зеркалирование базы данных позже в данной главе.)

На практике вы можете быть удивлены обнаружив насколько просто вы можете установить некий моментальный снимок базы данных. Данная простота частично объясняется тем уровнем, на котором создаются моментальные снимки базы данных: на уровне самой базы данных, а не на уровне её таблиц. Установка некоторого моментального снимка базы данных всего лишь влечёт за собой исполнение какого- то CREATE DATABASE с определённым предложением AS SNAPSHOT OF. По этой причине вы не можете создавать моментальные снимки базы данных из SQL Server Management Studio или любого другого GUI или мастера. Всё должно выполняться с применением сценариев SQL. Все сценарии SQL для данной главы доступны для выгрузки вами с вебсайта компаньона данной книги (www.informit.com/9780672337765). В дальнейшем все примеры применяют пример базы данных Microsoft AdventureWorks (преобразованный под сервер SQL 2016). Определённый файл сценария, с названием DBSnapshotSQL2016.sql также содержит некоторую подборку прочих полезных предложений SQL чтобы помочь вам лучше управлять некоторой средой моментальных снимков базы данных.

Одна из самых первых вещей, которую вы должны определить перед созданием некоторого моментального снимка базы данных является тот факт, будет ли порция данных вашей исходной базы данных иметь более одного файла в своём расположении. На все такие ссылки файлов должны быть заведены учётные записи в определённом моментальном снимке. Вы исполняете системную сохранённую процедуру sp_helpdb с названием своей исходной базы данных в качестве её параметра, как это показано здесь:

EXEC SP_HELPDB AdventureWorks
Go
 	   

Детализация местоположения файлов этой базы данных таково:

Name                 FileID File Name
AdventureWorks_Data  1      C:\Server\MSSQL13.SQL1016DXD01\DATA\AdventureWorks_Data.mdf
AdventureWorks_Log   2      C:\Server\MSSQL13.SQL2016DXD01\MSSQL\DATA\AdventureWorks_Log.ldf
		

Вам следует позаботиться только о той части данных самой базы данных, которые предназначены для нужного вам моментального снимка:

CREATE DATABASE SNAP_AdventureWorks_6AM
ON
 ( NAME = AdventureWorks_Data,
   FILENAME= 'C:\Server\ MSSQL13.SQL2016DXD01\MSSQL\DATA\SNAP_AW_data_6AM.snap')
AS SNAPSHOT OF AdventureWorks
go
 	   

Создание необходимого моментального снимка базы данных на самом деле настолько просто. Теперь давайте пройдём простой пример, который покажет как создать последовательности из четырёх моментальных снимков базы данных для вашей исходной базы данных AdventureWorks, которые представляют моментальные снимки через шесть часов (как это отображено на Рисунке 7.6). Вот снимок который выполняется в 12 по полудню:

CREATE DATABASE SNAP_AdventureWorks_12PM
ON
( NAME = AdventureWorks_Data,
FILENAME= 'C:\Server\ MSSQL13.SQL2016DXD01\MSSQL\DATA\SNAP_AW_data_12PM.snap')
AS SNAPSHOT OF AdventureWorks
go
 	   

Данные снимки выполняются через равные промежутки времени и могут применяться для составления отчётов или выполнения возвратов.

Данный пример использует базу данных AdventureWorks. В настоящее время AdventureWorks применяет только единственный файл данных, размещённый для его порции данных. Вот как вы создаёте свой первый снимок, отражающий моментальный снимок на 6 часов утра:

Вы видите как это выглядит, открыв SQLServer Management Studio. Рисунок 7.11 отображает полученный моментальный снимок базы данных SNAP_AdventureWorks_6AM совместно со своей исходной базой данных AdventureWorks. Он также показывает определённые результаты выполненных системных запросов к свойствам объектов этой базы данных.

Теперь вы в деле со своим моментальным снимком базы данных!

Если вы желаете избавиться от некоторого снимка или перекрыть некий текущий снимок более новым моментальным снимком, вы просто применяете команду DROP DATABASE и после этого создаёте его вновь. Ваша команда DROP DATABASE немедленно удаляет все записи данного моментального снимка базы данных и все выделенные неполные файлы, связанные с данным моментальным снимком. Это очень просто, на самом деле. Следующий пример сбрасывает только что созданный моментальный снимок:

Use [master]
go
DROP DATABASE SNAP_AdventureWorks_6AM
go
 	   

Если вы пожелаете, вы таже можете сбросить (удалить) некий снимок базы данных из Студии управления сервером SQL кликнув правой кнопкой по соответствующей записи моментального снимка базы данных и выбрав опцию Удаления (Delete). Однако лучше выполнять всё с помощью сценариев с тем, чтобы вы могли в точности повторять то же самое действие снова и снова.

Если у вас имеется некий моментальный снимок базы данных, определённый для какой- то исходной базы данных, вы можете применять этот снимок для возврата (revert) к данному километровому столбу момента-времени моментального снимка. Другими словами, вы осознанно перекроете некую исходную базу данных этим представлением своей базы данных на некоторый момент времени (которое вы получили когда создали некий моментальный снимок). Вам следует помнить, что вы утратите все изменения данных которые произошли после этого момента времени и текущее состояние своей исходной базы данных. Однако это может быть в точности тем что вам требуется.

Возврат (reverting) это всего лишь логический термин, применяемый для команды DATABASE RESTORE в вашем предложении FROM DATABASE_SNAPSHOT. На самом деле он вызывает то, что имеющийся снимок базы данных на определённый момент времени становится самой исходной базой данных. Под имеющимися покровами, по большей части большинство из них управляется на уровне метаданных системного каталога. Однако, результат состоит в том, что данная исходная база данных будет в точности в том же состоянии, что и применяемый моментальный снимок базы данных. Когда вы применяете некий моментальный снимок базы данных в качестве основы восстановления какой- то базы данных, перед этим все прочие моментальные снимки базы данных, которые имеют в качестве исходной ту же самую базу данных, должны быть сброшены. Опять же, чтобы посмотреть какие моментальные снимки базы данных могут быть определены для некоторой конкретной базы данных, вы можете исполнить следующий запрос:

Use [master]
go
SELECT name
     , database_id
     , source_database_id — исходная DB данного моментального снимка
     , create_date
     , snapshot_isolation_state_desc
  FROM sys.databases
Go
 	   

Данный запрос отобразит все имеющиеся исходные базы данных и вновь созданные моментальные снимки базы данных следующим образом:

name            database_id source_database_id   create_date   snapshot_isolation_state_desc
----------------------------------------------------------------------------------
AdventureWorks            5       NULL           2016-02-17 23:37:02.763    OFF
SNAP_AdventureWorks_6AM   9         5            2016-12-05 06:00:36.597     ON
SNAP_AdventureWorks_12PM 10         5            2016-12-05 12:00:36.227     ON
		

В данном примере присутствуют два снимка для базы данных AdventureWorks. Для начала, должен быть сброшен тот, который вы не желаете применять после выполнения возврата. Затем вы можете выполнить восстановление с оставшимся снимком, которое вам требуется. Вот эти шаги:

Когда этот процесс осуществится, ваша исходная база данных и моментальный снимок в конечном итоге являются базой данных одного и того же момента времени. Однако помните, что сама исходная база данных начнёт быстро отклоняться по мере того как начнут поступать вновь обновления.

Возврат к некоторой "золотой" копии некоторой базы данных через некий моментальный снимок базы данных несомненно должен быть популярным благодаря своей простоте создания и возврата. Группы тестирования и QA будут благоденствовать благодаря этому свойству и это будет непосредственно воздействовать на саму скорость проверок в некоторой организации. С помощью увеличения имеющейся частоты и стабильности ваших сред проверок и QA должно быть достигнуто непосредственное улучшение качества вашего приложения.

Вот эти шаги:

По умолчанию вы получаете те роли и определения безопасности, которые вы создали для самой исходной базы данных, доступными для вас в рамках данного моментального снимка базы данных кроме ролей или персональных полномочий, которые вы имеете в своей исходной базе данных, применяемых для обновления данных или объектов. Это именуется как "наследование из своей исходной базы данных". Такие права обновления не доступны вам в некотором моментальном снимке базы данных. Некий моментальный снимок базы данных является какой- то базой данных, доступной только для чтения! Если у вас имеются определённые роли или ограничения, которые вы желаете иметь представленными в таком моментальном снимке базы данных, вам потребуется определить их в вашей исходной базе данных и вы немедленно получите их. Вы управляете из некоторого единого места и все довольны.

Размер неполного файла, вероятно, является наиболее критически важной стороной, с которой приходится иметь дело при управлении моментальными снимками базы данных. Крайне важно, чтобы вы внимательно отслеживали растущий размер любого (или всех) создаваемых вами неполных файлов моментальных снимков базы данных. Если моментальный снимок исчерпывает доступное пространство из- за того что вы недостаточно хорошо управляете размером файла, он становится сомнительным и не доступным для применения. Единственным выходом из этого сценария является сброс данного снимка и повторное его создание. Далее приводятся некоторые подлежащие рассмотрению проблемы для неполных файлов:

Обычно вам не следует иметь слишком много снимков базы данных, определённых на на некоторой базе данных, поскольку необходимы накладные расходы операций копирования-записью для каждого моментального снимка. Однако это определяется изменчивостью вашей исходной базы данных и ёмкостью сервера. Если имеется небольшая изменчивость и ваш сервер не занимает много ЦПУ, памяти и дискового пространства, такая база данных может быть более готовой для поддержки большего числа моментальных снимков одновременно. Если имеющаяся изменчивость высока, а ЦПУ, память и, возможно, ёмкость дисков близки к насыщению, вам следует решительно минимизировать общее число моментальных снимков базы данных.

Даже хотя зеркалирование и было великолепным добавлением в сервере SQL на протяжении многих лет, оно будет отклоняться в будущих версиях сервера SQL после сервера SQL 2016. Стоит отметить, что все ключевые компоненты технологии, которые составляют зеркалирование базы данных были применены в в возможностях групп доступности AlwaysOn. Между тем, применение зеркалирования базы данных всё ещё некий доступный первый шаг при достижении как высокой доступности, так и распределённых рабочих нагрузок и будет оставаться таковым, по крайней мере, на протяжении некоторого последующего числа лет. Кое- что, что также следует иметь в уме, так это то, что зеркалироваие базы данных имеет весьма небольшое число ограничений настроек, в то время как группы доступности AlwaysOn требуют минимальных уровней версий ОС и сервера SQL. Это означает, что даже самые небольшие компании имеют некий шанс получения отработки отказа базы данных в близком к реальному режиме времени без причудливого, затратного оборудования, необходимого при более сложных конфигурациях. С помощью зеркалирования базы данных вы можете установить некую среду восстановления после сбоев базы данных в близком к реальному времени режиме применяя общедоступные машины с небольшой стоимостью без каких бы то ни было требований совместимости оборудования, причём зеркалирование базы данных способно выполнять восстановление менее чем за 3 секунды! Зеркалирвоание базы данных на самом деле допускает кому бы то ни было непосредственно приблизиться примерно к 99.9% (трём девяткам) доступности на самом уровне базы данных при очень низкой стоимости и к тому же просто настраивается и управляется.

Когда вы зеркалируете некую базу данных, вы на самом деле запрашиваете какую- то полную копию одной из баз данных, которая должна быть создана и сопровождаться, причём с самым последним наполнением, которое только возможно; вы запрашиваете некий зеркальный образ. Зеркалирование базы данных является неким свойством уровня базы данных. Это означает, что отсутствует поддержка фильтрации, подмножеств и любых видов разделения на части. Вы зеркально отражаете некую полую базу данных или совсем ничего. Такое ограничение на самом деле сохраняет зеркалирование базы данных простым и ясным для реализации. Несомненно, это также порождает некоторые нежелательные последствия, такие как пожирание намного большего дискового пространства, но то что вы получаете взамен, хорошо соответствует этой стоимости хранилища.

Зеркалирование базы данных работает с применением имеющегося журнала транзакций в вашей основной базе данных (а именно, той базы данных, для которой вы создаёте зеркало). Вы можете выполнять зеркалирование только некоторой базы данных, которая применяет установленную модель полного восстановления базы данных. В противном случае не будет иметься возможности переправлять записи журнала транзакций на другой сервер. Применяя технологию копирования-записью, некое изменение данных в базе данных первичного сервера (которое отражается в активных записях журнала транзакций) сначала "копируется" на свой целевой сервер, а затем "записывается" (то есть применяется или восстанавливается) в журнале транзакций этого целевого сервера базы данных (то есть сервере зеркала). Именно поэтому такое действие именуются копированием- записью (copy- on- write). Зеркалирование базы данных сильно отличается от репликации данных. При реплицировании изменения базы данных осуществляются на определённом логическом уровне (предложения INSERT, UPDATE и DELETE; исполнение сохранённых процедур и тому подобное), в то время как зеркалирование базы данных применяет действительные записи журнала транзакций как на стороне самого первичного сервера базы данных, так и на стороне сервера такого зеркала базы данных. В действительности сами физические "активные" записи журнала из имеющегося журнала транзакций вашей первичной базы данных копируются и записываются непосредственно в журнал транзакций вашей базы данных зеркала. Такие транзакции уровня записи физического журнала могут применяться чрезвычайно быстро. Так как эти записи физического журнала применяются к вашей базе данных зеркала, даже сам кэш данных отражает прямое применение этих записей журнала. Это делает всю такую базу данных и кэш данных готовыми для чрезвычайно быстрого взятия на себя роли первичной. Рисунок 7.12 отображает некую типичную конфигурацию зеркалированной базы данных, которая имеет три составляющих:

Как уже упоминалось ранее в данной главе, зеркалирование базы данных поднимает имеющийся уровень доступности приложения на основе сервера SQL на очень высокий уровень без какого- либо специализированного оборудования и дополнительных навыков персонала администрирования. Однако то, когда вам следует применять зеркалирование базы данных разнится в зависимости от ваших истинных потребностей.

В основном, если вам требуется увеличить имеющуюся доступность самого уровня базы данных, иметь автоматическую защищённость данных (то есть избыточное хранение данных), либо снижение времени простоя, которое бы бы обычно требовалось для выполнения обновлений, вы можете применять зеркалирование базы данных. Ещё более популярный сценарий зеркалирования баз данных состоит в том, что вам необходимо отгрузить составление отчётов, что легко удовлетворяется периодическими моментальными снимками базы данных. Такое применение предоставляет громадное облегчение сильно загруженным серверам транзакций, которые также могут применяться для составления отчётов.

Как вы уже видели, некая обычная конфигурация зеркалирования базы данных имеет какой- то основной сервер, сервер зеркала и сервер свидетельства. Каждый из этих серверов играет свою роль в определённый момент. Ваши основной сервер и сервер зеркала переключают роли, поэтому важно понимать, чем являются эти роли и когда некий сервер играет определённую роль.

Некая роль соответствует тому что какой- то сервер делает в определённый момент времени. Имеются три возможные роли:

При базе данных с зеркалом у вас имеется вариант развёртывания одного из трёх режимов: высокой надёжности с методикой автоматического восстановления (высокая доступность с неким свидетельским сервером), высокая надёжность без автоматического режима восстановления (высокая защищённость без какого бы то ни было свидетельского сервера), а также режим высокой производительности. Каждый режим имеет отличительные характеристики отработки отказа и защищённости и применяет имеющиеся конфигурации зеркалированной базы данных с небольшими различиями. Как вы и могли ожидать, режим высокой производительности предлагает наименьший объём защиты; вы должны пожертвовать уровнями защиты ради производительности.

Зеркалирование базы данных исполняется либо с синхронными, либо с асинхронными операциями:

То, являются операции синхронными или асинхронными, зависит от самих установок безопасности транзакций. Вы управляете этой настройкой через опцию SAFETY при настройке команд Transact-SQL (T-SQL). Значением по умолчанию является установка SAFETY в значение FULL (которая предоставляет синхронные операции). Для асинхронной работы вы устанавливаете её в значение OFF. Если вы применяете свой мастер зеркалирования базы данных (Database Mirroring Wizard), данная опция устанавливается для вас автоматически.

Из всех этих трёх режимов только высокая безопасность с методикой автоматического восстановления (режим высокой доступности) требует наличие свидетельского сервера. Все прочие прекрасно могут функционировать без такого третьего сервера в своей конфигурации. Помните, что имеющийся свидетельский сервер отслеживает и основной сервер и сервер зеркала и будет применён (в некотором кворуме) для автоматического восстановления после отказа.

Переключение ролей является тем действием, которое переносит роль ведущего сервер на имеющийся сервер зеркала. Именно сервер зеркала действует как партнёр для восстановления необходимого основного сервера. При возникновении некоторого отказа, имеющаяся роль основного сервера переключается на готовый сервер зеркала и его база данных вступает в действие в качестве такой основной базы данных.

Варианты отработки отказа включают в себя:

Microsoft применяет ряд уникальных понятий и технологий при зеркалировании баз данных. Вы уже изучили такую технологию копирования- записью (copy- on- write). Также Microsoft применяет конечные точки (endpoints), которые назначаются каждому серверу в некоторой конфигурации базы данных с зеркалом. Кроме того, установление соединения с каждым сервером намного более плотно управляется и требует учётные записи служб или интегрированной (на уровне домена) аутентификации. Внутри сервера SQL предоставление прав также может выдаваться для тех учётных записей, которые будут исполнять зеркалирование базы данных.

Вы можете полностью настроить зеркалирование базы данных с применением сценариев T-SQL, либо вы можете применять мастер зеркалирования базы данных (Database Mirroring Wizard) в SSMS. Я предлагаю чтобы вы применяли нечто повторяемое, подобное сценариям SQL, а вы можете просто создавать сценарии SQL применяя свой мастер. Обычно никому не улыбается иметь необходимость повторно создавать или управлять некоторой конфигурацией базы данных с зеркалом посреди ночи. Наличие такого полного процесса в виде некоторого сценария уменьшает практически любые ошибки.

Прежде чем вы приступите к установке и настойке некоторой среды зеркалированной базы данных, будет лучше пробежаться по некому простейшему конечному списку основных требований, которые вам необходимо проверить с тем, чтобы вы вы знали что вы надлежащим образом зеркалировали какую- то базу данных:

Пока вы не двинулись далее, вы должны установить по своей конечной точке для каждого из имеющихся серверов, которые станут частью вашей конфигурации зеркалированной базы данных. Вы можете применить для выполнения этого имеющийся вариант Настройки безопасности (Configure Security) своего мастера, однако погружение в практику применения сценариев SQL на самом деле будет лучшим подходом. Применение сценариев SQL очень простое, как вы убедитесь в этом вскорости.

Конечные точки применяют адресацию TCP/ IP и порты ожидания для всех взаимодействий между имеющимися серверами. В пределах некоторого сервера такая конечная точка задаётся неким определённым названием (а именно, именем конечной точки) для более простой ссылки и для установления роли партнёрства, которую данный сервер (конечная точка) будет возможно играть. Кроме того, для разрешения доступа каждого сервера к определённому другому необходимо GRANT некоторого соединения, а для этого следует применять некую учётную запись службы. Такая учётная запись службы обычно является определённой регистрацией, которая известна вашему домену и должна применяться для всех соединений в данной топологии вашего зеркалирования базы данных. Рисунок 7.13 показывает все свойства зеркалированной базы данных вашей базы данных AdventureWorks в некотором экземпляре сервера SQL с названием SQL2016DXD01. Как вы можете видеть, никакие сетевые адреса сервера не установлены для зеркалирования базы данных ни в каком виде, а само состояние зеркалирование сообщает, что "Данная база данных не была настроена для зеркалирования".

Далее давайте взглянем на то, как установить высокую безопасность с методикой автоматического восстановления (режим высокой доступности) зеркалированной базы данных с серверами основным, зеркальным и свидетельствующим. Для этого вы можете зеркалировать свою старую добрую базу данных AdventureWorks которую Microsoft поставляет вместе с сервером SQL (а именно версию OLTP, которая не содержит файлов FileStream).

Рисунок 7.14 иллюстрирует такую подлежащую установке конфигурацию зеркалировано базы данных.

Для данного примера наш первоначальный основной сервер является экземпляром сервера SQL с названием SQL2016DXD01, наш первоначальный сервер зеркала является экземпляром сервера SQL с именем SQL2016DXD02, а наш свидетельствующий сервер является экземпляром сервера SQL, именуемым SQL2016DXD03.

Вам необходимо установить некую локальную конечную точку с названием EndPoint4DBMirroring9xxx на каждом из этих экземпляров серверов SQL и указать порт TCP ожидания, который будет применяться для всех взаимодействий зеркалированной базы данных. Мне также нравится встраиваь такой номер порта в качестве части самого названия конечной точки, например, EndPoint4DBMirroring51430 для той конечной точки, котрая будет прослушивать порт 51430. В данной конфигурации наш основной сервер будет выполнять ожидание на порту 51430, наш сервер зеркала на порту 51440, а свидетельский сервер на порту 51450. Данные номера портов должны быть уникальными внутри некоторой отельной машины сервера, причём комбинация самого название данной машины и порта должны быть уникальными в рамках данной сетевой среды. Неким примером полностью определённого названия сетевого адреса какого- то сервера и его порта ожидания является TCP://DXD001.ADS.DXD.COM:51430, где DXD001.ADS.DXD.COM является самим названием машины внутри данного домена, а 51430является необходимым портом ожидания, созданным для данной конечной точки.

Кроме того, необходимо определить начальную роль каждого сервера. Для данного примера наш экземпляр SQL2016DXD01 может играть роль любого партнёра (то есть зеркала и/ млм ведущего сервера), наш экземпляр SQL2016DXD02 также может играть роль любого партнёра, а наш экземпляр SQL2016DXD03 будет играть только роль свидетеля.

Я включил три шаблона сценария SQL в данную книгу (доступные на её сопроводительном вебсайте с названием www.informit.com/title/9780672337765), которые имеют рабочие примеры создания необходимых конечных точек, предоставления прав соединения для регистрации этих конечных точек, резервного копирования и восстановления баз данных, а также резервного копирования и восстановления журналов транзакций.

Самыми первыми, на которые стоит взглянуть, являются 2016 Create EndPoint Partner1.SQL, 2016 Create EndPoint Partner2.SQL и 2016 Create EndPoint Witness.SQL. Вы можете улучшить эти шаблоны чтобы начать свой процесс установки в случае, если вы не применяете Мастер настройки безопасности (Configure Security Wizard).

После того как вы проверите все стороны данной планируемой топологии зеркалирования, вы можете настроить полное зеркалирование базы данных!

Каждый экземпляр сервера в данной конфигурации зеркалированной базы данных должен иметь некую конечную точку с тем, чтобы все прочие серверы могли взаимодействовать с ним. Это является неким видом, аналогичным частной телефонной линии к вашим друзьям. Для данного примера вы можете применять предоставленные сценарии вместо использования мастера Настройки безопасности (Configure Security Wizard). Самым первый сценарий содержится в файле 2016 Create EndPoint Partner1.SQL.

Из SSMS вам требуется открыть некий новый запрос на соединение со своей основной базой данных пройдя File, New и появившийся диалог New Query и выбрав Query with Current Connection. Откройте свой файл SQL для вашей первой конечной точки.

Приводимый ниже T-SQL CREATE ENDPOINT создаёт необходимую конечную точку с названием EndPoint4DBMirroring1430, причём его listener_port имеет значение 51430, а роль вашей зеркалированной базы данных Partner:

-- создание конечной точки для основного сервера --
CREATE ENDPOINT [EndPoint4DBMirroring51430]
    STATE=STARTED
    AS TCP (LISTENER_PORT = 51430, LISTENER_IP = ALL)
    FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM RC4)
 	   

После исполнения этого T-SQL вы должны выполнить следующие предложения SELECT для проверки того, что все конечные точки были созданы верно:

select name,type_desc,port,ip_address from sys.tcp_endpoints;
select name,role_desc,state_desc from sys.database_mirroring_endpoints;
 	   

Если вы также взглянете на свойства своей базы данных AdventureWorks в своём основном сервере (SQL2016DXD01 для данного примера), вы видите определённый сетевой адрес для этого основного сервера, автоматически появившийся теперь, когда вы просматриваете свою страницу Зеркалирования свойств базы данных (см. Рисунок 7.15).

Начиная с примеров сценариев 2016 Create EndPoint Partner2.SQL и 2016 Create EndPoint Witness.SQL, вам необходимо повторить весь процесс создания конечной точки для своего сервера зеркала (использующего listener_port со значением 51440) и свидетельствующего сервера (применяющего listener_port со значением 51450) открыв некоторый запрос на соединение для каждого из этих серверов и выполнив следующие команды CREATE ENDPOINT:

-- создание конечной точки для сервера зеркала --
CREATE ENDPOINT [EndPoint4DBMirroring51440]
    STATE=STARTED
    AS TCP (LISTENER_PORT = 51440, LISTENER_IP = ALL)
    FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM RC4)
 	   

Для вашего свидетельствующего сервера (отметим, что его роль теперь - роль свидетеля), вы выполняете следующее:

-- создание конечной точки для свидетельствующего сервера --
CREATE ENDPOINT [EndPoint4DBMirroring51450]
    STATE=STARTED
    AS TCP (LISTENER_PORT = 51450, LISTENER_IP = ALL)
    FOR DATA_MIRRORING (ROLE = WITNESS, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM RC4)
 	   

Существует возможность иметь некое предложение AUTHORIZATION [login] в той команде CREATE ENDPOINT, которая устанавливает все полномочия для некоторой учётной записи регистрации, которая определена для этой конечной точки. Однако выделение этого в некий отдельный GRANT в высшей степени напряжённый момент разрешения таких полномочий соединения. Для каждого запроса соединения SQL вы выполняете некий GRANT для разрешения некоторой учётной записи регистрации соединиться с определённой ENDPOINT для зеркалирования базы данных. Если вы не имеете какой- то определённой учётной записи регистрации для применения, значением по умолчанию является [NT AUTHORITY\SYSTEM].

Из экземпляра основного сервера (SQL2016DXD01) вы выполняете следующее предложение GRANT (подставляя для применения зеркалированной базой данных в качестве вашей определённой учётной записи регистрации [NT AUTHORITY\SYSTEM]):

GRANT CONNECT ON ENDPOINT::EndPoint4DBMirroring51430 TO [NT AUTHORITY\SYSTEM];
 	   

Затем из своего экземпляра сервера зеркала (SQL2016DXD02) вы выполняете следующее предложение GRANT:

GRANT CONNECT ON ENDPOINT:: EndPoint4DBMirroring51440 TO [NT AUTHORITY\SYSTEM];
 	   

А потом в экземпляре свидетельского сервера (SQL2016DXD03) вы исполняете такое предложение GRANT:

GRANT CONNECT ON ENDPOINT:: EndPoint4DBMirroring51450 TO [NT AUTHORITY\SYSTEM];
 	   

Когда все конечные точки настроены и роли установлены, вы можете создать саму базу данных на своём сервере зеркала и вывести её на тот момент, когда она имеет возможность осуществлять зеркалирование. Вначале вы должны сделать некую резервную копию своей основной базы данных (в нашем примере AdventureWorks). Эта резервная копия будет применена для создания необходимой базы данных на имеющемся сервере зеркала. Чтобы выполнить это вы можете воспользоваться задачами SSMS или сценариями SQL. В нашем случае применяются именно сценарии SQL (DBBackupAW2016.sql), которые легко повторять.

На своём основном сервере вы осуществляете следующим образом полное резервное копирование:

BACKUP DATABASE [AdventureWorks]
      TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD01\MSSQL\Backup\AdventureWorks4Mirror.bak'
    WITH FORMAT
GO
 	   

Далее вы копируете этот файл резервной копии в некоторое место, в котором его может видеть ваш сервер зеркала из имеющейся сетевой среды. Когда это осуществлено, вы можете выполнить следующую команду RESTORE базы данных для создания на вашем сервере зеркала базы данных AdventureWorks (с применение опции WITH NORECOVERY):

-- примените это восстановление базы данных(с опцией NoRecovery) для создания зеркалированной версии данной DB --
RESTORE FILELISTONLY
    FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD01\MSSQL\Backup\AdventureWorks4Mirror.bak'
go
RESTORE DATABASE AdventureWorks
    FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD01\MSSQL\Backup\AdventureWorks4Mirror.bak'
    WITH NORECOVERY,
          MOVE 'AdventureWorks_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD02\MSSQL\Data\AdventureWorks_Data.mdf',
          MOVE 'AdventureWorks_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD02\MSSQL\Data\AdventureWorks_Log.ldf'
GO
 	   

Так как вам нет нужды иметь ту же самую структуру каталога на своём сервере зеркала, вы применяете опцию MOVE как часть данного восстановления чтобы поместить все файлы базы данных в том местоположении, в котором вы пожелаете.

Этот процесс восстановления должен привести к некоторому результату, который выглядит как следующий окончательный набор:

Processed 24216 pages for database 'AdventureWorks', file 'AdventureWorks_Data' on file 1.
Processed 3 pages for database 'AdventureWorks', file 'AdventureWorks_Log' on file 1.
RESTORE DATABASE successfully processed 24219 pages in 5.677 seconds (33.328 MB/sec).
 	   

Вы должны теперь применить по крайней мере один сброс журнала транзакций для данной зеркальной базы данных. Это приведёт вашу базу данных зеркала к некому моменту синхронизации со своим основным сервером и оставляет вашу базу данных зеркала в состоянии постоянного восстановления. В данный момент восстановления базы данных вы можете пройти через свой мастер Зеркалирования базы данных (Database Mirroring Wizard) и стартовать зеркалирование для высокой доступности.

Со своего основного сервера вы выполняете сброс (то есть резервное копирование) некоторого журнала транзакций следующим образом:

BACKUP LOG [AdventureWorks] TO
  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD01\MSSQL\Backup\AdventureWorks4MirrorLog.bak'
  WITH FORMAT
Go
Processed 4 pages for database 'AdventureWorks', file 'AdventureWorks_Log' on file 1.
BACKUP LOG successfully processed 4 pages in 0.063 seconds (0.496 MB/sec).
 	   

Затем вы перемещаете эту резервную копию в то место, где она доступна для доступа со стороны вашего сервера зеркала. Когда это выполнено, вы вы восстанавливаете этот журнал в своей базе данных зеркала:

RESTORE LOG [AdventureWorks]
  FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016DXD02\MSSQL\Backup\AdventureWorks4MirrorLog.bak'
  WITH FILE = 1, NORECOVERY
GO
 	   

Ваш процесс восстановления журнала должен дать нечто, что выглядит подобно следующему набору результатов:

Processed 0 pages for database 'AdventureWorks', file 'AdventureWorks_Data' on file 1.
Processed 4 pages for database 'AdventureWorks', file 'AdventureWorks_Log' on file 1.
RESTORE LOG successfully processed 4 pages in 0.007 seconds (4.464 MB/sec).
		

Теперь вы готовы осуществлять зеркалирование своей базы данных в режиме высокой доступности.

Чтобы достичь того, что все узлы в имеющейся топологии видят друг друга, вам необходимо указать соответствующие конечные точки и значения портов ожидания для всех баз данных, вовлечённых в данную конфигурацию зеркалирования базы данных (а именно, основной и зеркальной). Это также активирует зеркалирование базы данных. Данный процесс требует изменения самой базы данных с применением либо предложения SET PARTNER, либо SET WITNESS внутри исполняемой команды ALTER DATABASE. Мастер Зеркалирования базы данных (Database Mirroring Wizard) может также выполнить данный шаг для вас, но сделать это вручную проще.

Вы указываете своё уникальное значение порта ожидания конечной точки для каждой конечной точки, причём они уникальны в рамках конкретного сервера. В данном примере это порты со значениями 51430, 51440 и 51450.

Помните, что вы будете делать это после того как вы создадите необходимую базу данных AdventureWorks на стороне своего сервера зеркала (воспользовавшись восстановлением базы данных) и журнала. После создания такой базы данных вы можете исполнить приводимую ниже команду ALTER DATABASE на своём сервере зеркала (в данном примере SQL2016DXD02) для указания того основного сервера, который является партнёром для данного зеркала:

-- На имеющемся сервере базы данных зеркала: указание конечной точки её основного сервера --
ALTER DATABASE AdventureWorks
    SET PARTNER = ' TCP://DXD001:51430'
GO
 	   

Теперь мы готовы к самому последнему этапу: На своём основном сервере вы определяете его зеркло и свидетеля. После осуществления этого этапа имеющаяся топология зеркалирования пытается выполнить свою синхронизацию и начать зеркалирование базы данных. Последующие предложения указывают конечную точку определённого сервера зеркала и конечную точку свидетельского сервера для конкретной базы данных основного сервера:

-- На имеющемся основном сервере: определяем его конечную точку сервера зеркала --
ALTER DATABASE AdventureWorks
    SET PARTNER = 'TCP://DXD001:51440'
GO
-- На имеющемся основном сервере: определяем его конечную точку свидетельского сервера --
ALTER DATABASE AdventureWorks
    SET WITNESS = 'TCP://DXD001:51450'
GO
 	   

Вы не должны изменять какие- либо базы данных на своём свидетельском сервере.

Когда данный процесс успешно завершится, вы имеете зеркало! На самом деле, при данной настройке вы пребываете в режиме автоматической отработки отказа.

Если у вас имеется проблема или вы просто пожелаете начать сначала, вы можете сбросить некую конечную точку или достаточно легко внести изменения в какую- то конечную точку. Чтобы сбросить конечную точку и покинуть её, вы применяете имеющуюся команду DROP ENDPOINT. В данном примере следующая команда сбросила бы ту конечную точку, которую вы только что создали:

-- Для сброса некоторой имеющейся конечной точки --
DROP ENDPOINT EndPoint4DBMirroring51430;
 	   

Видоизменение некоторой конечной точки (например, замена имеющегося значения listener_port) настолько же просто, как и её сброс. Приводимый далее пример отображает как видоизменить listener_port на значение 51435 для определённой в настоящий момент конечной точки из- за некоторого конфликта на сетевом уровне:

-- Для видоизменения некоторой имеющейся конечной точки --
ALTER ENDPOINT EndPoint4DBMirroring51430
    STATE = STARTED
       AS TCP( LISTENER_PORT = 51435 )
      FOR DATABASE_MIRRORING (ROLE = PARTNER)
 	   

Однако, поскольку вы применяете номер порта в самом названии конечной точки, может быть лучше просто сбросить имеющуюся и создать новую конечную точку чтобы отвечать соглашению именования. В любом случае вы запросто можете манипулировать такими конечными точками для удовлетворения своих сетевых потребностей.

Как вы видите на Рисунке 7.16, все базы данных полностью синхронизированы для зеркалирования и вы теперь пребываете в полностью безопасном режиме высокой доступности.

Если вы заглянете в свой файл журнала сервера SQL (то есть ваш текущий журнал), вы сможете обнаружить записи журнала сервера SQL, указывающие что зеркалирование базы данных активно:

05/16/2016 23:42:06,spid31s,Unknown,Database mirroring is active
           with database 'AdventureWorks' as the principal copy.
05/16/2016 23:41:01,spid54,Unknown,Database mirroring has been enabled on
           this instance of SQL Server.
05/16/2016 23:03:01,spid54,Unknown,The Database Mirroring endpoint is now
           listening for connections.
05/16/2016 23:03:01,spid54,Unknown,Server is
           listening on [ 'any' <ipv4> 51430].
 	   

После того как активное зеркалирование запущено, вы можете отслеживать всю полную топологию зеркалирования несколькими способами. Вы должны начать с регистрации этой подлежащей зеркалированию базы данных в свойствах SSMS с названием Монитор зеркалирования базы данных (Database Mirroring Monitor). Монитор зеркалирования базы данных позволяет вам отслеживать роли текущего партнёрства зеркалирования (то есть основной, зеркальной и свидетельской), отслеживать всю историю транзакций, протекающих через ваш сервер зеркала, просматривать все состояния и скорость такого потока транзакций, а также устанавливать пороговые значения для уведомления вас об возникающих отказах или прочих проблемах. Кроме того, вы можете администрировать все учетные записи для входа/ служб, подлежащие применению в данной топологии зеркалирования. Рисунок 7.17 отображает как вы запускаете Монитор зеркалирования базы данных из SSMS: вы кликаете правой кнопкой саму основную базу данных, которая будет зеркалироваться, выбираете Tasks, а затем выбираете Launch Database Mirroring Monitor.

Вы обязаны зарегистрировать ту базу данных, которая подлежит зеркалированию. Для выполнения этого вы выбираете экземпляр основного сервера или сервера зеркала и делаете отметку в блоке Register для данной базы данных. Монитор зеркалирования базы данных регистрирует эту базу данных и оба экземпляра серверов партнёров для этой базы данных, как это отображено на Рисунке 7.18.

После того как эта база данных зарегистрирована, все экземпляры партнёров и сведетельствующего сервера отображаются в самом Мониторе зеркалирования базы данных, как это показано на Рисунке 7.19.

Взглянув один раз вы можете увидеть какой сервер какую роль играет (основную или зеркальную) и будет ли каждый из партнёров определён и подключён на некотором свидетельствующем сервере. Кроме того вы можете видеть все не отправленные записи журнала (размер), не восстановленные записи журнала (размер), когда была осуществлена самая последняя транзакция, то время, которое потребовалось для отправки этой транзакции на экземпляр сервера зеркала, саму скорость отправки (кБ/ секунду), текущую скорость с которой восстанавливаются все транзакции (кБ/ секунду), накладные расходы на фиксацию самого зеркала (в миллисекундах), номер порта экземпляра свидетельского сервера, а также режим работы данного зеркалирования (в данном случае, высокая надёжность с автоматической отработкой отказа - синхронная).

Рисунок 7.20 показывает все подробности истории транзакций для некоторой определённой части имеющегося потока зеркалирования (либо ту, что отправляется основной частью, либо ту, что восстанавливается на части зеркала). Вы можете кликнуть на соответствующего партнёра для просмотра всех подробностей истории транзакций процесса зеркальной копии и восстановления. Я включил некую сохранённую процедуру с названием TRAFFIC_GENERATOR2016 в файл, именуемый как TRAFFIC_GENERATOR2016.sql, в вебсайт поддержки данной книги. Данная процедура может создавать некое приличное количество транзакций заказов продаж для базы данных AdventureWorks с тем, чтобы вы могли отслеживать как зеркалируются транзакции. Пройдите далее, выгрузите её и попробуйте.

Со страницы Монитора зеркалирования базы данных вы запросто можете приостановить (и продолжить исполнение) зеркалирования базы данных, если вы полагаете, что имеются некие проблемы, связанные с выполнением зеркалирования. Кроме того, вы можете видеть какую роль играет каждый экземпляр сервера.

С большой вероятностью в некий момент у вас может возникнуть необходимость удалить все следы зеркалирования базы данных из каждого экземпляра некоторой конфигурации зеркалирования базы данных. Это достаточно просто осуществить. В целом, вам придётся запретить зеркалирование базы данных на своём основном сервере, сбросит саму базу данных зеркала и удалить все конечные точки с каждого из экземпляров серверов. Вы можете просто начать со страницы Свойств базы данных (Database Properties) и опций Mirroring и сделать всё необходимое. В качестве альтернативы вы можете выполнить это с помощью сценариев SQL. Давайте вначале воспользуемся опциями Mirroring. Взглянем на эти опции на Рисунке 7.21, вы можете просто выбрать удаление зеркалирования (из экземпляра основного сервера). Это черезчур просто - почти пугающе!

Данный процесс зеркалирования немедленно запрещается. Когда зеркалирование отключено, вы можете сбросить имеющуюся базу данных на своём экземпляре сервера зеркала, удалить все конечные точки на каждом из экземпляров серверов (а именно, основном, зеркальном и свидетельском экземплярах), и всё это делается в SSMS. Этот подход является незамысловатым.

Если вы удаляете зеркалирование при помощи сценариев SQL, вам необходимо прервать само зеркалирование на основном сервер, удалить имеющуюся основную конечную точку, сбросить базу данных зеркала и удалить конечную точку этого зеркала, а также сбросить затем конечную точку свидетельского сервера. К этому моменту всё зеркалирование удаляется. Приводимый далее пример показывает как удалить ту конфигурацию зеркалирования базы данных, которую вы только что настроили.

Команды ALTER DATABASE и DROP ENDPOINT прерывают зеркалирование на вашем основном экземпляре и удаляют его конечную точку:

ALTER DATABASE AdventureWorks set partner off
go
DROP ENDPOINT EndPoint4DBMirroring51430
go
 	   

В экземпляре сервера зеркала (не в основном!) вы исполняете команды SQL DROP DATABASE и DROP ENDPOINT следующим образом:

DROP DATABASE AdventureWorks
go
DROP ENDPOINT EndPoint4DBMirroring51440
go
 	   

В экземпляре свидетельского сервера вы удаляете конечную точку так:

DROP ENDPOINT EndPoint4DBMirroring51450
go
 	   

Чтобы убедиться что вы удалили эти конечные точки из всех экземпляров серверов, вы просто выполняете эти предложения SELECT:

select name,type_desc,port,ip_address from sys.tcp_endpoints
select name,role_desc,state_desc from sys.database_mirroring_endpoints
 	   

Все ссылки на ваши конечные точки и роли удалены.

Вы также можете быстро глянуть в записи журнала сервера SQL которые были сделаны при удалении зеркалирования базы данных:

06/17/2016 00:26:21,spid57,Unknown,The Database Mirroring
           endpoint has stopped listening for connections.
06/17/2016 00:25:18,spid9s,Unknown,Database mirroring connection error 4
           'The connection was closed by the remote end<c/> or an error
           occurred while receiving data: '64(The specified network
           name is no longer available.)'' for 'TCP://DXD001:51450'.
06/17/2016 00:25:00,spid9s,Unknown,Database mirroring connection error 4
           'The connection was closed by the remote end<c/> or an error
           occurred while receiving data: '64(The specified network
           name is no longer available.)'' for 'TCP://DXD001:51440'.
06/17/2016 00:23:59,spid24s,Unknown,Database mirroring has
           been terminated for database 'AdventureWorks'.
 	   

Всё это только информационные сообщения. Не требуется никакой деятельности пользователя. Как вы можете увидеть из этих сообщений, вы теперь в состоянии без какого- либо зеркалирования базы данных. Вам придётся полностью повторить снова построение зеркала базы данных, если вы пожелаете вновь зеркалировать свою базу данных.

Из SSMS вы легко можете отработать отказ со своего основного экземпляра сервера на зеркальный (и обратно снова) кликнув на кнопку Failover в соответствующей странице Свойств зеркалирования базы данных (Database Properties Mirroring), как это показано на Рисунке 7.22.

В некоторый момент времени вам следует проверить отработку отказа чтобы гарантировать её работу. Когда вы кликаете свою кнопку Failover для данной конфигурации зеркалирования базы данных, вы получаете приглашение подтвердить продолжение такой работы кликнув Yes или No. Запомните, что кликнув Yes вы закрываете все соединения со своим основным экземпляром сервера, которые установлены в настоящий момент для соединения с этой базой данных. (Позже в этой главе я покажу как уведомить ваших клиентов как о самом основном экземпляра сервера, так и об экземпляре зеркала, чтобы они могли просто закрепиться и работать с тем экземпляром сервера, который им необходим в соответствии с архитектурой.)

Теперь, если вы взглянете на страницу Свойств зеркалирования базы данных (Database Properties Mirroring, см. Рисунок 7.23), вы видите, что значения ваших основного и зеркального портов ожидания поменялись местами: Основной экземпляр теперь имеет значение порта 51440, а у экземпляра зеркала значение порта равно 51430. Оба экземпляра сервера полностью переключили свои роли. Вы теперь должны пройти к своему экземпляру сервера, играющего основную роль чтобы отработать обратно к первоначальному режиму функционирования. Если вы попытаетесь открыть текущую базу данных экземпляра сервера зеркала, вы получите некую ошибку, постулирующую что вы не можете получить доступ к этой базе данных, поскольку она теперь в состоянии восстановления.

Вы также можете вручную исполнить команду ALTER DATABASE, чтобы принудительно отработать отказ на свой зеркальный сервер таким манером:

ALTER DATABASE AdventureWorks set partner FAILOVER;
 	   

Данная команда имеет тот же самый эффект, что и применение SSMS, либо даже остановит саму службу экземпляра вашего основного сервера SQL.

Любое приложение клиента способно соединяться с каждым из партнёров в конфигурации с зеркалом. Сам клиент, конечно, желал бы быть подключённым только к тому экземпляру сервера, который в настоящий момент является основным. При помощи некоторого расширения имеющегося файла настройки клиентского соединения все приложения .NET легко могут добавлять в свои информационные строки обоих партнёров и, если основной экземпляр отказывает, они автоматически установят соединение к новому основному экземпляру (при конфигурации с зеркалом). Та строчная информация расширенного соединения, которую вы предоставляете в своём файле настроек (app.config) для вашего приложения иллюстрируется ниже. Данное расширение применяет добавление Failover Partner=, которое указывает соответствующий экземпляр сервера отработки отказа для данной конфигурации с зеркалом:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="WindowsApplication4.Properties.Settings.AdventureWorksConnectionString"
            connectionString="Data Source=DXD001\SQL2012DXD01;
                              Failover Partner=DXD001\SQL2012DXD02;
                              Initial Catalog=AdventureWorks;
                              Integrated Security=True"
                              providerName="System.Data.SqlClient" />
    </connectionStrings>
</configuration>
 	   

Как я уже предлагал ранее в этой главе, вы можете применять зеркалированную базу данных для улучшения производительности; вы можете также создать некий моментальный снимок базы данных для такой базы данных с зеркалом и выставить этот снимок для своих пользователей, составляющих отчёты. Выполнение этого ещё больше улучшает общую доступность базы данных для всех конечных пользователей (как для пользователей транзакций, так и для пользователей обработки отчётов). Кроме того, это служит изоляции всех работающих с отчётами пользователей от пользователей транзакций. Все пользователи отчётов соединяются со своей зеркальной версией общей базы данных (через некий моментальный снимок такого зеркала базы данных), а их запросы на составление отчёта не оказывают воздействия ни коим образом на сам основной сервер. Помните, что сама база данных зеркала ни коим образом не применяется ни для какого доступа (она пребывает в постоянно обновляемом режиме). Сервер SQL допускает для неё создание некоторого моментального снимка (отсылаем вас к Рисунку 7.10). Как уже упоминалось ранее, она единственная реальная проблема возникает только в случае отработки отказа вашего основного сервера на свой сервер зеркала. Когда ваш сервер зеркала становится основным, все моментальные снимки прекращают соединение со своими пользователями обработки отчётов. Этим пользователям отчётов необходимо повторно установить соединение для того чтобы начать работу с того места, где они покинули соединение. Однако, вы теперь имеете и пользователей транзакций, и пользователей отчётов применяющих один и тот же экземпляр сервера базы данных, а это влияет на производительность.

Возможным решением для данной ситуации было бы автоматическое (или выполняемое вручную) сбрасывание имеющегося моментального снимка на вашем сервере зеркала когда он становится основным и создание некоторого нового снимка на вашем старом основном сервере, если он доступен (то есть, теперь как зеркало). Затем вы просто указываете всем своим пользователям отчётов на этот новый снимок базы данных. Такой процесс может обрабатываться достаточно быстро на некотором прикладном уровне. Это в основном обусловлено обратимостью подхода настройки составления отчётов основной/ зеркальный, который всегда пытается получить тот моментальный снимок базы данных, который применяется для отчётов, которые должны выполняться на том сервере, который является сервером зеркала. Действительно, вы никогда не пожелаете иметь активные моментальные снимки на обоих серверах и на основном, и на зеркальном, в одно и то же время.

Последующие шаги выводят определённую методику создания конкретного моментального снимка на вашем зеркале, его сбросе в случае, когда зеркало становится основным экземпляром и создания некоторого нового моментального снимка для вашего старого основного экземпляра (который теперь является зеркалом):

Это всё. У вас теперь снова имеются пользователи отчётов, полностью изолированные от вашего основного сервера (а также пользователей транзакций). Жизнь может вернуться к обычной очень быстро.

Как определено в Главе 1, Понимание Высокой доступности, данный сценарий посвящён приложению управления портфелем инвестиций, размещающемуся на главной ферме сервера в самом сердце мирового финансового центра: в Нью Йорке. Обслуживая только потребителей в Северной Америке, данное приложение предоставляет возможность полностью выполнять торговлю на бирже, а также опции для всех финансовых рынков (как в Соединённых Штатах, так и международных), помимо полного оценкой портфелей инвестиций, историей эффективности и оценкой владения. Первичными пользователями являются менеджеры, управляющие инвестициями для своих крупных клиентов. Покупки/ продажи на рынке составляют 90% всей дневной активности, совместно с массовыми оценками, историей эффективности и отчётами оценок, выполняемыми после закрытия этих рынков. На протяжении каждого рабочего дня недели происходят три основных пика, движимые тремя основными мировыми торговыми рынками (Соединённые Штаты, Европа и Дальний Восток). На протяжении выходных дней имеющиеся приложения используются для составления отчётов долговременного планирования, а также фронтальной загрузки торговых рынков на предстоящую неделю.

Все обновления торговых площадок и полные потребности составления отчётов в конце недели являются наиболее значимыми моментами для поддержки, причём необходимы промежуточные составления отчётов в течение каждого дня, но исключительно как некий момент во времени. Производительность имеющейся части OLTP данного приложения не должна приноситься в жертву никоим образом.

Исходя из перечисленных приоритетов, а также желания иметь достаточно простыми управление и сопровождение, наша компания изначально предпочитает воспользоваться зеркалированной базой данных (для доступности своего основного экземпляра) и моментальными снимками базы данных (для отчётов на момент времени). Данная компания не могла сразу воспользоваться вариантом IaaS Azure. Он в данный момент находится в повторной оценке для возможных обновлений данного решения в последующие годы. На протяжении многих лет мантра данной компании звучала как "Научись ползать, прежде чем пойдёшь".

Данная компания изначально сделала оценку для общих стоимостей инкрементальных приращений между $100k и $250k, которые включают в себя следующие прикидки:

Отсутствуют потребности в специализированном оборудовании или контроллерах SCSI для реализации зеркалирования базы данных или моментальных снимков базы данных. Общая стоимость инкрементального приращения для построения данного решения с Высокой доступностью составляет приблизительно $163 000 (далее - Итоговая стоимость).

Теперь, давайте поработаем над окончательным вычислением ROI для данных стоимостей инкрементальных приращений совместно с общей стоимостью времени простоя:

Итоговые ROI:

После построения данного решения Высокой доступности, необходимая цель непрерывной работы достигается легко. Порой имеются некоторые задержки в повторной синхронизации имеющегося зеркала когда один из экземпляров отрабатывает отказ перехода на другой экземпляр сервера. За последний год данный выбор дал доступность 99.9% для основной базы данных (применяемой для действий OLTP), простое управление, а также выгрузку на своё зеркало составления отчётов на момент времени. Это замечательно согласуется с имеющимися требованиями данной компании для момента во времени. В целом пользователи очень довольны производительностью и доступностью. Теперь они рассматривают последующие возможные сценарии обновления для снижения времени простоя до значения 0.05% (то есть 99.5% времени работы) на следующий год.

Данная глава охватывает два достаточно сложных и приветствующихся решения, которые могут потенциально применены для улучшения состояния с высокой доступностью. Оба достаточно просто реализуются и управляются. Оба проверены временем и предоставляются на протяжении многих лет успеха во многих компаний по всему миру. Моментальные снимки базы данных могут рассматриваться в качестве включающих возможности для многих целей. Они великолепно подходят для требований составления отчётов на определённый момент времени, отката некоторой базы данных к какому- то моменту времени (возможность восстановления и доступность), изолирования базы данных от проблем, которые могут возникать при массовых обновлениях, а также потенциально снижая воздействия обработки запросов к своим основным базам данным (через зеркалирование базы данных и моментальные снимки базы данных). Вы должны помнить что моментальные снимки базы данных являются моментами во времени и доступны только для чтения. Единственный способ обновления некоторого моментального снимка состоит в его сбросе и повторном создании. Латентность данных возможностей этого снимка во времени должна быть сделана очень ясной для любого из его пользователей.

Моментальный снимок некоторой базы данных является каким- то снимком всей базы данных целиком, не её подмножества. Это с очевидностью делает моментальные снимки базы данных очень силно отличающимися от альтернативных возможностей доступа к данным, таким как репликация данных и материализованные представления. Данная функциональность стала возможной благодаря основному прорыву Microsoft с названием технологии копирования- записью (copy- on write). Это несомненно исключительное расширение для сервера SQL, но оно не должно применяться для замены добрых старых резервных копий базы данных и их восстановлений. Моментальные снимки базы данных являются одной из возможностей, которую я рекомендую вам рассмотреть как можно быстрее.

Зеркалирование базы данных предоставляет некий способ для пользователей чтобы получить некий минимальный уровень высокой доступности для её баз данных и приложений без необходимости применять сложные конфигурации оборудования и программных средств (таких, как те, что требуются для Служб кластера - Cluster Services, кластеризации сервера SQL, а также более высоких редакций ОС и сервера SQL, которые поддерживают конфигурации AlwaysOn). Даже хотя зеркалирование базы данных было великолепным добавлением для сервера SQL, она будет исключаться в не столь отдалённой перспективе, следовательно примените здесь некие предосторожности. Как уже упоминалось ранее в данной главе, все основные компоненты, которые составляют зеркалирование базы данных были применены в имеющихся возможностях групп доступности AlwaysOn. На самом деле, они составляют сердцевину групп доступности (которые обсуждались в Главе 6). Обе данные технологии хорошо выступят в потребностях некоторых организаций для высокой доступности и, поскольку вы знакомы с этими технологическими улучшениями, они предоставят основу для постепенного перехода к более надёжным решениям по мере изменения ваших нужд.

{Прим. пер.: Обращаем ваше внимание на тот факт, что SQL Server 2017 привнёс собой новые методики организации HADR при помощи контейнеров и Kubernetes, подробнее в нашем переводе Главы 11. SQL Server и контейнеры из вышедшей в октябре 2018 в издательстве Apress книги Боба Вордса "Профессиональный SQL Server поверх Linux"}