☰

升级 Cyrus 并拆分邮箱

tag-icon • tag-icon migration mailbox cyrus
升级 Cyrus 并拆分邮箱

我正在尝试将 Cyrus IMAP 服务器从 2.2.12 升级到 2.4.12/13。

现在我正在寻找一个好的指南来做这件事，因为我的实际版本是旧版本。我猜这不仅仅是升级版本或安装新版本并导入配置，我错了吗？我想我需要迁移数据库信息，但不知道该怎么做。

我们的主要和唯一的 Cyrus 服务器管理着 10000 多个用户及其相应的邮箱。通过新的迁移，我们希望将此主服务器拆分为较小的服务器，以按客户端拆分邮箱。我如何从 Cyrus 2.2.12 中导出几个邮箱？我想有选择地导出邮箱。

我找到了“Mailsync”工具，但它似乎不能选择邮箱。有什么方法可以正确迁移到新版本的 Cyrus？

答案1

（大约八年前，我将 50,000 多个用户帐户从旧邮件服务器（运行 uw-imapd）迁移到由三台服务器和运行 Cyrus 的新服务器“场”。当时，我使用我的 l337 Perl 技能创建了一个迁移脚本，该脚本将登录到旧服务器并通过 IMAP 将邮件一次一个用户帐户复制到新服务器。OpenLDAP 服务器 +Perdition位于此服务器前面，决定应将用户转发到何处（旧服务器或新服务器）。该操作在线完成，没有任何停机时间。这有点偏离主题，所以我会继续回复。）

提醒一句：您要做的工作可能有点繁琐，而且输入一个足够简短的回复也不容易。:-) 这里有一些要点供您考虑。

您还有一些工作要做。升级 Cyrus 本身并非不可能，但同时将用户从一台服务器拆分到多台服务器需要规划。仅仅将所有内容从旧服务器复制到新服务器是行不通的，因为 BerkeleyDB/skiplist 格式在中间发生了变化，旧数据文件无法立即使用。

对于用户/邮箱列表，最好使用ctl_mboxlist -dswitch 将旧服务器上的用户/邮箱信息转储到文本文件，然后ctl_mboxlist -u将内容加载到新服务器。如果您只升级 Cyrus 并同时移动到更强大但只有单个服务器，则情况就是这样。可以使用rsync，然后reconstruct -rfx user/*在 Cyrus 中使用命令复制邮箱。

如果您想同时进行拆分，您可能想尝试一下 ifxfermailbox命令cyradm现在是否真的允许您将邮箱从一台服务器移动到另一台服务器。如果可以，您只需创建一个脚本，该脚本调用xfermailbox10,000 次并将您的用户帐户移动到您想要的任何位置。

reconstruct -rfx user/someaccount另一个提示：如果您发现迁移后某些用户找不到邮件文件夹/邮件，则可能需要命令。

到目前为止一切都很好，但是你考虑过以下问题吗：

  • 如果您要将用户分散到多个服务器，您是否有类似的措施Perdition或Cyrus Murder负责将 POP/IMAP 登录重定向到正确的邮件服务器？
  • 如果拆分，您是否有 OpenLDAP 或其他集中式身份验证/用户管理？
  • 如果拆分，您是否已配置 Postfix 或任何 SMTP 服务器来确定用户帐户的实际位置？
  • 您目前有性能问题吗？10,000 个用户帐户并不是很多，除非您确实有将用户帐户分散到多个服务器的严重原因，否则您应该仔细考虑这一点。某种集中式存储 + 两个配置为主动/被动故障转移模式的半强大服务器可能在系统管理方面更明智、更简单。当然，拥有多个带有本地磁盘的小型服务器可能有助于分散 I/O 负载，但如果您给它足够的 RAM，Cyrus 会说“谢谢”，并且 I/O 应该不是真正的问题。
  • 如果您决定将负载分散到多台服务器是因为性能问题，请仔细检查您的 Cyrus 是否使用 BerkeleyDB 或 Skiplist 等mailboxes.db。未经良好调整的 BerkeleyDBDB_CONFIG可能很容易降低性能和/或导致死锁。Skiplist 更省心。此外，Cyrus 中的 POP3 实现非常耗费熵，如果您的服务器没有基于硬件的随机数生成器，则在没有守护程序的情况下登录可能会非常慢rngd，或者 Cyrus 配置为使用/dev/urandom而不是/dev/random随机性。

我希望这对你有点帮助。

答案2

你给了我很好的线索。

无论如何，我会回答我应该考虑的想法：

  • 我们有Perdition，但我们正在考虑保留Perdition或者改用nginx。
  • 我们有 LDAP
  • 现在我对此还不确定，我应该检查并调查
  • 如今，我们不再有性能问题，但我们正在成长，越来越多的客户正在使用我们的系统。我们认为，按客户或客户组进行拆分可能是一个不错的选择。从系统管理员的角度来看，这可能是一项繁琐的工作，但对业务和 SLA 来说可能是件好事。任何其他选择都会受到欢迎 :)
  • 正如我之前评论的那样，我们没有性能问题，无论如何我们都在使用 BerkeleyDB

无论如何，现在我正在制定一个计划，计划我们应该做些什么才能成功迁移，所以我无法尝试你提供给我的命令。

我检查完之后会再回来。

多谢！

相关内容