主页 / server / 问题 / 26777
Accepted
Nathan Milford
Asked: 2009-06-17 10:37:20 +0800 CST

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

  • 772

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

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

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

有没有人有这个东京暴君的经验？对于最佳 ulog 大小与 Tokyo Tyrant 实例需要在 ulog 中查看多远才能假定主状态，您是否有感觉（承认每次安装都基于所存储的内容而有所不同）？

谢谢，内森

logging nosql

3 个回答

  1. Best Answer

    只是为了跟进，下面是 Mikio Hirabayashi（TT 开发人员）对措辞相似的电子邮件的回复：

    如果可以确认只有一个slave，也就是双主的另一部分，访问主服务器，请通过命令“tcrmgr inform -st ...”查询到slave的延迟时间，可以确定可以删除哪个文件.

    运行该命令将允许您查看从属设备落后于主设备多远。一旦你知道你可以花一些时间找到正确的 ulog 转换大小和返回多少 ulog 文件，你就可以丢弃并感到安全。可能最好在模拟东京暴君键/值数据库等的繁重一天的负载下进行。

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

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

    @kubanskamac 的答案在抽象上是正确的，但 Mikio 给出了开始优化的命令。

    • 1

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

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

    • 1

  3. 免责声明：这是我第一次听说东京暴君。我只是在查看文档时看到了一些熟悉的模式。

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

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

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

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

    我不知道如何弄清楚你的哪些 ulog是由东京暴君犯下的。但也许这个总体大纲会有所帮助。

    • 0

相关问题