如何在运行 RabbitMQ 实例时正确拍摄 EBS 卷快照?
我在 EC2 实例上使用 RabbitMQ,并且 EBS 卷上有 Mnesia 表,因此当我对其进行快照并尝试启动具有相同数据的另一个实例时,该表似乎正在被另一个 RabbitMQ 实例使用。
解决这个问题的唯一方法是关闭 RabbitMQ 以进行刷新/快照,然后在完成后重新启动它?
有没有办法清理文件,使它们看起来不被锁定或被强制解锁?
这不是我会遇到的常见问题,只是好奇是否有更好的解决方案。
为了澄清一下,我看到的错误是:timeout_waiting_for_tables
。
I'm using RabbitMQ on an EC2 instance and I have the Mnesia tables on an EBS volume, so when I snapshot it and try to launch another instance with the same data, it appears that the table is in use by another RabbitMQ instance.
Is the only way to get around this to shut RabbitMQ down for the flush/snapshot and then start it back up once it's done?
Is there a way to clean up the files so that they don't appear locked or are forcefully unlocked?
It's not a common problem I'll be facing, just curious if there's a better solution.
To clarify, the error I see is: timeout_waiting_for_tables
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您首先需要关注文件系统。不确定您是否使用 LVM、ext3、xfs 或其他什么,但如果您使用 LVM,您可能需要查看 dmsetup 手册页;具体来说,dmsetup 挂起/恢复
您最终会得到类似的结果:
一旦文件系统同步/挂起,就需要担心rabbitmq了。 Rabbitmq 开发人员 Matthias Radestock 在电子邮件线程中指出:
检查 Rabbitmq Makefile< 中的 force-snapshot 目标/a>.
You first have the filesystem to be concerned with. Not sure if you're using LVM, ext3, xfs or what, but if you're on LVM, you might want to checkout the dmsetup man page; specifically dmsetup suspend / resume
You will end up with something like:
Once you've got the filesystem sync'ing / suspending, there's rabbitmq to worry about. Rabbitmq developer Matthias Radestock states in an email thread:
Checkout the force-snapshot target in the Rabbitmq Makefile.