为什么RabbitMQ会继续破坏损坏的持久性日志文件？

Question

我在 Django 应用中运行 Celery ，其中 RabbitMQ 作为消息代理。然而，RabbitMQ一直在崩溃。首先是我从Django得到的错误。跟踪大多不重要，因为我知道导致错误的是什么，正如您将看到的那样。

Traceback (most recent call last):

  ...

  File "/usr/local/lib/python2.6/dist-packages/amqplib/client_0_8/transport.py", line 85, in __init__
    raise socket.error, msg

error: [Errno 111] Connection refused

我知道这是因为 rabbit_persister.log 文件已损坏。这是因为在我杀死与RabbitMQ绑定的所有进程后，我运行“sudo rabbitmq-server start”以获得以下崩溃：

...

starting queue recovery                                               ...done
starting persister                                                    ...BOOT ERROR: FAILED
Reason: {{badmatch,{error,{{{badmatch,eof},
                            [{rabbit_persister,internal_load_snapshot,2},
                             {rabbit_persister,init,1},
                             {gen_server,init_it,6},
                             {proc_lib,init_p_do_apply,3}]},
                           {child,undefined,rabbit_persister,
                                  {rabbit_persister,start_link,[]},
                                  transient,100,worker,
                                  [rabbit_persister]}}}},
         [{rabbit_sup,start_child,2},
          {rabbit,'-run_boot_step/1-lc$^1/1-1-',1},
          {rabbit,run_boot_step,1},
          {rabbit,'-start/2-lc$^0/1-0-',1},
          {rabbit,start,2},
          {application_master,start_it_old,4}]}
Erlang has closed

我当前的修复：每次发生这种情况时，我都会将相应的rabbit_persister.log文件重命名为其他内容（rabbit_persister.log.bak），并且能够成功重启RabbitMQ。但问题一直在发生，我不知道为什么。有什么想法吗？

另外，作为免责声明，我没有使用Erlang的经验;我只使用RabbitMQ，因为它是Celery青睐的经纪人。

在此先感谢，这个问题让我非常讨厌，因为我一遍又一遍地做同样的修复。

Answer 1

persister是RabbitMQ的内部消息数据库。该“日志”可能类似于数据库日志，删除它会导致您丢失消息。我猜它已被不洁的经纪人关闭所破坏，但这有点不合时宜。

有趣的是，您在rabbit_persister模块中收到错误。拥有该文件的最后一个版本的RabbitMQ是2.2.0，所以我强烈建议你升级。最好的版本始终是最新版本，您可以使用RabbitMQ APT repository获得。特别是，在2.2.0之后的版本中，persister已经看到了相当多的修复，所以你的问题很可能已经解决了。

如果您在升级后仍然看到问题，则应在RabbitMQ Discuss邮件列表中进行报告。开发人员（Celery和RabbitMQ）都在解决那里报告的任何问题。

Answer 2

一个。因为您运行的是早于2.7.1的旧版RabbitMQ B.因为RabbitMQ没有足够的RAM。您需要在服务器上单独运行RabbitMQ并为该服务器提供足够的RAM，以便RAM是持久消息日志的最大可能大小的2.5倍。

您可以通过添加更多内存并杀死其他服务而无需任何软件更改即可解决此问题。

另一种方法是从源代码构建自己的RabbitMQ，并包含使用Tokyo Cabinet保留消息的toke扩展。确保您使用的是本地硬盘而不是NFS分区，因为Tokyo Cabinet存在NFS损坏问题。当然，使用2.7.1版本。根据您的消息内容，您可能还可以从Tokyo Cabinets压缩设置中受益，以减少持久消息的读/写活动。