东京暴君ulog /更新日志管理

Question

我正在测试“东京暴君”的主主设置，并发现ulog失控了，并锁定了磁盘。

起初，我发现-ulim选项很有用，并且限制了日志文件的大小，但是它只是简单地滚动到一个新的日志中，留下旧的日志来扰乱分区。

我想，一旦我在更新日志中了解到东京暴君需要多久才能进行故障转移，我就会编写一个shell脚本，它将删除比X更老的ulog。

有人对这个东京暴君有过什么经验吗？对于最优ulog大小与东京暴君实例需要在ulog中查看以获得主状态，您有感觉(承认每个安装都是根据所存储的内容而有所不同)吗？

谢谢你，内森

Answer 1

FYI，我编写了一个ulog管理脚本，其中考虑到复制延迟：

http://conigliaro.org/2010/04/28/tokyo-tyrant-update-log-ulog-management/

Answer 2

免责声明:这是我第一次听说“东京暴君”。我只是看到一些熟悉的模式在看文档。

在我所知道的事务性系统(例如数据库)中，注意到两种类型的意外事件：

• 电源故障-当您由于某种原因丢失了RAM缓存的内容，但重新启动后，您仍然能够访问磁盘文件。
• 磁盘故障-您不再能够访问磁盘文件中的数据；文件丢失或只包含垃圾；您必须从备份恢复。

每个日志通常经过三个阶段的存在：

1. 刚用非常新鲜的事务创建的活动日志；它包含的数据尚未保存到数据文件中；您绝对需要这样做，以便在发生停电时恢复数据文件的一致性。
2. 在提交数据(写入数据库文件)之后，日志现在被称为提交日志；数据以两种不同的格式/位置在磁盘上-在此日志中和在数据库文件中；在发生电源故障时不需要此日志，但在磁盘故障时需要它--在还原数据库文件之后(从前一周开始？)，您可以以相同的时间顺序重新应用连续commited+active日志中的所有事务，以获得新的数据副本；如果您丢失了最新的日志，您已经丢失了最近的事务，但至少您仍然拥有相当新鲜和完全一致的数据库。
3. 备份数据库文件后(始终复制到安全的位置)，您的日志将成为归档日志。你不需要它来防止任何一次失败。

我不知道如何找出你的那些ulogs是由东京暴君犯下的。但也许这个大致的大纲会有所帮助。