Модуль 12. Репликация в SQL Server 2005

Репликация SQL Server 2005, применение, альтернативы

12.1. Зачем нужна репликация

Репликация формально определяется как процесс синхронизации информации на разных источниках данных. Чаще всего репликация в SQL Server используется в следующих ситуациях:

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

q      для сбора информации с нескольких серверов на один сервер. Например, при помощи репликации можно собирать и сводить воедино отчеты об операциях, которые были произведены в филиалах;

q      для снятия нагрузки с рабочего сервера. Предположим, что какой-то сервер SQL Server 2005 используется для обычной OLTP-задачи, например, для работы с заказами, поступающими на предприятие. Эта же информация требуется для создания отчетов. При этом нагрузка, которая возникает при создании отчетов, может мешать пользователям работать с заказами. В такой ситуации для создания отчетов можно использовать второй сервер, а данные для него передавать при помощи репликации;

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

Отметим некоторые принципиальные моменты, которые связаны с репликацией.

Репликацию удобнее всего использовать, когда данные между серверами синхронизируются с интервалом от 15—30 минут до нескольких дней. Если данные нужно синхронизировать быстрее, имеет смысл подумать о применении распределенных транзакций (или, возможно, о использовании зеркального отображения баз данных — см. разд. 7.3). Если данные нужно синхронизировать реже, чем раз в несколько дней, то, возможно, проще будет использовать резервные копии или пакеты SSIS.

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

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

Например, разработчики, обслуживающие базу данных Комитета финансов мэрии Санкт-Петербурга, столкнулись с проблемами при обмене данных. У Комитета финансов есть множество подразделений в разных районах города, которые должны осуществлять платежи. При этом дать каждому подразделению канал связи, достаточный для использования стандартных средств репликации SQL Server, не представлялось возможным. Фактически большинство подразделений могло использовать для подключения к центральному офису только модемные коммутируемые соединения с самым разным качеством линий. В то же время в конце каждого дня информация о всех проведенных подразделением платежах должна была передаваться в главную базу данных.

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

Автору совершенно не хотелось бы создавать впечатление, что система репликации SQL Server 2005 никуда не годиться. Наоборот, во многих ситуациях без нее обойтись очень сложно. Однако не следует забывать и про альтернативные возможности, которые во многих случаях могут оказаться лучше.

Получить учебные материалы по этому курсу