3.2. Быстрый старт (адаптивная репликация)
В данном разделе кратко описывается запуск кластера из двух узлов Cook с адаптивной репликацией.
Предупреждение
Для работы кластера в режиме синхронной репликации требуется Ред База Данных версии 5.1 и выше.
Предупреждение
Cook сам управляет процессом RedDatabase, другими словами rdbserver - дочерний процесс cookd. Важно, чтобы любые init-скрипты/сервисы/юниты/службы были отключены, а еще лучше - удалены, во избежание запуска rdbserver без управления cookd.
Предупреждение
Данное руководство не описывает установку в production.
3.2.1. Подготовка к работе
Для начала необходимо:
Подготовить две физические или виртуальные машины, например с IP 192.168.0.1 и 192.168.0.2
Установить Cook любым из способов (см. Инсталляция)
Установить RedDatabase версии не ниже 5.0.0
Установить Consul версии не ниже 1.8. Consul поставляется вместе с архивом Cook
Установить Gobetween версии не ниже 0.8. Gobetween поставляется вместе с архивом Cook
3.2.2. Запуск
Запустим кластер consul из двух узлов:
На 192.168.0.1:
consul agent -server -bootstrap-expect 2 -data-dir=data -client 0.0.0.0 -retry-join=192.168.0.2
На 192.168.0.2:
consul agent -server -data-dir=data -client 0.0.0.0 -retry-join=192.168.0.1
Создадим конфигурацию первого узла кластера в файле cookd.yml на 192.168.0.1:
cluster_name: testcluster
node_name: node1
cook:
listen: 0.0.0.0:5030
advertise: 192.168.0.1:5030
rdb:
listen: 0.0.0.0:3050
advertise: 192.168.0.1:3050
pidfile: /opt/RedDatabase/rdb.pid
home: /opt/RedDatabase
password: masterkey
replication_dir: /replication
init:
cook:
hints:
node1:
sync: True
node2:
sync: True
rdb:
databases:
- database: /data/database.fdb
alias: mydatabase
Здесь /replication - локальный каталог, в нем текущий ведущий узел копит оперативные и архивные журналы репликации, а ведомые - полученные журналы.
Примечание
Не смотря на то что кластер конфигурируется как синхронный, узлы все равно обмениваются асинхронными журналами в момент инициализации.
В init описана начальная кластерная конфигурация. В данном случае указана только база данных и ее alias. В дальнейшем ее можно закомментировать или убрать.
Запустим первый узел:
cookd -c cookd.yml
После запуска узел инициализирует новый кластер.
Создадим конфигурацию второго узла кластера в файле cookd.yml на 192.168.0.2:
cluster_name: testcluster
node_name: node2
cook:
listen: 0.0.0.0:5030
advertise: 192.168.0.2:5030
loggers:
cook: INFO
rdb:
listen: 0.0.0.0:3050
advertise: 192.168.0.2:3050
pidfile: /opt/RedDatabase/rdb.pid
home: /opt/RedDatabase/rdb
password: masterkey
replication_dir: /replication
init:
slave_database_mapping:
mydatabase: /data/database.fdb
Здесь локальная конфигурация практически идентичная, но в init описана локальное расположение БД для инициализации реплики. В дальнейшем секцию init можно закомментировать или убрать.
Также начиная с v0.4.0 можно использовать регулярные выражения, для сопоставления базы данных в кластере с локальным файлом на узле. Псевдоним, для интерпретации, как регулярного выражения при этом обрамляется в /<выражение>/. Результаты группы захвата, можно использовать в качестве имени базы, используя синтаксис str.format() Python 3
init:
slave_database_mapping:
/db-(\d+)/: /data/db-{0}.fdb
Запустим второй узел:
cookd -c cookd.yml
Узел подключится к кластеру, инициализируется, начнет репликацию и синхронизируется с первым.
Статус кластера можно посмотреть с помощью cookctl:
cookctl -c node1.yml status
Cluster:
testcluster
generation 1
locked by node1
Databases:
mydatabase
Nodes:
node1 (master/sync) sync node, API URL http://192.168.0.1:5030, RDB 5.0.0.0 on 3050 and AUX 3060 (192.168.0.1/3050), failover enabled, priority 0
node2 (slave/sync) sync node, API URL http://192.168.0.2:5030, RDB 5.0.0.0 on 3051 and AUX 3060 (192.168.0.2/3050), failover enabled, priority 0
Запустим Gobetween на любом из узлов, используя конфигурацию сгенерированную Cook:
gobetween from-consul localhost:8500 --key=service/testcluster/gobetween --scheme=http -f toml
После этого можно подключаться к кластеру через Gobetween по адресу localhost/3050:mydatabase.