Введение

Высокая готовность - главное требование к критически важным приложениям баз данных. СУБД IBM DB2 9.5 предоставляет много функций, позволяющих обеспечить выполнение этого требования. Если вы только приступаете к работе с DB2 на распределенных платформах или даже некоторое время используете этот программный продукт, то, возможно, некоторые из функций обеспечения высокой готовности могут показаться вам не слишком понятными. Когда следует использовать конкретную функцию и что мы получим в результате ее использования?

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

Сначала давайте определим значение термина "высокая готовность". Требование высокой готовности (high availiability, HA) - это требование обеспечения доступности данных для зависимых от них приложений при первой необходимости. Цель - ликвидация или минимизация простоев. С понятием высокой готовности тесно связано понятие аварийного восстановления; основное отличие этих двух понятий заключается в том, что решение аварийного восстановления (disaster recovery, DR) сосредоточено на защите от потери данных в результате катастрофических отказов системы. В этой статье мы будем говорить исключительно об обеспечении высокой готовности.

Терминология и клиент-серверная архитектура баз данных

Терминология и клиент-серверная архитектура баз данных

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

Решение для управления базами данных, как правило, состоит из трех компонентов:

• Пользовательское приложение;
• Клиентское программное обеспечение;
• Ядро базы данных.

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

• Аппаратное обеспечение сервера;
• Сетевые подключения;
• Дисковые устройства хранения;
• Операционная система.

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

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

Транзакции SQL бывают двух основных типов - транзакции чтения и транзакции записи. Транзакции чтения - это инструкции select, которые не содержат операций вставки (insert), изменения (update) или удаления (delete), а транзакции записи, напротив, должны внести в базу данных хотя бы одно изменение. Транзакции чтения требуют непротиворечивого представления данных -- то есть, если две транзакции чтения завершаются одновременно, то они должны сгенерировать единообразные результирующие наборы при выборке из одинаковых диапазонов данных. Транзакции записи требуют, чтобы зафиксированные изменения в базе данных сохранялись даже в случае возникновения ситуации отказа. На выбор решения высокой готовности могут оказывать определенное влияние бизнес-требования. Как правило, при проектировании решения высокой готовности руководствуются двумя факторами - требованиями надежности и непротиворечивости транзакций. Если бизнес-процесс требует более высокой степени готовности, а непротиворечивость чтения является менее важным требованием, то более рентабельным может оказаться асинхронный подход. И наоборот, если непротиворечивость транзакций является главным требованием, то необходимо выбрать синхронный подход. Если необходимо обеспечить и высокую готовность, и непротиворечивость транзакций, то количество доступных вариантов оказывается еще меньше.

В начало

Высокая готовность

Существует два типа высокой готовности - это постоянное обеспечение высокой готовности и обеспечение высокой готовности при отказе системы.

Постоянное обеспечение высокой готовности

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

Для описанного типа систем используется три базовых проекта - с программным обеспечением готовности, с совместным использованием ресурсов и с использованием нескольких копий.

Проект с программным обеспечением готовности

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

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

1. Поддержание баз данных в синхронизированном состоянии.
2. Использование недетерминированных функций.
3. Использование неатомарных хранимых процедур.

Недетерминированные функции - это такие функции, которые могут генерировать разный вывод в зависимости от того, где они выполняются. Например, специализированный счетчик DB2 CURRENT TIMESTAMP генерирует различные выходные значения в разных системах вследствие различий в показаниях несинхронизируемых системных часов или из-за невозможности входа инструкции в системы точно в одно и то же время.

Неатомарные хранимые процедуры - это, как правило, хранимые процедуры, которые были зафиксированы или отменены не полностью. Транзакции в хранимой процедуре могут генерировать разные результаты в зависимости от условий в момент их выполнения.

Проект с совместным использованием ресурсов

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

Наиболее часто используемый совместный ресурс - это физический носитель данных. На рисунке 1 показаны данные, которые хранятся в централизованной системе хранения, и три компонента системы, которые к ним обращаются.

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

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

DB2 for zOS в среде с совместным использованием данных демонстрирует идеальную цель для архитектуры с совместным использованием ресурсов. Основой этой среды является компонент z Parallel Sysplex, который предоставляет таймеры sysplex и средства согласования. Средства согласования представляют собой компоненты с высокой степенью интеграции, которые позволяют создавать совместно используемые ресурсы, такие, как средства блокировки и буферные пулы. Кроме того, высокой эффективностью обладает технология связи между компонентами. Отказ одного из компонентов не влияет на транзакционную рабочую нагрузку других компонентов. Кроме высокой готовности вы получаете также повышение мощности и более уравновешенную рабочую нагрузку. Чтобы использовать это решение, вам не придется изменять существующие приложения.

DB2 для платформ, отличных от-zOS, не поддерживает этот тип архитектуры.

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

Обеспечение высокой готовности за счет использования нескольких копий базы данных

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

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

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

Транзакции записи (предложения insert, update и delete) передаются всем копиям одновременно. Gridscale отслеживает копии, которые синхронизируются после того, как будет получен их ответ на запрос транзакции записи. После ответа на транзакции записи эти копии становятся доступными для передачи транзакций чтения (предложение select). Описанный механизм гарантирует, что транзакция всегда будет генерировать непротиворечивые результаты.

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

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

Gridscale, кроме того, решает многие другие проблемы, которые связаны с распределенными копиями. Например, по возможности, недетерминированные функции реализуются на сервере Gridscale. В большинстве ситуаций Gridscale не требует внесения изменений в клиентские приложения. На клиентской стороне драйвер DB2 заменяется драйвером Gridscale с дополнительными функциями, специфическими для Gridscale. Доступны драйверы Gridscale для Java, DB2 CLI, а также приложений .NET. Приложение не имеет информации о Gridscale или уровне транзакций.

Итоговый эффект решения заключается в отсутствии простоев из-за потери одной или нескольких систем, более высокой масштабируемости и меньшей стоимости. Более низкая стоимость системы обусловлена возможностью использовать имеющееся на рынке аппаратное обеспечение; не приобретая более масштабные и мощные компьютеры или более дорогостоящие системы хранения.

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

Обеспечение высокой готовности в случае отказа

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

• Главная и резервная системы;
• Система обнаружения отказа;
• Система перемещения источника данных.

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

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

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

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

Специализированное ПО для обеспечения высокой готовности

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

Tivoli® System Automation (TSA) - Linux - AIX

Veritas Cluster Server - Windows®, AIX и Linux

High Availability Cluster Multiprocessing (HACMP - AIX)

Microsoft Cluster Server (MSCS) - Windows

Sun Cluster - Sun

Steeleye Lifekeeper - Linux и Windows

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

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

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

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

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

• Время, необходимое для обнаружения отказа.
• Период времени, необходимый для переноса зависимостей ресурсов базы данных (массив хранения, сетевые ресурсы и т. п.)
• Время, которое требуется ядру DB2 на восстановление кеша.

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

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

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

Синхронная репликация доступна в двух вариантах реализации - репликация дискового хранилища и функция аварийного восстановления высокой готовности DB2 (High Availability Disaster Recover, HADR).

Репликация дискового хранилища

Репликация дискового хранилища использует специальное аппаратное устройство хранения и программное обеспечение для выполнения синхронных дисковых записей главного сервера DB2 на резервном устройстве хранения. В случае отказа главного сервера ресурсы базы данных запускаются на резервной машине. Аппаратное/программное обеспечение хранилища должно осуществлять записи на диск в обеих системах, в противном случае резервное хранилище может оказаться рассинхронизированным по отношению к главному. Пример этого типа проекта, использующий программный продукт IBM Peer to Peer Remote Copy (PPRC), показан на рисунке 4. Поскольку все записи в хранилище данных должны выполняться синхронно в оба каталога, то в проекте решения должна учитываться пропускная способность ввода/вывода, необходимая для передачи данных между главным и резервным хранилищем.

Функции DB2 HADR и DB2 HA

Функция аварийного восстановления высокой готовности DB2 (High Availability Disaster Recovery, HADR) представляет собой высокопроизводительную систему репликации базы данных, которая использует механизм ведения журналов в DB2. Сценарий DB2 HADR включает две системы DB2, главную и резервную. Главная система несет всю транзакционную нагрузку и реплицирует все изменения в базе данных на резервной системе. В случае отказа роль резервной системы может быть передана главной при помощи одной команды.

Функция HADR обеспечивает синхронную репликацию всех записанных в журнал операций DB2. Основное требование к двум системам DB2 в паре HADR DB2 - это наличие подключения по протоколу TCP/IP. Установка и администрирование функции HADR не отличается сложностью, в DB2 имеется мастер, который поможет в выполнении этих задач.

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

Непроизводительные издержки на выполнение HADR весьма невысоки. Метод репликации, используемый по умолчанию (доступны и другие методы), имеет только одно требование - запись журнала должна оказаться в памяти резервной системы до того, как главной системе будет возвращено подтверждение. Часто синхронные выполнения операций ввода/вывода для локальной записи предпочтительнее, чем передача данных на резервную систему через TCP/IP. Необходимо реплицировать только изменения данных, поэтому на транзакции чтения использование функции HADR влияния не оказывает. В этих обстоятельствах влияние выполнения HADR отсутствует или незначительно.. В обстоятельствах, когда выполняется большое количество регистрируемых транзакций, влияние HADR определяется пропускной способностью и сетевой задержкой между системами. Если пропускная способность сети больше, чем ожидаемая активность записи в журнал, вы не должны заметить значительного влияния на производительность.

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

Операции обработки отказа для функции HADR можно автоматизировать при помощи программ обеспечения высокой готовности. Версия DB2 9.5 для AIX и Linux включает функцию обеспечения высокой готовности DB2 High Availability (HA).

Функция DB2 HA представляет собой реализацию TSA и API диспетчера кластеризации DB2 с высокой степенью интеграции. При установке DB2 в среде AIX или Linux вы можете выбрать установку этой функции, которая автоматически установит TSA. Настройка конфигурации TSA и DB2 реализуется при помощи утилиты DB2 High Availability Configuration Utility (db2haicu), которая значительно облегчает настройку кластера высокой готовности. Еще одно важное преимущество функции HA заключается в том, что она использует API диспетчера кластеризации. API диспетчера кластеризации позволяет информировать DB2 о создаваемых кластерах. Благодаря информации о кластерах изменения, которые вносятся в систему DB2 и влияют на кластер HA, будут обработаны автоматически. Один из примеров - останов ядра DB2. DB2 оповещает кластер аварийной готовности о том, что администратор останавливает ядро базы данных, в результате нет необходимости предпринимать действия по перезапуску или передаче ресурсов из-за события останова.

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

Репликация DB2

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

Репликация - это асинхронный процесс, поэтому в ходе обработки ситуации отказа невозможно гарантировать, что все данные не будут противоречить своим копиям. Репликация имеет много настраиваемых параметров, но строится на репликации изменений в таблицах базы данных из одного хранилища в другое. Настраиваемый характер репликации позволяет использовать множество параметров, в том числе, выбор для репликации только определенного подмножества таблиц и/или диапазонов данных, преобразование данных в процессе репликации и использование нескольких мест назначения репликации. Удаленное расположение в данном случае не является проблемой, если пропускная способность сети достаточна для того, чтобы удовлетворить потребности клиентов.

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

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

С традиционной репликацией связаны некоторые издержки. Объем дополнительной работы зависит от количества операций вставки, удаления и обновления в исходных таблицах. В базовых таблицах не нужны дополнительные блокировки, поскольку репликация анализирует только файлы журнала, а не базовые таблицы. Но для заполнения вспомогательных таблиц (таблиц изменений) и записи этих транзакций необходимы ресурсы базы данных. На рисунке 6 показаны основные моменты сценария традиционной репликации.

Репликация на основе очереди сообщений похожа на традиционную репликацию, однако в ней не используются вспомогательные таблицы. Вместо этого все изменения размещаются непосредственно в очередях сообщений. Очереди предоставляются сервером репликации Websphere® Replication Server и могут создаваться на отдельном сервере, а также на главном или резервном сервере базы данных. Очереди обеспечивают высокую скорость репликации и гарантированный механизм поставки к месту назначения. Репликация на основе очередей сообщений DB2 не имеют издержек традиционной репликации, обеспечивают более высокую пропускную способность и добавляют дополнительную избыточность благодаря использованию очередей.

В начало

Автоматическое перенаправление (маршрутизация) клиентов (функция automatic client reroute)

При возникновении отказа на сервере базы данных клиентские подключения закрываются. Функция автоматического перенаправления (маршрутизации) клиента Automatic client reroute (ACR) позволяют клиентским компонентам DB2 автоматически восстанавливать подключения к исходному или альтернативному серверу, благодаря чему снижается время простоя для клиентских компонентов. Информация об альтернативном сервере для ACR - это параметр, заданный на сервере базы данных. Информация об альтернативном сервере помещается в кеш на клиентской стороне после первого подключения к серверу базы данных и передачи информации параметров серверной стороны. При обнаружении ошибки связи ACR поочередно производит попытки подключения к исходному и альтернативному серверу. ACR не воспроизводит оперативные транзакции, поэтому после того, как подключение к клиенту будет установлено, необходимо будет выполнить все незафиксированные задания. ACR генерирует сообщения с предупреждениями для всех приложений, использующих ACR, что позволяет приложениям при необходимости выполнить другие операции. На рисунке 8 показан возможный потенциал работы ACR с несколькими клиентами, включая серверы приложений.

Некоторые программные продукты, например, связующее ПО WebSphere, умеют работать с ACR. Это еще более упрощает работу и повышает готовность приложений. Дополнительную информацию об ACR можно найти в разделе Ресурсы.

В начало

Заключение

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

Ресурсы

Научиться

• Оригинал статьи: Implementing high availability with DB2 9.5 (EN);
  
  
• Читайте DB2 for z/OS: Data Sharing in a Nutshell (DB2 для z/OS: совместное использование данных - это просто). Книга из серии Redbook предоставляет информацию о системах обеспечения высокой готовности с совместным использованием ресурсов;(EN)
  
  
• В разделе на странице xkoto можно получить дополнительную информацию об обеспечении высокой готовности с использованием нескольких копий и виртуализации данных;(EN)
  
  
• В статье Building a high availability database environment using WebSphere middleware (Создание среды базы данных в конфигурации высокой готовности при помощи связующего ПО WebSphere) можно найти дополнительную информацию об использовании функции аварийного восстановления высокой готовности DB2 с сервером приложений WebSphere Application Server; (EN)
  
  
• В разделе Информационный центр IBM DB2 9.5 можно получить дополнительную информацию об установке и настройке функции автоматического перенаправления (маршрутизации) клиента;(EN)
  
  
• Раздел Information Management: дополнительная информация о технологиях Information Management. Техническая документация, справочные статьи, материалы для загрузки, информация о продуктах и т.п.;
  
  
• Следите за анонсами событий и подкастами на сайте developerWorks.(EN)
  
  

Получить продукты и технологии

• Используйте в своем следующем проекте разработки ознакомительных версий ПО IBM, которое можно загрузить непосредственно с сайта developerWorks.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Примите участие в блогах developerWorks и присоединяйтесь к сообществу developerWorks.(EN)
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Высокая готовность
• Автоматическое перенаправление (маршрутизация) клиентов (функция automatic client reroute)
• Заключение
• Ресурсы
• Об авторе
• Комментарии