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

为了跟进，下面是来自Hiriayashi的（TT开发者）回复类似措辞的电子邮件：

如果只能确认一个作为双主站的另一部分的从站，则访问主站服务器，请通过命令“tcrmgr inform -st …”查询到从站的延时时间，并确定哪些文件可以被删除。

运行这个命令可以让你看到主机后面有多远。 一旦你知道你可以花一些时间find正确的ulog周转大小和许多ulog文件，你可以垃圾，感到安全。 可能最好在模拟东京暴虐的关键/价值数据库等重的一天的负载下做到这一点。

我无耻地撕掉了一个从stackoverflow的脚本：

 >＃！/ bin / bash
 > 
 >＃删除最新的5个文件，以保持东京暴君ulogs
 >杀死磁盘。
 > logdir ='/ path / to / ttserver / ulog /' 
 > mydir =`ls -t $ logdir` it = 1
 > 
 >用于$ mydir中的文件
 >做
 >如果[$ it -gt 5]
那么
 > echo文件$它将被删除：$ logdir $文件
 > #rm -rf $文件
 > fi
 > it = $（（it + 1））
 >完成

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

仅供参考，我已经写了一个ulogpipe理脚本来考虑复制延迟：

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

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

在我知道的交易系统（例如数据库）中，关注两种意外事件：

• 电源故障 – 当由于某些原因丢失RAMcaching的内容时，但重新启动后，仍然可以访问磁盘文件
• 磁盘故障 – 您不再能够访问磁盘文件中的数据; 文件丢失或只包含垃圾; 你必须从备份中恢复

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

1. 使用非常新鲜的事务创build的活动日志 ; 它所包含的数据还没有被保存到数据文件中; 你绝对需要这个来恢复数据文件在电源故障的情况下的一致性
2. 在提交数据（写入数据库文件）之后，日志现在称为提交日志 ; 数据以两种不同的格式/位置在磁盘上 – 在这个日志和数据库文件中; 如果发生电源故障，则不需要此日志，但是在发生磁盘故障时需要它 – 在恢复数据库文件（从前一周？）之后，可以按照相同的时间顺序重新应用连续的已提交+活动日志中的所有事务序列以获得新的数据副本; 如果你失去了最新的日志，你已经失去了最近的交易，但至less你还是有一个非常新鲜和完全一致的数据库
3. 数据库文件备份后（一致地复制到安全的地方），您的日志成为归档日志 。 你不需要它来防止任何失败。

我不知道如何弄清楚东京暴君有哪些ulog 。 但也许这个总纲将有所帮助。