Manticore Search Manual

返回当前连接 ID。

mysql> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 6               |
+-----------------+
1 row in set (0.00 sec)

返回混合搜索的RRF融合得分。仅在混合查询（使用OPTION fusion_method='rrf'的查询）中可用。默认情况下，结果按hybrid_score() DESC排序。

SELECT id, hybrid_score() FROM t
WHERE match('machine learning') AND knn(vec, 5, (0.1, 0.1, 0.1, 0.1))
OPTION fusion_method='rrf';

返回KNN向量搜索的距离。在包含多个KNN子查询的混合搜索查询中，返回所有子查询中的最小距离。

mysql> select id, knn_dist() from test where knn ( image_vector, 5, (0.286569,-0.031816,0.066684,0.032926) ) and match('white') and id < 10;
+------+------------+
| id   | knn_dist() |
+------+------------+
|    2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec)

返回当前会话中最后一条语句插入或替换的文档的 ID。

相同的值也可以通过 @@session.last_insert_id 变量获得。

mysql> select @@session.last_insert_id;
+--------------------------+
| @@session.last_insert_id |
+--------------------------+
| 11,32                    |
+--------------------------+
1 rows in set
mysql> select LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 25,26,29         |
+------------------+
1 rows in set

返回一个“短”通用标识符，作为 63 位无符号整数，遵循与自动 ID 生成相同的算法。

注意：使用 uuid_short() 会增加用于自动 ID 的计数器，因此请小心使用。虽然你可以在查询中运行 uuid_short()，例如 SELECT uuid_short() FROM ...，但这种方法并不理想，因为它可能在自动生成的 ID 中产生较大的间隔。

mysql> select uuid_short();
+---------------------+
| uuid_short()        |
+---------------------+
| 5839598169280741377 |
+---------------------+
1 row in set (0.00 sec)
mysql> select uuid_short();
+---------------------+
| uuid_short()        |
+---------------------+
| 5839598169280741378 |
+---------------------+
1 row in set (0.00 sec)

备份和恢复

Last modified: March 23, 2026

≫ 保护和压缩表

定期备份您的表对于在系统崩溃、硬件故障或数据损坏/丢失时进行恢复至关重要。强烈建议在升级到新的 Manticore Search 版本或运行 ALTER TABLE 前进行备份。

数据库系统备份有两种独特的方法：逻辑备份和物理备份。这两种方法各有优缺点，具体取决于特定的数据库环境和需求。这里，我们将深入探讨这两种备份类型的区别。

逻辑备份涉及将数据库模式和数据导出为 SQL 语句或数据库特定的数据格式。这种备份形式通常对人类可读，并且可用于在不同系统或数据库引擎上恢复数据库。

逻辑备份的优缺点：

➕ 可移植性： 逻辑备份通常比物理备份更具可移植性，因为它们可以用于在不同硬件或操作系统上恢复数据库。
➕ 灵活性： 逻辑备份允许您选择性地恢复特定的表、索引或其他数据库对象。
➕ 兼容性： 逻辑备份可用于在不同数据库管理系统或版本之间迁移数据，只要目标系统支持导出格式或 SQL 语句。
➖ 备份与恢复速度较慢： 逻辑备份通常比物理备份慢，因为需要数据库引擎将数据转换为 SQL 语句或其他导出格式。
➖ 系统负载增加： 创建逻辑备份可能导致系统负载较高，因为该过程需要更多的 CPU 和内存资源来处理和导出数据。

Manticore Search 支持使用 mysqldump 进行逻辑备份。

物理备份涉及复制构成数据库的原始数据文件和系统文件。这种备份类型本质上是创建数据库在某一时间点的物理状态快照。

物理备份的优缺点：

➕ 速度： 物理备份通常比逻辑备份快，因为它们直接从磁盘复制原始数据文件。
➕ 一致性： 物理备份确保整个数据库的一致性备份，因为所有相关文件都会被一起复制。
➕ 系统负载较低： 与逻辑备份相比，创建物理备份通常对系统负载较小，因为过程不涉及额外的数据处理。
➖ 可移植性： 物理备份通常比逻辑备份的可移植性差，因为它们可能依赖于特定的硬件、操作系统或数据库引擎配置。
➖ 灵活性： 物理备份不允许选择性恢复特定数据库对象，因为备份包含整个数据库的原始文件。
➖ 兼容性： 物理备份不能用于在不同数据库管理系统或版本之间迁移数据，因为原始数据文件在不同平台或软件间可能不兼容。

Manticore Search 提供了用于物理备份的命令行工具 manticore-backup。

总之，逻辑备份提供了更多的灵活性、可移植性和兼容性，但可能较慢且资源消耗较高；物理备份更快、更一致且资源消耗较低，但在可移植性和灵活性方面可能受限。您可以根据具体的数据库环境、硬件和需求选择合适的备份方法。

manticore-backup 工具包含在官方 Manticore Search 安装包中，可自动备份以 RT 模式运行的实例中的表。

如果您遵循了官方安装说明，您应该已经安装了所有内容，无需担心。 否则，manticore-backup 需要 PHP 8.1.10 和特定模块或 manticore-executor，并且您需要确保其中一个可用。

注意，目前 manticore-backup 尚不支持 Windows。

首先，确保您在运行要备份的 Manticore 实例的同一服务器上运行 manticore-backup。

其次，建议以 root 用户运行此工具，以便工具能转移您备份文件的所有权。否则，将生成备份但不进行所有权转移。无论哪种情况，都应确保 manticore-backup 有权访问该 Manticore 实例的数据目录。

manticore-backup 唯一必需的参数是 --backup-dir，用于指定备份的目标位置。如果不提供其他参数，manticore-backup 将：

定位一个使用默认配置运行的 Manticore 实例
在 --backup-dir 目录下创建一个带时间戳的子目录
备份该实例中的所有表

‹›

Example

Example

📋

manticore-backup --config=path/to/manticore.conf --backup-dir=backupdir

‹›

Response

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: all tables
Target dir: /mnt/backup/
Manticore config
  endpoint =  127.0.0.1:9308
Manticore versions:
  manticore: 5.0.2
  columnar: 1.15.4
  secondary: 1.15.4
2022-10-04 17:18:39 [Info] Starting the backup...
2022-10-04 17:18:39 [Info] Backing up config files...
2022-10-04 17:18:39 [Info]   config files - OK
2022-10-04 17:18:39 [Info] Backing up tables...
2022-10-04 17:18:39 [Info]   pq (percolate) [425B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info]   products (rt) [512B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info] Running sync
2022-10-04 17:18:42 [Info]  OK
2022-10-04 17:18:42 [Info] You can find backup here: /mnt/backup/backup-20221004171839
2022-10-04 17:18:42 [Info] Elapsed time: 2.76s
2022-10-04 17:18:42 [Info] Done

要仅备份特定表，请使用 --tables 标志，后跟逗号分隔的表名列表，例如 --tables=tbl1,tbl2。这只备份指定的表，忽略其余表。

‹›

Example

Example

📋

manticore-backup --backup-dir=/mnt/backup/ --tables=products

‹›

Response

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: products
Target dir: /mnt/backup/
Manticore config
  endpoint =  127.0.0.1:9308
Manticore versions:
  manticore: 5.0.3
  columnar: 1.16.1
  secondary: 0.0.0
2022-10-04 17:25:02 [Info] Starting the backup...
2022-10-04 17:25:02 [Info] Backing up config files...
2022-10-04 17:25:02 [Info]   config files - OK
2022-10-04 17:25:02 [Info] Backing up tables...
2022-10-04 17:25:02 [Info]   products (rt) [512B]...
2022-10-04 17:25:02 [Info]    OK
2022-10-04 17:25:02 [Info] Running sync
2022-10-04 17:25:06 [Info]  OK
2022-10-04 17:25:06 [Info] You can find backup here: /mnt/backup/backup-20221004172502
2022-10-04 17:25:06 [Info] Elapsed time: 4.82s
2022-10-04 17:25:06 [Info] Done

参数	描述
`--backup-dir=path`	备份目录路径，备份将在此处存储。该目录必须已经存在。此参数是必需的且没有默认值。每次运行备份时，`manticore-backup` 将在提供的目录中创建一个带有时间戳的子目录（`backup-[datetime]`），并将所有需要的表复制到其中。因此，`--backup-dir` 是所有备份的容器，并且可以安全地多次运行脚本。支持 S3 URL 格式 `s3://bucket/prefix` — 详情请参阅 S3 存储支持。
`--restore[=backup]`	从 `--backup-dir` 恢复。仅 `--restore` 列出可用的备份。`--restore=backup` 将从 `<--backup-dir>/backup` 恢复。适用于本地路径和 S3 URL。
`--force`	在恢复时跳过版本检查，并优雅地恢复备份。
`--disable-telemetry`	如果您想禁用向 Manticore 发送匿名指标，请使用此标志。您也可以使用环境变量 TELEMETRY=0
`--config=/path/to/manticore.conf`	Manticore 配置文件路径。可选。如果未提供，则使用操作系统的默认配置。用于确定与 Manticore 守护进程通信的主机和端口。`manticore-backup` 工具支持动态配置文件。如果配置分散在多个文件中，可多次指定`--config`选项。
`--tables=tbl1,tbl2, ...`	你想备份的表的分号分隔列表。要备份所有表，可省略此参数。所有提供的表必须存在于你要备份的 Manticore 实例中，否则备份会失败。
`--compress`	是否压缩备份文件。默认未启用。
`--unlock`	在极少数情况下，当出现异常时，表可能被锁定。使用此参数解锁它们。
`--version`	显示当前版本。
`--help`	显示此帮助信息。

manticore-backup 支持直接将备份存储到/从 S3 兼容存储中，包括 AWS S3、MinIO、Wasabi、Cloudflare R2 等。只需将 s3://bucket/prefix URL 作为 --backup-dir 传递。

在运行 manticore-backup 之前设置以下环境变量：

变量	必需	描述
`AWS_ACCESS_KEY_ID`	是	AWS 访问密钥（或 `AWS_ACCESS_KEY`）
`AWS_SECRET_ACCESS_KEY`	是	AWS 密钥（或 `AWS_SECRET_KEY`）
`AWS_REGION`	否	AWS 区域（默认：`us-east-1`）
`AWS_ENDPOINT_URL`	否	自定义 S3 兼容端点 — 仅服务器 URL，不包含桶名（例如，`http://localhost:9000`）
`AWS_S3_ENCRYPTION`	否	启用 SSE-S3 服务器端加密（默认：对于 AWS S3 为 `1`；对于 MinIO、R2 或其他自定义端点设为 `0`）

⚠️ AWS_ENDPOINT_URL 不应包含桶名。桶名将从 s3://bucket/prefix 参数中获取。在端点 URL 中包含桶名会导致每次请求中桶名被重复，并导致错误。
# 错误 — 桶 "mybucket" 在 URL 路径中重复
AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com/mybucket

# 正确 — 端点仅为服务器地址
AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com

# Backup to AWS S3 (SSE-S3 encryption enabled by default)
export AWS_ACCESS_KEY_ID=your_key
export AWS_SECRET_ACCESS_KEY=your_secret
manticore-backup --backup-dir=s3://my-bucket/backups
# Restore from S3
manticore-backup --restore --backup-dir=s3://my-bucket/backups
manticore-backup --restore=backup-20221004171839 --backup-dir=s3://my-bucket/backups
# Use with MinIO (disable encryption)
export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=minioadmin
export AWS_ENDPOINT_URL=http://localhost:9000
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups
# Use with Cloudflare R2
export AWS_ACCESS_KEY_ID=your_r2_access_key
export AWS_SECRET_ACCESS_KEY=your_r2_secret_key
export AWS_ENDPOINT_URL=https://<account_id>.r2.cloudflarestorage.com
export AWS_REGION=auto
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups

备份需要 s3:PutObject，恢复需要 s3:GetObject，列出可用的恢复点需要 s3:ListBucket。

你也可以通过运行简单命令 BACKUP TO /path/to/backup 来备份数据。

注意： Windows 不支持 BACKUP。建议改用 mysqldump。

注意： BACKUP 需要 Manticore Buddy。如果不起作用，请确认 Buddy 已安装。

BACKUP
  [{TABLE | TABLES} a[, b]]
  TO path_to_backup
  [{OPTION | OPTIONS}
    async = {on | off | 1 | 0 | true | false | yes | no}
    [, compress = {on | off | 1 | 0 | true | false | yes | no}]
  ]

例如，要备份表 a 和 b 到 /backup 目录，运行以下命令：

BACKUP TABLES a, b TO /backup

备份过程可以通过以下选项进行控制和调整：

async：使备份非阻塞，立即返回备份路径响应，备份进行时可以执行其他查询。默认值为 0。
compress：启用使用 zstd 的文件压缩。默认值为 0。

例如，要以异步模式启用压缩将所有表备份到 /tmp 目录：

BACKUP TO /tmp OPTION async = yes, compress = yes

使用 async = 1（或 yes、on、true）时，备份操作在后台任务中运行：

命令立即返回备份路径
备份进行时可继续执行其他查询
备份任务由 Manticore Buddy 管理的独立线程运行
任务运行期间会出现在 SHOW QUERIES 输出中，完成后自动移除

异步备份示例：

BACKUP TO /tmp/mybackup OPTION async = 1

将立即返回类似下列输出：

+----------------------------------+
| Path                             |
+----------------------------------+
| /tmp/mybackup/backup-20221004... |
+----------------------------------+

你可以使用 SHOW QUERIES 检查备份是否仍在运行。备份完成后任务将从查询列表消失，所有备份文件将存在指定目录。

如果备份路径包含空格，请用单引号括起来，例如 BACKUP TO '/path/with spaces'
不含空格的路径无需引号：BACKUP TO /tmp/backup
支持 Windows 路径：BACKUP TO 'C:\path' 或 BACKUP TO C:\windows\backup
确保 Manticore Buddy 已启动（默认启动）
备份目录必须存在且 Manticore 进程有写权限

为确保备份期间表的一致性，Manticore Search 的备份工具采用创新的 FREEZE 和 UNFREEZE 命令。不同于 MySQL 等传统的锁表功能，FREEZE 停止向磁盘刷新数据，但仍允许对表进行写入（在某种程度上）和选择更新数据。

但如果在涉及大量插入的长时间备份操作中，内存块大小超出 rt_mem_limit 阈值，数据可能被刷新到磁盘，此时写操作将被阻塞直到刷新完成。尽管如此，该工具在表冻结期间在表锁、数据一致性和数据库写入可用性之间保持平衡。

使用 manticore-backup 或 SQL BACKUP 命令时，会执行一次 FREEZE 来冻结所有要备份的表。接着备份过程逐个备份表，成功备份后释放相应表的冻结状态。

如果备份失败或中断，工具会尝试解冻所有表。

要从备份恢复 Manticore 实例，使用带有 --backup-dir 和 --restore 参数的 manticore-backup 命令。例如：manticore-backup --backup-dir=/path/to/backups --restore。如果 --restore 未指定参数，则只会列出 --backup-dir 中的所有备份。

‹›

Example

Example

📋

manticore-backup --backup-dir=/mnt/backup/ --restore

‹›

Response

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file:
Backup dir: /tmp/
Available backups: 3
  backup-20221006144635 (Oct 06 2022 14:46:35)
  backup-20221006145233 (Oct 06 2022 14:52:33)
  backup-20221007104044 (Oct 07 2022 10:40:44)

要启动恢复任务，请运行带有 --restore=backup name 标志的 manticore-backup，其中 backup name 是 --backup-dir 目录下的备份文件夹名称。请注意：

在被恢复的同一主机和端口上，不能有任何 Manticore 实例正在运行。
旧的 manticore.json 文件不得存在。
旧的配置文件不得存在。
旧的数据目录必须存在且为空。

如果所有条件都满足，恢复将继续。该工具会提供提示，所以您不必记住所有细节。避免覆盖已有文件非常重要，因此如果这些文件仍然存在，请先将其删除。因此有以上所有条件要求。

‹›

Example

Example

📋

manticore-backup --backup-dir=/mnt/backup/ --restore=backup-20221007104044

‹›

Response

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file:
Backup dir: /tmp/
2022-10-07 11:17:25 [Info] Starting to restore...
Manticore config
  endpoint =  127.0.0.1:9308
2022-10-07 11:17:25 [Info] Restoring config files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring state files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring data files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] The backup '/tmp/backup-20221007104044' was successfully restored.
2022-10-07 11:17:25 [Info] Elapsed time: 0.02s
2022-10-07 11:17:25 [Info] Done

Manticore 支持 MySQL 的 mysqldump 工具最高到 9.7，以及 MariaDB 的 mariadb-dump 工具最高到 12.3。

注意：某些版本的 mysqldump / mariadb-dump 需要安装 Manticore Buddy。如果转储操作不成功，请确保已安装 Buddy。

要创建 Manticore Search 数据库的备份，可以使用 mysqldump 命令。以下示例中将使用默认端口和主机。

请注意，mysqldump 仅支持实时表。

‹›

Basic
Replace mode
Replication mode

📋

mysqldump -h0 -P9306 manticore > manticore_backup.sql
mariadb-dump -h0 -P9306 manticore > manticore_backup.sql

执行此命令将生成名为 manticore_backup.sql 的备份文件。该文件包含所有数据和表结构。

mysqldump -h0 -P9306 --replace --net-buffer-length=16m -etc manticore tbl > tbl.sql

这将生成一个名为 tbl.sql 的备份文件，其中使用 replace 命令代替 insert，并在每个批次中保留列名。文档将批处理为最大 16 兆字节大小。不会有 drop/create table 命令。这对于更改分词设置后进行全文重建索引非常有用。

mysqldump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0
mariadb-dump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0

在这种情况下，mysqldump 会生成诸如 REPLACE INTO cluster:table ... 的命令，这些命令会直接发送到 Manticore 实例，从而重新插入文档。使用 cluster 用户和 -t 标志以启用复制模式。详细信息见下方注释。

如果您想要从备份文件恢复 Manticore Search 数据库，mysql 客户端是您的首选工具。

请注意，如果您在纯模式下恢复，则不能直接删除并重建表。因此，您应当：

使用带 -t 选项的 mysqldump 以从备份中排除 CREATE TABLE 语句。
在继续恢复之前，手动TRUNCATE表。

‹›

SQL

📋

mysql -h0 -P9306 < manticore_backup.sql
mariadb -h0 -P9306 < manticore_backup.sql

此命令使您能够从 manticore_backup.sql 文件中恢复所有内容。

以下是一些可以与 mysqldump 一起使用以定制备份的更多设置：

-t 跳过 drop/create 表命令。对更改分词设置后进行全文重建索引非常有用。
--no-data：此设置将忽略表数据，只备份表结构。
--ignore-table=[database_name].[table_name]：此选项允许在备份时跳过特定表。注意数据库名称必须为 manticore。
--replace 使用 replace 替代 insert。对更改分词设置后全文重建索引非常有用。
--net-buffer-length=16M 将批处理大小调整为最多 16 兆字节，以加快恢复速度。
-e 用于批处理文档。加速恢复。
-c 保留列名称。在更改表架构（例如字段顺序改变）后重建索引时很有用。

欲了解设置的完整列表及详细说明，请参阅官方的 MySQL 文档或 MariaDB 文档。

创建复制模式的转储（转储包括 INSERT/REPLACE INTO <cluster_name>:<table_name>）时：
- 确保在转储过程中表未被更改。
- 使用 cluster 用户。例如：mysqldump -u cluster ... 或 mariadb-dump -u cluster ...。您可以通过执行 SET GLOBAL cluster_user = new_name 来更改启用复制模式的 mysqldump 用户名。
- 使用 -t 标志。
- 使用 --skip-lock-tables 标志。
- 在复制模式下指定表时，需使用 cluster_name:table_name 语法。例如：mysqldump -P9306 -h0 -t -ucluster manticore cluster:tbl。
建议在计划备份所有数据库时明确指定 manticore 数据库，而不是使用 --all-databases 选项。
注意，mysqldump 不支持备份分布式表，也不能备份包含非存储字段的表。对于这些情况，建议使用 manticore-backup 或者 BACKUP SQL 命令。如果您有分布式表，推荐始终指定要转储的表。

其他函数关于 RT 表结构的简要说明

Last modified: June 10, 2026

可以使用一个称为 indexer 的特殊工具从外部源创建一个普通表，该工具从配置中读取“配方”，连接数据源，拉取文档，并构建表文件。这是一个耗时的过程。如果数据发生变化，表就会过时，需要从更新后的源重新构建。如果数据是增量变化的，例如一个博客或新闻推送，其中旧文档从不变更，只添加新文档，那么重建将花费越来越多的时间，因为每次都需要一次又一次地处理存档源。

解决这个问题的一种方式是使用多个表，而不是一个单一的大表。例如，你可以处理前几年生成的源并保存表。然后，只取当前年的源放入单独的表中，并根据需要频繁重建。然后你可以将这两个表作为分布式表的部分放置并用于查询。关键在于每次重建时，你最多只处理最近12个月的数据，而含有旧数据的表保持不变，无需重建。你还可以更进一步，将最近12个月的数据表拆分为月表、周表或者日表，依此类推。

这种方法是有效的，但你需要手动维护分布式表。也就是说，需要添加新的分片，删除旧的，并保持部分表的总数不宜过多（表数量过多搜索可能变慢，操作系统通常限制同时打开的文件数量）。为应对这一点，你可以通过运行 indexer --merge 手动合并几个表。但这只解决了表太多导致维护困难的问题。即使采用“每小时”重建索引，你仍然很可能在新数据到达源和重建表时间之间存在明显的时间差，而这段时间内数据无法被搜索。

实时表的设计旨在解决该问题。它由两部分组成：

一个特殊的基于内存的表（称为 RAM 分片），包含当前正在到达的数据部分。
一组普通表，称为磁盘分片，是过去构建的。

这与标准的分布式表非常相似，由几个本地表组成。

你不需要通过运行 indexer 构建这样的表，indexer 是读取配置中的“配方”和表数据源。相反，实时表提供了“插入”和“替换”现有文档的能力。执行“插入”命令时，你将新文档推送到服务器。服务器立刻从添加的文档构建一个小表并在线发布。因此，在“插入”命令完成后，你可以对所有表部分（包括刚添加的文档）执行搜索。

搜索服务器自动维护该表，因此你不用担心。但你可能想了解一些“它是如何维护的”细节。

首先，由于索引数据存储在内存中——断电怎么办？我会丢失表么？其实，在完成之前，服务器会将新数据保存到一个特殊的“二进制日志（binlog）”中。它由一个或多个文件组成，这些文件存在于持久存储中，随着越来越多的更改而增大。你可以调节新查询（或事务）存储到 binlog 的频率，以及执行 binlog 文件上的“同步”命令的频率，以强制操作系统将数据安全地写入存储。最保守的方法是每笔事务后都刷新并同步。这是最慢但最安全的方式。最省资源的方法是完全关闭 binlog，这是最快的，但你有丢失索引数据的风险。中间的变种，比如每秒刷新/同步也是支持的。

binlog 是专门为顺序保存新到事务设计的；它不是表，不能被搜索。它仅仅是保险策略，确保服务器不会丢失你的数据。如果突发故障发生，软件或硬件问题导致崩溃，服务器将加载 RAM 分片的最新可用转储文件，然后重放 binlog，重复存储的事务。最终，服务器将达到最后一次更改时的状态。

其次，限制是什么？如果我想处理比如说 10TB 的数据，但内存装不下怎么办！实时表的内存容量是有限的且可配置。当索引到一定数据量时，服务器通过合并小事务管理内存表部分，保持事务数量和总体大小较小。然而，这有时会导致插入延迟。当合并不再改善状况，且新插入达到内存限制时，服务器会将基于内存的表转成存储在磁盘上的普通表（称为磁盘分片）。此表加入 RT 表第二部分的表集合中并上线。内存被刷新，空间被释放。

当内存中的数据安全保存到磁盘时，发生以下情况：

服务器将收集的数据保存为磁盘表
或在干净关机时或通过手动刷新将内存部分转储

该表对应的 binlog 就不再需要，因此被丢弃。如果所有表都已经保存，binlog 将被删除。

第三，磁盘集合呢？ 如果拥有许多磁盘部分会导致搜索变慢，那么我手动以分布式表方式制作它们，或者它们由RT表产生的磁盘部分（或者称作“块”）有什么区别呢？其实这两种情况下，你都可以将几个表合并成一个。例如，你可以合并昨天的按小时划分的多个表，保留一个“昨天的每日”表。手动维护时，你需要自己考虑模式和命令。而使用RT表，服务器提供了OPTIMIZE命令，它做同样的事情，但让你避免了不必要的内部细节。

第四，如果我的“文档”构成一个“迷你表”，且我不再需要它，我可以直接扔掉它。但如果它被“优化”过，也就是说和大量其他文档混合在一起，我怎么撤销或删除它呢？是的，索引文档是“混合”在一起的，没有简单的方法能删除某一个文档而不重建整个表。而对于普通表，重建或合并只是正常的维护方式；对于实时表，这只保持了操作的简便性，但不保证“实时性”。为了解决这个问题，Manticore使用了一个技巧：当你删除一个由文档ID标识的文档时，服务器只是记录该编号。和其他被删除的文档一起，它们的ID被保存到所谓的kill-list中。当你对表执行搜索时，服务器首先检索所有匹配的文档，然后去除在kill-list中出现的文档（这是最基本的描述，实际上内部更为复杂）。关键是——为了实现“即时”删除，文档实际上并没有真正删除，而只是标记为“已删除”。它们仍占据不同表结构中的空间，本质上是垃圾。影响排名的词统计数据也不受影响，这意味着它的工作方式确实如声明：我们在所有文档中搜索，然后仅在最终结果中隐藏标记为已删除的文档。当一个文档被替换时，意味着它在表的旧部分被标记为已删除（杀死），并在最新部分重新插入。“通过killlist隐藏”的所有后果在此情况下同样适用。

当表的某个部分进行重建时，例如，当RAM块的某些事务（段）被合并，或者RAM块被转换成磁盘块，或者两个磁盘块合并时，服务器会对受影响的部分进行全面迭代，并从所有这些部分中物理排除被删除的文档。也就是说，如果它们存在于某些词的文档列表中，就会被清除。如果它是唯一的词，则会完全删除。

总结一下：删除分两个阶段进行：

首先，在实时中将文档标记为“已删除”，并在搜索结果中抑制它们。
在对RT表块执行某些操作时，最终彻底物理删除这些已删除的文档。

第五，如果RT表其集合中包含普通磁盘表，我能否直接将已有的旧磁盘表添加进去？ 不可以。为避免不必要的复杂性和防止意外损坏，这是不允许的。但是，如果你的RT表刚创建且无数据，则可以通过ATTACH TABLE将你的磁盘表附加到它中。你的旧表将被移动到RT表内，并成为其一部分。

关于RT表结构的总结：它是一个巧妙组织的普通磁盘表集合，配有一个快速的内存表，用于实时插入和半实时删除文档。RT表拥有统一的模式、统一的设置，并且可以轻松维护，无需深入细节。

备份和恢复将 RAM 块刷新到新磁盘块

Last modified: August 28, 2025

其他函数

CONNECTION_ID()

HYBRID_SCORE()

KNN_DIST()

LAST_INSERT_ID()

UUID_SHORT()

≫ 保护和压缩表

备份与恢复

逻辑备份

物理备份

使用 manticore-backup 命令行工具

安装

使用方法

参数

S3 存储支持

配置

使用示例

所需的 S3 权限

BACKUP SQL 命令参考

BACKUP 的通用语法

异步备份行为

重要注意事项

备份如何保持表的一致性

使用 manticore-backup 工具恢复

使用 mysqldump 备份和恢复

恢复

额外选项

注释

实时表结构