在多主复制集群中，必须先建立一个参考点，其他节点才能加入并形成集群。这称为集群引导，涉及将单个节点启动为 primary component。单个节点的重启或关闭后的重新连接可以正常进行。
如果是整个集群的完全关闭，应先启动最后停止的服务器，并使用 --new-cluster 命令行选项或通过 systemd 运行 manticore_new_cluster。为了确保服务器能够成为参考点，集群 路径 下的 grastate.dat 文件中，safe_to_bootstrap 选项应更新为值 1。--new-cluster 和 safe_to_bootstrap=1 两个条件都必须满足。如果在未设置这些选项的情况下启动其他节点，会报错。可以使用 --new-cluster-force 命令行选项来强制覆盖此保护，并从另一台服务器启动集群。或者，可以通过 systemd 运行 manticore_new_cluster --force。
如果所有服务器发生严重崩溃或不干净关闭，必须识别出 grastate.dat 文件中集群 路径 下具有最大 seqno 的最先进节点，并使用 --new-cluster-force 命令行选项启动该节点。
当 Manticore 搜索守护进程停止且集群中没有剩余节点可提供服务时，必须进行恢复。由于用于复制的 Galera 库具有多主特性，Manticore 复制集群是一个单一的逻辑实体，它维护其节点和数据的一致性，以及整个集群的状态。这允许在多个节点上同时安全写入，确保集群的完整性。
然而，这也带来了挑战。让我们以由节点 A、B 和 C 组成的集群为例，看看当部分或全部节点不可用时需要做些什么。
当节点 A 停止时，其他节点会收到“正常关闭”消息。集群规模缩小，并进行仲裁数重新计算。
启动节点 A 时，它会加入集群，但在与集群完全同步之前不会处理任何写事务。如果捐赠者节点 B 或 C 上的写集缓存（可通过 Galera 集群的 gcache.size 控制）仍包含节点 A 错过的所有事务，节点 A 将接收一次快速增量状态转移（IST），即仅传输错过的事务。如果没有，将进行快照状态转移（SST），涉及转移表文件。
在节点 A 和 B 都停止的场景下，集群规模减少到 1，由节点 C 形成主要组件处理写事务。
然后，节点 A 和 B 可以照常启动，启动后将加入集群。节点 C 作为捐赠者，为节点 A 和 B 提供状态转移。
所有节点都已关闭，集群处于关闭状态。
现在的问题是如何初始化集群。重要的是，在 searchd 的干净关闭过程中，节点会将最后执行的事务编号写入集群目录中的 grastate.dat 文件，并带有 safe_to_bootstrap 标志。最后停止的节点会有选项 safe_to_bootstrap: 1 和最先进的 seqno 编号。
必须先启动这个节点以形成集群。要启动集群，应该使用 --new-cluster 标志在该节点上启动服务器。在 Linux 上，也可以运行 manticore_new_cluster，它将通过 systemd 以 --new-cluster 模式启动 Manticore。
如果其他节点先启动并自举集群，那么最先进的节点会加入该集群，执行完全 SST 并接收一个缺失部分事务的表文件，这与之前它所拥有的表文件不同。这就是为什么必须先启动最后关闭的节点，它在 grastate.dat 中应有 safe_to_bootstrap: 1 标志。
发生崩溃或网络故障导致节点 A 从集群消失时，节点 B 和 C 会尝试重新连接节点 A。失败后，它们会将节点 A 从集群中移除。由于三节点中的两个仍在运行，集群保持仲裁数，继续正常运行。
当节点 A 重启时，它将自动加入集群，如情况 1所述。
节点 A 和 B 离线。节点 C 无法自行形成仲裁数，因为 1 个节点小于全部 3 个节点的一半。因此，节点 C 上的集群状态变为非主要状态，拒绝任何写事务并显示错误消息。
同时，节点 C 等待其他节点连接并尝试连接它们。如果发生这种情况，网络恢复，节点 A 和 B 重新上线，集群将自动重组。如果节点 A 和 B 只是临时断开与节点 C 的连接，但它们仍能相互通信，则它们将继续正常运行，因为它们仍然形成了仲裁数。
但如果节点 A 和 B 都因断电而崩溃或重启，则必须有人使用以下命令在节点 C 上激活主组件：
- SQL
- JSON
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1POST /cli -d "
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1
"重要的是，在执行该命令之前，必须确认其他节点确实无法访问。否则，可能会发生脑裂，形成分离的集群。
所有节点崩溃。在这种情况下，集群目录中的 grastate.dat 文件未更新，且不包含有效的 seqno 序列号。
如果发生这种情况，需要有人找到数据最新的节点，并使用命令行参数 --new-cluster-force 启动该节点上的服务器。所有其他节点将按正常方式启动，如情况 3所述。
在 Linux 上，也可以使用 manticore_new_cluster --force 命令，通过 systemd 以 --new-cluster-force 模式启动 Manticore。
脑裂可能导致集群转变为非主状态。例如，考虑一个由偶数个节点（四个）组成的集群，比如位于不同数据中心的两对节点。如果网络故障中断了数据中心之间的连接，脑裂就会发生，因为每组节点恰好持有半数仲裁。结果，两组节点都停止处理写事务，因为Galera复制模型优先考虑数据一致性，没有仲裁的集群无法接受写事务。然而，两组中的节点都会尝试与另一组的节点重新连接，以努力恢复集群。
如果有人在网络恢复之前想要恢复集群，应采取案例5中概述的相同步骤，但仅在其中一组节点上执行。
执行该语句后，运行该语句的节点所在组将能够再次处理写事务。
- SQL
- JSON
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1POST /cli -d "
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1
"然而，需要注意的是，如果在两组节点上都执行该语句，将导致形成两个独立的集群，随后的网络恢复也不会使两组重新合并。
使用默认配置，Manticore 正在等待您的连接：
- 为 MySQL 客户端开放端口 9306
- 为 HTTP/HTTPS 连接开放端口 9308
- 为 HTTP/HTTPS 以及来自其他 Manticore 节点和基于 Manticore 二进制 API 的客户端开放端口 9312
- SQL
- HTTP
- PHP
- Python
- Python-asyncio
- Javascript
- Java
- C#
- Rust
- docker
mysql -h0 -P9306HTTP 是无状态协议，因此不需要任何特殊的连接阶段：
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 mysqlManticore Search 通过使用 MySQL 协议实现了 SQL 接口，允许使用任何 MySQL 库或连接器以及许多 MySQL 客户端连接到 Manticore Search，并像使用 MySQL 服务器一样操作它，而非直接操作 Manticore。
然而，SQL 方言有所不同，仅实现了 MySQL 中可用的 SQL 命令或函数的一个子集。此外，还存在 Manticore Search 特有的子句和函数，例如用于全文搜索的 MATCH() 子句。
Manticore Search 不支持服务器端的预准备语句，但可以使用客户端预准备语句。需要注意的是，Manticore 实现了多值（MVA）数据类型，这在 MySQL 或实现预准备语句的库中没有对应类型。在这些情况下，MVA 值必须在原始查询中构造。
部分 MySQL 客户端/连接器需要用户/密码和/或数据库名称的值。由于 Manticore Search 没有数据库概念，也没有实现用户访问控制，这些值可以随意设置，因为 Manticore 会直接忽略它们。
SQL 接口的默认端口是 9306，且默认启用。
你可以在配置文件的 searchd 部分，使用 listen 指令配置 MySQL 端口，格式如下：
searchd {
...
listen = 127.0.0.1:9306:mysql
...
}请记住，Manticore 没有用户认证功能，所以请确保 MySQL 端口不会被网络外的人访问。
可以使用单独的 MySQL 端口执行“VIP”连接。连接到此端口时，将绕过线程池，总是创建一个新的专用线程。这在严重过载的情况下非常有用，避免服务器停滞或阻止通过常规端口的连接。
searchd {
...
listen = 127.0.0.1:9306:mysql
listen = 127.0.0.1:9307:mysql_vip
...
}连接 Manticore 最简单的方法是使用标准的 MySQL 客户端：
mysql -P9306 -h0MySQL 协议支持SSL 加密。可以在同一个 mysql 监听端口上建立安全连接。
MySQL 连接支持压缩，客户默认即可使用。客户端只需指定连接应使用压缩即可。
下面是一个使用 MySQL 客户端的示例：
mysql -P9306 -h0 -C压缩可用于安全连接和非安全连接。
官方 MySQL 连接器可用于连接 Manticore Search ，但可能需要在 DSN 字符串中传递某些设置，因为连接器可能会尝试执行 Manticore 尚未实现的某些 SQL 命令。
JDBC 6.x 及以上版本的连接器要求 Manticore Search 版本为 2.8.2 或更高，且 DSN 字符串应包含以下选项：
jdbc:mysql://IP:PORT/DB/?characterEncoding=utf8&maxAllowedPacket=512000&serverTimezone=XXX默认情况下，Manticore Search 会向连接器报告自己的版本，但这可能导致一些问题。为解决该问题，应在配置文件的 searchd 部分设置 mysql_version_string 指令，将版本设为低于 5.1.1 的版本：
searchd {
...
mysql_version_string = 5.0.37
...
}.NET MySQL 连接器默认使用连接池。为了正确获取 SHOW META 的统计信息，应将查询与 SHOW META 命令作为单个多语句发送（SELECT ...;SHOW META）。如果启用连接池，需在连接字符串中添加选项 Allow Batch=True 以允许多语句：
Server=127.0.0.1;Port=9306;Database=somevalue;Uid=somevalue;Pwd=;Allow Batch=True;可以通过 ODBC 访问 Manticore。建议在 ODBC 字符串中设置 charset=UTF8。部分 ODBC 驱动不喜欢 Manticore 服务器报告的版本，因为它们将其视为非常旧的 MySQL 服务器。该版本信息可通过 mysql_version_string 选项覆盖。
基于 MySQL 的 Manticore SQL 支持 C 风格注释语法。所有从开启符 /* 到关闭符 */ 的内容都会被忽略。注释可以跨多行，不能嵌套，且不应被记录。MySQL 特有的 /*! ... */ 注释目前也被忽略。（注释支持主要是为了更好地兼容 mysqldump 生成的转储文件，而非增强 Manticore 与 MySQL 之间的一般查询互操作性。）
SELECT /*! SQL_CALC_FOUND_ROWS */ col1 FROM table1 WHERE ...