сеть 2 (4 вариант), страница 9

Асинхронное тиражирование транзакций в распределенных системах

В распределенной системе идеальным являлось бы состояние, когда каждая программа-клиент обращается только к тем серверам, которые находятся в пределах ее локальной сети, а передача данных и обеспечение целостности осуществляется системными средствами и не требуют специальных действий со стороны прикладной программы. Такое распределение функций возможно и реализуется на практике с помощью механизма асинхронного тиражирования транзакций.
Синхронное проведение изменений в участвующих в распределенной транзакции базах данных не всегда является необходимым требованием. Рассмотрим, например, случай ввода данных с измерительного оборудования в цехе и последующего анализа их на уровне управления. Здесь важно обеспечить достаточно малый (но, возможно, ненулевой) интервал времени между изменениями в исходных данных и изменениями в их копии в другом узле системы, где происходит построение отчетов.
Механизм асинхронного тиражирования транзакций (репликации) гарантирует доставку измененных данных на вторичные серверы непосредственно после завершения транзакции, если сервер доступен, или сразу после подключения сервера к сети. Такой подход предполагает хранение дублирующей информации в различных узлах сети и обеспечивает, по сравнению с другими подходами к репликации, снижение трафика, уменьшение времени ответа системы, а также позволяет оптимизировать нагрузку на серверы.
Асинхронная репликация не делает линии связи более надежными или скоростными. Она перекладывает передачу данных, обеспечение их целостности и ожидание при передаче данных с прикладной программы и пользователя на системный уровень.
Асинхронная репликация, в отличие от 2РС, не обеспечивает полной синхронности информации на всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно небольшой, интервал времени, величина которого определяется быстродействием соответствующего канала связи. Для большинства задач кратковременное наличие устаревших данных в удаленных узлах вполне допустимо.
Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность данных, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.

Репликационный сервер

В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его репликационном сервере создается подписка (subscription) на соответствующее описание тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных данных.
Современные СУБД используют системный журнал, в который делаются записи о изменениях в базе данных и завершении транзакций. Журнал используется сервером БД для отката и доката транзакций после сбоев и для резервного копирования. Репликация данных в Sybase также использует журнал как источник информации о завершенных транзакциях.
В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается специальная компонента - репликационный агент (Replication Agent - RA). Он подключается к серверу БД и получает от него уведомления о завершении транзакций. Измененные данные передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в соответствии с описанием тиражирования и подписками отправляет данные в специальном эффективном протоколе по месту назначения - соответствующим репликационным серверам в удаленных узлах.
Именно в этом месте - между репликационными серверами - связь может быть медленной или недостаточно надежной. Передаваемые данные в составе транзакции при недоступности узла- получателя записываются в стабильные очереди на диске и затем передаются по мере возможности. Данные могут передаваться в удаленный узел по маршруту, содержащему несколько репликационных серверов. Данная возможность лежит в основе построения иерархических систем репликации.
По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же оператора DELETE в узле, хранящем копию таблицы; выполнение INSERT или UPDATE над первичной таблицей точно так же приведет соответственно к добавлению или обновлению записи в копии таблицы в результате работы системы репликации. Имеется гибкий механизм конфигурирования так называемых функциональных строк (function strings), которые переопределяют любую операцию на макроязыке с возможностью подстановки параметров.
В одной базе данных могут содержаться как первичные данные, так и данные-копии. Приложение- клиент, работающее со своей СУБД, может вносить изменения напрямую (операторами INSERT, DELETE, UPDATE) только в первичные данные. Для изменения копии данных предназначен механизм асинхронного вызова процедур.
Для работы механизма асинхронного вызова процедур в нескольких базах данных создаются процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры вместе со значениями параметров передается через журнал и механизм репликации к узлам- подписчикам. Затем в базах данных подписчиков вызывается одноименная процедура с теми же значениями параметров.
Таким образом, для обновления "чужих" для узла данных (копии данных) прикладная программа- клиент вместо выполнения оператора UPDATE вызывает заранее определенную в этом узле хранимую процедуру и передает ей параметры (например, значение первичного ключа и новые значения для обновляемых колонок). Тело этой процедуры пустое и она не выполняет никаких действий, однако ее вызов записывается в журнал. Механизм репликации обеспечивает вызов на узле, содержащем первичные данные, одноименной процедуры с подстановкой параметров. В теле этой процедуры может быть записан оператор UPDATE, обновляющий первичные данные. Тот же механизм репликации передаст изменения в данных узлу, инициировавшему операцию.
Репликационный сервер и Replication Agent реализованы в виде отдельных модулей и могут выполняться не на том же компьютере, что сервер базы данных. Включение в систему репликационного сервера практически не оказывает влияние на загрузку сервера первичной базы данных.
СУБД, хранящая вторичные данные, может быть любой СУБД, доступной через шлюз, в том числе Oracle, Informix, Ingres, DB2, RMS, ISAM, или даже приложение Open Server.
СУБД, хранящая первичные данные, требует наличия для нее RA. Сейчас RA имеется для Sybase SQL Server, Oracle, DB2, Sybase SQL Anywhere. Готовятся RA и для других СУБД. Интерфейс RA открыт и возможно создание RA для нестандартных источников данных.
Некоторые применения тиражирования данных:

• сервер, выполняющий активное обновление данных (OLTP), разгружается от сложных запросов, связанных с поддержкой принятия решений (DSS);

• консолидация данных от подразделений в центре;

• обмен данными по медленным и/или ненадежным линиях связи;

• поддержание резервной базы данных;

• построение сети равноправных узлов, обменивающихся данными.

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

Распределенная обработка и доступ к данным средствами Sybase OmniConnect

В различных узлах предприятия используются базы данных от разных производителей. Например, в системе принятия решений это может быть Sybase, а в геоинформационной системе - Oracle.
OmniConnect осуществляет унифицированный доступ приложений к разнородным источникам данных. Специальные шлюзовые компоненты организуют работу в системе с любой промышленной СУБД, включая Oracle, Informix, Ingres, DB/2, RMS, ISAM. Приложения-клиенты при этом работают только с сервером OmniConnect на диалекте SQL фирмы Sybase (TransactSQL), а необходимая трансляция языка SQL и преобразование типов данных автоматически осуществляется шлюзовыми модулями.
Для работы с хранилищами данных на "больших" ЭВМ (mainframe) Sybase поставляет также продукцию фирмы Micro Decisionware - лидера на рынке промежуточного ПО (Sybase купила фирму MDI в начале 1994 года). MDI предоставляет шлюзы в DB/2, SQL/DS, SQL/400, в том числе через IBM DRDA-интерфейс.
OmniConnect хранит информацию о размещении таблиц на том или ином сервере БД. Централизованно хранятся и исполняются глобальные хранимые процедуры. Приложение-клиент может осуществлять транзакции, в которых участвуют таблицы из различных БД, а также выполнять процедуры, которые OmniConnect при работе с СУБД, отличными от Sybase, прозрачно преобразует к соответствующему диалекту SQL.

Sybase MPP

Sybase MPP - это расширение архитектуры Sybase SQL Server, разработанное и оптимизированное для массовой параллельной обработки. Он обладает открытой параллельной архитектурой, предназначенной для поддержки очень больших баз данных (VLDB). Sybase MPP использует стандартный SQL и открытые интерфейсы. С ним работают те же приложения, что и с SQL Server, без необходимости перепрограммирования (рис.9).
Sybase MPP выполняет параллельно операции считывания (выборки), добавления, обновления и удаления записей. Параллельно выполняются и загрузка/восстановление, и создание индексов. Архитектура Sybase MPP не содержит узких мест, связанных с разделяемой памятью или разделяемым дисковым пространством. При выполнении параллельной выборки Sybase MPP использует индексы.
Дополнительные процессоры и диски могут добавляться в систему постепенно, достигая масштабируемости в сотни раз. Имеется возможность тиражировать и перестартовать ключевые компоненты системы так, чтобы обеспечить быстрое восстановление при сбоях.
С точки зрения приложений, пользователей и разработчиков Sybase MPP выглядит как сервер с одной логической базой данных. Для этой базы данных работает оптимизатор запросов. Поддерживаются хранимые процедуры и глобальный репозитарий, где хранится информация о размещении данных.
Для управления системой имеются графические утилиты.

Sybase IQ

В системах поддержки принятия решений используется два типа продуктов. Одни оптимизированы для предварительно известных запросов, а другие - для запросов "на лету" (т.е. заранее неизвестных). Sybase IQ не требует заранее определять "пути", то есть не требует использовать предварительные знания о структуре запросов.

С использованием побитовой схемой индексации Sybase IQ практически все данные в БД могут быть проиндексированы. Поэтому никакой запрос не приведет к просмотру записей таблиц. Sybase IQ обладает высокой производительностью для заранее запланированных запросов и отлично справляется с запросами "на лету".
Sybase IQ не требует изменений в приложениях - любая программа, работающая с SQL Server, будет работать с IQ. Собственно Sybase IQ не выполняет отдельных обновлений данных. Он в прозрачном для клиента режиме передает их для выполнения SQL Server. Sybase IQ очень эффективно выполняет пакетные дополнения к базе данных. В отличие от технологий, основанных на B-деревьях, при добавлении 10 миллионов строк в таблицу, где уже есть десятки миллионов строк, Sybase IQ просто построит дополнительные страницы индекса и не потребует перестраивать весь индекс целиком.

Sybase Backup Server

Sybase Backup Server - это специальный сервер для высокопроизводительной выгрузки и загрузки баз данных, не требующий остановки SQL Server и не снижающий его производительности.
Дамп базы данных и журнала производится без прекращения использования БД. Поэтому имеется возможность выполнять дамп часто, что повышает надежность системы. Backup Server выполняет весь необходимый ввод-вывод. Команды на дамп или загрузку выдаются непосредственно для SQL Server, который обращается к Backup Server. Основные характеристики Backup Server:

• можно выполнять дамп параллельно частями так, что данные из одной БД и журнала будут одновременно записываться на несколько (до 32) устройств;

• один дамп может занимать несколько лент или файлов;

• имеется возможность выполнять выгрузку и загрузку в локальной сети так, что SQL Server находится на одном компьютере, а Backup Server и лента - на другом;

• поддерживаются все платформо-специфичные опции работы с лентой, такие, как именование томов, размеры блоков и т.д.;

• несколько выгрузок и загрузок могут управляться с одного или нескольких локальных или удаленных серверов.

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

Инструменты управления SQL-сервером

Для анализа функционирования сервера Sybase предоставляет компоненту SQL Monitor, представляющую на любом компьютере-клиенте в графическом виде данные по загрузке сервера, вводу/выводу, интенсивности транзакций, использованию памяти сервером.
SQL Monitor как клиент взаимодействует с SQL Monitor-сервером, выполняющемся на том же компьютере, что и SQL Server. SQL Monitor-сервер использует разделяемую память для доступа к информации о работе SQL Server, и поэтому не загружает SQL Server.

Управление конфигурацией