Главная » Microsoft SQL Server, Базы данных » Зачем реплицировать данные

0

Администраторам может понадобиться репликация данных по нескольким причинам.

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

?               Требования приложений.

?               Выигрыш в производительности.

?               Распространение информации.

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

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

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

?               Региональные. Эти сбои связаны с глобальными разрушениями, вызванными землетрясениями, наводнениями, атаками террористов и др.

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

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

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

Большинство финансовых учреждений используют зеркальное отображение данных на аппаратном уровне. При этом они используют оборудование от таких производителей, как EMC, Hitachi или Veritas. Эти решения в большей мере масштабируемы, чем кластеризация. Они способны обеспечить устойчивость к отказам регионального уровня и автоматическое восстановление. Кластеризация ограничена расстоянием между узлами (обычно позволяющими получить отклик от опрашиваемого узла в течение 500 миллисекунд).

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

Зеркальное отображение данных, внедренное в S&L Server 2005, предназна- Ноеиикз ^ чено для решения проблем предыдущих версий, связанных с обеспечением 2005                                            надежности хранения информации. Использование этой функции в значи

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

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

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

?               Автоматическое восстановление невозможно.

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

I Чтобы просмотреть метаданные транзакций, реплицированных в публикации,

S VS выберите в динамическом представлении управления sysdm_repl_tranhash.

?               При репликации изменяются объекты на сервере назначения, что иногда неприменимо при восстановлении работоспособности систем. Например, свойство идентичности столбца удаляется, первичные ключи заменяются уникальными индексами, свойство NOT FOR REPLICATION не используется, а декларативная ссылочная целостность, равно как и некоторые индексы сервера источника, не реплицируются.

?               Системные объекты не реплицируются.

?               Изменения в первичных ключах сервера источника не реплицируются.

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

Требования приложений

Репликация часто используется, когда приложению нужно консолидировать данные из одного или нескольких серверов в центральное хранилище. Также во время перемещения между серверами данные могут быть трансформированы. Зачастую администраторам баз данных приходится работать в условиях существования центрального офиса и нескольких филиалов. В этом случае ему приходится консолидировать данные о продажах в центральное хранилище, а также распространять по филиалам централизованную информацию, такую как каталоги продукции. Еще один пример предполагает наличие коммивояжеров, которые в дневное время посещают клиентов, оформляют заказы, а по возвращении в офис синхронизируют информацию с центральным сервером. Классическим примером такой ситуации является служба доставки, которая использует карманные компьютеры (с установленной СУБД SQL Server Everywhere) и выполняет синхронизацию с центральным сервером в точках назначения. Репликация может использоваться для централизованной консолидации данных, для переноса данных между серверами, для обмена данными между экземплярами SQL Server и продуктами других производителей СУБД, такими как Oracle, Sybase и др. С версии SQL Server 2005 стала доступной репликация баз данных Oracle в SQL Server. Репликация может использоваться также и для синхронизации информации в пределах одной базы данных.

Выигрыш в производительности

Репликацию часто используют, когда необходимо перенести функцию отчетности на отдельный сервер, освободив главный. В противоположность другим способам распространения данных (репликации журнала и зеркальному отображению данных), репликация позволяет создать на сервере отчетности полностью отличные индексы и даже таблицы, наполнив их все теми же данными центрального сервера. Вы можете также повысить производительность операций чтения, реплицируя одни и те же данные в банк серверов. Вместо того чтобы замыкать тысячу пользователей на один сервер, можно объединить в единый банк 10 серверов, снизив нагрузку на каждый из них до 100 пользователей. Это позволило бы повысить производительность операций чтения в 10 раз. Еще одним примером повышения производительности с помощью репликации является объединение в глобальную сеть нескольких офисов одной организации. Задержки, связанные с подобной организацией сетей, могут замедлить работу приложений. Несмотря на то что использование серверов Citrix или службы терминалов идеально подходит для подобных распределенных сетей, зачастую более эффективным является подход с использованием серверов SQL Server в удаленных офисах и их репликации с центральным сервером. При этом приложения в удаленных офисах будут обращаться к локальным базам данных. Изменения, выполняемые ими, будут впоследствии реплицированы на центральный сервер. Еще один интересный подход связан с репликацией данных на рабочие узлы, выполнением в них вычислений и последующей репликацией результатов назад, на центральный сервер. Такой подход позволяет в значительной мере выиграть в производительности, так как обработка пакета распределяется среди нескольких рабочих узлов.

Распространение данных

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

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

По теме:

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