我已经构建了一个应用程序作为我的 UG 论文的一部分，它使用 mysql 数据库（社区版）。现在，我的教授希望我为数据库提供容错能力（通过奇偶校验！！）！我争辩说我们不需要那个。无论如何，我搜索了一下，发现这里mysql 具有内置的复制引擎（一种提供容错的机制，对吧？），以及许多其他提供可靠性的技术。但是我从那里学到的是，有一个主服务器和一些从服务器使用复制来提供容错。现在我的问题是：
如果我只有一台数据库服务器怎么办？mysql 是否对单个独立数据库服务器有任何容错能力（即没有主从结构，没有集群等）？
我是否需要尝试为存储在 mysql 数据库中的数据提供任何类型的容错？
社区版和企业版 mysql 服务器之间有什么区别（仅在容错方面）？
不知何故，我觉得我们不需要做任何事情来为 mysql db 提供容错，它本身就很好。但我需要一些关于这件事的可靠信息。
赏金编辑：
再次来自上面的第二个问题：
我是否需要尝试为存储在 mysql 数据库中的数据提供任何类型的容错？
尝试通过使用奇偶校验（每字节位）为 mysql 数据库提供容错的明智之处是什么？
关于数据库中数据的一些细节：
具体来说，数据是大约 6500 个 Unicode 字符串的集合，大小小于 1 MB，是初始化数据，永远不会随着时间而改变。唯一的事务将是从数据库中读取数据，不更新不删除。我的应用程序需要对这些字符串进行全文搜索，这是我使用 mysql 的唯一原因，因为它提供了全文搜索。我知道我可以通过使用 elasticsearch 之类的东西来避免 mysql 的 FT 搜索。
“奇偶校验”检查只能发现故障，因此它不是容错的。
许多人认为主要故障点是磁盘子系统，因此他们使用 RAID。在这种情况下，您可以假设奇偶校验可用于修复 - 但只是因为有一些其他机制可以说“此驱动器发生故障”。
但是如果主板死了怎么办？
所以你使用复制和主从，两台服务器并排放置。
但是，如果建筑物的电源发生故障怎么办？还是龙卷风袭击了两台服务器？或者 ...
所以你把 Slave 放在另一个数据中心。
（我可以继续这个愚蠢的故事，但我不会。）
您可以将 MySQL 的两个“实例”放在同一台服务器上，然后将一个复制到另一个。然后对您的解决方案有多棒进行大量讨论。（没关系，实际上任何失败都会取出两个副本。）
或者你可以花几块钱租用亚马逊的空间给另一台服务器。然后，您可以诚实地吹嘘“容错”。
赏金之后
使用引擎=InnoDB；这使您可以更轻松地从服务器崩溃中恢复。
加载数据后，获取
mysqldump静态表的转储（或其他），并将其存储在其他地方。这是为了从洪水、陨石、软件故障、磁盘故障等中进行“灾难恢复”。重新加载将是手动的并且需要一些时间（但您没有对此进行限制）。这些都是简单的措施，可以有效地涵盖几乎所有的灾难。如果我要列出 mysql 设置可能出错的其他事情，“奇偶校验”不会显示为任何解决方案的一部分。
要完成您的任务，请使用 RAID-5 设置您的磁盘。最少三个驱动器。您可能会使用软件 raid 和单个驱动器的分区来伪造它。但是，这对于从任何类型的故障中恢复都毫无用处；相反，它会显示“平价”的使用。
“校验和”更常用于捕获（但不纠正）错误。对于 512-16KB 字节的数据，这通常是 4-8 字节的开销。从技术上讲，这不是“平价”，但它更有效。
每个字节一个奇偶校验位提供错误检测，但不提供错误纠正。见
SECDED更正。例如，这需要 64 位“字”上的 8 位。Seymour Cray 说“农民平等”，但最终他在“核心”记忆中实施了 SECDED。（这是在 70 年代。你的教授可以追溯到那么远吗？）可以让 DBMS 处理故障检测和恢复（如果配置正确）。在应用程序中手动实现这种行为是最不寻常的。实际上，这就是软件堆栈的用途——从应用程序中删除那些常见且经常需要的功能，就像操作系统负责内存管理和线程调度一样。
也就是说，您可以向每个包含字符串的表添加另一列。它将保存字符串的哈希值。检索哈希和字符串，如果两个哈希不同，则重新计算并抛出错误。
鉴于这是一篇大学论文，教授可能试图传达一个学习点，除了关于实施的任何实用性。您的长期利益可能是调查他的建议的可能实施，而不是列出他是个白痴的原因。只是在说'。
这里有几件事。如果你想保证数据的完整性，你可以使用一个内置了这种东西的引擎。MySQL 的默认引擎 InnoDB 计算每个页面的校验和（通常是 16K 的数据），如果校验和失败（在大多数情况下，由于硬件问题；但它本身可能是一个错误，或者某人手动篡改文件）。
此外，在发生崩溃时，InnoDB 使用事务日志来恢复由于内存缓冲而可能无法完全同步到磁盘的丢失事务。
校验和保证数据的物理一致性，但不允许从中恢复；并且它们不能防止其他问题，例如逻辑错误或意外删除。
复制设置允许服务冗余（甚至地理冗余），以及某些数据冗余以防止由于硬件导致的数据丢失。但是，由于复制几乎是实时的，因此它不能防止意外删除用户等情况。此外，虽然在最新版本中复制具有在线数据的校验和，但这很少成为问题。但是，mysql 从属服务器存在一个相对常见的问题——由于不安全/不确定的查询（可能在两个不同的服务器上返回不同结果的查询）、不同的配置或潜在的风险操作（例如不正确的过滤），可能会出现复制错误。有第三方工具，例如pt-table-checksum允许在写入数据时比较两个副本（并且还提供用户级校验和）。
虽然像延迟从站这样的东西可能有助于避免这些问题，但确保数据生存性的最常见方法是执行定期备份。特别是，完整备份和二进制日志允许时间点恢复，并且您可以添加校验和以验证数据在存储时没有损坏。逻辑备份比大型数据集的行备份慢，但如果要避免物理完整性，则更安全。
直接回答你的问题：