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 回答