Table 'テーブル' is marked as crashed and should be repaired

データベースへ接続してsqlを実行したときに

Table 'テーブル' is marked as crashed and should be repaired

というエラーが返ってきた。エラーの内容はテーブルがクラッシュしているから修復すべきということらしいが、そのテーブルは一度クラッシュしたのを修復を終えたばかりなのだが・・・。もう一度実行してみると何事もなくsqlの結果が返ってきた。どうも動作が不安定になっているような予感。レコード数が５０００万近くあるので気軽に修復するというわけにはいかないんだが。

mysqlのデータベースのテーブルから不要なフィールド（列）を削除

テーブルを再設計するために不要なフィールドを削除してみる。たしか前にフィールドを削除したときは、フィールドにインデックスが作成されている場合はフィールド削除の前にインデックスを削除しておかないとエラーが出たような記憶が・・・。今回はインデックスは削除済みなので問題は起こらないだろうという推測のもとにフィールドを削除してみる。

続きを読む mysqlのデータベースのテーブルから不要なフィールド（列）を削除

mysqlのテーブルから不要なインデックスを削除する

テーブルを設計し直すために不要なインデックスを削除してみることにする。

mysql> drop index idx1 on ac200902;
Query OK, 49398993 rows affected (4 hours 21 min 8.09 sec)
Records: 49398993  Duplicates: 0  Warnings: 0

レコード数が約４９００万もあったので１日ぐらいかかるのを予想していたが、約４時間半で完了できた。amd64クアッドコア２．１ＧＨｚが効いたのだろうか。

シティカードジャパンのご利用明細書がeステートメントに変わった

citiシティカードから毎月送られてくるカードの利用明細書が来なくなったのでどうしたのだろうかと思っていたら、どうやらメールにＰＤＦ形式のファイルを添付してくる方針に変わった模様。紙資源の節約ということでその方針には賛成する。しかし、その添付しているPDFファイルにパスワードロックがかかっていて、しかも１４桁ものパスワードを入力しないといけなくなっている。これはいくらなんでも大げさすぎると思う。パスワードがロック解除できないという問い合わせが激増しそうな気がするが。

シティバンク – eステートメント

mysqlのテーブルのクラッシュ


/usr/local/mysql/bin/myisamchk --recover --force --sort_buffer_size=2048M /usr/local/mysql/data/auc/200902.MYI

これでmysqlのテーブルがクラッシュしたのは２回目。前回は先月の中ごろだったので修復してから１ヶ月しかもたなかった。前回の修復作業はかなりの疲労を伴った。テーブルのレコード数が膨大であるためにいつ終わるのか見当もつかないから。テーブルのレコード数が４０００万でそのうち４つのフィールドにインデックスが作成されている。結局、修復にかかる時間は前回の作業で２０時間ほどかかった。今回はレコード数がそれより１０００万増えているため、修復にかかる時間はさらに要することが予想される。

続きを読む mysqlのテーブルのクラッシュ

mysqlへの接続が8時間後に切れる

java.lang.Exception: The last packet successfully received from the server was20910 milliseconds ago.The last packet sent successfully to the server was 20910 milliseconds ago, which is longer than the server configured value of ‘wait_timeout’. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property ‘autoReconnect=true’ to avoid this problem.

（翻訳）

最後の箱はうまくサーバーwas20910から受け取りましたミリ秒、最後の箱がうまくサーバーに送信したago.Theは20910ミリ秒前でした、サーバーが『wait_timeout』の価値を構成したより、長いです。あなたは、どちらの期限切れになっておよび／またはあなたのアプリケーションで使用の前に接続有効性をテストして、クライアントタイムアウトのためにサーバー構成された価値を増やすか、この問題を避けるためにConnector/Jコネクションのプロパティ『autoReconnect=true』を使うことを考慮しなければなりません。

tomcatのウェブアプリケーションでサーブレットを実行したときに上記エラーが発生した。mysqlの設定で、my.cnfファイルには wait_timeout=28800 という設定をしているのだけれど、エラー内容はその値を増やすか、autoReconnect=trueを設定しろということらしい。それをすれば上記エラーは発生しなくなるのかわからないが、とりあえず試してみる。http://www.jajakarta.org/tomcat/tomcat5.0/ja/docs/tomcat-docs/jndi-datasource-examples-howto.htmlのページを参考に、tomcatのコンテキストファイルのデータベース接続urlに

url=”jdbc:mysql://localhost/database?autoReconnect=true”

というパラメータを追加した。効果があるかどうかは様子見。

その後

java.net.ConnectException: Connection timed out
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
        at java.net.Socket.connect(Socket.java:519)
        at java.net.Socket.connect(Socket.java:469)

というエラーが発生したのをログにて確認した。context.xmlファイルのデータベース接続情報のパラメータへ、自動再接続の設定を有効にするようにして動作テスト。以下記述例。データベースのurlの末尾に?autoReconnect=trueというパラメータを追加した。この状態で稼動したところ、1日稼動したところデータベースへの接続関連のエラーは発生していないことが確認できた。とりあえずしばらくは様子見。

<Context path=”/” reloadable=”true” docBase=”ROOT”>

<Resource name=”jdbc/db”
auth=”Container”
type=”javax.sql.DataSource”
driverClassName=”com.mysql.jdbc.Driver”
url=”jdbc:mysql://localhost/db?autoReconnect=true”
username=”nakahira”
password=”nakahira-pass”
maxActive=”100″
maxIdle=”100″ />

</Context>

apache2の設定備忘録

mod_rewriteの有効化

mod_rewriteはurlをリダイレクトする処理に使う。apache2では下記コマンドで有効化を行う。


# a2enmod rewrite

proxy_ajpの有効化

proxy_ajpはapacheとtomcatを連携する場合に使う。ポート８０でのアクセスをtomcatの使うポート8080へ渡すために必要な設定。下記コマンドで有効化。


# a2enmod proxy_ajp