8.1. 見つけたバグを報告するには — Mroonga vmrn_version documentation

本文へスキップ
`Ctrl`+`K`

# 8.1. 見つけたバグを報告するには

バグを報告する方法はいくつかあります。

どのやりかたを使ってもらっても構いません。

## 8.1.1. Issue trackerにバグを報告する

Mroongaプロジェクトでは、 GitHub issue tracker を使っています。

バグを報告するのは英語でも日本語でもどちらでも良いです。

## 8.1.2. バグを報告する他の方法

Mroongaプロジェクトでは、Mroongaについて話す コミュニティ があります。バグの内容を記載したEメールを送ってください。

# 8.2. 再現可能なバグ報告をするためのデータをあつめるには

Mroongaがクラッシュしたり、SQLの結果が期待通りでない検索結果を返すことがあります。そういった問題を解決するためには再現可能なバグ報告が必要です。

再現可能なバグ報告には、次の情報をできるだけ提供してもらえると、問題を調査するのに役立ちます。

Name | Description
--- | ---
環境情報 | どのバージョンを使っているか、インストールしたパッケージの情報 rpm:
    rpm -qa > INSTALLED.txt
deb:
    dpkg -l > INSTALLED.txt
Windowsではどのzipパッケージを使っているかを教えてください。
問題の引き金となる実行中のクエリー | 実際に実行したクエリーを示します。
サンプルのスキーマとデータ | 問題を再現させる小さなサンプルスキーマとデータを提供してください。問題をすばやく解決するのにつながります。
MySQLのエラーログ | より低レベルのエラー情報を含んでいます。 例えば `/var/log/mysqld.log` にあります。( `log-error` 設定によりかわります)
groonga.log | より低レベルのエラー情報を含んでいます。 例えば `/var/lib/mysql/groonga.log` にあります。( `mroonga_log_file` の設定によりかわります)

上記の情報がバグの再現に十分でない場合、追加の情報が必要です。

Name | Description
--- | ---
MySQLのダンプ | 同じデータベースを再構築するのに必要です。 `mysqldump -u USER -pPASSWORD --opt --flush-logs --single-transaction --master-data=2 --default-character-set=utf8 --hex-blob --databases DATABASE > dump.sql` などとして作成します。
MySQLのbinlog | ダンプデータが問題の再現に十分ならば必要ありません。例えば、 `/var/lib/mysql/mysql-bin.*` にあります。 ( `log-bin` の設定によりかわります)
MySQLのデータディレクトリー(オフラインバックアップ) | ダンプデータやバイナリーログが残っていない場合、必要になることがあります。例えば、 `/var/lib/mysql/` にあります。 ( `datadir` の設定によりかわります)