多主复制实战：用Galera搭建Manticore Search高可用集群

多主复制实战：用Galera搭建Manticore Search高可用集群

【免费下载链接】manticoresearchOpen-source search database for full-text, vector, and hybrid search with real-time indexing and SQL.项目地址: https://gitcode.com/gh_mirrors/ma/manticoresearch

Manticore Search 是一款开源搜索数据库，支持全文、向量与混合搜索，并内置了基于 Galera 库的多主复制能力。借助它，你可以用几行 SQL 就把多台服务器组成一个高可用集群：任意节点都能读和写，数据几乎同步，节点故障还能自动剔除和恢复。本文带你从零理解到落地，完整走通 Manticore Search 高可用集群的搭建与运维。

为什么选 Galera 多主复制？

很多搜索引擎的"集群"其实只是分片或主从复制，写流量被限制在单一主节点上。而 Manticore Search 的复制方案由 Galera 库 驱动，带来几个对生产环境至关重要的特性 🎯：

• 真正的多主：随时可对集群中任意节点写入，无需选主；
• 几乎同步复制：无从属延迟，节点崩溃后不丢数据；
• 热备份：节点切换零停机，因为根本没有"故障转移到主"这一步；
• 自动节点配置：新节点加入时自动拉取数据，无需手动备份恢复；
• 自动剔除不可靠节点，并支持基于认证的复制。

💡 复制支持 Linux 和 macOS，覆盖percolate、rt和distributed表；Windows 原生版本暂不支持，可通过 WSL 使用。

完整机制见官方中文手册：设置复制。

开工前：3 个必配的配置项

在配置文件的searchd段落中确认以下三项，否则复制无法启用：

1. data_dir— 数据目录（纯内存模式不支持复制）；
2. listen— 必须有一个带replication类型的端口范围监听器，供集群节点间通信；
3. server_id（可选）— 为每个节点设置唯一值，保证集群表 Auto ID 不冲突。

searchd { listen = 9312 listen = 192.168.1.101:9360-9370:replication data_dir = /var/lib/manticore/ }

如果开启了身份验证，还要给参与复制的用户授予replication权限（如GRANT replication ON 'posts' TO 'repl_user'），细节参见 设置复制。

五分钟上手：4 步搭建高可用集群

假设你已有一个名为pq_title的实时表，三台机器node-a、node-b、node-c都装好了 Manticore Search。

第 1 步：在 node-a 上创建集群

CREATE CLUSTER posts

第 2 步：把本地表加入集群

ALTER CLUSTER posts ADD pq_title

第 3 步：让其余节点加入

在 node-b、node-c 上分别执行（指向任意一个已建集群的节点即可）：

JOIN CLUSTER posts AT 'node-a:9312'

新节点加入时会自动进行状态传输（SST）——由现有节点提供完整数据副本，无需你手动备份。传输过程中可通过cluster_posts_sst_total变量查看 0 到 100 的进度，说明见 复制集群状态。

第 4 步：用集群名:表名的方式写入

INSERT INTO posts:pq_title VALUES ( 3, 'test me' )

这一行会在 node-a 上执行，但数据会几乎同步地出现在所有节点上。读取则更灵活——SELECT * FROM pq_title直接查本地表即可，任何节点返回的结果都一致。

创建、加入集群的完整语法参见：创建复制集群、加入复制集群。

监控集群健康：一条 SHOW STATUS 就够

高可用集群最怕"带病运行"。执行SHOW STATUS可以查看所有集群状态变量，重点盯住这几个：

变量	健康值	含义
cluster_posts_status	primary	集群仲裁存在，可正常读写
cluster_posts_node_state	synced	本节点已完成同步
cluster_posts_size	3	当前在群节点数
cluster_posts_nodes_view	—	本节点实际看到的集群成员

此外还能看到 SST 进度、conf_id（成员变更次数）、last_error等。变量清单的完整解释在 复制集群状态 一节，配合仪表盘可以构建完整的集群监控面板。

节点故障了怎么办？恢复手册

多主复制的精髓在于"把集群当作一个逻辑系统"。按故障场景对号入座即可：

场景 1：单节点崩溃存活节点会短暂保留旧成员列表，随后自动剔除故障节点并重算法定人数，集群继续可写。故障节点重启后自动重新加入——若错过了的事务还在其他节点的复制缓存里，走轻量的增量传输（IST）追赶；否则走重量级的快照传输（SST）全量拉取。

场景 2：所有节点干净关闭（如机房维护）每个节点关闭时会把复制状态写入grastate.dat，其中seqno（事务序号）和safe_to_bootstrap标志决定了谁应该先启动。选seqno最大且safe_to_bootstrap: 1的节点（通常是最后关闭的），用特殊模式拉起它：

searchd --new-cluster

其余节点再正常启动，自动重新加入。systemd 用户可直接用manticore_new_cluster命令。

场景 3：所有节点崩溃grastate.dat的元数据已不可靠，选择数据最新的节点用searchd --new-cluster-force强制引导。

场景 4：仲裁丢失（集群变成 non-primary 拒绝写入）在确认另一侧确实离线后，只在一侧执行：

SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1

⚠️ 切记：绝不能在脑裂的两侧都执行该命令，否则会形成两个永不自动合并的独立集群。

这套恢复决策的完整推演，值得精读 集群恢复 与 重启集群 两篇官方文档。

实践避坑清单

• 一张表只属于一个集群：复制是按表划域的，规划好表与集群的归属关系；
• 写语句必须带集群前缀：漏写posts:前缀会直接报错，这是新手最常见的坑；
• 端口范围别交叉：不同集群的replication监听器端口范围不能重叠，每个集群至少预留两个端口；
• 节点数建议取奇数：3 或 5 个节点的仲裁更稳健，偶数集群在分裂时两侧可能同时失去法定人数；
• 集群生命周期管理：增删节点用ALTER CLUSTER ... UPDATE nodes，退出集群用EXIT CLUSTER，参考 管理复制节点。

写在最后

Manticore Search 用"SQL + Galera"的组合，把过去需要分片框架、自研中间件才能实现的多主高可用，压缩成了几条CREATE CLUSTER/JOIN CLUSTER语句。对于需要实时写入、又不想忍受复制延迟的搜索场景（电商、日志、推荐召回），这套方案值得直接落地。动手时建议从 3 节点起步，配合SHOW STATUS养成日常巡检习惯，高可用集群便能长期稳定运行 🚀

【免费下载链接】manticoresearchOpen-source search database for full-text, vector, and hybrid search with real-time indexing and SQL.项目地址: https://gitcode.com/gh_mirrors/ma/manticoresearch