返回当前连接 ID。

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

返回 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)

定期备份您的表对于在系统崩溃、硬件故障或数据损坏/丢失时进行恢复至关重要。强烈建议在升级到新的 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-extra 包的一部分，您需要确保其中之一可用。

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

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

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

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

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

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

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 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 检查备份是否仍在运行。备份完成后任务将从查询列表消失，所有备份文件将存在指定目录。

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

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

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

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

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

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

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)

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

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.6 版本）和来自 MariaDB 的 mariadb-dump 工具（最高到 12.1 版本）。

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

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

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

mysql -h0 -P9306 < manticore_backup.sql
mariadb -h0 -P9306 < 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 命令。如果您有分布式表，推荐始终指定要转储的表。

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

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

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

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

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

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

你不需要通过运行 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块被转换成磁盘块，或者两个磁盘块合并时，服务器会对受影响的部分进行全面迭代，并从所有这些部分中物理排除被删除的文档。也就是说，如果它们存在于某些词的文档列表中，就会被清除。如果它是唯一的词，则会完全删除。

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

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

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

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