Создание кластера > Настройка репликации

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

Есть одно исключение при обычном запуске: если кластер уже стал чистым однузловым кластером, например после того, как остальные узлы вышли с помощью EXIT CLUSTER, запустите этот оставшийся узел обычным способом. После корректного завершения работы Manticore восстанавливает такой кластер, состоящий только из него самого, как primary / synced без --new-cluster.

Решение о том, какой узел запустить первым, основывается на файле grastate.dat — небольшом файле состояния репликации, хранящемся в каталоге данных кластера. Наиболее важные поля:

seqno — номер последней известной этому узлу транзакции
safe_to_bootstrap — помечен ли этот узел как безопасный для первого запуска после чистого завершения работы

Пример того, как может выглядеть grastate.dat после чистого завершения работы:

# saved replication state
version: 2.1
uuid:    <cluster-uuid>
seqno:   12345
safe_to_bootstrap: 1

В этом примере:

seqno: 12345 означает, что этот узел знает о транзакциях вплоть до порядкового номера 12345
safe_to_bootstrap: -1 означает, что этот узел помечен как безопасный для первого запуска

Если весь кластер был корректно остановлен, запустите узел, который был остановлен последним. На практике это обычно узел с:

наибольшим значением seqno
safe_to_bootstrap: 1

Запустите этот узел первым. Это укажет Manticore начать новую копию кластера с этого узла. После этого запустите оставшиеся узлы обычным образом, чтобы они могли повторно присоединиться.

Используйте это после чистого полного отключения кластера.

‹›

Bash
Systemd

📋

searchd --new-cluster

Если другой узел будет запущен первым без требуемого состояния чистого завершения работы, запуск будет отклонен для защиты кластера от восстановления из более старой копии.

Если все узлы аварийно завершили работу или были остановлены некорректно, файл grastate.dat может больше не быть надежным для обычного выбора начальной загрузки. В этом случае найдите узел с самыми свежими данными, обычно тот, у которого наибольший seqno, и запустите его с опцией --new-cluster-force. Это отменяет обычную защиту и принудительно запускает кластер с выбранного узла.

Используйте это после аварийного или некорректного полного отключения кластера.

‹›

Bash
Systemd

📋

searchd --new-cluster-force

Восстановление кластера

Last modified: June 30, 2026

Если репликационный узел или весь кластер становится недоступным, правильная процедура восстановления зависит от того, сколько узлов остаются доступными и был ли останов чистым или внезапным.

Репликационный кластер следует рассматривать как одну логическую систему, а не набор независимых серверов. Это обеспечивает многомастерные записи и согласованность данных, но также означает, что вы должны осторожно восстанавливать кворум. В частности, не запускайте команду ручного восстановления, которая восстанавливает записи на сохранившейся стороне, пока не убедитесь, что пропавшие узлы действительно отсутствуют. Эта команда показана далее на этой странице как SET CLUSTER <name> GLOBAL 'pc.bootstrap' = 1. Если запустить её слишком рано, можно создать расщепление мозга и получить два независимых кластера.

Для примеров ниже предполагается кластер с узлами A, B и C, если не указано иначе.

Сначала определите, в какой ситуации вы находитесь:

Есть хотя бы один узел онлайн?
Узел был остановлен чисто или он упал? Чистая остановка означает, что searchd был остановлен нормально и имел время сохранить состояние репликации перед выходом. Падение, потеря питания или kill -9 не являются чистой остановкой.
Сохранившаяся часть кластера ещё имеет кворум? Кворум означает, что достаточно узлов могут видеть друг друга, чтобы безопасно оставаться кластером с возможностью записи.
Если все узлы отключены, какой узел следует запустить первым для восстановления кластера?

Полезные проверки:

SHOW STATUS LIKE 'cluster_<name>_status'
SHOW STATUS LIKE 'cluster_<name>_size'
SHOW STATUS LIKE 'cluster_<name>_node_state'
если все узлы отключены, проверьте grastate.dat, небольшой файл состояния репликации, хранящийся в директории данных кластера. Особенно обратите внимание на seqno и safe_to_bootstrap: при чистой остановке лучший узел для запуска первым обычно тот, с наиболее продвинутым seqno и safe_to_bootstrap: 1. Для полной процедуры bootstrap см. Перезапуск кластера.

Пример того, как grastate.dat может выглядеть после чистой остановки:

# saved replication state
version: 2.1
uuid:    <cluster-uuid>
seqno:   12345
safe_to_bootstrap: 1

В этом примере:

seqno: 12345 означает, что этот узел знает о транзакциях до порядкового номер 12345
safe_to_bootstrap: 1 означает, что этот узел помечен как безопасный для запуска первым

При чистом восстановлении после остановки всех узлов, это обычно тот тип узла, который вы запускаете первым с --new-cluster для восстановления кластера.

После восстановления, дождитесь, пока перезапущенный узел сообщает cluster_<name>_status=primary и cluster_<name>_node_state=synced, прежде чем считать его полностью доступным для записи. Это можно проверить с помощью SHOW STATUS LIKE 'cluster_<name>_status' и SHOW STATUS LIKE 'cluster_<name>_node_state'. В локальных тестах перезапущенные узлы иногда некоторое время находились в состоянии cluster_<name>_node_state=joining и cluster_<name>_status=disconnected перед достижением synced/primary.

Если узел A остановлен нормально, узлы B и C продолжают обслуживать записи. Вы можете подтвердить, что кластер всё ещё здоров на этих узлах с помощью SHOW STATUS LIKE 'cluster_<name>_status' и SHOW STATUS LIKE 'cluster_<name>_size'.

Когда узел A запускается снова, он автоматически присоединяется к кластеру. До завершения синхронизации не отправляйте записи на этот узел. Проверьте SHOW STATUS LIKE 'cluster_<name>_status' и SHOW STATUS LIKE 'cluster_<name>_node_state' и дождитесь primary / synced.

Если узлы-доноры B или C ещё имеют все транзакции, которые узел A пропустил, в своём репликационном кэше, узел A может догнать их с помощью инкрементного переноса состояния (IST). IST означает инкрементный перенос состояния. Это означает, что узел получает только транзакции, которые он пропустил, поэтому восстановление обычно быстрее и легче. В противном случае потребуется перенос состояния через снимок (SST). SST означает перенос состояния через снимок. Это означает копирование файлов таблиц из другого узла вместо простого воспроизведения пропущенных транзакций. SST более тяжелый: обычно он медленнее, перемещает больше данных и может сделать восстановление более разрушительным на больших кластерах.

Если узлы A и B остановлены чисто и узел C остаётся онлайн, узел C может продолжать принимать записи. Проверьте SHOW STATUS LIKE 'cluster_<name>_status' и SHOW STATUS LIKE 'cluster_<name>_size' на узле C, если хотите подтвердить, что он теперь единственный активный узел.

Когда узлы A и B запускаются снова, они автоматически присоединяются и синхронизируются с узлом C. Во время присоединения проверьте SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', и SHOW STATUS LIKE 'cluster_<name>_size'. Дождитесь, пока все узлы показывают primary / synced и ожидаемый размер кластера, прежде чем считать восстановление завершенным.

Если узлы A и B были намеренно удалены из кластера, например с помощью EXIT CLUSTER, и узел C теперь является единственным сохранённым узлом в кластере, узел C также может восстановиться после собственного чистого перезапуска при обычном запуске демона. В этом случае, когда он один, --new-cluster не требуется.

Если все узлы в многонодовом кластере были штатно остановлены, кластер полностью недоступен и его нужно снова запустить особым образом, чтобы один узел мог стать первым запущенным узлом кластера.

При чистой остановке каждый узел записывает свой последний номер транзакции в grastate.dat. Узел, который был остановлен последним, является самым безопасным узлом для запуска первым:

он имеет наиболее продвинутый seqno
он имеет safe_to_bootstrap: 1

Запустите этот узел с --new-cluster. Это указывает Manticore запустить новую копию кластера с этого узла. Если вы запускаете Manticore через systemd в Linux, используйте manticore_new_cluster. Он запускает Manticore в режиме --new-cluster за вас.

После этого запустите остальные узлы нормально и позвольте им присоединиться. Проверьте восстановление с помощью SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', и SHOW STATUS LIKE 'cluster_<name>_size'.

Если вы запустите менее продвинутый узел первым, более продвинутый узел позже присоединится к нему и получит полный SST из более старого состояния, что может отбросить транзакции, которые существовали только на более продвинутом узле. Поэтому узел с safe_to_bootstrap: 1 должен быть вашим первым выбором.

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

Эта процедура создаёт новый кластер. Она отбрасывает старое членство в кластере и историю репликации, а затем копирует таблицы с одного выбранного узла на другие узлы. Не используйте её, пока на каком-либо узле ещё есть исправная копия старого кластера в состоянии primary / synced. В этом случае сохраните исправный кластер и восстановите остальные узлы через JOIN CLUSTER.

Остановите Manticore на каждом узле, который входил в сбойный кластер. Не записывайте данные в локальные таблицы во время этой процедуры.
Сделайте резервную копию всего data_dir на каждом узле. Сохраните копию старого дескриптора кластера, если в нём есть пользовательские path, nodes или options поставщика, которые вам нужны при воссоздании кластера.
Выберите узел, чьи локальные таблицы содержат данные, которые нужно сохранить. Этот узел станет источником для нового кластера. Если позже добавить его таблицы в кластер, таблицы с теми же именами на других узлах будут заменены.
На каждом узле отредактируйте <data_dir>/manticore.json. В верхнеуровневом объекте clusters удалите только запись для сбойного кластера. Например, удалите clusters.posts для кластера с именем posts.

Оставьте объект indexes и каждый каталог таблицы на месте. Не удаляйте и не создавайте таблицы заново.
Запустите Manticore обычным образом на каждом узле. Бывшие таблицы кластера должны теперь отображаться как локальные таблицы. Проверьте таблицы на выбранном исходном узле, прежде чем продолжать. Если они отсутствуют или неполные, остановитесь и восстановите резервную копию.
На выбранном исходном узле создайте кластер. Укажите любые сохранённые path, nodes или параметры поставщика, если они по-прежнему нужны. Если включена аутентификация, добавьте '<replication-user>' AS user в этот оператор и в операторы JOIN CLUSTER ниже. У учётной записи должны совпадать сохранённые данные аутентификации и право replication на каждом узле. См. настройку репликации.
```
CREATE CLUSTER posts
```
На каждом другом узле подключите новый кластер через первый узел:
```
JOIN CLUSTER posts AT 'node-a.example:9312'
```
На выбранном исходном узле присоедините существующие локальные таблицы к новому кластеру:
```
ALTER CLUSTER posts ADD table_a, table_b
```
Дождитесь, пока каждый узел не сообщит cluster_posts_status=primary и cluster_posts_node_state=synced, прежде чем возобновлять запись.

Если узел A исчезает из-за сбоя или сетевой проблемы, узлы B и C сначала попытаются переподключиться к нему. Если это не удается, они удаляют его из кластера, пересчитывают кворум и продолжают работать как основной кластер.

В локальных тестах это удаление узла не было мгновенным: оставшиеся узлы сохраняли старый размер кластера в течение нескольких секунд, прежде чем отбросить отказавший узел и переключиться на меньший основной кластер.

Когда узел A снова запускается, он автоматически присоединяется и наверстывает упущенное так же, как после чистого завершения работы одного узла. Снова используйте SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state' и SHOW STATUS LIKE 'cluster_<name>_size', чтобы подтвердить завершение восстановления.

Если узлы A и B потеряны, и работает только узел C, узел C больше не имеет кворума в трехузловом кластере. Он переключается в состояние non-primary и отклоняет запись.

Ошибка записи явная:

ERROR 1064 (42000): cluster '<name>' is not ready, not primary state (synced)

Если узлы A и B только временно отключены, но все еще могут видеть друг друга, они могут продолжать принимать записи, в то время как узел C остается изолированным. Используйте SHOW STATUS LIKE 'cluster_<name>_status' на каждой стороне, если вам нужно увидеть, какая сторона все еще доступна для записи.

Если узлы A и B действительно аварийно завершили работу, а узел C — единственная сохранившаяся копия, с которой вы хотите продолжать работать, выполните эту команду на узле C, чтобы снова сделать его доступным для записи:

Если вы подтвердили, что другие узлы действительно отключены, выполните:

‹›

SQL
JSON

📋

SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1

Важно:

выполняйте это только после того, как убедитесь, что другие узлы недостижимы
выполняйте это только на стороне, которая должна выжить
после начальной загрузки узел снова может принимать записи, и другие узлы позже смогут к нему повторно присоединиться

Если каждый узел аварийно завершил работу, grastate.dat, как правило, больше не заслуживает доверия для обычного выбора начальной загрузки. В локальных тестах все узлы показывали:

seqno: -1
safe_to_bootstrap: 0

В этой ситуации выберите узел с самыми свежими данными и запустите его с --new-cluster-force. Это заставляет Manticore запустить новую копию кластера с этого узла, даже несмотря на то, что обычные метаданные чистого завершения работы не заслуживают доверия. Если вы запускаете Manticore через systemd в Linux, используйте manticore_new_cluster --force. Он запускает Manticore в режиме --new-cluster-force для вас.

Затем запустите оставшиеся узлы в обычном режиме и позвольте им повторно присоединиться. Проверьте восстановление с помощью SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state' и SHOW STATUS LIKE 'cluster_<name>_size'.

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

Если вам необходимо восстановить запись до устранения проблемы с подключением, выберите только одну сторону разделения и выполните ту же команду восстановления там, чтобы эта сторона снова стала доступной для записи. Перед этим проверьте SHOW STATUS LIKE 'cluster_<name>_status' на обеих сторонах, чтобы знать, какая сторона в настоящее время является неосновной.

Выберите сторону, которая должна остаться доступным для записи кластером, затем выполните:

‹›

SQL
JSON

📋

SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1

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

В локальном тестировании внезапная потеря половины четырехузлового кластера воспроизвела то же поведение non-primary, и та же команда восстановления вернула одну выжившую половину в состояние primary.

Перезапуск кластера Понимание статусов репликации

Last modified: July 14, 2026

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

cluster_%_status - может ли кластер принимать записи
cluster_%_node_state - что делает этот конкретный узел

‹›

SQL

📋

SHOW STATUS LIKE 'cluster_%_status';
SHOW STATUS LIKE 'cluster_%_node_state';

‹›

Response

+----------------------------+-------+
| Counter                    | Value |
+----------------------------+-------+
| cluster_posts_status       | primary |
| cluster_posts_node_state   | synced |
+----------------------------+-------+

primary - нормальная работа, можно читать и записывать
non-primary - потерян кворум, запись заблокирована
disconnected - узел изолирован, пытается переподключиться

synced - нормальная работа
joining - узел присоединяется к кластеру (временно)
donor - помогает другому узлу присоединиться (временно)
closed - узел остановлен
destroyed - узел упал, требуется перезапуск

Что произошло	cluster_%_status	cluster_%_node_state	Что делать
Нормальная работа	`primary`	`synced`	Ничего
Большинство узлов недоступно	`non-primary`	`synced`	Инициализировать заново или ждать
Узел запускается	`disconnected`	`joining` → `synced`	Ждать
Узел упал	varies	`destroyed`	Перезапустить узел
Сетевая изоляция (большинство)	`primary`	`synced`	Продолжать работу как обычно
Сетевая изоляция (меньшинство)	`non-primary`	`synced`	Ждать или инициализировать заново

Когда большинство узлов недоступно и статус показывает non-primary:

‹›

SQL
JSON

📋

-- Check which node has highest sequence number
SHOW STATUS LIKE 'cluster_%_last_committed';
-- Bootstrap the cluster (run on best node only)
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1;

‹›

Response

+----------------------------+-------+
| Counter                    | Value |
+----------------------------+-------+
| cluster_posts_last_committed | 1547 |
+----------------------------+-------+

Восстановление кластера 4️⃣ Подключение к серверу

Last modified: September 01, 2026

Со стандартной конфигурацией, Manticore ожидает ваши подключения на:

порт 9306 для клиентов MySQL
порт 9308 для HTTP/HTTPS подключений
порт 9312 для HTTP/HTTPS, а также подключений от других узлов Manticore и клиентов, основанных на бинарном API Manticore

Если включены аутентификация и авторизация, MySQL-клиенты должны подключаться с именем пользователя и паролем Manticore, а клиенты HTTP/HTTPS должны использовать Basic-аутентификацию или bearer token. Имена пользователей чувствительны к регистру. См. Аутентификация и авторизация для начальной настройки, а также создания или ротации bearer token.

‹›

SQL
HTTP
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust
docker

📋

mysql -h0 -P9306

HTTP — это безсессионный протокол, поэтому не требует специальной фазы подключения:

curl -s "http://localhost:9308/search"

require_once __DIR__ . '/vendor/autoload.php';
$config = ['host'=>'127.0.0.1','port'=>9308];
$client = new \Manticoresearch\Client($config);

import manticoresearch
config = manticoresearch.Configuration(
    host = "http://127.0.0.1:9308"
)
client =  manticoresearch.ApiClient(config)
indexApi = manticoresearch.IndexApi(client)
searchApi = manticoresearch.searchApi(client)
utilsApi = manticoresearch.UtilsApi(client)

import manticoresearch
config = manticoresearch.Configuration(
    host = "http://127.0.0.1:9308"
)
async with manticoresearch.ApiClient(config) as client:
    indexApi = manticoresearch.IndexApi(client)
    searchApi = manticoresearch.searchApi(client)
    utilsApi = manticoresearch.UtilsApi(client)

var Manticoresearch = require('manticoresearch');
var client= new Manticoresearch.ApiClient()
client.basePath="http://127.0.0.1:9308";
indexApi = new Manticoresearch.IndexApi(client);
searchApi = new Manticoresearch.SearchApi(client);
utilsApi = new Manticoresearch.UtilsApi(client);

import com.manticoresearch.client.ApiClient;
import com.manticoresearch.client.ApiException;
import com.manticoresearch.client.Configuration;
import com.manticoresearch.client.model.*;
import com.manticoresearch.client.api.IndexApi;
import com.manticoresearch.client.api.UtilsApi;
import com.manticoresearch.client.api.SearchApi;
ApiClient client = Configuration.getDefaultApiClient();
client.setBasePath("http://127.0.0.1:9308");
IndexApi indexApi = new IndexApi(client);
SearchApi searchApi = new UtilsApi(client);
UtilsApi utilsApi = new UtilsApi(client);

using ManticoreSearch.Client;
using ManticoreSearch.Api;
using ManticoreSearch.Model;
string basePath = "http://127.0.0.1:9308";
IndexApi indexApi = new IndexApi(basePath);
SearchApi searchApi = new UtilsApi(basePath);
UtilsApi utilsApi = new UtilsApi(basePath);

use std::sync::Arc;
use manticoresearch::{
    apis::{
        {configuration::Configuration,IndexApi,IndexApiClient,SearchApi,SearchApiClient,UtilsApi,UtilsApiClient}
    },
};
async fn maticore_connect {
    let configuration = Configuration {
        base_path: "http://127.0.0.1:9308".to_owned(),
        ..Default::default(),
    };
    let api_config = Arc::new(configuration);
    let utils_api = UtilsApiClient::new(api_config.clone());
    let index_api = IndexApiClient::new(api_config.clone());
    let search_api = SearchApiClient::new(api_config.clone());

Запустите контейнер Manticore и используйте встроенный клиент MySQL для подключения к узлу.

docker run --name manticore -d manticoresearch/manticore && docker exec -it manticore mysql

Понимание статусов репликации Протокол MySQL

Last modified: June 16, 2026

Перезапуск кластера

Восстановление кластера

Прежде чем восстанавливать что-либо

Один узел был остановлен чисто

Два узла были остановлены чисто и один узел остался онлайн

Все узлы были остановлены чисто

Воссоздание кластера из существующих локальных таблиц

Один узел упал или стал недоступным

Два узла потеряны, и работает только один узел

Все узлы аварийно завершили работу

Кластер с четным числом узлов потерял кворум, например, после разделения

Понимание статуса кластера и состояний узлов

Краткая справка

Значения статусов

cluster_%_status

cluster_%_node_state

Типичные сценарии

Восстановление после потери кворума

Подключение к серверу