定期备份您的表对于在系统崩溃、硬件故障或数据损坏/丢失时进行恢复至关重要。强烈建议在升级到新的 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 来备份数据。

注意：BACKUP 不支持 Windows。请考虑使用 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 会停止将数据刷新到磁盘，同时仍允许一定程度的写入和从表中选择更新的数据。

然而，如果在涉及大量插入的长时间备份操作中，您的 RAM 块大小超过了 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（最高 9.5 版本）的 mysqldump 工具和来自 MariaDB（最高 12.1 版本）的 mariadb-dump 工具。

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 的数据，但它根本放不下内存怎么办！实时表的内存是有限的，可以配置。当索引到一定量的数据时，服务器通过合并小事务来管理内存部分，保持它们的数量和总体大小较小。但这个过程有时会导致插入时延迟。当合并不再有效，且新插入达到内存限制时，服务器会将基于内存的表转换为存储在磁盘上的普通表（称为磁盘分片）。该表被添加到实时表第二部分的表集合中，并可在线访问。然后内存被刷新，空间被释放。

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

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

该表的 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表具有统一的模式、统一的设置，并且可以轻松维护，无需深入细节。