本节介绍了一些常见数据库故障,并提供了一些建议的修正方法。本节包含以下主题:
由于 csadmind 是处理组调度引擎 (Group Scheduling Engine, GSE) 和警报分发引擎的服务,因此,此故障可能是由 GSE 队列或警报队列中的违例条目引起的。
修正方法:
如果 csadmind 未运行,则立即发出 stop-cal。
保持日历服务器运行可能导致事务日志累积,从而进一步损坏数据库,并可能需要更长时间才能使事务日志文件与数据库一致。
尝试再次重新启动 csadmind(再次重新发出 start-cal)。
如果启动成功,请通过以下操作确保这两个队列正常运行:
使用 csschedule 检查 GSE 队列。
使用 dbrig 检查警报队列。
有关运行 csschedule 和 dbrig 的说明,请参见附录 D,Calendar Server 命令行实用程序参考。
如果 csadmind 发生转储故障,请分析 pstack。
如果您在跟踪中发现任何与 GSE 相关的函数(这些函数将带有 GSE 字母),请查看 GSE 队列中的第一个条目和引用的事件数据库中的条目。通常情况下,GSE 条目中引用的事件就是违例条目。要解决此问题,请执行以下步骤:
使用 csschedule 删除 GSE 条目。
使用 cscomponents 从数据库中删除违例事件。
有关运行 csschedule 和 cscomponents 的说明,请参见附录 D,Calendar Server 命令行实用程序参考。
如果条目未损坏,则可能是日历服务器无法处理的特殊故障。
请执行以下步骤:
拍下损坏的数据库的日历环境快照,并与客户支持联系。
要创建环境备份,请执行以下步骤:
为避免服务中断,请将日历数据库临时置入只读状态,并恢复为热备份副本。
将日历数据库临时置入只读状态,以防出现添加、修改或删除事务。最终用户尝试添加、修改或删除任何日历数据时,将收到错误消息。数据库处于只读模式时,用于添加、修改或删除日历事件和待办事件的管理员工具也将不起作用。
要将日历数据库置入只读模式,请编辑 ics.conf 文件,按如下所示将指定参数设置为 "yes":
caldb.berkeleydb.readonly=”yes”
按照恢复自动备份副本中的说明,恢复为热备份副本。
配置并启用 csstored 之后,在几分钟的更新后即可使用热备份。还应当始终验证热备份副本以确保其未损坏。(运行 db_verify。)
如果所有修复操作均失败,请执行转储和重新装入过程以查看是否可以抢修数据库。
使用转储和装入过程来恢复日历数据库中介绍了此过程。
这种情况可能是由包含 Berkeley DB 数据库页面锁定的控制线程在退出时没有释放该锁定而引起的。要确认是否存在此问题,请针对 cshttpd 进程和 csadmind 运行 pstack。(pstack 是位于 /usr/bin/pstack 中的标准 UNIX 实用程序)它应当显示为获取锁定而正在等待的线程。
要解决此问题,请重新启动 Calendar Server,如下所示:
数据库循环通常是由数据库文件损坏引起的。由于是数据库损坏,因此,它是不可修复的。有以下几种选择:
恢复为热备份。
如果是最近发生的损坏,则可以使用其中一个热备份。
使用灾难归档恢复过程。
有关建议的过程,请参见恢复自动备份副本。
使用转储和重新装入过程(使用转储和装入过程来恢复日历数据库)。