Назад | Перейти на главную страницу

Переключение публикации репликации SQL Server

У меня есть производственная база данных, размещенная на SQL Server 2008R2 Standard, которая реплицируется на второй сервер, на котором работает та же версия SQL-сервера, через подписку на производственную базу данных. База данных подписчиков используется для запуска отчетов SQL по данным. Удаления не реплицируются, поэтому база данных отчетов довольно велика по сравнению с опубликованной производственной базой данных, которая очищается еженедельно.

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

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

Это так просто, или есть что-то, что я пропустил, что могло обернуться и укусить меня? Главное, что я хочу убедиться, - это то, что база данных, используемая для отчетности (подписанная база данных), не теряет никаких данных и продолжает получать новые реплицированные данные из новой базы данных.

Спасибо

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

Если вы используете Мастер новой подписки, то же самое можно сделать, выбрав Не инициализировать на Инициализировать подписки страница.

Уловка будет в том, как вы синхронизируете. В хранимой процедуре sp_addarticle значение по умолчанию для параметра @pre_creation_cmd - отбрасывать таблицу на подписчике. Это будет проблемой для вас. Вот как я могу это сделать:

  1. Сделайте все, что вы собираетесь сделать, чтобы переместить опубликованную базу данных на новый сервер. Это, вероятно, будет включать прерывание репликации (преднамеренное).
  2. На подписчике переименуйте все свои таблицы (или поместите их в другую схему). Это защитит их от любых бед, которые могут случиться с ними в процессе повторной инициализации репликации. В качестве альтернативы вы можете переименовать базу данных с намерением создать новую базу данных, которая будет служить подписчиком.
  3. Восстановите публикацию и подписку
  4. Разрешить публикации синхронизировать
  5. Для каждой таблицы, для которой настроено это условие архивирования, вставьте данные из того места, куда вы переместили таблицы на шаге 2, которые не существуют в «живых» таблицах на подписчике. По сути, левое соединение между сохраненной вне таблицы и живой таблицей в каждом случае

Я также предлагаю вам воспользоваться этой возможностью, чтобы создать более безопасное место для ваших архивных данных. Если когда-либо репликация ломается сама по себе (может и случается), вы окажетесь в сложной ситуации с повторной инициализацией. Если бы мне пришлось это сделать, я бы создал специальную процедуру, которая вызывается репликацией (вы можете указать ее с помощью параметра @del_cmd для sp_addarticle), которая вставляет запись в вашу архивную таблицу, а затем выполняет удаление из вашей живой таблицы. Но есть множество способов добиться того же. Удачи.