Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/apostoldevel/process-replication

Replication process for Apostol CRM
https://github.com/apostoldevel/process-replication

Last synced: about 2 months ago
JSON representation

Replication process for Apostol CRM

Awesome Lists containing this project

README 

        
Репликация (Replication)

-

**Процесс** для [Апостол CRM](https://github.com/apostoldevel/apostol-crm).



Описание

-

Процесс репликации подразумевает собой распространение изменений данных с главного сервера (мастер, master), на один или более подчиненных серверов (слейв, slave).



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



Алгоритм работы

-



Репликация состоит из трех шагов:



1. Мастер-сервер сохраняет изменения данных в журнале репликации (`replication.log`).

2. Слейв-сервер копирует эти данные в журнал ретрансляции (`replication.relay`) с указанием источника данных (`source`).

3. Слейв-сервер воспроизводит изменения из журнала ретрансляции, применяя их к собственным данным.



Установка

-

Следуйте указаниям по сборке и установке [Апостол CRM](https://github.com/apostoldevel/apostol-crm#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0)



Настройка

-



### Мастер-сервер



Любой сервер может выступать в качестве Мастер-сервера, для этого нужно определиться со списком таблиц для репликации:



### Список таблиц  для репликации



Список доступных для репликации таблиц можно посмотреть с помощью следующего SQL запроса:



```postgresql

SELECT * FROM ReplicationTable ORDER BY schema, name;

```



Активировать репликацию для таблицы из списка можно с помощью следующего SQL запроса:



```postgresql

SELECT replication.table('schema', 'table', true);

```



Отключить репликацию для таблицы из списка можно с помощью следующего SQL запроса:



```postgresql

SELECT replication.table('schema', 'table', false);

```



#### Задействовать репликацию можно и в два этапа.



На первом этапе нужно определиться со списком таблиц и установить для них признак репликации на втором включить репликацию.



Установить или снять признак репликации на таблице можно с помощью следующего SQL запроса:



```postgresql

--Установить

SELECT replication.set_table('schema', 'table', true);

--Снять

SELECT replication.set_table('schema', 'table', false);

```

Как применять SQL запрос к списку таблиц в виде массива продемонстрировано в следующем примере:



```postgresql

SELECT replication.set_table('db', t.name, true) FROM (SELECT unnest(ARRAY['table1', 'table2', 'table3', 'tableN']) AS name) AS t;

```



### Включение репликации



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



```postgresql

SELECT replication.on();

```



### Отключение репликации



Для того, что-бы отключить репликацию на сервере выполнить следующий запрос:



```postgresql

SELECT replication.off();

```



### Слейв-сервер



Слейв-сервер подключается к Мастер-серверу по [WebSocket API](https://github.com/apostoldevel/module-WebSocketAPI).



Для активации Слейв-сервера в фале конфигурации необходимо убедиться в наличии следующих настроек:

```

## Process: Replication

[process/Replication]

## default: false

enable=true



## Source name

#source=localhost



## Replication mode: master, slave

## default: slave

#mode=slave



auth=https://master-server.com

server=wss://master-server.com

provider=system

application=replication

oauth2=replication.json

```



Значения в параметрах `auth` и `server` должны соответствовать DNS-имени или IP-адресу Мастер-сервера.



Файл `replication.json` должен располагаться в папке `oauth2` каталога с настройками Слейв-сервера (как правило это `/etc/`).



В этом файле указывается `client_id` и `client_secret` пользователя (OAuth2-клиента) зарегистрированного на Мастер-сервере. Обратите внимание на то, что бы пользователь был также включен в группу `replication` на Мастер-сервере.



Пример файла:



```json

{

  "type": "service_account",

  "issuers": ["accounts.master-server.com"],

  "scopes": ["scope"],

  "client_id": "",

  "client_secret": "",

  "algorithm": "HS256",

  "auth_uri": "/oauth2/authorize",

  "token_uri": "/oauth2/token"

}

```



Режимы репликации

-



Существует три режима репликации:



- Slave;

- Proxy;

- Master.



#### Slave



По умолчанию Слейв-сервер работает в режиме Слейв-Мастер. Это означает, что данные будут передаваться только от Мастер-сервера к Слейв-серверу.



#### Proxy



Прокси-сервер выполняет функции Слейв-сервера но при этом дублирует поступающие в журнал ретрансляции (`replication.relay`) данные в журнал репликации (`replication.log`). Это позволяет другим серверам подключенным к Прокси-серверу получать данные с Мастер-сервера к которому подключен Прокси-сервер.



#### Master



Слейв-сервер можно настроить в режим работы Мастер-Мастер. Для этого нужно указать в параметре `mode` значение `master` и выполнить настройки репликации описанные выше в разделе [Мастер-сервер](#Мастер-сервер). В этом режиме оба сервера будут передавать данные друг другу, но при этом только один из них будет подключен к другому.



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



Можно, конечно, настроить два сервера друг на друга в режиме `slave`, но лучше придерживаться правила при котором только один сервер подключается к другому. При такой схеме можно выстроить распределённую сеть где множество Слейв-сервер (в режиме `master`) будут подключается к одному главному Мастер-серверу.