Репликация

Материал из Eludia.

В данной заметке приведены некоторые сведения по поводу средств Eludia.pm, которые можно использовать для репликации данных между экземплярами приложений.

Dump БД

Начнём с простого: выгрузки данных из БД в файл и импорта из этого файла в другой экземпляр аналогичной БД. Разумеется, для этого можно и, может быть, оптимально использовать стандартные средства самих СУБД. Однако в реальности приходится сталкиваться со следующими проблемами:

• в таблицах, не представляющих интереса (например, log) может быть накоплено большое количество данных, а стандартные утилиты (например, Oracle exp) не позволяют корректно (то есть вместе с sequences) экспортировать подмножество схемы;

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

Отсюда возникает идея: наладить экспорт требуемых данных в простой открытый текстовый формат с минимальной зависимостью от версии СУБД (в идеале — полностью независимый от неё) и, соответственно, импорт из этого формата.

В Eludia.pm в качестве такого формата используется JSON. Дампы данных являются текстовыми файлами, где каждая строка расшифровывается как отдельный JSON-массив. Некоторые строки представляют описание схемы данных, прочие — сами данные. Формат записей описан вместе с процедурой sql_export_json.

Экспортировать нужные данные и затем загрузить их можно при помощи утилит из модуля Eludia::Install:

ins db_dump /sessions /log > db.json

ins db_load < db.json

Описанным способом можно переносить схемы и между разными СУБД, хотя проблемы диалектов могут проявиться на уровне имён типов.

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

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

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

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

В описанных условиях, если клиент согласен пожертвовать актуальностью данных, скажем, в рамках последних 15 минут, можно наладить репликацию в рамках приложения при помощи offline-скриптов с использованием следующих API-функций:

• sql_export_table_to_json_by_id для экспорта обновлений log и прочих append only таблиц;
• sql_export_table_to_json_by_timestamp для экспорта обновлений всех прочих таблиц;
• sql_import_json для импорта обновлений.

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

Кроме того, при настройке симметричных конфигураций под Linux весьма полезен lsyncd: для синхронизации conf-файлов, ядра и библиотек приложения.