MySQLを使ってアプリ開発や運用の際に、意図しない挙動や想定しない値が返ってくるなど、バグかと思われる状況に遭遇することもあります。今回はこのような状況を分析および解決につなげる手順や情報をご紹介します。
バグをMySQL開発チームに報告、その前に……
MySQLのバグはバグデータベースに登録することでMySQL開発チームに報告することができます。ただバグ報告をする際にはいくつかのポイントがありますので、まずはその点を確認します。
- バグデータベースに既存の報告が無いかの確認
- バグ報告の3つの原則を整理
- バグ報告時に不要な情報を削除
- バグを“英語で”報告
以上の点を踏まえてバグ報告することで、MySQL開発チームでも状況を分析しやすくなり、問題解決までの時間を少しでも短くできることが期待できます。ただしバグ修正については開発ロードマップや各機能の開発状況、問題の深刻度などによって優先順位が変わってきます。
バグ報告時の流れや注意点についてはリファレンスマニュアルにも掲載されていますので、併せてご確認ください。
バグデータベースに既存の報告が無いかの確認
問題がすでに報告されていないかはバグデータベースの検索機能を利用します。問題が報告済みのバグと同じ場合には、バグのページの［Affects Me］ボタンを押し開発者に同様の問題に遭遇しているケースが複数あることを知らせることができます。
最新でないバージョンを利用している場合、最新のバージョンで該当する問題が修正済みのことがあります。その場合にはバージョンアップを検討してください。
検索キーワードにはエラーメッセージの一部やログにエラー出力されているものなど使います。数字のみだとバグ報告の番号としてヒットしてしまうため、別のキーワードを併せて入力する必要があります。
status（ステータス）はActiveだと現在修正中または検証中のバグ報告のみが検索対象となります。特に最新ではないマイナーバージョンでバグと思われる状況に遭遇した場合などは、ステータスをActiveからAllにすることで、すでに修正済みのものを含めて確認ができます。
またseverity（深刻度）は、デフォルトではFeature Request（機能追加リクエスト）以外のバグ報告のみを検索対象とします。問題の内容によってはバグではなく機能が不足しているケースもありますので、Allで検索するほうが良いです。
他にもcategories（カテゴリ）で機能での絞り込みができます。この絞り込みはプルダウンで選択するだけではなく、機能名をタイプすると候補が表示されより簡単に選択できます。version（バージョン）にはMySQL 5.7.9などマイナーバージョン番号は含めず、5.7のようにメジャーバージョンのみとしておくことをお勧めします。
バグ報告の3つの原則を整理
MySQLのバグ報告に限りませんが、3つの点を明確にしておくことが重要です。
- 実行した作業（SQL文やコマンドなど）
- 想定した挙動（出力や値など）
- 発生した結果
まず1.の「実行した作業」としては、実行したSQL文やコマンド、およびその事前準備としてスキーマの定義やデータなどを整理します。SQL文やスキーマの定義、データには外に出せない値などが含まれていることもあります。その場合には同じ構文や型を用いてテスト環境にて動作確認した結果を用意することになります。実際の環境のみで発生するような場合は、値をマスクすることになりますが、値に依存する問題の場合はMySQL開発チームで再現できない可能性があります。
2.の「想定した挙動」は出力そのものを再現する必要はなく、「条件に合致するデータが10件表示される」「エラーが発生せずに処理か完了する」といった内容を整理します。
3.の「発生した結果」は、SQL文やコマンドを実行した結果をそのまま利用すれば問題ありません。値のマスクなどは必要な場合は1.と同様に検討します。
バグ報告時に不要な情報を削除
バグ報告の際には情報を必要最低限に絞り込みます。MySQLのバグデータベースでは、状況説明は10行程度で書いて欲しいとされています。また問題の状況の説明と問題を再現するための情報は分けて記載してください。テスト環境などでも再現できている場合、テーブルから不要な列やデータを削除して情報量を減らします。
バグを“英語で”報告
報告されたバグはMySQL開発チームや世界中のMySQLコミュニティのエンジニアが見ることになります。そのためバグ報告は英語でお願いしています。英語に自信がない場合などは、日本MySQLユーザ会のメーリングリストでは支援を依頼する手もあります。
トリアージチームでの再現と判定
通常バグ報告後にMySQLのトリアージチーム（対応優先順位の選別）が問題の再現を行います。問題が再現しバグとして確認されるとステータスがVerifiedになり、メールで通知されます。ちなみに多くの場合トリアージチームのUmeshが判定しており、彼の名前が某社の梅酒に似ているので日本人かと思われる方がいるようですが、彼は南アジアの方だそうです。
トリアージチームで再現できない場合などはステータスがNeed Feedbackとなり、メールが送られてきます。この場合は再現に必要な情報の追加など、トリアージチームが求めている情報を登録してください。追加情報が送られていない場合は、一定期間後にステータスがNo Feedbackとなり、クローズされた扱いとなってしまいます。
バグ報告したけれど……
報告したバグがVerifiedになっても残念ながらすぐに修正されるとは限りません。問題によっては修正がMySQL全体に大きな影響を与えることやアーキテクチャに大幅に手を入れる必要があることがあります。
また、該当の製品や機能ですでに多くにバグが報告されており、かつ他のバグ報告のほうが、深刻度が高いなどで後回しにされてしまうケースも多々あります。またMySQLのサポート契約を持っているお客様の環境で見つかったバグが優先されることも少なくありません。問題が運用上、大きな問題となりビジネスに影響を与える場合などには、サポート契約を通して緊急パッチの提供を依頼することも検討してください。
自分で直したんだけど……
ソースコードを確認することで問題の原因を見つけられることもあり得ます。このような場合に自分でパッチを作るケースもあり、このパッチを含めてバグ報告をすることもできます。
著作権の所有者を明確化するため、Oracle Contributor Agreementへの署名を求められた場合は対応をします。極めて小規模なパッチを除いて、挙動の説明とテストケースを付けてバグ報告することが期待されています。またMySQLサーバなどは複数のOSをサポートしていますので、特定のOSでのみ動作するパッチはそのまま取り込まれず、再実装されて取り込まれることになります。
