Reshard现有的大型SVN信息库

我们有一个相当大的SVN信息库（50 GB，超过100000个修订版）。使用它非常慢，我的猜测是，这是db/revs和db/revprops中的平面目录结构（其中每个修订是一个文件）。Reshard现有的大型SVN信息库

我们在SVN 1.5上使用FSFS格式（在Linux服务器上），但回购是使用较旧的SVN版本创建的。现在我读了SVN 1.5支持“分片”，并且我明白这个特性将修订版分发到多个目录中，因此单个目录不包含那么多文件。这听起来很有用，但不幸的是，它看起来像这个特性只能用于刚刚用SVN 1.5创建的存储库。

如何将大型现有线性回购转换为分段回购？手册中提到了“fsfs-reshard.py”这个工具，但是这个脚本写着“这个脚本还没有完成，还没准备好用于实时数据，请相信我们。”所以我绝对不想使用它。有其他选择吗？

来源

2010-10-27 kayahr

尽管更改为新的存储库格式可能会有所帮助，可疑的是它会解决性能问题。一旦你尝试过它，我会有兴趣知道它是否有用。 – 2010-10-27 15:41:09

我认为我们已经使用了最新的格式（或者至少1.5版本的最新版本（我们现在还没有使用1.6版本））。如果我没有记错的话，我们已经做了一次“svnadmin升级”以具备新的合并功能。所以这可能是svnadmin升级立即退出而不更改任何内容的原因。看起来像“升级”不升级目录结构。我会尝试一下，如果一个完整的转储/负载帮助。 – kayahr 2010-10-27 16:30:19

最好的方法就像前面提到的dump/load cylcle一样。但你可以试试upgrade。

svnadmin upgrade

制作副本首先尝试升级并测试....（不要错过做备份）。

来源

2010-10-27 15:38:55 khmarbaise

升级步骤非常快，值得一做。对于这种大小的存储库来说，转储/加载周期可能会占用周末的最佳部分，这可能是不切实际的。 – 2010-10-27 15:55:50

升级什么都不做。立即退出并表示已完成，但回购仍处于线性格式。如果转储/加载有帮助，我会尝试。可能需要几个小时。 – kayahr 2010-10-27 16:24:06

转储/装载是诀窍。谢谢。 – kayahr 2010-10-28 07:43:34

请问svnadmin dump和svnadmin load有诀窍吗？ http://subversion.apache.org/faq.html#dumpload

来源

2010-10-27 15:28:19

这工作得很好！对于8000个变更集，花费了大约10分钟，所以不是很长的时间。 – 2011-02-19 11:11:31

你很幸运。最后一次我在我们的服务器上试了一次，整个周末花了60000转！很高兴它的工作。 – 2011-02-21 09:00:05

由于倾倒/恢复过程需要大量的磁盘空间和处理时间，我已经出版（2010年）的fsfs-reshard.py的改进版本，其包括用于颠覆1.6 FSFS格式5的支持： https://github.com/ymartin59/svn-fsfs-reshard

它支持之间开关线性到分片布局，在需要时拆包碎片。由于分片统计计算，您可能会预计打包的修订版本大小选择适当的分片大小。

当然它必须是used with care：在可能的话

一次仓库复制

第一测试过程准备好要恢复的备份
处理时，为防止进入仓库
运行svnadmin verify之前把它住

来源

2015-11-28 08:26:59

Reshard现有的大型SVN信息库

回答

相关问题