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

Содержание

Глава 7. Моментальные снимки Сервера баз данных SQL
Что такое моментальный снимок базы данных?
Технология копирования-записью
Когда применять моментальные снимки базы данных
Возврат к моментальному снимку для целей восстановления
Предохранение базы данных перед проведением массовых изменений
Предоставление тестовой (или с гарантированным качеством) стартовой точки (основной линии)
Предоставление Отчётной базы данных на некий момент времени
Предоставление Высокой доступности и разгружающей Отчётной базы данных из зеркала базы данных
Установка и сброс моментального снимка базы данных
Создание моментального снимка базы данных
Сброс моментального снимка базы данных
Возврат к моментальному снимку для целей восстановления
Возврат исходной базы данных из моментального снимка
Применение моментального снимка базы данных для тестирования и QA
Безопасность для моментального снимка базы данных
Управление размером неполного файла моментального снимка
Число моментальных снимков базы данных на исходную базу данных
Добавление зеркалирования базы данных для Высокой доступности
Что такое зеркалирование базы данных?
Когда применять зеркалирование базы данных
Роли конфигурации определённого зеркала базы данных
Роли исполнения и роли переключения
Режимы работы зеркалированной базы данных
Установка и настройка зеркалирования базы данных
Подготовка к зеркалированию базы данных
Создание конечных точек
Предоставление полномочий
Создание базы данных на имеющемся сервере зеркала
Определение прочих конечных точек для зеркалирования базы данных
Мониторинг среды базы данных с зеркалами
Удаление зеркалирования
Проверка отработки отказа от основного к зеркалу
Установка и настройка клиента для зеркалирования базы данных
Сопоставление установки моментальных снимков и зеркалирования базы данных?
Обратимая настройка отчёта Основной/ Зеркальный
Сценарий 3: Управление портфелем инвестиций с помощью снимков БД и зеркал БД
Выводы

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

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

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

[Замечание]Замечание

Зеркалирование базы данных некоторое время назад помечалось как не рекомендуемое. Однако, оно всё ещё включается во все выпуски сервера SQL. Для создания высокой доступности и разгрузки от нагрузок отчётов в отдельные экземпляры SQL новым рекомендуемым методом создания избыточных (вторичных) баз данных являются группы доступности AlwaysOn (см. Главу 6, Группы доступности AlwaysOn сервера SQL). Однако, как вы увидите в данной главе, зеркалирование баз данных очень эффективно при создании некоторой отдельной зеркальной базы данных и является достаточно легко устанавливаемым с точки зрения администрирования. Поэтому применение этого свойства является допустимым, но имейте в виду, что оно может уйти прочь в определённой следующей версии сервера SQL (сервер SQL 2018?) либо определённо в одной из последующих (сервер SQL 2020?). Да будет ли это?

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

Что такое моментальный снимок базы данных?

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

  • Они снижают время восстановления базы данных, так как могут восстанавливать некую имеющую проблемы базу данных с помощью некоторого моментального снимка - имеющего названия возврата (reverting).

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

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

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

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

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

 

Рисунок 7.1


Основная концепция моментального снимка базы данных: база данных источник и её моментальный снимок, всё в каком- то отдельном экземпляре сервера SQL

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

 

Рисунок 7.2


Страницы данных базы данных источника и неполный файл страниц данных, содержащий определённый моментальный снимок базы данных.

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

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

 

Рисунок 7.3


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

[Замечание]Замечание

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

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

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

  • Исходная база данных (Source database) - Это сама база данных, на которой основан обсуждаемый моментальный снимок базы данных. Именно он является основоплагающим механизмом, который применяет сервер SQL.

  • Моментальный снимок баз данных (Snapshot databases) - Это могут быть один или более моментальных снимков определённых для любой единственной базы данных источника. Все моментальные снимки должны располагаться в одном и том же экземпляре сервера SQL.

  • Неполный файл моментального снимка базы данных (Database snapshot sparse file) - Это новое размещение страниц данных содержит все первоначальные страницы данных исходной базы данных после проведения обновлений этих страниц данных исходной базы данных. Один неполный файл связан с каждым файлом данных базы данных. Если у вас имеется некая исходная база данных, размещённая в одном или более файлов данных, вы имеете соответствующие неполные файлы для каждого из них.

  • Возврат к некоторому моментальному снимку базы данных (Reverting to a database snapshot) - Если вы восстанавливаете некую исходную базу данных, основываясь на некотором определённом моментальном снимке базы данных, который был сделан в определённый момент времени, вы выполняете возврат (reverting). В действительности вы выполняете некую операцию базы данных RESTORE в каком- то предложении FROM DATABASE_SNAPSHOT.

  • Технология копирования-записью (Copy-on-write technology) - В качестве части некоторой транзакции изменения в имеющейся исходной базе данных, какая- то копия имеющейся страницы данных исходной базы данных записывается в неполный файл с тем, чтобы данный моментальный снимок мог бы обслуживаться правильно (то есть, видеть ту страницу данных, которая была в момент выполнения моментального снимка данных).

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

 

Рисунок 7.4


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

Технология копирования-записью

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

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

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

 

Рисунок 7.5


Применение технологии копирования записью для моментальных снимков базы данных.

[Замечание]Замечание

Моментальные снимки базы данных не могут применяться ни для каких внутренних баз данных сервера SQL - tempdb, master, msdb или model. Кроме того, моментальные снимки базы данных поддерживаются только в Корпоративной редакции сервера SQL 2016 (Enterprise Edition of SQLServer 2016).

Когда применять моментальные снимки базы данных

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

Возврат к моментальному снимку для целей восстановления

Рисунок 7.6

 

Рисунок 7.6


Основная конфигурация моментального снимка базы данных: некая исходная база данных и один или более моментальных снимков базы данных с различными интервалами времени.

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

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

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

Предохранение базы данных перед проведением массовых изменений

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

 

Рисунок 7.7


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

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

Предоставление тестовой (или с гарантированным качеством) стартовой точки (основной линии)

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

 

Рисунок 7.8


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

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

Предоставление Отчётной базы данных на некий момент времени

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

 

Рисунок 7.9


База данных отчётов на некий момент времени с применением моментального снимка.

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

Предоставление Высокой доступности и разгружающей Отчётной базы данных из зеркала базы данных

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

 

Рисунок 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
 	   

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

[Замечание]Замечание

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

SNAP_AdventureWorks_data_6AM

Применяемое соглашение для названий файлов аналогичное. Само название начинается со слова SNAP, за которым следует название той исходной базы данных, для которой представлен этот моментальный снимок (в данном примере AdventureWorks), после чего указывается определённая порция данных (например, data или data1), краткое указание того что представляет данный снимок (например 6AM) и затем заданное расширение имени файла snap для того чтобы отличать его от файлов .mdf и .ldf. Например, имя файла моментального снимка для предыдущего моментального снимка базы данных будет выглядеть следующим образом:

SNAP_AdventureWorks_data_6AM.snap

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

  1. Создайте необходимый моментальный снимок для своей исходной базы данных AdventureWorks:

    
    Use [master]
    go
    CREATE DATABASE SNAP_AdventureWorks_6AM
    ON ( NAME = AdventureWorks_Data
       , FILENAME= 'C:\Program Files\Microsoft SQL Server\ MSSQL13.SQL2016DXD01\MSSQL\DATA\SNAP_AdventureWorks_data_6AM.snap')
    AS SNAPSHOT OF AdventureWorks
    Go
     	   
  2. Взгляните на этот только что созданный моментальный снимок с точки зрения самого экземпляра сервера SQL, применив некий SQL запрос для своего системного каталога sys.databases следующим образом:

    
    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-05-21 23:37:02.763                OFF
    SNAP_AdventureWorks_6AM    6          5          2016-05-22 06:18:36.597                 ON
    		

    Отметим, что source_database_id для только что созданного моментального снимка базы данных содержит сам идентификатор базы данных своей исходной базы данных.

  3. Взглянем на только что созданный физический файл для необходимого неполного файла (этого моментального снимка базы данных), выполним запрос системного каталога sys.master_files:

    
    SELECT database_id, file_id, name, physical_name
    FROM   sys.master_files
    WHERE  Name = 'AdventureWorks_data'
      and  is_sparse = 1
    go
     	   

    Отметим, что данный пример сосредоточен только на имеющихся неполных файлах для вновь созданного моментального снимка базы данных (а именно, квалификации is_sparse = 1). Результат данного запроса таков:

    
    database_id file_id     name                  physical_name
    ----------- ----------- ------------------------------------------------------
    6           1           AdventureWorks_Data   C:\Prog...\DATA\SNAP_AdventureWorks_data_6AM.snap
    		
  4. Чтобы посмотреть общее число байт, которое отъедает неполный файл некого моментального снимка (до какого размера он вырос), вы можете исполнить некую последовательность предложений SQL для системного каталога представлений/ таблиц с применением fn_virtualfilestats и sys.master_files. Однако ниже представлен черновик сохраняемой процедуры, которая делает эту задачу намного проще. Просто создайте эту сохранённую процедуру в своём экземпляре сервера SQL (она также доступна в выгружаемом файле сценариев к данной главе):

    
    CREATE PROCEDURE SNAP_SIZE_UNLEASHED2016
           @DBDATA varchar(255) = NULL
    AS
    if @DBDATA is not null
       BEGIN
          SELECT B.name as 'Sparse files for Database Name'
               , A.DbId
               , A.FileId
               , BytesOnDisk 
            FROM fn_virtualfilestats(NULL, NULL) A
    		   , sys.master_files B
           WHERE A.DbID = B.database_id
             and A.FileID = B.file_id
             and B.is_sparse = 1
             and B.name = @DBDATA
       END
    else
       BEGIN
          SELECT B.name as 'Sparse files for Database Name'
               , A.DbId
               , A.FileId
               , BytesOnDisk
            FROM fn_virtualfilestats (NULL, NULL) A
    		   , sys.master_files B
           WHERE A.DbID = B.database_id
             and A.FileID = B.file_id
             and B.is_sparse = 1
       END
    Go
     	   

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

    
    EXEC SNAP_SIZE_UNLEASHED2016 'AdventureWorks_Data'
    Go
     	   

    Вот детализация результирующих байт, которые данный неполный файл использует на диске:

    
    Sparse files for Database Name  DbId   FileId   BytesOnDisk
    ------------------------------------------------------------------------------
    AdventureWorks_Data              6      1       3801088
    		

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

  5. Воспользуйтесь приводимым ниже предложением SQL для выбора строк из данного только что созданного моментального снимка базы данных для некоторого обычного запроса на определённый момент времени к таблице CreditCard:

    
    Use [SNAP_AdventureWorks_6AM]
    go
    SELECT [CreditCardID]
         ,[CardType]
         ,[CardNumber]
         ,[ExpMonth]
         ,[ExpYear]
         ,[ModifiedDate]
      FROM [SNAP_AdventureWorks_6AM].[Sales].[CreditCard]
     WHERE CreditCardID = 1
    go
     	   

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

    
    CreditCardID  CardType      CardNumber       ExpMonth ExpYear  ModifiedDate
    ----------------------------------------------------------------------------
    1             SuperiorCard  33332664695310   11       2006     2013-12-03 00:00:39.560
    		

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

 

Рисунок 7.11


Моментальный снимок SSMS ответвления DB, результатов системного запроса и состояния изоляции моментального снимка (ON).

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

Сброс моментального снимка базы данных

Если вы желаете избавиться от некоторого снимка или перекрыть некий текущий снимок более новым моментальным снимком, вы просто применяете команду 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. Для начала, должен быть сброшен тот, который вы не желаете применять после выполнения возврата. Затем вы можете выполнить восстановление с оставшимся снимком, которое вам требуется. Вот эти шаги:

  1. Спрасываем нежелательные снимки (снимок):

    
    Use [master]
    go
    DROP DATABASE SNAP_AdventureWorks_12PM
    go
     	   
  2. Применяем команду RESTORE DATABASE в своему оставшемуся моментальному снимку:

    
    USE [master]
    go
    RESTORE DATABASE AdventureWorks 
       FROM DATABASE_SNAPSHOT = 'SNAP_AdventureWorks_6AM'
    go
     	   

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

Применение моментального снимка базы данных для тестирования и QA

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

Вот эти шаги:

  1. Создайте необходимый золотой моментальный снимок базы данных до того, как вы запустите своё тестирование:

    
    Use [master]
    go
    CREATE DATABASE SNAP_AdventureWorks_GOLDEN
    ON ( NAME = AdventureWorks_Data
       , FILENAME= 'C:\Program Files\Microsoft SQL Server\ MSSQL13.SQL2016DXD01\MSSQL\DATA\SNAP_AdventureWorks_data_GOLDEN.snap')
    AS SNAPSHOT OF AdventureWorks
    Go
     	   
  2. Выполните проверки или QA со своим ключевым содержимым.

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

    
    USE [master]
    go
    RESTORE DATABASE AdventureWorks
       FROM DATABASE_SNAPSHOT = 'SNAP_AdventureWorks_GOLDEN'
    go
     	   

Безопасность для моментального снимка базы данных

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

Управление размером неполного файла моментального снимка

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

  • Наблюдайте постоянно за неполными файлами. Используйте сохранённые процедуры аналогичные SNAP_SIZE_UNLEASHED2016 для помощи в этом вопросе.

  • Пристально следите за имеющейся изменяемостью вашей базы данных. Такая частота изменений часто передаётся самому размеру вашего неполного файла и тому насколько быстро он растёт. Высеченным на камне правилом является согласование частоты сбросов и повторного создания некоторого моментального снимка базы данных после того как размер неполного файла составляет около 30% размера вашей исходной базы данных. Требования пользователей на вашу задержку данных могут запрашивать более частых сброса/ повторного создания.

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

Число моментальных снимков базы данных на исходную базу данных

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

Добавление зеркалирования базы данных для Высокой доступности

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

[Замечание]Замечание

Зеркалирование базы данных не может быть реализовано в некоторой базе данных, которая также настроена для хранения FileStream.

Что такое зеркалирование базы данных?

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

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

 

Рисунок 7.12


Базовая конфигурация зеркалированной базы данных с основным, зеркальным и свидетельским серверами.

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

  • Сервер зеркальной базы данных - Этот сервер зеркала является получателем всего зеркалирования со своего основного сервера базы данных. Такая зеркальная база данных сохраняется в режиме горячего ожидания и не может применяться напрямую ни коим образом. Это "пассивный" сервер в данной конфигурации. На самом деле , после того как вы настроите зеркалирование базы данных, такая база данных отражает своё состояние как находящееся в непрерывном режиме "восстановления". Это происходит по той причине, что все физические записи транзакций непрерывно применяются к данной базе данных зеркала. Эта база данных на самом деле является некоторой базой данных горячего резерва и не доступна ни для какого непосредственного использования базы данных. Она применяется в случае падения своей основной базы данных и не должна портиться ни коим образом; она должна быть точным зеркальным образом своей основной базы данных. Единственное исключение для такого сценария отсутствия применения состоит в создании моментальных снимков с данной базы данных зеркала. (Я обсужу эту великолепную возможность позже в данной главе.)

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

[Замечание]Замечание

Зеркалирование базы данных не может применяться ни к каким внутренним базам данных сервера SQL - tempdb, masterdb, msdb или modeldb. Зеркалирование базы данных полностью поддерживается в редакциях сервера SQL Standard (Стандартной), Developer (редакции Разработчика) и Enterprise (Корпоративной), но не поддерживается в редакции сервера SQL Express. Однако в качестве свидетельского сервера могут применяться даже машины с редакцией серверов SQL Express.

Когда применять зеркалирование базы данных

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

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

Роли конфигурации определённого зеркала базы данных

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

Роли исполнения и роли переключения

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

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

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

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

Режимы работы зеркалированной базы данных

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

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

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

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

То, являются операции синхронными или асинхронными, зависит от самих установок безопасности транзакций. Вы управляете этой настройкой через опцию 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 применяя свой мастер. Обычно никому не улыбается иметь необходимость повторно создавать или управлять некоторой конфигурацией базы данных с зеркалом посреди ночи. Наличие такого полного процесса в виде некоторого сценария уменьшает практически любые ошибки.

Подготовка к зеркалированию базы данных

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

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

  2. Удостоверьтесь что у вас имеется доступным столько же или более объёма дискового пространства на вашем сервере зеркала, скольк на вашем основном сервере. Вам также требуется аналогичное пространство для роста на них обоих.

  3. Проверьте наличие связи друг с другом серверов. Возможно, наиболее простой способ сделать это состоит в попытке зарегистрировать каждый из экземпляров сервера SQL в SSMS. Если вы можете зарегистрировать данный сервер, такой сервер может применяться для зеркалирования базы данных. Выполните это для своих основного, зеркального и свидетельского серверов.

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

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

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

 

Рисунок 7.13


Страница свойств зеркалированной базы данных: адресация сетевой среды зеркалирования и состояние зеркалировния.

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

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

 

Рисунок 7.14


Некая конфигурация зеркалированной базы данных с высокой доступностью для базы данных AdventureWorks.

Для данного примера наш первоначальный основной сервер является экземпляром сервера 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).

 

Рисунок 7.15


Страница зеркалирования базы данных AdventureWorks на вашем основном сервере с портом ожидания 51430.

Начиная с примеров сценариев 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
 	   
[Замечание]Замечание

В вашем предложении WITH FILE =, соответствующий номер файла должен помечать необходимое значение в имеющихся результатах резервных копий журнала (в предыдущем примере когда обратите внимание на имеющуюся ссылку file 1).

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


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).
		
[Замечание]Замечание

Вам может понадобиться обновление FILE = x, записи в вашей команде RESTORE LOG чтобы соответствовать имеющемуся в файле значению, выдаваемому в процессе данного резервного копирования журнала.

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

Определение прочих конечных точек для зеркалирования базы данных

Чтобы достичь того, что все узлы в имеющейся топологии видят друг друга, вам необходимо указать соответствующие конечные точки и значения портов ожидания для всех баз данных, вовлечённых в данную конфигурацию зеркалирования базы данных (а именно, основной и зеркальной). Это также активирует зеркалирование базы данных. Данный процесс требует изменения самой базы данных с применением либо предложения 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, все базы данных полностью синхронизированы для зеркалирования и вы теперь пребываете в полностью безопасном режиме высокой доступности.

 

Рисунок 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.

 

Рисунок 7.17


Запуск монитора зеркалирования базы данных из SSMS.

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

 

Рисунок 7.18


Регистрация зеркалированной базы данных в мониторе зеркалирования базы данных.

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

 

Рисунок 7.19


Зарегистрированная база данных и состояние каждого партнёра зеркалирования.

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

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

 

Рисунок 7.20


История транзакций партнёров зеркалирования.

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

Удаление зеркалирования

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

 

Рисунок 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.

 

Рисунок 7.22


Проверка отработки отказа зеркалированной базы данных.

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

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

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


ALTER DATABASE AdventureWorks set partner FAILOVER;
 	   

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

 

Рисунок 7.23


Экземпляры сервера переключают роли вслед за отработкой отказа.

[Замечание]Замечание

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

Установка и настройка клиента для зеркалирования базы данных

Любое приложение клиента способно соединяться с каждым из партнёров в конфигурации с зеркалом. Сам клиент, конечно, желал бы быть подключённым только к тому экземпляру сервера, который в настоящий момент является основным. При помощи некоторого расширения имеющегося файла настройки клиентского соединения все приложения .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. Создайте определённый моментальный снимок на каком- то сервере базы данных зеркала для отчётов на этом сервере зеркала (DXD001\SQL2016DXD02):

    
    Use [master]
    go
    CREATE DATABASE SNAP_AdventureWorks_REPORTING
    ON ( NAME = AdventureWorks_Data, FILENAME= 'C:\Program Files\ Microsoft SQL Server\MSSQL13.SQL2016DXD02\MSSQL\DATA\SNAP_AdventureWorks_data_REPORTING.snap')
    AS SNAPSHOT OF AdventureWorks
    Go
     	   

    Как вы можете видеть на Рисунке 7.24, это была бы работающая конфигурация вашего основного сервера (DXD001\SQL2016DXD01), его сервера зеркала (DXD001\SQL2016DXD02), а также моментального снимка базы данных отчётов (SNAP_AdventureWorks_REPORTING), как это отображается в студии управления сервера SQL (SSMS, SQL Server Management Studio).

     

    Рисунок 7.24


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

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

  2. Сбрасываем имеющийся моментальный снимок базы данных отчётов на своём новом основном сервере (теперь основным является DXD001\SQL2016DXD02):

    
    Use [master]
    go
    DROP DATABASE SNAP_AdventureWorks_REPORTING
    go
     	   
  3. Создаём для себя новый моментальный снимок базы данных отчётов на своём новом сервере зеркала базы данных (теперь зеркалом является DXD001\SQL2016DXD01):

    
    Use [master]
    go
    CREATE DATABASE SNAP_AdventureWorks_REPORTING
    ON ( NAME = AdventureWorks_Data, FILENAME= 'C:\Program Files\Microsoft SQL Server\ MSSQL13.SQL2016DXD01\MSSQL\DATA\SNAP_AdventureWorks_data_REPORTING.snap')
    AS SNAPSHOT OF AdventureWorks
    Go
     	   

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

Сценарий 3: Управление портфелем инвестиций с помощью снимков БД и зеркал БД

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

  • Доступность:

    • 20 часов в день

    • 7 дней в неделю

    • 365 дней в году

  • Планируемое время простоя: 4%

  • Не планируемое время простоя: 1% будет допустим

  • Возможная категория доступности: Высокая доступность

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

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

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

  • Два новых сервер со множеством ядер и 64ГБ ОЗУ по $50k за сервер

  • Две лицензии Microsoft Windows Server 2012

  • Две лицензии сервера SQL в Корпоративной редакции

  • Двенадцать дней дополнительной стоимости обучения для персонала

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

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

  1. Стоимость сопровождения (на период одного года):

    • $7.7k (оценка) - Ежегодная стоимость персонала системных администраторов (дополнительное время на подготовку этого персонала)

    • $25.5k (оценка) - Стоимость продложения лицензионной поддержки

  2. Стоимость оборудования:

    • $100k стоимости аппаратных средств - Общая стоимость всех дополнительных технических средств в данном новом решении с Высокой доступностью

  3. Стоимость развёртывания/ оценки:

    • $25k стоимость развёртывания - Общая стоимость развёртывания, тестирования, QA (обеспечения качества), а также промышленной реализации данного решения

    • $5k стоимость оценки Высокой доступности

    • Стоимость простоя (на протяжении периода в 1 год):

      • Если вы отслеживали записи времени простоя за последний год, воспользуйтесь этими значениями; в противном случае проведите некую оценку планируемого и не планируемого времени простоя для данного вычисления. В этом сценарии наша оценка одного часа простоя составляет $150k/ час - это впечатляет!

      • Стоимость планируемого простоя (убыточная стоимость) = Планируемые часы простоя в данном деле не стоят ничего на самом деле. Данная компания предлагает некую устоявшуюся практику, которая подразумевает обычные часы работы и запрещает изменение данных вне таких предлагаемых окон. Она работает в окнах времени работы биржи.

      • Стоимость не планируемого простоя (убыточная стоимость) = Часы не запланированного простоя x Стоимость одного часа простоя для данной компании:

        1. 1% (оценка процентного соотношения не планируемого времени простоя) x 8 760 часов в году = 87.6 часов незапланированного времени простоя

        2. 87.6 часов x $150k/час (почасовая стоимость простоя) = $13 140 000 в год стоят незапланированные простои. Общий убыток составляет $4.6 миллиардов в год.

Итоговые ROI:

  • Итоговая стоимость получения данного решения Высокой доступности = $163 000 (за начальный год и примерно $32.5k в год за последующие годы)

  • Общая стоимость простоя = $13 140 000 (за один год)

    Данная инкрементальная стоимость составляет приблизительно 1.24% от общей стоимости простоя за 1 год. Другими словами, все инвестиции в данное конкретное решение Высокой доступности окупятся за 1.1 часа! Это гигантское значение 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"}