This is a read-only copy of the MariaDB Knowledgebase generated on 2024-12-22. For the latest, interactive version please visit https://mariadb.com/kb/.

向MariaDB社区报告错误

有关文档错误报告,请参阅Reporting Documentation Bugs

MariaDB的错误和功能跟踪器可在https://jira.mariadb.org找到。

本页面包含了社区报告MariaDB产品中错误的一般指南。如果您想与其他MariaDB开发人员讨论问题或新功能,可以在此处找到电子邮件列表和论坛。

已知的错误

首先,请检查是否在MariaDB bugs database中已经报告了此错误。

对于MariaDB错误数据库,请使用JIRA搜索以检查您即将提交的报告是否已经存在。您不必成为JIRA搜索专家,但请至少做出一些努力。

  • 选择Issues=>Search for issues
  • 如果表单在顶部有一条长空白行,请按右侧的Basic以切换到更简单的模式;
  • Project字段中,选择相关项目(MDEV用于通用MariaDB服务器和客户端);
  • Contains text文本字段中,输入您未来报告中最重要的关键字;
  • Enter或放大镜图标进行搜索。

如果您看到已经关闭的错误报告,请注意“修复版本”字段——可能已经在即将发布的版本中修复了这些错误。如果它们说已经在您当前使用的版本或更早版本中修复,则可以忽略它们并提交一个新的(尽管请在您的错误报告中提到您发现了它们,这可能很有用)。

如果您找到了一个开放的错误报告,请投票/添加评论说这个错误也影响了您,并提供任何其他信息,这些信息可能有助于我们找到和修复错误。

如果该错误尚未在MariaDB错误数据库中,则是时候提交错误报告了。如果您正在提交关于已经在MySQL错误数据库中的错误报告,请在报告开头指出。在MariaDB错误数据库中提交MySQL中的错误报告是有意义的,因为:

  • 它显示MariaDB团队有兴趣在MariaDB中修复此错误。
  • 它允许开始在MariaDB中修复错误——分配版本、分配MariaDB开发人员到错误等。

报告错误

错误和功能请求报告到MariaDB bugs database

JIRA隐私

请注意,我们的JIRA条目是公开的,而且JIRA非常擅长记录已完成的所有事情。这意味着如果您在描述中包含机密信息,将会有一个包含它的日志,即使您已经将其删除。唯一的摆脱方法是完全删除JIRA条目。

JIRA中的附件也是公开的。

评论的访问可以限制为特定组(例如仅开发人员),但现有组相当广泛,因此您也不应依赖它。

如果您有私人信息- SQL片段、日志、数据库转储等-您愿意与MariaDB团队分享,但不与整个世界分享,请将其放入文件中,必要时进行压缩,上传到mariadb-ftp-server,并在JIRA描述中提及即可。这样只有MariaDB团队才能访问它。

报告安全漏洞

如上所述,所有JIRA问题都是公开的。如果您认为已发现安全漏洞,请发送电子邮件至security@mariadb.org,请勿在JIRA中使用。我们将按照负责任的披露惯例自行在JIRA中输入。

好的错误报告内容

以下是我们需要修复错误所需的信息。我们获得的信息越多,重复错误越容易,修复速度就越快。

良好的错误报告包括:

  1. 环境(操作系统、硬件和MariaDB版本)发生错误的地方。
  2. 服务器错误日志文件中的任何相关错误或警告。通常是您数据库目录中的hostname.err文件,但根据发行版和版本可能会有所不同;如果找不到它,请在运行中的服务器上运行SELECT @@log_error。如果变量或其指向的文件为空,则错误日志很可能转到系统日志中。如果这是systemd,则可以使用journalctl -n 50 -u mariadb.service获取MariaDB日志的最后50行。如果可能,请附上至少从上次服务器重启到日志结束的完整未删节错误日志。
  3. 如果问题与MariaDB更新或更改服务器版本、从以前的崩溃中恢复等相关,则包括使用的以前版本以及以前服务器会话的错误日志。
  4. 您的my.cnf文件内容或者mysqld --print-defaultsSHOW VARIABLES的输出。
  5. 您可以提供的任何背景信息(stack trace、表、表定义(show-create-table SHOW CREATE TABLE {tablename})、数据转储、查询日志)。
  6. 如果错误是关于服务器产生了错误的查询结果:实际结果(您正在获取什么)、期望结果(您认为应该产生什么),并且除非显而易见,否则请说明为什么您认为当前结果是错误的。
  7. 如果错误涉及性能问题,例如某个查询在一个版本上比另一个版本慢,则在两个服务器上都输出EXPLAIN EXTENDED <query>。如果是SELECT查询,请使用analyze-format-json ANALYZE FORMAT=JSON
  8. 一个测试用例或其他重复错误的方法。最好是使用普通SQL或mysqltest格式。有关此信息,请参见mysqltest/README
  9. 如果无法进行测试用例,则向我们提供核心转储+相应二进制文件将非常有帮助。

JIRA字段

以下部分介绍了在提交报告时需要填写哪些JIRA字段以及应该在其中放置什么。

除了下面提到的内容,您在创建新的错误报告时不必填写或更改任何字段。

项目

如果您为MariaDB服务器、客户端程序或MariaDB Galera集群提交报告,则目标项目为MDEV。连接器和MaxScale有相应名称的单独项目。如果您选择了错误的项目,则可能会延迟错误处理,但没有理由惊慌-我们会纠正它。如果您告诉我们错误,我们将更快地更正它。

一些项目名称包括:

  • CONC - MariaDB Connector/C
  • CONJ - MariaDB Connector/J
  • CONJS - MariaDB Connector/node.js
  • CONPY - MariaDB Connector/Python
  • MCOL - ColumnStore
  • MDBF - MariaDB基金会开发(与mariadb.org域名有关的任何内容)
  • MDEV - MariaDB服务器、客户端程序或MariaDB Galera集群
  • MXS - MaxScale
  • ODBC - MariaDB Connector/ODBC

类型

功能请求与错误报告不同。在Jira中为功能请求指定Task类型,为错误报告指定Bug类型。与项目字段一样,选择错误的类型将使请求进入错误的队列,可能会延迟其处理,但最终它将被注意到并得到修正。

另请参见下一个MariaDB版本的计划,了解我们正在考虑在下一个MariaDB版本中拥有的功能。

概述

请确保摘要行具有信息性和独特性。始终应该很容易识别您的报告与其他类似报告之间的区别,否则会出现一个合理的问题-为什么它们不是重复的?

例如:

  • 良好的摘要:Server crash with insert statement containing DEFAULT into view
  • 不是很好的摘要:mysqld crash

通常情况下,我们尽量不更改原始摘要,除非有充分的理由这样做,以便您始终可以轻松地识别自己的报告。

优先级

我们在JIRA中没有单独的严重性/优先级字段,因此此优先级字段具有双重用途。对于原始报告,它表示从报告者的角度看问题的重要性。默认值为'Major';有两个较低和两个较高的值。请准确设置值。虽然我们在初始处理过程中会考虑它,但将值增加到合理值以上不会有任何好处,唯一的效果将是浪费时间,而有人将试图理解为什么一个微不足道的问题会得到如此高的优先级。之后,该值将被更改,并且报告将在其到期时间内处理。

受影响版本

请提供您所知道的有关哪些版本受到影响的所有信息。可供选择的有主要版本(10.6、10.5等)和次要版本(10.5.9、10.4.12等)。请始终在其中指定您正在使用的确切版本(X.Y.Z),以及您在哪里遇到了问题。

此外,如果您知道出现问题的确切版本,请同时放置它。如果该问题一直存在,据您所知,在所有先前版本中都存在,您也可以在此处放置主要版本,例如10.0。或者,您可以在描述或注释中提到所有这些内容。

还请在描述或注释中注明您所知道的未受影响的版本。此信息将有助于缩短进一步处理时间。

环境

在此处放置与环境相关的信息,这些信息可能对于复制或分析问题很重要:操作系统、硬件、相关的第三方应用程序、编译器等。

描述

描述中最重要的部分是重现问题的步骤。有关好的错误报告内容的更多详细信息,请参见上面好的错误报告内容部分。

如果在重现过程中执行了某些SQL,请不要用“我创建了一个带有文本列和日期列的表,并用一些行填充了它”的话来描述-而是在可能的情况下放置您运行的确切SQL查询。遇到问题时也是如此:而不是说“它无法工作,查询失败,我收到了一个错误”,请始终粘贴您收到的确切输出。

在描述中使用{noformat}...{noformat}和{code}...{code}块来处理代码和控制台输出。

附件

如果您有SQL代码、数据库转储、日志等合理大小的文件,请将它们附加到报告中(如果需要,请先将它们归档)。如果它们太大,您可以将它们上传到ftp.askmonty.org/private。除非从报告的性质中绝对清楚配置是不相关的,否则附加您的cnf文件总是一个好主意。

链接

如果您在MariaDB、MySQL或Percona bug base中发现或提交了一个与您的问题相关的错误报告,您可以将它们放在Links部分;同样适用于任何外部链接到您认为重要的第三方资源。或者,您可以在描述或评论中提到它们。

标签

您不必设置任何标签,但如果您想为自己方便使用任何标签,请随意这样做。但是,请不要放置太通用的值——例如,标签mariadb是没有意义的,因为那里的一切都是mariadb。在报告处理过程中删除某些标签后,请不要感到惊讶。

也影响MySQL或Percona中的XtraDB/TokuDB的错误

我们的正常做法是,如果适用于其版本,则向上报告错误。虽然我们可以代表您这样做,但如果您自己这样做,效果会更好——这样您将更容易跟踪它。

如果该错误影响MySQL,则还应在MySQL错误数据库中报告该错误。 如果该错误影响XtraDB或TokuDB,并且可在Percona服务器上重现,则应将其发送到Percona Launchpad

收集有关错误报告的其他信息

获取带有详细信息的堆栈跟踪

请参阅文章如何从核心文件中生成堆栈跟踪

提取二进制日志的一部分

请参阅此处文章。

获取有关服务器的帮助

如果您需要个性化帮助,希望确保以高优先级修复错误,或希望有人登录到您的服务器查找问题,您始终可以从MariaDB Corporation购买支持合同或使用他们的咨询服务。

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.