Главная » Microsoft SQL Server, Базы данных » Создание публикаций репликации снимков базы данных – ЧАСТЬ 2

0

После выбора состава реплицируемых объектов и способа репликации щелкните на кнопке Next. В отдельных случаях может быть открыто диалоговое окно Article Issues с предупреждениями системы. Просмотрите эти предупреждения и при необходимости приведите параметры статьи в соответствие с ними. Щелкните на кнопке Next, чтобы перейти к диалоговому окну фильтрации строк таблиц.

Если вы хотите установить в статьях горизонтальную фильтрацию, щелкните на кнопке Add. Фильтрация таблиц была подробно описана в предыдущем разделе. После создания фильтра щелкните на кнопке Next. Откроется диалоговое окно агента снимка базы данных. Выберите, хотите ли вы сгенерировать снимок базы данных немедленно или отложить этот процесс на более позднее время.

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

В некоторых публикациях транзакций вам может потребоваться изменить некоторые параметры, так как возможности изменить настройки в процессе создания публикации нет. Чтобы внести эти изменения, раскройте папку локальных публикаций и выберите ту, параметры которой хотите изменить. Щелкните на ней правой кнопкой мыши и в контекстном меню выберите пункт Properties. В открывшемся окне вы увидите семь разделов.

?. General (Общие параметры).

?               Articles (Параметры статьи).

?               Filter rows (Параметры фильтрации строк).

?               Snapshot (Параметры снимка базы данных).

?               FTP Snapshot (Параметры подключения к серверу FTP).

?               Publication Access List (Список доступа к публикации).

?               Agent Security (Параметры безопасности агента).

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

Во вкладке Article можно внести изменения в статьи, содержащие снимок базы данных. Здесь вы можете добавить или удалить статьи из публикации или изменить их параметры.

Во вкладке Filter Rows вы можете модифицировать существующие фильтры или добавить новые в статьи таблиц.

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

Вкладка FTP Snapshot позволяет управлять параметрами, используемыми подписчиками при подключении к серверам FTP для загрузки снимков базы данных. Например, вы можете разрешить доступ по запросу к снимкам на сайте FTP для загрузки, определить, следует ли использовать анонимный доступ, а также указать, какая учетная запись NT может быть использована, если не используется аутентификация FTP. (Следует учесть, что система безопасности NT не применяется; эта учетная запись должна быть локальной, а не доменной; также пароль будет передаваться по Интернету в открытом, текстовом виде.) Здесь же можно задать имя сервера FTP (заметим, что он не обязательно должен находиться на серверах издателя или распространителя), используемого им порта, а также путь из корня FTP (здесь обязательно следует указать префикс / ftp).

Во вкладке Snapshot содержится ряд параметров, управляющих некоторыми аспектами работы агента распространения.

?               Independent Distribution Agent. Установленное по умолчанию значение true означает, что при необходимости может быть запущено несколько агентов распространения, обслуживающих одну и ту же базу данных подписки. В SQL Server 2000 по умолчанию было принято, что при существовании нескольких публикаций в одной базе публикаций, все из которых имеют подписки из одной базы подписок, должен был существовать всего один агент распространения, совместно используемый всеми публикациями для данной базы подписки. В SQL Server 2005 в таком случае может существовать множество агентов распространения, каждый из которых открывает отдельный поток данных, направленный в базу данных подписки, что обеспечивает значительно большую производительность.

?               Snapshot always available. Определяет, следует ли формировать новый снимок базы данных при каждом запуске агента снимков. По умолчанию это так. Если вы работаете только с именованными подписчиками, можете установить для этого параметра значение false.

?               Allow anonymous subscriptions. Позволяет подписчикам создавать как именованные, так и анонимные подписки.

?               Attachable subscription database. Позволяет копировать существующую базу данных подписки другому подписчику для ускорения развертывания. По умолчанию эта возможность отключена; скорее всего, эта возможность будет исключена в будущих версиях SQL Server.

?               Allow pull subscriptions. Позволяет создавать подписки по требованию.

?               Allow initialization from backup files. Позволяет создавать резервную копию, а затем восстановить ее у подписчика. При дальнейшем конфигурировании подписки нужно будет указать, что снимок базы должен развертываться из резервной копии. Для создания подписки в этом случае следует использовать хранимую процедуру sp_adds nap shot следующим образом:

exec sp_addsubscription ©publication = N’test’, ©subscriber =

1имя_сервера_подписчика’ , @destination_db = N’awsub’, @subscription_type = N’Push1,

@sync_type = N’initialize with backup1, @article = N’all’, @update_mode = N’read only1, @subscriber_type = 0, @backupdevicetype=’disk1,@backupdevicename=1 с:\adventure.bak’

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

?               The Allow non-SQL Server Subscribers. Позволяет выполнять репликацию в гетерогенные источники данных, такие как Oracle, Sybase, DB2 и др.

?               Allow data transformations. Этот раздел позволяет запускать пакеты DTS для преобразования транзакций по пути их следования от издателя к подписчику. Этот параметр недоступен в SQL Server 2005, однако он доступен в SQL Server 2000, так что подписчики, использующие SQL Server 2005, смогут использовать это преимущество.

?               Schema Replication. В этом разделе определите, хотите ли вы реплицировать инструкции DDL (ALTER TABLE, ALTER VIEW, ALTER PROC и т.п.) подписчикам. По умолчанию для этого параметра установлено значение true.

?               Allow peer-to-peer subscriptions. Позволяет открыть публикацию для развертывания в одноранговой среде.

?               Allow immediate updating. Определяет, открыта ли подписка для непосредственных обновлений.

?               Allow queued updating. Определяет, доступна ли подписка для очередей обновлений.

Если подписка открыта для немедленных обновлений или очередей, то доступны два дополнительных параметра: Report Conflicts Centraly и Conflict Resolution Policy. Первый из них определяет, будут ли все конфликты отправляться издателю или будут протоколироваться в таблицах на стороне подписчиков. Второй параметр определяет решения, принимаемые для разрешения конфликтов: выигрывает издатель, выигрывает подписчик или выигрывает издатель, а подписка реинициализируется.

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

Последняя вкладка диалогового окна параметров публикации — Agent Security. Здесь вы можете определить, под какими учетными записями будут запускаться все агенты чтения журнала, снимков, распространения и чтения очереди.

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

Создание публикаций двусторонней репликации транзакций

Двусторонние репликации транзакций лучше всего использовать в парах “издатель-подписчик”, где необходим взаимный обмен транзакциями. Без существенных усилий невозможно расширить топологию этой репликации более чем на одну пару “издатель-подписчик”. Если вам нужен двусторонний обмен репликациями между несколькими узлами, то лучшим решением будет использование репликации слияния или одноранговой репликации. Перед тем как развертывать решение двусторонней репликации, следует позаботиться о минимизации вероятности возникновения конфликтов. В идеальном случае в любой момент времени изменения должны выполняться только на одном узле — например, если вы используете двустороннюю репликацию из соображений отказоустойчивости системы, где заранее известно, что активизированным является только один узел. Если же вы собираетесь разрешить одновременное выполнение обновлений на нескольких узлах, следует разделить таблицы с помощью различных диапазонов идентификаторов и приращений или с помощью столбца идентификатора региона.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии