Введение в репликацию для перколяторных индексов

Опубликовано: Jun 11, 2019
Автоперевод: Introduction to replication for percolate indexes

С версии 2.8.2 доступна новая основная функция - репликация для перколяторных индексов.

Репликация основана на библиотеке Galera (также используется в форке MySQL от Percona и MariaDB). Мы считали, что будет лучше использовать проверенное решение, чем изобретать велосипед и строить его с нуля, что заняло бы гораздо больше времени.

Почему только для перколяторных индексов? Перколяторный индекс - это модифицированный индекс реального времени, который легче манипулировать и, таким образом, он является лучшим кандидатом для первоначального тестирования. Но оставайтесь с нами, так как следующим шагом будет добавление поддержки индексов реального времени для репликации!

Как это влияет на меня, если я не хочу использовать репликацию? Функция репликации встроена в официальные пакеты, но если вы не планируете ее использовать, ничего не должно мешать вам обновиться до последней версии Manticore. Если вы компилируете Manticore самостоятельно, требования для компиляции изменились. Ознакомьтесь с документацией для получения информации об изменениях.
Репликационные кластеры основаны на индексах. Как только кластер определён, вы можете добавить перколяторные индексы к нему.
Репликация является многомастной и синхронной. Это означает, что вы можете записывать данные на любой узел, и изменения сразу же распространятся на все узлы в кластере.

Настройка репликации

Требования:

- Порт API listen должен быть открыт на выделенном интерфейсе (не 0.0.0.0).
  - Диапазон портов, открытых на выделенном интерфейсе, используемом для репликации. Рекомендуется использовать как минимум 2 порта на кластер.
  - Открытый порт SphinxQL для выполнения команд по настройке узла.
  - data_dir должен быть указан в конфигурации searchd. Это необходимо для временных данных репликации.

Дополнительно:

server_id - уникальный номер для каждого узла, используемый для генерации UUID, если отсутствует, демон сгенерирует его на основе MAC-адреса.

Конфигурация searchd должна выглядеть следующим образом:

searchd {
listen = 9306:mysql41
listen = my_ip1:9312
listen = my_ip1:9350-9459:replication
...
data_dir = /var/lib/manticore/data_dir
server_id = 1
...
}

На первом узле мы подключаемся к нему, используя SphinxQL, и создаем кластер:

mysql> CREATE CLUSTER test;

В качестве альтернативы вы также можете указать узлы, которые собираются подключиться к новому кластеру. Кроме IP, нам также нужно указать порт API.

mysql> CREATE CLUSTER test  'my_ip1:9312,my_ip2:9312,my_ip3:9312' as nodes;

Определенный список узлов используется в случае перезапуска кластера. Если узлы не определены при создании или добавлены дополнительные узлы, необходимо выполнить команду ALTER CLUSTER cluster_name UPDATE nodes для обновления списка всех активных узлов, в противном случае в случае перезапуска узлы, отсутствующие в списке, необходимо будет вручную добавить обратно в кластер.

Далее мы подключаемся к другим узлам и присоединяем их к кластеру, связывая их с существующим узлом (используя его IP и порт API):

mysql> JOIN CLUSTER test AT 'my_ip1:9312';

На данный момент мы определили кластер, и следующий шаг - добавить индекс (или несколько) к нему. Это можно сделать с любого узла:

mysql> ALTER CLUSTER test ADD pq1;

Чтобы добавить новые сохраняемые запросы к индексу pq1, наш обычный запрос INSERT нуждается в небольшом изменении: требуется префиксировать имя индекса именем кластера:

mysql> INSERT INTO test:pq1 VALUES('samsung');

Префикс кластера требуется только для операторов записи (INSERT, REPLACE, DELETE, TRUNCATE). Операторы чтения (CALL PQ, SELECT и DESCRIBE) могут использовать обычное имя индекса.

Что дальше?

Для получения дополнительной информации обо всех параметрах репликации смотрите документацию .

В наших онлайн-курсах вы можете найти курс введения в репликацию и простой курс восстановления после сбоя .

На момент написания этой статьи репликация для индексов реального времени находится в разработке.