Общие сведения
Продукт Avanpost FAM поддерживает кластерное развёртывание в инфраструктуре для решения задач, связанных с обеспечением отказоустойчивости и масштабируемости системы.
Репликация на уровне СУБД
Несколько экземпляров компонента Avanpost FAM Server могут быть размещены в виде кластера с применением полной репликации данных на уровне СУБД PostgreSQL. При этом база данных или кластер баз данных выступает в качестве средства согласования взаимодействия между несколькими экземплярами компонента Avanpost FAM Server.
Настройка такого механизма репликации описана в ряде инструкций:
- Установка Avanpost FAM Server в отказоустойчивом (кластерном) исполнении
- Установка Avanpost FAM Mobile Services в отказоустойчивом (кластерном) исполнении
Программная синхронизация
Продукт Avanpost FAM поддерживает возможность программной синхронизации для создания отказоустойчивого кластера. Данная функциональность гарантирует доступность сервисов Avanpost FAM даже в случае сбоя на одном или нескольких узлах кластера. В рамках функциональности Avanpost FAM синхронизирует данные об атрибутах пользователей на различных узлах (нодах) посредством механизма логической репликации. По роли, реализуемой в процессе синхронизации узлы делятся на:
- узлы-подписчики - узлы, которые передают данные узлам-подписчикам;
- узлы-подписки - узлы-подписки, которые принимают данные от узла-подпичика.
При этом один узел может в разное время выступать то в одной, то в другой роли.
Настройка такого механизма программной синхронизации описана в инструкции:
Механизм работы синхронизации
Для синхронизации данных между двумя и более узлами с развернутыми Avanpost FAM используется логическая репликация PostgreSQL с опережающий записью (WAL).
После запуска реиницализации (reinit) создаются триггеры, связанные с синхронизируемыми объектами (таблицами). При выполнении операции UPDATE c cинхронизируемой таблицей модуль hstore запускает функцию, сравнивающую старые и новые значения хэш-функций в таблице. Модуль hstore предназначен для быстрого сравнивания названий столбцов при срабатывании триггера после изменения в таблицах (в частности, в таблице users). После сравнивания hstore определяет, стоит ли фиксировать в мета-данных изменения (а потом распространять его через репликатор).
Подписка осуществляется в рамках логической синхронизации с использованием схемы sync (в частности, в рамках данной схемы для подтверждения записи нужно, чтобы все реплики получили данные от подписчика). Обновленные на узле-подписчике данные вносятся в таблицу changes, откуда посредством логической репликации передаются в таблицу с метаданными данного узла. Затем к узлу-подписчику посредством gRPC подключается репликатор узла-подписки. Репликатор узла-подписки обновляет данные, функционируя в режиме pull ("вытягивания"). В этом режиме узлы, получающие информацию, подключается к узлам, от которых требуется получить информацию. При обнаружении отличия в сравненных хэшах, репликатор сравнивает актуальные данные по временной метке и запрашивает недостающие или отличающиеся данные. В ответ узел-подписчик предоставляет следующие списки с хэш-функциями:
diff-hashes -список, в котором содержатся изменения;not exists-hashes -список, в котором содержатся не существующие хэши;tombstones -список, в котором содержатся удаленные хэши.
Репликатор узла-подписки обнаруживает отличия после сравнения хэшей, сравнивает актуальные данные по временной метке и запрашивает недостающие или отличающиеся данные. На основании полученных данных узел обновляет свои таблицы.
Команда реинициализация (reinit) использует следующие файлы с настройками:
tables.toml -файл, содержащий наименования синхронизируемых таблиц;views.toml -файл, содержащий представления с полями, используемыми для вычисления хэш-функций. Также для оптимизации процесса файл содержит параметры, значения которых не стоит учитывать при обновлении данных в процессе репликации (например, столбцыcreated_at/updated_at).
Команда реинициализация (reinit) работает со следующими таблицами :
| Наименование | Описание |
|---|---|
| Таблица с обновлениями данных. Содержит информацию об операциях, связанных с реплицируемыми данными. В таблице Для данной таблицы можно настроить автоматическую синхронизацию данных, когда команда |
| Таблица с метаданными (в зависимости от настроек: например, meta_users - таблица с метаданными пользователей, meta_delete_users - таблица с метаданными удаленных пользователей и т.п., ) |
| Таблица с идентификаторами узлов, обновляющих данные. |
| Таблица с именами узлов. |
Сценарий использования
Произошло изменение электронной почты пользователей. Триггер, запускающий процесс сравнения и обновления данных (user_sync_trigger), привязан к таблице с пользователями users. Функция, запущенная триггером, сравнивает старые значения с новыми и записывает изменения в таблицу changes для отправки. Запущенный репликатор осуществляет логическую репликацию данных. При этом параметр wal_position показывает до куда дошло обновление данных. Когда репликатор обнаруживает, что у конкретного пользователя изменился e-mail, он находит данный e-mail в таблице с метаданными пользователей и обновляет хэш для параметра.
Если пользователь был удален, репликатор удалит запись о пользователе из таблицы с метаданными (meta_users) и создаст запись в таблице с удаленными метаданными (meta_deleted). Таблица с метаданными содержит актуальную информацию о пользователях в таблице users.
Передача данных другому узлу осуществляется следующим образом. Репликатор другого узла, запрашивающий данные, получает и проверяет их аналогичным образом. Если репликатор, запрашивающий данные, получает списки хэшей (diff-hashes - список, в котором содержатся изменения; not exists-hashes - список, в котором содержатся не существующие хэши; tombstones - список, в котором содержатся удаленные хэши) и обнаруживает отличия после сравнения хэшей, он сравнивает актуальные данные по временной метке и запрашивает недостающие или отличающиеся данные.
При этом репликатор обладает кэшем, содержащем информацию об изменениях. Если изменений долго не происходит, репликатор сравнивает данные, содержащиеся в gRPC-запросе с данными, содержащимися в кэше. Если изменения обнаруживаются, репликатор обращается к базе данных.