3.1. Быстрый старт (асинхронная репликация)
В данном разделе кратко описывается запуск кластера из двух узлов Cook.
Предупреждение
Cook сам управляет процессом RedDatabase, другими словами rdbserver - дочерний процесс cookd. Важно, чтобы любые init-скрипты/сервисы/юниты/службы были отключены, а еще лучше - удалены, во избежание запуска rdbserver без управления cookd.
Предупреждение
Данное руководство не описывает установку в production.
3.1.1. Подготовка к работе
Для начала необходимо:
Подготовить две физические или виртуальные машины, например с IP 192.168.0.1 и 192.168.0.2
Установить Cook любым из способов (см. Инсталляция)
Установить RedDatabase версии не ниже 3.0.8
Установить Consul версии не ниже 1.8. Consul поставляется вместе с архивом Cook
Установить Gobetween версии не ниже 0.8. Gobetween поставляется вместе с архивом Cook
Настроить общий ресурс для передачи логов или архивов (например SMB или NFS). Данный ресурс должен гарантировать fsync, например быть смонтирован, как WRITETHROUGH (smb)
Предупреждение
При разворачивании кластера в облаке и в целом внутри гипервизоров, нужно учитывать квоты, предоставляемые виртуальным машинам кластера. Для обеспечения максимальной производительности должны быть выделены отдельные хосты или установлены максимальные квоты виртуальным машинам кластера.
3.1.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
Создадим конфигурацию первого узла кластера в файле /etc/cook/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: /shared_dir/replication
slave_log_directory: /local_dir/slave_logs
init:
rdb:
databases:
- database: /data/database.fdb
alias: mydatabase
shared_replication_dir: True
Здесь /shared_dir/replication - общий ресурс, а /local_dir/slave_logs - локальный каталог.
Опция shared_replication_dir должна быть установлена в True, чтобы каталог репликации, расценивался, как общий между узлами.
В init описана начальная кластерная конфигурация. В данном случае указана только база данных и ее alias. В дальнейшем ее можно закомментировать или убрать.
Чтобы cook имел возможность записи в каталог /opt/RedDatabase, нужно вручную исправить права на каталоги и файлы или выполнить:
cookctl fixpermissions reddatabase reddatabase
Запустим первый узел:
systemctl start cookd
После того как кластер и узел инициализируются в логе будет следующее сообщение:
[node1] INFO:2022-04-21 11:19:57,666 - cook.mind:437 - Processing locked cluster as master. Lock owned by node1
Создадим конфигурацию /etc/cook/cookd.yml следующего узла node2 на 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
password: masterkey
replication_dir: /shared_dir/replication
slave_log_directory: /local_dir/slave_logs
init:
slave_database_mapping:
mydatabase: /local_dir/data/database.fdb
Здесь локальная конфигурация практически идентичная, но в init описана локальное расположение БД для инициализации slave. В дальнейшем секцию init можно закомментировать или убрать.
Также начиная с c можно использовать регулярные выражения, для сопоставления базы данных в кластере с локальным файлом на узле. Псевдоним, для интерпретации, как регулярного выражения при этом обрамляется в /<выражение>/. Результаты группы захвата, можно использовать в качестве имени базы, используя синтаксис str.format() Python 3
init:
slave_database_mapping:
/db-(\d+)/: /databases/db/db-{0}.fdb
Чтобы cook имел возможность записи в каталог /opt/RedDatabase, нужно вручную исправить права на каталоги и файлы или выполнить:
cookctl fixpermissions reddatabase reddatabase
Запустим второй узел:
systemctl start cookd
После того как узел подключится к кластеру и инициализируются в логе будет следующее сообщение:
[node2] INFO:2022-04-21 11:23:57,127 - cook.mind:437 - Processing locked cluster as slave. Lock owned by node1
После этого архивы репликации, созданные на node1, по мере поступления будут применяться на node2.
Статус кластера можно посмотреть с помощью cookctl:
cookctl status
testcluster (9682539a-5a36-4828-ac32-2e0b88ece6e1, 0.2.0) generation 1 (3e033d00-5aae-4bd2-bfc5-eaf0e388dd7e), locked by node1
node1 (master) API URL http://192.168.0.1:5030, RDB 3.0.8.0 on 3050 and AUX 3060 (192.168.0.1/3050), failover enabled
/local_dir/data/database.fdb (mydatabase, 68825f33-f8ff-4cf0-94c1-023bd5d1ac8a) 1:1 192.168.0.1/3050:mydatabase
node2 (slave) API URL http://192.168.0.2:5031, RDB 3.0.8.0 on 3050 and AUX 3060 (192.168.0.2/3050), failover enabled
/local_dir/data/database.fdb (mydatabase, 68825f33-f8ff-4cf0-94c1-023bd5d1ac8a) 1:1 192.168.0.2/3050:mydatabase
Запустим Gobetween на любом из узлов, используя конфигурацию сгенерированную Cook:
gobetween from-consul localhost:8500 --key=service/testcluster/gobetween --scheme=http -f toml
После этого можно подключаться к кластеру через Gobetween по адресу localhost/3050:mydatabase.