基准测试通过模拟真实世界的故障场景并测量系统响应来评估数据库的容错能力。这个过程涉及故意引入故障——例如节点崩溃、网络分区或磁盘故障——同时监控恢复时间、数据一致性和系统可用性等指标。例如，基准测试可以模拟服务器宕机，测试数据库是否能继续使用副本来提供服务，或者在故障节点恢复后多快能恢复全部功能。这些测试揭示了冗余机制、故障转移过程和数据复制策略在压力下是否按设计工作。
容错基准测试的关键指标包括恢复时间目标（RTO），它衡量系统恢复的速度；以及恢复点目标（RPO），它决定了数据丢失的可承受程度。例如，像 Apache Cassandra 这样的分布式数据库可能会测试其在节点故障发生时能否保持可用性不低于 99.9%。Chaos Monkey（用于注入故障）或 Jepsen（用于测试分布式系统）等工具可以自动化这些场景。开发人员还会监控网络分裂期间的写入延迟，以评估数据库在分区期间是优先考虑一致性还是可用性。这些基准测试验证了当组件发生故障时，自动故障转移或基于仲裁的写入等功能是否正常工作。
基准测试还突出了容错能力和性能之间的权衡。例如，同步复制确保故障转移期间零数据丢失，但会增加写入延迟；而异步复制则提高了速度，代价是可能丢失数据。与异步配置相比，配置了同步提交的 PostgreSQL 集群在基准测试期间可能会显示更高的延迟。类似地，MongoDB 副本集中的自动故障转移机制减少了停机时间，但需要仔细调整以避免“脑裂”场景。通过量化这些权衡，基准测试可以帮助开发人员选择符合其应用程序需求的配置——例如，对关键系统优先考虑低 RTO，或在非关键工作负载中为了性能提升接受更高的 RPO。