もりやです。

At Mon, 7 Jun 2004 21:26:21 +0900
とみたまさひろ <20040607212621.597663ab.tommy@xxxxxxxxxx>  wrote:
>
>> 私もググってみたところ以下の文献で
>> http://jp.xoops.org/modules/newbb/viewtopic.php?topic_id=3565&forum=11
>> 
>>    Re: フォーラム(newbb)の内容が表示されない
>>    私のところでも確認しました。
>>    どうもMySQLで3.xから4.Xに上げると
>>    一部実ファイルが壊れてしまうようです。
>>    (xoops_posts_text ,xoops_postは確認しました。)
>>    データ形式が変わるのでしっかりコンバートしないといけないのか
>>   それともコンバートすると駄目だったのかちょっと確認しないと・・・。
>> 
>> というのを見つけました。
>
>「データが壊れる」というのは、どのレイヤで壊れたってことなんでしょうか
>ね。リンク先の情報だけでは良くわかりません。

元記事読んでいないのと、元記事にフォーラムとは書いていないですが、
"フォーラム(newbb)の内容が表示されない"とあわせて、
アプリレイヤが一番可能性が高いと思います。
つまり、MySQLは正常。


CREATE TABLE bb_posts (
  post_id int(8) unsigned NOT NULL auto_increment,
  pid int(8) NOT NULL default '0',
..省略
  PRIMARY KEY  (post_id),
  KEY uid (uid),
  KEY pid (pid),
  KEY subject (subject(40)),
  KEY forumid_uid (forum_id, uid),
  KEY topicid_uid (topic_id, uid),
  KEY topicid_postid_pid (topic_id, post_id, pid),
  FULLTEXT KEY search (subject)
) TYPE=MyISAM;

CREATE TABLE xoops_bb_posts_text (
  post_id int(8) unsigned NOT NULL auto_increment,
  post_text text,
  PRIMARY KEY  (post_id),
  FULLTEXT KEY search (post_text)
) TYPE=MyISAM;

#他にも、thread用のtableありますが、可能性低いので省略


で、「データが壊れた」..の可能性として、高い順から

1) 
この1つのForum POSTで tableが2つになっている構造のため、
MySQLとしては正常だが、アプリとしては、整合性が取れていないので、
エラーとなっている。(対応するPOST本文がないなど)
実際には、dbは正常なのでdbレベルでのエラー表示はなく、
単にそのPOSTがなくなったように見える状態だったかな?
たぶん、スレッドは見えるけど、中身が見えないのがこの状態。

この分離構造は phpbb 1.xのもので、
(phpbbをforkしたものからのfork)
xoopsがphpnuke -> myphpnuke -> xoopsのfork時のphpbb version 1xから
そのままの構造になっているという流れの為です。
不必要で、いいとは思いませんが、INSERT時に、mysql_insert_id()で
取得しているので、通常は問題は発生しません。
ただ、整合性のために常に複数のSQLになるので、
元記事が、ストレスツール、自動テストツールなどでテストした場合には、
1つのSQLでのMySQL任せに比べると高い確率で発生すると思います。

あとは、使っていない(MATCH..AGAINSTなし) FULLTEXT 生成?
これが、"どうもMySQLで3.xから4.Xに上げると" という部分に関係あるのかも。



2)インデックスが壊れた。
修復しても、1)の状態だと、ユーザーからみたら、フォーラムは壊れている状態。
多くのユーザーがdbの状態を確認するのに、phpmyadminを使い、
phpmyadminだとインデックスエラーの時にも
"tableは使われています"などの固定エラーしか出ないので、
1)か2)なのかがレポートからは分かりにくい状態です。

XXXXXXのtableは確認しました..というのは、
phpmyadminではそのtableのfieldのデータは見えている。
(インデックスが壊れていれば見えない)
=> MySQLとしては正常  => アプリレイヤの問題
と考えるしかないですね。

フォーラムを再インストールしましたというのは、
その時点のMySQL Versionの db上で、TABLEを削除して(データとも)、
SQL文で再度 CREATE TABLEから行なったということです。
なので、この時点ではアプリ上での整合性は取れています。

しっかりコンバート???の意味はよく分かりません。



3)回復不可能。完全に壊れた。



なので、
通常よりは壊れやすい構造を持ったアプリが、たまたま壊れた。
アプリ上か、インデックスかは不明。
どちらも、ユーザーからみると、「壊れている」状態。


ここから、MySQLが...と判断するには、無理がある感じ。
元記事分かりませんが、db比較なら、adodbなど複数db対応
db layerを使ったアプリで、同じ条件でやる必要があるし。
実スクリプトでの耐久テストなら、別な要因が少なく、大きなサイトの
事例も多い、Forum系でやるべきだし。
#ロックは別話

>
>> 　これは、MySQL4.xのMyISAMの問題なのか。もしそうであればMySQL AB
>> に改善をお願いしないといけない点のように思います。

PHP+MySQLで、
xoopsなどのphpnuke系、他のCMS系、VB, IPBなどのForum系で
MySQL4.x MyISAMの問題はないと思います。

>
>myisamchk で修復しないといけないような状態なら MySQL の問題ですね。そ
>うでなくて、XOOPS でちゃんと動かないというだけなら、単純に XOOPS が 
>MySQL 4.0.X に対応していないという問題かもしれませんし。

どちらでもないですかね。
4.xの機能は使っていません。
他のスクリプトも同様ですが、同じものが、3.x(の最後)と4.xで動くのが殆ど
で、特に問題はないと思います。
(db自体のアップグレードをちゃんとやるかは、ユーザーの問題)
他のスクリプトの場合だと、db layerで3x 4xと別になっているものがあります。
この3x,4x両方対応は、スクリプトの対象である、共有サーバー、専用サーバー
(どちらもデータセンターがパッケージで構築する)の一部がまだ3.xだからだ
と思います。新規設置時は4.xなので、殆ど4.xですが。