本节介绍了一些常见数据库故障,并提供了一些建议的修正方法。本节包含以下主题:
由于 csadmind 是处理组调度引擎 (Group Scheduling Engine, GSE) 和警报分发引擎的服务,因此,此故障可能是由 GSE 队列或警报队列中的违例条目引起的。
修正方法:
如果 csadmind 未处于运行状态,立即发出 stop-cal 命令。
保持日历服务器运行可能导致事务日志累积,从而进一步损坏数据库,并可能需要更长时间才能使事务日志文件与数据库一致。
验证是否已停止所有 Calendar Server 进程。
有关如何验证是否已停止所有进程的说明,参见停止子进程。
通过发出 start-cal -csadmind 命令来尝试再次重新启动 csadmind。
如果启动成功,通过执行以下步骤确保两个队列运行正常:
使用 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”
按照22.5.8 恢复自动备份副本中的说明,恢复为紧急备份副本。
配置并启用 csstored 之后,在几分钟的更新后即可使用紧急备份。还应当始终验证紧急备份副本以确保其未损坏。(运行 db_verify。)
如果所有修复操作均失败,请执行转储和重新装入过程以查看是否可以抢修数据库。
22.5.7 使用转储和装入过程来恢复日历数据库中介绍了此过程。
这种情况可能是由包含 Berkeley DB 数据库页面锁定的控制线程在退出时没有释放该锁定而引起的。要确认是否存在此问题,请针对 cshttpd 进程和 csadmind 运行 pstack。(pstack 是位于/usr/bin/pstack 中的标准 UNIX 实用程序)它应当显示为获取锁定而正在等待的线程。
要解决此问题,请重新启动 Calendar Server,如下所示:
数据库循环通常是由数据库文件损坏引起的。由于是数据库损坏,因此,它是不可修复的。有以下几种选择:
恢复为紧急备份。
如果是最近发生的损坏,则可以使用其中一个紧急备份。
使用灾难归档恢复过程。
有关建议的过程,请参见22.5.8 恢复自动备份副本。
使用转储和重新装入过程(22.5.7 使用转储和装入过程来恢复日历数据库)。