提问人：Floobinator 提问时间：10/10/2023 最后编辑：Floobinator 更新时间：10/11/2023 访问量：62
MySQL - 适用于 AWS RDS 和 RR 支持的最佳内部错误处理技术
MySQL - Best Internal Error Handling Technique for AWS RDS and RR Support
问：
我们有一个部署在 AWS RDS 上的定制 CRM 系统。我们的 FE 和 BE 系统是 JavaScript，数据库禁止 JS 开发人员直接操作数据库。它们必须通过预定义的 API 或受控查询系统。它运行良好，开发人员从未设法伤害数据库:)
更新：受控查询系统强制执行 JSON 构造，作为前端和后端系统更新、插入和删除记录的唯一方法。数据库监视 JSON 构造并相应地处理它们，包括剥离和拒绝不符合特定准则的数据和请求。
数据库有自己的内部错误报告系统，该系统运行良好，主要是因为 JS 开发人员通常不会报告来自失败的存储过程调用 （grr） 的错误。因此，数据库会在跟踪表中报告这些错误。这样，我们就可以看到 JS 开发人员发送了哪些糟糕的有效负载，或者捕获 SQL 中偶尔出现的错误。
更新：内部错误报告系统就是这样;每当存储过程触发未经处理的错误时，它都会将错误写出到由数据库团队监视的错误表中。它存在于核心数据库级别，与查询控制系统无关。
问题是我们已经部署了数据库的只读副本，现在内部错误报告系统在失败的 RR 调用上变得毫无用处。
有没有一种技术或方法可以让RR以某种方式向主机发送写出调用？还是必须切换到日志文件系统？如果我必须这样做，它几乎要求我们放弃我们的主错误表跟踪......
因此，我想核心问题是：对于使用只读副本的企业级CRM数据库，我们应该考虑哪种内部MySQL错误报告系统和技术？
谢谢！
答：
2赞
Bill Karwin
10/10/2023
#1
RDS 只读副本无法向源实例发送查询。
对于使用只读副本的企业级 CRM 数据库，我们应该考虑哪种内部 MySQL 错误报告系统和技术？
在处理请求的后端代码中检测并报告无效的有效负载，而不是在存储过程中。
您的代码可以将错误请求记录到您想要的任何实例。我的意思是，您可以将错误记录到源实例，即使请求（一旦验证）会导致在只读副本实例上执行存储过程。
但我建议将错误的请求记录到其他一些日志记录系统，而不是数据库。错误请求与数据库中的任何其他数据无关，它只是增加了更多的存储负载和查询负载，以记录数据库中的错误请求。
AWS 目前提供一项名为 Centralized Logging with OpenSearch 的服务。这听起来像是向其发送错误请求报告的可能候选者，但我没有使用过此 AWS 服务，因此我无法报告任何使用过它的经验。这只是我所说的那种事情的一个例子。
日志记录系统通常比使用成熟的 RDBMS 来完成该任务更简单、更便宜。
评论
0赞
Floobinator
10/11/2023
是的，我似乎无法确定它如何在受控容量下与 RDS 一起工作。我们自己的内部日志系统的一个好处是，我们可以准确地选择写入日志的内容，因此非常复杂的 SP 调用该错误可以包含其他数据。我们真正需要的是一个可以通过MySQL调用调用的外部日志系统，这样我们就可以手动写出我们已经在内部执行的操作......但我没有看到 OpenSearch 支持这一点......还有其他想法吗？
0赞
Bill Karwin
10/11/2023
OpenSearch 有助于聚合不同类型的日志，包括应用程序日志。我说的是使用应用程序日志发送错误消息，您可以在应用程序错误消息中包含所需的任何信息。
0赞
Bill Karwin
10/11/2023
真的，你根本不需要特殊服务。老式的方法是简单地将错误写入运行应用程序的同一主机上的指定文件。
1赞
Quassnoi
10/11/2023
#2
大方向是比尔在他的回答中所说的。我只添加一些特定于 AWS 的风格。
在 AWS 中，错误日志记录的首选位置是 CloudWatch。它非常易于设置和使用，而且与将错误日志存储在 RDS 中相比非常便宜。
流程是这样的：
创建日志组。它只完成一次，并且期望它与您的应用程序在业务中一样存在（希望是几年）。它是错误表的模拟。
后端应用程序的实例启动后，创建日志流。将执行此操作的代码放入应用程序启动代码中。
将验证逻辑和数据库调用包装到 try-catch 块中。如果验证程序或数据库调用引发异常，请将带有异常描述的事件放入日志流中。
有一个名为 winston 的不错的库，带有一个 CloudWatch 插件，可以为您处理所有这些。
CloudWatch 具有一些基本的分析和搜索功能，对于您的使用案例来说可能足够了。如果不是，您可以使用大量服务，例如 Quicksight（AWS 原生）;Kibana、Splunk、NewRelic（第三方）等，所有这些都可以轻松与 CloudWatch 集成。
详细描述它们超出了本答案的范围，但几乎每一个都比将日志数据存储在 RDS 中更方便且操作成本更低。
评论
0赞
Floobinator
10/12/2023
那么，CloudWatch 解决方案是否允许我从 MySQL 代码本身写入日志文件？我们需要能够从MySQL中写出自定义错误。我的理解是，这需要在语言本身中集成某种 API。我还没有看到任何从 MySQL 写入 CloudWatch 日志的实际示例......你知道吗？
0赞
Quassnoi
10/12/2023
@Floobinator：不，MySQL没有这样的东西。您正在采用的这种模式（使用数据库作为 API）有其用途，尤其是在开发的早期阶段，但它也有其缺点，这对您来说可能变得显而易见。如果将数据库视为存储层并使用存储库模式对其进行抽象，则开发复杂的应用程序要容易得多。是的，如果你不习惯，这听起来确实像是公司的废话。是的，它的存在是有原因的。对不起，我没有更好的答案给你。
0赞
Quassnoi
10/12/2023
@Floobinator：也就是说，应该有一些东西从JS代码中调用这个“受控查询系统”。如果有效负载未通过验证或发生其他情况，会发生什么情况？它有没有办法将其报告给调用者（除了将内容写入错误日志表之外）？如果是，则没有什么可以阻止您在主节点上并行实现这两种方法（允许写入），并仅在副本上回退到 JS 日志记录。
评论