Рассмотрим процесс переноса всех баз данных SharePoint Server 2013 Standard с одного сервера SQL Server 2012 на другой. В рассматриваемом примере базы данных SharePoint расположенные на отдельном виртуальном сервере должны быть перенесены в кластер SQL Server состоящий из двух физических серверов. Насколько я понимаю, описанная ниже процедура будет применима для всех редакций SharePoint 2010/2013. Официальное описание процедуры переноса всех баз данных SharePoint 2013 на новый экземпляр/сервер SQL Server можно найти в статье TechNet Library - Move all databases in SharePoint 2013. Весь процесс будет состоять из следующей последовательности действий:
1) Останавливаем все службы SharePoint/IIS, которые могут обращаться к БД;
2) Копируем базы данных с исходного SQL сервера на целевой;
3) На сервере SharePoint создаем SQL-алиас на новый SQL сервер и проверяем его;
4) Запускаем службы SharePoint/IIS остановленные в п.1 и проверяем результат.
То есть в сущности смысл всего процесса сводится к созданию SQL-алиаса. К своему стыду я понял, что когда занимался развертыванием SharePoint - недостаточно внимательно читал документацию и не воспользовался функционалом использования SQL алиасов изначально, но теперь у меня появилась возможность воспользоваться этой штукой.
Перед тем как приступить к процессу переноса баз данных, выполним резервное копирование всех компонент SharePoint любыми доступными нам способами. Например, можно выключить виртуальную машину на которой крутится SharePoint Server 2013 и выполнить её “холодный бэкап” с помощью DPM. И сразу же выполнить бэкап всех баз SharePoint расположенных на SQL Server. Если сервер SharePoint имеет на борту агента SCOM, то предварительно не помешает перевести его в режим обслуживания (Maintenance Mode), чтобы SCOM не завалил нас оповещениями, когда мы начнём останавливать службы SharePoint/IIS.
Итак, на работающем Front-End SharePoint сервере останавливаем службы, согласно документации:
net stop "SharePoint Administration"
net stop "SharePoint Timer Service"
net stop "SharePoint Tracing Service"
net stop "SharePoint User Code Host"
net stop "SharePoint VSS Writer"
net stop "World Wide Web Publishing Service"
net stop "SharePoint Server Search 15"
На всякий случай я остановил ещё две имеющиеся у меня службы имеющие отношение к SharePoint
net stop "SharePoint Search Host Controller"
net stop "AppFabric Caching Service"
Выполняем команду
iisreset /stop
Копируем базы на новый SQL сервер. Сделать это можно разными способами. Я опишу пример использования мастера копирования баз (Copy Database Wizard) который доступен нам в составе SQL Server Management Studio. Подключаемся к текущему SQL серверу, открываем свойства любой базы SharePoint и вызываем мастер копирования через меню Tasks > Copy Database
В качестве источника вводим имя текущего SQL сервера и выбираем режим аутентификации при подключении к этому серверу
В качестве получателя вводим имя сервера на который хотим выполнить перенос базы данных и также выбираем режим аутентификации.
Выбор метода передачи базы данных от источника к получателю зависит от наших конкретных задач. Первый метод быстрее, но он приводит к тому, что база данных отсоединяется на сервере-источнике. Второй метод может выполнить как перенос так и копирование базы данных однако при этом методе на сервере-получателе может потребоваться больше дискового пространства (замечено, что в некоторых случаях, у переносимой базы раздувается файл лога транзакций даже не смотря на то, что режим восстановления базы установлен как Simple). В своих экспериментах я использовал как первый так и второй метод, но остановился на втором, так как после копирования данных мне нужно было сохранить все БД на сервере-источнике, чтобы в случае проблем можно было быстро откатиться к старой конфигурации.
Забегая вперёд, чтобы не вводить вас в заблуждение, сразу хочу сказать, что фактически в своём случае перенос всех баз данных относящихся к SharePoint я выполнил вручную после ряда экспериментов, которые показали что полностью выполнить мою задачу с помощью этого мастера не удаётся. С помощью мастера были успешно перенесены базы данных служб поиска и профилей SharePoint, а вот базы данных конфигурации и контента не переносились ни первым ни вторым методом ни под каким соусом. Ошибки при переносе точно не вспомню, но что-то в духе несоответствия типов в базе данных источнике и получателе, что само по себе было странно так как базу получатель мастер вроде бы создавал сам. Разумеется порядок сортировки (Collation) на обоих экземплярах SQL Server у меня был идентичным. Фактически мастер оказался мне полезен лишь как средство переноса учетных записей - SQL-логинов…
Вернёмся к мастеру переноса. После того как выбран метод переноса, нам покажут список всех баз на сервере-источнике и мы можем выбрать для переноса сразу несколько баз. Первые два столбца определяют тип перемещения баз данных – перенос или копирование. В нашем случае, как я уже говорил, резонней выбрать копирование. В крайней правой колонке отображается текущее состояние баз в плане готовности к переносу/копированию.
Дальше по каждой из выбранных баз нам будет предложено настроить расположение файлов БД на сервере-получателе и при желании поменять имя файлов и самой БД. Имя БД в нашем случае разумеется менять нельзя.
Далее нам будет предложено выбрать для копирования дополнительные серверные объекты SQL Server связанные с выбранными нами базами. В нашем случае такими объектами являются SQL логины, которые были добавлены на SQL сервер-источник в процессе развёртывания SharePoint.
Ещё хочу отметить тот факт, что пока игрался с мастером обнаружил ещё одну его проблему – невозможность скопировать SQL Server Agent job в случае если внутри джоба есть ссылка на ещё несуществующую на сервере-получаете базу, даже в том случае, если джоб и база с которым она связана копируются в рамках одного захода мастера.
При выборе копируемых серверных объектов можно ограничиться определённым кругом значений, так например я отметил только те логины которые имеют отношение к SharePoint
На следующем шаге мастера будет сгенерировано имя SSIS пакета который будет выполняться на сервере-получаете и при этом также есть возможность выбрать режим логирования операции копирования/переноса. Как показали эксперименты установленную службу SSIS на серверах для успешного копирования данных в нашем случае иметь не надо.
Далее выбираем расписание запуска задания службой агента SQL Server Agent. При этом учетная запись от имени которой выполняется служба агента на сервере-получателе должна иметь полный доступ к экземпляру SQL Server на сервере-источнике. О предоставлении таких прав необходимо позаботиться до запуска процедуры копирования на финальном шаге мастера.
На финальном шаге ещё раз проверяем все настройки и запускаем задачу копирования…
Как я уже сказал метод с использованием мастера копирования приведён лишь для наглядности одного из возможных вариантов. В реальности я использовал сначала этот мастер для переноса логинов, а затем все базы данных SharePoint перенес в ручную методом классического Backup/Restore баз данных. В конечном счете на новом SQL сервере я получил аналогичную структуры баз данных, сервисных логинов и разрешений на эти БД.
После того как БД перенесены, настраиваем на нашем FE-сервере SharePoint SQL-алиас, который заставит перенаправлять все запросы SQL клиента на сервер баз данных, указанный в настройках SharePoint на фактически другой сервер/экземпляр SQL Server. При этом SQL клиент установленный на FE-сервере SharePoint будет использовать имя указанное в SQL-алиасе более предпочтительно чем разрешение имен в DNS.
Создать SQL-алис можно также разными способами, - с помощью оснастки SQL Server Configuration Manager…
…или с помощью утилиты SQL Server Client Network Utility
C:windowssystem32cliconfg.exe
Я выбрал второй вариант, так как на моём FE-сервере SharePoint не были установлены компоненты управления SQL Server, и поэтому оснастка SQL Server Configuration Manager отсутствовала, а утилита SQL Server Client Network Utility уже есть в системе в составе предустановленных по умолчанию компонент MDAC.
Создав SQL-алиас, ссылающийся на новый SQL сервер по NetBIOS имени я не получил желаемого результата, так как когда устанавливался SharePoint, указывалось FQDN имя сервера БД. Поэтому пришлось создать ещё один SQL-алиас с использованием FQDN имён.
Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра:
HKLMSOFTWAREMicrosoftMSSQLServerClientConnectTo
Перед тем как запускать службы SharePoint желательно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем имя старого сервера БД так как оно может быть прописано в SharePoint, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection
Если мы всё сделали правильно, то получим положительный результат подключения
При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.
Теперь на нашем SharePoint сервере запускаем остановленные ранее службы командами:
iisreset /start
net start "SharePoint Search Host Controller"
net start "SharePoint Server Search 15"
net start "World Wide Web Publishing Service"
net start "SharePoint VSS Writer"
net start "SharePoint User Code Host"
net start "SharePoint Tracing Service"
net start "SharePoint Timer Service"
net start "SharePoint Administration"
net start "AppFabric Caching Service"
Либо можно просто перезагрузить сервер и убедиться в том, что все службы запустились успешно и в системных логах нет ошибок, говорящих о невозможности подключения к БД.
Дополнительные источники информации:
TechNet Library - Move content databases in SharePoint 2013
TechNet Library - Move service application databases (SharePoint 2013)
SharePoint Automation - Moving Databases, the Easy Way!
Bugra Postaci's Blog - Stop SharePoint Completely or stopping the farm
Small City Design - How to configure SQL Server client aliases in a SharePoint farm
MSDN Library - Creating and Configuring Universal Data Link (.udl) Files
Большое спасибо за статью, Алексей!
Использование алиасов не накладывает какие-нибудь ограничения?
Если нет, то почему тогда MS предлагает второй более непростой способ TechNet Library — Move service application databases (SharePoint 2013) (http://technet.microsoft.com/en-us/library/jj729805.aspx) ?
Думаю это скорее касается ситуаций, когда нужно выполнить перенос баз каких-то отдельных служб SharePoint. Если же для всех баз меняется SQL-сервер, то гораздо проще провернуть это через SQL-Alias. Использование алиасов не накладывает ограничений, насколько я знаю, и даже является рекомендуемым. Поэтому когда я писал цикл заметок о развёртывании SP 2013, я начинал именно с создания алиаса.
Спасибо за ответ Алексей!
Алексей, спасибо за статью! Я сделал перенос всех баз и создал алиас для подключения к новому серверу, но моя ферма по-прежнему подключается к старому. Подскажите пожалуйста, как сделать чтобы ферма использовала для подключения к новому серверу созданные псевдонимы?
Обратная ссылка: Ошибка при создании Login в SQL Server — Create failed for Login — The server principal already exists — Error 15025 или история одного "тупняка"… | Блог IT-KB /