昨天 MCM 又提出了一个 SharePoint 问题。
您为 SharePoint 搜索数据库配置了哪种 HA？我从一个非常大的 SharePoint 场管理员那里听说，他们没有搜索数据库的冗余副本，如果丢失，他们会重新填充。问题是，重新抓取他们的 4300 万个项目需要 8周。
我不是 SharePoint 专家，但我猜想如果没有功能齐全的搜索数据库，功能就会退化。8 周听起来合适吗？这似乎慢得惊人。您的经验是什么？
谢谢！
答案1
我使用的系统处理约 1.12 亿个文件。完全抓取大约需要 3 周时间。
我想说这取决于你如何为农场设置爬虫。最好使用多个索引服务器来帮助分散负载。
如果这对您来说很重要，我的最佳建议是将所有数据库放在同一个 HA 集群上。但是，搜索数据库在设计上是需要重新生成的。
功能是否会降低？仅搜索，因为您的查询将仅返回已抓取的数据。内容仍然很好。
答案2
MOSS 搜索数据库的问题在于，它与物理上驻留在场索引服务器文件系统中的索引文件紧密耦合；我相信事务同步精确到毫秒。因此，如果您丢失了搜索数据库，您唯一的选择（除非您有专门的 SharePoint DR 工具）是重建索引并使用新的搜索数据库重新开始，因为您的索引文件将与恢复的数据库不同步并损坏。
最新版本的 Microsoft Data Protection Manager 2007 能够备份搜索索引和数据库，但您必须运行特殊脚本才能启用该功能。我不确定其他供应商的工具是否能够做到这一点，我认为有几种可以，但我记不清了。如果您使用 SQL 备份或 SharePoint 的现成备份/恢复工具，则恢复索引的唯一方法是从头开始重建它。
前面的答案是关于使用多个索引来管理搜索语料库大小的，尽管这确实会给服务器场增加一些额外的开销和复杂性。需要构建一个额外的索引服务器，并且有效地管理用户查询以使其命中正确的索引和/或合并结果可能是一个挑战。
答案3
托管 BDC、搜索、用户配置文件的 SSP DB 的恢复情况非常糟糕，因为部分数据在 SQL Server 中，部分数据在服务器上的文件中。这是一个非常糟糕的架构。如果所有内容都在 SQL Server 中，那么恢复是可行的。但由于搜索索引的一部分在文件系统上，恢复变成了一场噩梦。
实际上，我们已经必须恢复 SSP。为此，我们将内容数据库附加到新服务器场并提取用户配置文件的信息（我们不使用 BDC）。
然后我们通过重新抓取内容重建了搜索索引。这很麻烦，而且意味着搜索恢复的 SLA 很差，但我们认为这是最可靠的解决方案。