E-mail:
Пароль:
Забыли пароль?

Асинхронная репликация

Асинхронная репликация

Конференция «OPEN FORUM '2000»

Асинхронная репликация. Основные задачи.

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

Поскольку репликация асинхронная, то этот процесс происходит не сразу, а в течение некоторого времени, в течение которого данные на разных серверах будут отличаться. Такое построение позволяет значительно (в самом лучшем случае, прямо пропорционально количеству серверов) увеличить производительности системы и наращивать его по мере роста нагрузки (увеличения количества клиентов или размеров базы данных) простым прибавлением серверов в систему репликации.

Правила репликации Для управления системой на логическом уровне используются правила репликации, которые создаются обычным SQL запросом и представляют собой описание того, какие объекты, куда и каким образом реплицировать. В ЛИНТЕР® создание правила репликации выглядит так:

CREATE REPLICATION RULE имя_правила
FOR [имя_пользователя.] имя_таблицы
[ TO имя_удаленной_таблицы]
ON NODE имя_сервера
[ USER имя_пользователя] [ PASSWORD 'пароль']
[ ENABLE/DISABLE ]
[ SYNC/ASYNC ]
[ IGNORE OLD VALUE/CHECK OLD VALUE/CORRECT NUMBERS ];
Ещё есть Alter и Drop
Все правила хранятся в системной таблице $$$repl
Активное/пассивное правило Синхронно/асинхронно

Сама репликация происходит по первичным ключам – каждая таблица, подлежащая репликации должна содержать первичный ключ, значение которого используется для идентификации (при удалениях и изменениях значений) в реплицируемых таблицах. Есть три поведения системы при возникновении рассогласования между значением записи в базах данных. Если такое выяснилось во время выполнения правила (update, delete) то:

  • IGNORE OLD VALUE – игнорировать несовпадение старого значения

  • CHECK OLD VALUE – обязательно проверить старое состояние и вернуть ошибку, если нет полного совпадения.

  • CORRECT NUMBERS – если не совпадают числовые значения, то сохранить разницу между старым и новым значением

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

Сервер репликации в ЛИНТЕР®

В системе асинхронной репликации участвуют два или более серверов, на каждом из которых работает ЛИНТЕР® (пока один, далее, возможно, несколько) и два процесса репликации, In и Out , которые обеспечивают выполнение правил репликации. Объектами репликации являются таблицы базы данных, список которых вместе с правилами и адресами рассылки хранится в БД (на схеме – ЛИНТЕР®).

Сервер репликации представляет собой специальный процесс, который получает данные об измененных данных от ЛИНТЕР® и сохраняет эти данные в очередях репликации в хранилище данных репликации, которое представляет собой соответствующим образом урезанное ядро, оно же будет использоваться процессами In и Out для получения данных, подлежащих репликации и рассылке. Также к нему имеют доступ мониторы репликации, которые могут отображать входящий и исходящий потоки репликации и, возможно, отображать статистические данные процесса.

Функции компонентов

  • ЛИНТЕР® – основное ядро, работает независимо от остальных компонент. Должно обеспечивать только одну дополнительную функцию: выдавать для сервера репликации измененные записи.

  • Сервер репликации – запускается отдельно и независимо от ЛИНТЕР®, запускает хранилище данных репликации, In и Out; формирует структуру данных в ХДР, запрашивает и получает данные от ЛИНТЕР®, сохраняет их в ХДР, формирует очередь рассылки в ХДР.

  • Хранилище данных репликации – ЛИНТЕР®, который хранит данные для рассылки. К этим данным имеют доступ СР, процессы In, Out и мониторы.

  • Процесс In – получает от удаленного Out информацию об измененных записях, после получения информации о завершенном коммите выполняет транзакцию, отсылая код возврата отправителю. Получаемые данные хранит в ХДР в виде приемной очереди.

  • Процесс Out – ожидает завершения транзакций (хранящихся в ХДР) и рассылает данные по назначению. Получает и заносит в ХДР коды возврата от удаленных серверов.

  • Монитор In - отображает приходящие данные, может работать в нескольких режимах:

    • отображение входящих записей

    • отображение входящих транзакций

    • отображение выполнения изменений (по записям)

    • отображение выполняемых транзакций

  • Монитор Out – отображает иcходящие данные, может работать в нескольких режимах:

    • - отображение получаемых от ЛИНТЕР® записей

    • - отображение получаемых от ЛИНТЕР® транзакций

    • - отображение рассылаемых изменений (по записям)

    • - отображение рассылаемых транзакций

    • - отображение выполненных транзакций

    • - …

Элемент очереди рассылки включает в себя полную информацию о старом и новом состоянии записи, адрес назначения, номер канала, производящего операцию, номер транзакции и время операции. Эта информация заносится в таблицу очереди рассылки на сервере репликации. В качестве первичного ключа этой таблицы используется время операции. Процесс In получает данные и помещает их в приемную очередь, структура которой похожа на структуру таблицы очереди рассылки, после помещения в эту очередь он формирует ответ, уведомляющий отправителя о нормальном приеме. Одновременно (возможно, с контролем за загруженностью ЛИНТЕР®) происходит собственно репликация, коды завершения сохраняются в таблице приемной очереди. В качестве идентификатора кортежа используется PRIMARY KEY (для очереди рассылки это OPER_DATE (дата операции, она уникальна), на приемной очереди это уже не PRIMARY KEY, там идентификация происходит по OPER_DATE и SERVER_SRC (передающий сервер)), описание которого передается от Out к In и сохраняется в таблицах сервера репликации. В случае некорректного завершения одного из процессов он стартует заново, восстанавливается (если это ЛИНТЕР® или сервер репликации) и работа продолжается. Повторное прохождение одного и того же блока отслеживается с помощью времени операции (OPER_DATE). В качестве протоколов проделанной работы используются эти же очереди с соответствующими кодами завершения, временами операции, приема, передачи и серверов рассылки и назначения.
Мониторы имеют доступ к этим таблицам и могут получить любую информацию о ходе репликации в реальном масштабе времени. При необходимости администратор системы может запустить процедуру очистки очередей сервера репликации, при этом будут удалены все уже реплицированные записи, возможно до указанной администратором даты.

Анализ особенностей системы

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

Достоинства и недостатки

Итак, к достоинствам систем асинхронной репликации следует отнести:

  • Хорошую масштабируемость (стремящуюся к прямо пропорциональной зависимости от количества серверов, участвующих в процессе репликации в случае отсутствия изменяющих запросов)

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

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

Недостатки:

  • Падение эффективности в случае высокой динамики изменений – рассылка и параллельные изменения всех БД понижают скорость отработки поисковых запросов

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

  • Необходимость нетривиального администрирования, разрешение коллизий с одинаковыми первичными ключами и, по какой-либо причине, рассогласованными данными. Уменьшить вероятность неразрешимых коллизий (или даже исключить ее) можно на этапе проектирования приложения или, в ряде случаев, при создании самих баз данных на разных серверах (например, выделения для таблиц с PRIMARY KEY AUTOINC отдельных непересекающихся диапазонов для каждого сервера).

Направление развития

Анализируя недостатки асинхронной репликации можно предложить несколько усовершенствований, которые могли бы увеличить эффективность системы (и которые в настоящее время находятся на стадии реализации):

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

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

  • Возможно усложнение правил репликации.

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

Где опробовано: Window NT, Unix, Usix, Linux, Solaris .

Выводы

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


Возврат к списку

ѕрокрутить вверх