☰

Tokyo Tyrant ulog / 更新日志管理

tag-icon • tag-icon logging nosql
Tokyo Tyrant ulog / 更新日志管理

我正在主-主设置中测试 Tokyo Tyrant，发现 ulog 失控并锁定了磁盘。

起初我发现 -ulim 选项很有用并且限制了日志文件的大小，但是它只是滚动到新的日志，而旧日志却使分区变得混乱。

我想我会编写一个 shell 脚本，一旦我发现 Tokyo Tyrant 需要多远的更新日志才能实现故障转移，它就会删除早于 X 的 ulog。

有人用过这个 Tokyo Tyrant 吗？您是否对最佳 ulog 大小以及 Tokyo Tyrant 实例需要在 ulog 中追溯多远才能获得主状态有感觉（承认每个安装都因存储内容而异）？

谢谢，内森

答案1

顺便说一下，以下是 Mikio Hirabayashi（TT 开发人员）对一封措辞类似的电子邮件的回复：

如果可以确认仅有一个从服务器（双主的另一部分）访问主服务器，请通过命令“tcrmgr inform -st ...”向从服务器查询延迟时间，并确定可以删除哪个文件。

运行该命令将允许您查看从服务器落后于主服务器多少。一旦您知道您可以花一些时间找到正确的 ulog 周转大小，并且可以丢弃许多 ulog 文件并感到安全。最好在模拟 Tokyo Tyrant 键/值数据库等繁重工作日的负载下执行此操作。

我厚颜无耻地从 stackoverflow 上抄了一个脚本：

/bin/bash > #!/bin/bash
>
> # 删除除最新 5 个文件之外的所有文件，以防止 Tokyo Tyrant ulogs
> 杀死磁盘。
> logdir='/路径/到/ttserver/ulog/'
> mydir=`ls -t $logdir` it=1
>
> 对于 $mydir 中的文件
> 做
> 如果 [ $it -gt 5 ]
> 然后
> echo 文件 $it 将被删除：$logdir$file
> #rm -rf $文件
> 菲
> 它=$((它+1))
> 完成

@kubanskamac 的回答在摘要中是正确的，但 Mikio 给出了开始优化的命令。

答案2

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

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

答案3

免责声明：这是我第一次听说 Tokyo Tyrant。我只是在看文档时看到了一些熟悉的模式。

在我所知道的事务系统（例如数据库）中，需要注意两种类型的意外事件：

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

每根日志通常要经历三个存在阶段：

  1. 活动日志刚刚使用非常新鲜的交易创建的；它包含的数据尚未保存到数据文件中；在断电的情况下，您绝对需要它来恢复数据文件的一致性
  2. 数据提交（写入数据库文件）后，日志现在称为提交日志；数据以两种不同的格式/位置存储在磁盘上 - 在此日志中和在数据库文件中；如果发生电源故障，则不需要此日志，但如果发生磁盘故障，则需要它 - 恢复数据库文件（从前一周？）后，您可以按照相同的时间顺序重新应用连续提交+活动日志中的所有事务，以获得最新的数据副本；如果您丢失了最新的日志，那么您就丢失了最近的事务，但至少您仍然拥有相当新鲜且完全一致的数据库
  3. 数据库文件备份后（一致地复制到安全的地方），您的日志将变为归档日志。您不需要它来防止任何一种故障。

我不知道如何找出你的哪一个乌洛格斯是东京暴君犯下的罪行。但也许这个概述会有所帮助。

相关内容