如何在运行 RabbitMQ 实例时正确拍摄 EBS 卷快照?

发布于 2024-08-03 21:57:44 字数 294 浏览 3 评论 0原文

我在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

妞丶爷亲个 2024-08-10 21:57:44

您首先需要关注文件系统。不确定您是否使用 LVM、ext3、xfs 或其他什么,但如果您使用 LVM,您可能需要查看 dmsetup 手册页;具体来说,dmsetup 挂起/恢复

您最终会得到类似的结果:

dmsetup suspend <dev> 
ec2-create-snapshot <vol> 
dmsetup resume <dev> 

一旦文件系统同步/挂起,就需要担心rabbitmq了。 Rabbitmq 开发人员 Matthias Radestock 在电子邮件线程中指出:

<块引用>

但是对于持久的消息我不太确定。怎么样
rabbit_persister.LOG 管理吗?我可以备份一份吗
每当,或者我可以只采取rabbit_persister.LOG.previous之一?

我会备份这两个文件。 应该是
可以恢复
来自备份的rabbit_persister.LOG
即使该备份已被采纳
附加的中间 - 我没有
不过经过测试。
.previous 日志
以防备份需要
在滚动原木时放置。

<块引用>

我应该在哪里查看它的滚动频率?

决定何时滚动的逻辑
日志相当复杂。

<块引用>

我可以触发手动掷骰吗?

rabbit__persister:force_snapshot() 中
Erlang shell 可以解决这个问题。

检查 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:

dmsetup suspend <dev> 
ec2-create-snapshot <vol> 
dmsetup resume <dev> 

Once you've got the filesystem sync'ing / suspending, there's rabbitmq to worry about. Rabbitmq developer Matthias Radestock states in an email thread:

But for the persistant messages I am not so sure. How is the
rabbit_persister.LOG managed? Can I just take a backup copy of it
whenever, or may I only take one of the rabbit_persister.LOG.previous?

I'd back up both files. It should be
possible to restore the
rabbit_persister.LOG from a backup
even when that backup was taken in
the middle of an append - I haven't
tested that though.
The .previous log
is needed in case the backup takes
place while the log is being rolled.

Where would I look to find out how often it is rolled?

The logic for deciding when to roll
the log is rather complex.

Can I trigger a manual roll?

rabbit__persister:force_snapshot() in
the Erlang shell does the trick.

Checkout the force-snapshot target in the Rabbitmq Makefile.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文