過去ログ表示


過去ログ 29 を表示

トピック内全 9 記事中の 1 〜 9 番目を表示
[ 最新記事及び返信フォームをトピックトップへ ]
このトピックの全ページ / [0]

Bugzillaのバグが消えた...。
(#4021) このトピック中1番目の投稿

bugzilla-2.16.1-jaを使って社内開発ソフトの不具合管理をイントラネットで行っていますが、時々バグのステータスを変更する操作(特に、”複数のバグをまとめて変更”の時に多いように思います。)を行うと、それに関係するbugがデータベース上からすべて削除されることがあり困っています。現在は、1日1度バックアップしているので、最悪前の日の状態には戻ることが出来ますが、今後利用頻度が上がってくると不安です。再現方法が見つからなくて困っています。どなたか同じ現象で困っている方?もしくは解決された方がいらっしゃいましたらご一報いただきたく...。
環境は、
OS:Linux 2.4.9-34(Red Hat Linux 7.2 2.96-108.1)
MySQL:mysql-3.23.49-3(RPM版)
Webサーバ:apache-1.3.23-11(RPM版)
です。

Re[1]: Bugzillaのバグが消えた...。
(#4035) このトピック中2番目の投稿

> bugzilla-2.16.1-jaを使って社内開発ソフトの不具合管理をイントラネットで行っていますが、時々バグのステータスを変更する操作(特に、”複数のバグをまとめて変更”の時に多いように思います。)を行うと、それに関係するbugがデータベース上からすべて削除されることがあり困っています。現在は、1日1度バックアップしているので、最悪前の日の状態には戻ることが出来ますが、今後利用頻度が上がってくると不安です。再現方法が見つからなくて困っています。

Bugzillaについて詳しくはないのですが...

Bugzillaそのものは、画面の各フィールドの内容にあわせ、SQLステートメントを発行しているだけです。
おっしゃる状況では、そのSQLの作り方が悪い(bugzillaのバグ)か、MySQLの設定などが原因か、MySQLのバグなのかなどは、推測すらできません。
しかし、http://bugzilla.mozilla.org/で、プロダクト=bugzillaで、2002-10-01から現時点にいずれかのフィールドが更新されたオープン中のバグ(452)をざっと眺めてみても、DBのレコードが間違って消されてしまうような重大なバグは見つかりませんでした。
従って、bugzillaそのものが原因とはちょっと思えません。
# DBシステムのバグや不都合に、アプリケーションが対応、というのはあり得ますが。

消されてしまったバグのナンバーとかからMySQLのログを調べて、どんなリクエストで消されたのか、とか、消される直前に発行した要求からbugzillaが出しているSQLリクエストを調べそれらをテストしてみる、とかをすることはできませんか?

また、RDBシステムとしてみた場合、"複数のバグをまとめて変更"の時、と聞いて気になるのは、DBの特にロック関係の設定です。
MySQLがどうなっているかは知りませんが、個々のレコードの更新には行ロックやレコードロックが自動的にかかるけれど、複数DBや複数行の更新には、データベースロックとかテーブルロックとかをアプリケーション側できちんとかけないといけない(あるいはデフォールトはそうなっている)RDBシステムもあるように聞いています。
ここらあたりはどうんなんでしょうか?

なお、http://www.bugzilla.org/ に、netscape.public.mozilla.webtoolsがbugzillaのニュースグループだと書いてあります。
こちらはご覧になりましたか?
# プロバイダーによってはnetscape.*も登録されています(DTIはありました)。
# 無ければ、news.mozilla.orgに直接。


Re[2]: Bugzillaのバグが消えた...。
(#4041) このトピック中3番目の投稿

ありがとうございます。

> 消されてしまったバグのナンバーとかからMySQLのログを調べて、どんなリクエストで消されたのか、とか、消される直前に発行した要求からbugzillaが出しているSQLリクエストを調べそれらをテストしてみる、とかをすることはできませんか?

今までlogの設定を行っていなかったので、追うことができませんでしたが、最近設定しました。それ以来再発していないので、次に起これば何かヒントになるかもしれないと思っています。

> また、RDBシステムとしてみた場合、"複数のバグをまとめて変更"の時、と聞いて気になるのは、DBの特にロック関係の設定です。
> MySQLがどうなっているかは知りませんが、個々のレコードの更新には行ロックやレコードロックが自動的にかかるけれど、複数DBや複数行の更新には、データベースロックとかテーブルロックとかをアプリケーション側できちんとかけないといけない(あるいはデフォールトはそうなっている)RDBシステムもあるように聞いています。
> ここらあたりはどうんなんでしょうか?

漠然とは、その辺の問題かな?とも思っていたのですが、今のところこのDBにアクセスしているのは下名のみで、アクセスが重なったりすることはないはずですが...DBのことは詳しくないので、考えが浅はかかもしれませんが...。

> なお、http://www.bugzilla.org/ に、netscape.public.mozilla.webtoolsがbugzillaのニュースグループだと書いてあります。

英語が苦手な下名なりに見てみましたが、該当するものを見つけることができませんでした。


Re[1]: Bugzillaのバグが消えた...。
(#4043) このトピック中4番目の投稿

Bugzilla のコードを見てないのでなんともいえないのですが
最近の MySQL ってテーブルタイプを昔からある MyISAM や
BDB, InnoDB から選択できますよね。

MySQL はテーブルサイズとかそれほど意識せずに使えますが
BDB や InnoDB はオプションの値として意識する必要がある
のでその辺りも確認してみてはいかがかと。

また、MySQL的に RH はあまり良いディストリビューションでは
ないようです。 RH7.2は判りませんが、それ以前のバージョン
の場合はなにかと問題があったそうです。
http://www.softagency.co.jp/mysql/TIPS/compile.html#redhat


Re[3]: Bugzillaのバグが消えた...。
(#4057) このトピック中5番目の投稿

>>http://www.bugzilla.org/ に、netscape.public.mozilla.webtoolsがbugzillaのニュースグループだと書いてあります。
> 該当するものを見つけることができませんでした。

ちょっと不親切だったかな(^^;
Discussion&Supportのリンクではいる、http://www.bugzilla.org/discussion.html です。
お使いのニュースサーバーにnetscape.public.mozilla.webtoolsがなければ、Mail&Newsで、ニュースサーバー=news.mozilla.orgでニュースアカウントを追加すればアクセスできます。
このニュースサーバーは、一般に公開されています。

なお、ラマヌじゃん!!さんも紹介なさっているサイトに、MySQL 3.23.49 のマニュアルの日本語訳があります。
その中に以下の記述がありました。
> 5.3.2 テーブル・ロッキングの問題
> MySQL のテーブル・ロッキングのコードはデッドロック・フリーです。
> MySQL はとても速いロックスピードを得るために、
> (レコードのロックやフィールドのロックの代わりに)
> テーブルのロックを使用します。大きなテーブルには、
> テーブルのロックはレコードのロックよりはるかに良いですが、
> いくつかの落とし穴があります。
> BDBとInnoDBのテーブルでは、LOCK TABLESを使用して明示的にテーブルを
> ロックするか、 ALTER TABLE のようなテーブル中のすべてのレコードを
> 修正するコマンドを実行した場合にのみ、MySQLはテーブル・ロッキングを
> 使用します。これらのテーブル・タイプについては、LOCK TABLES を
> 全く使用しないことを推奨します。
http://www.softagency.co.jp/mysql/Manual/mysql-3.23.49/manual.ja_MySQL_Optimization.html#Locking_Issues

MySQLではこの違いがあるために、アプリケーションによってはBDB/InnoDBでDBを作成してしまうと問題が起こる可能性があります。
DBの定義とかはBugzillaのインストールスクリプトでやっていてこれは無いと思いますが、念のため。

Re[2]: Bugzillaのバグが消えた...。
(#4225) このトピック中6番目の投稿

せっかく助言頂いたにも関わらずしばらく返答できなくて申し訳ありません。
(別の仕事がビジーになってしまって、手が回りませんでした。)

> Bugzilla のコードを見てないのでなんともいえないのですが
> 最近の MySQL ってテーブルタイプを昔からある MyISAM や
> BDB, InnoDB から選択できますよね。

MySQLは、初めて使ったので詳しいことはわからないのですが、
今回の場合は、テーブルの作成などはBugzillaのスクリプトは自動で
作成したものなので、大丈夫なのでは...と下名的には思っていました。
(wada様からも同じ指摘を受けました)
確認しましたが、Bugzillaで使っているテーブルはすべてMYISAMになって
いました。

> また、MySQL的に RH はあまり良いディストリビューションでは
> ないようです。 RH7.2は判りませんが、それ以前のバージョン
> の場合はなにかと問題があったそうです。
> http://www.softagency.co.jp/mysql/TIPS/compile.html#redhat

前にPostgreSQLをセットアップした際にも、同じような指摘を受けたような...。
やはり、RHのディストリビューションは、避けたほうが良いのでしょうか...。




Re[4]: Bugzillaのバグが消えた...。
(#4226) このトピック中7番目の投稿

せっかく助言頂いたにも関わらずしばらく返答できなくて申し訳ありません。
(別の仕事がビジーになってしまって、手が回りませんでした。)

> >>http://www.bugzilla.org/ に、netscape.public.mozilla.webtoolsがbugzillaのニュースグループだと書いてあります。
>>該当するものを見つけることができませんでした。
>
> ちょっと不親切だったかな(^^;
> Discussion&Supportのリンクではいる、http://www.bugzilla.org/discussion.html です。
> お使いのニュースサーバーにnetscape.public.mozilla.webtoolsがなければ、Mail&Newsで、ニュースサーバー=news.mozilla.orgでニュースアカウントを追加すればアクセスできます。
> このニュースサーバーは、一般に公開されています。

下名は、今までニュースを使ったことが無いので(笑われるかもしれませんが)詳しい
ことはわからないのですが、同ページのnetscape.public.mozilla.webtoolsのリンク
をクリックすると、Outlook Expressが起動して表示されたので、それらの内容を確認
しました(時間が取れなくて、まだ”ざっと”というところですが)。

> なお、ラマヌじゃん!!さんも紹介なさっているサイトに、MySQL 3.23.49 のマニュアルの日本語訳があります。
> その中に以下の記述がありました。
>>5.3.2 テーブル・ロッキングの問題
>>MySQL のテーブル・ロッキングのコードはデッドロック・フリーです。
>>MySQL はとても速いロックスピードを得るために、
>>(レコードのロックやフィールドのロックの代わりに)
>>テーブルのロックを使用します。大きなテーブルには、
>>テーブルのロックはレコードのロックよりはるかに良いですが、
>>いくつかの落とし穴があります。
>>BDBとInnoDBのテーブルでは、LOCK TABLESを使用して明示的にテーブルを
>>ロックするか、 ALTER TABLE のようなテーブル中のすべてのレコードを
>>修正するコマンドを実行した場合にのみ、MySQLはテーブル・ロッキングを
>>使用します。これらのテーブル・タイプについては、LOCK TABLES を
>>全く使用しないことを推奨します。
> http://www.softagency.co.jp/mysql/Manual/mysql-3.23.49/manual.ja_MySQL_Optimization.html#Locking_Issues
>

ラマヌじゃん!!さんからのご助言されたので確認しましたが、Bugzillaで使って
いるテーブルは、すべてMyISAMでした。



Re[5]: Bugzillaのバグが消えた...。
(#4232) このトピック中8番目の投稿

> ラマヌじゃん!!さんからのご助言されたので確認しましたが、Bugzillaで使って
> いるテーブルは、すべてMyISAMでした。
だとすると、ロッキングに絡むDBのレコードの消失とは考えにくいですね。

http://www.bugzilla.org/releases/2.16.1/release-notes.html の、
Bugzilla 2.16.1のリリースノートの*** Outstanding Issues Of Note ***のところには、
>- Renaming or removing keywords that are in use will not update
> the "keyword cache" on bugs, and queries on keywords may not work
> properly, until you rebuild the cache on the sanity check page
> (sanitycheck.cgi). The changer will receive a warning to do
> this when altering the keyword.
> (bug 69621)
>- If you search on any CC or added comments, as well as at least
> one other of CC, added comments, assignee, reporter, etc, then
> the search can be very slow. This is because of limitations of
> the MySQL optimiser.
> (bug 96101)
>- Querying on CC takes too long on big databases.
> (bug 127200)
>- Attachment changes have no midair collision detection, unlike bug changes.
> (bug 99215)
などが、書かれています。
複数のバグを同時に更新した後に、実際にそれらのバグのレコードが削除されてしまったというのではなく、
更新したはずのバグがその直後の検索でひっかからなかったとか、
検索のタイムアウトが起こっていて見つからない、ということはありませんか?
最後のbug 99215のコリジョンディテクションが関係すると、意図した更新がなされなかっただけ、ということも考えられます。



Re[6]: Bugzillaのバグが消えた...。
(#4235) このトピック中9番目の投稿

ご助言有難うございます。

英語が不得意なもので申し訳ありませんが、つまりは複数のレコードに例えば
コメントなどを一度に追加した場合には、レコードの更新に時間がかかるため
キャッシュの再構築が追いつかず、その直後の検索では引っかからないということで
しょうか?

実際に行ったことは、複数のバグに対して一度にコメントを付与して、その後
それらのバグのステータスを変更したのですが、
複数といっても5件くらいで、コメントも20文字くらいです。

その後、何度か検索しても引っかからないので、mysqlでbugs(Bugzilla DB)に
コネクトしてbugsテーブルにselectを投げましたが、やはりBugzillaで表示される
もの以外は消えていました。

やっぱ、”RHディストリビューションのMySQLは、お勧めできない”ということなので
しょうか...。



このトピックの全ページ / [0]

返信不可


- Child Tree -