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

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

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

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

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

A. Правила репликации

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

CREATE REPLICATION RULE имя_правила
       FOR [ имя_пользователя. ] имя_таблицы
       [ TO имя_удаленной_таблицы ]
       ON NODE имя_сервера
       [ USER имя_пользователя ] [ PASSWORD 'пароль' ]
       [ ENABLE / DISABLE ] 
           [ SYNC / ASYNC ]
           [ IGNORE OLD VALUE / CHECK OLD VALUE / CORRECT NUMBERS  ];

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

Есть три модели поведения системы при возникновении рассогласования между значениями записей в базах данных реплицируемых серверов. Если такая ситуация возникла во время выполнения операции (update, delete), можно предпринять следующие действия:
• IGNORE OLD VALUE – игнорировать несовпадение старого значения,
• CHECK OLD VALUE – обязательно проверить старое состояние и вернуть ошибку, если нет полного совпадения,
• CORRECT NUMBERS – если не совпадают числовые значения, сохранить разницу между старым и новым значением.

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

B. Сервер репликации СУБД ЛИНТЕР

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

Сервер репликации (СР) представляет собой специальный процесс, который получает данные об измененных данных от СУБД ЛИНТЕР и сохраняет эти данные в очередях репликации в хранилище данных репликации (ХДР), которое представляет собой соответствующим образом «урезанное» ядро. Оно же будет использоваться процессами In и Out для получения данных, подлежащих репликации и рассылке.

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

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

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

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

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

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

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

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

В качестве идентификатора кортежа используется первичный ключ (для очереди рассылки это OPER_DATE (дата операции, она уникальна), на приемной очереди это уже не первичный ключ, там идентификация происходит по OPER_DATE и SERVER_SRC (передающий сервер)), описание которого передается от Out к In и сохраняется в таблицах сервера репликации.

Если один из процессов (ЛИНТЕР или СР) завершается некорректно, этот процесс стартует заново, восстанавливается и работа продолжается. Повторное прохождение одного и того же блока отслеживается с помощью времени операции (OPER_DATE).

В качестве протоколов проделанной работы используются эти же очереди с соответствующими кодами завершения и создаваемый компонентами log-файл.

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

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

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

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

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

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

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

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

Анализируя недостатки механизма асинхронной репликации можно предложить несколько усовершенствований, которые могли бы увеличить эффективность работы системы (большинство из них в настоящее время находятся на стадии реализации и войдут в следующие версии системы):
• Падение производительности во время проведения изменений подсказывает, что репликацию данных следует производить не во время их поступления, а в момент наименьшей загрузки. Это может быть определенное время суток (например, ночь) или действительно момент небольшой загрузки, определяемый сервером репликации. Конечно, такой подход увеличивает время, в течение которого данные на серверах будут рассогласованы, так что этот вопрос остается «на совести» администратора системы или проектировщика приложения.
• Сложность администрирования является стимулом для написания программы-администратора, которая может взять на себя ряд основных и наиболее часто требующихся функций: чистка хранилища (в зависимости от накопившихся данных или по времени), отслеживание коллизий, проверка и синхронизация реплицируемых таблиц и многое другое.
• Возможно усложнение правил репликации, введение горизонтальной (только выборочные записи) и вертикальной (выборочные столбцы) репликации.
• Рассылка произведенных изменений может быть синхронной (с ожиданием ответа) и асинхронной – изменения рассылаются, а ответ когда придет – тогда и придет. Второй способ быстрее, но не всегда гарантирует последовательное выполнение транзакций (хотя принципиально этот вопрос решаем).

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