51

在阅读了 O'Reilly 的一篇关于该主题的文章后,我想向 Stack Overflow 询问他们对此事的看法。

4

6 回答 6

62

本地写入磁盘,然后定期批量插入数据库(例如在日志翻转时)。在单独的低优先级进程中执行此操作。更高效、更健壮...

(顺便说一句,确保您的数据库日志表包含“日志事件来自哪台机器”的列 - 非常方便!)

于 2008-11-14T15:05:17.733 回答
9

我会说不,因为相当大比例的服务器错误涉及与数据库通信的问题。如果数据库在另一台机器上,网络连接将是另一个无法记录的错误来源。

如果我要将服务器错误记录到数据库中,那么拥有一个在本地(写入事件日志或文件或其他东西)写入的备份记录器至关重要,以防数据库无法访问。

于 2008-11-14T15:02:59.750 回答
4

如果可以的话,登录到数据库并且它不会减慢你的数据库:)

在数据库中查找任何内容比在日志文件中查找任何内容要快得多。特别是如果您提前考虑您将需要什么。登录 db 让我们像这样查询日志表:

select * from logs
where log_name = 'wcf' and log_level = 'error'

然后在发现错误后,您可以看到导致此错误的整个路径

select * from logs
where contextId = 'what you get from previous select' order by timestamp

如果您将其记录在文本文件中,您将如何获得此信息?

编辑: 正如 JonSkeet 建议的那样,如果我说应该考虑将日志记录到 db 异步,这个答案会更好。所以我声明它:) 我只是不需要它。例如如何做到这一点,您可以查看 Richard Kiessig 的“Ultra Fast ASP.NET”。

于 2014-05-08T08:57:36.477 回答
3

如果数据库是生产数据库,这是一个可怕的想法。您遇到备份、复制和恢复方面的问题。就像为数据库本身、副本(如果有)和备份提供更多存储空间。更多时间设置和恢复复制,更多时间验证备份,更多时间从备份中恢复数据库。

于 2017-04-19T12:07:47.480 回答
2

如果您想要数据库中的日志,这可能不是一个坏主意,但如果您有很多日志文件条目,我会说不要遵循本文的建议。主要问题是我已经看到文件系统无法跟上来自繁忙站点的日志,更不用说数据库了。如果你真的想这样做,我会考虑在日志文件首次写入磁盘后将它们加载到数据库中。

于 2008-11-14T15:05:49.013 回答
2

考虑一个使用 RAM 进行读写的正确设置数据库?这比写入磁盘要快得多,并且不会出现您在为大量客户端提供服务时看到的磁盘 IO 瓶颈手柄。

尽管我的最新应用程序正在使用数据库日志记录,但我没有任何基准来证明这些数据。如其中一个响应中所述,这将具有故障保护功能。如果无法创建数据库连接,请创建本地数据库(可能是 h2?)并写入。然后我们可以定期检查数据库连接,重新建立连接,转储本地数据库,并将其推送到远程数据库。

如果您没有 HA 站点,则可以在非工作时间完成此操作。

在未来的某个时候,我希望开发基准来证明我的观点。

祝你好运!

于 2012-07-19T03:22:55.643 回答