タグ別アーカイブ: MySQL

コマンドラインのmysqlでmysqldからのメッセージが文字化けする

データベースの中身に入っているデータが文字化けするとかじゃないです。
ターミナルでサーバ機に接続して、そこからmysqlコマンドでデータベースに接続して、そこでSQLかちゃかちゃ打ち込んでたりすると、コマンドの実行結果そのものとは別にちょっとしたメッセージが出るじゃないですか。
えーといまいちわかりにくいですね、まあエラーメッセージに顕著なんですよ。

ERROR 1064 (42000): Something is wrong in your syntax  : ‘lock’ ノユカ・ : 1 ケヤフワ
ERROR 1141 (42000): ・譯シ・カ。シ ‘root’ (・ロ・ケ・ネ ‘%’ 、ホ・?・カ。シ) 、マオト、オ、・ニ、、、?サ、・
ERROR 1044 (42000): ・譯シ・カ。シ ‘root’@’localhost’ 、ホ ‘information_schema’ ・ヌ。シ・ソ・ル。シ・ケ、リ、ホ・「・ッ・サ・ケ、ン、キ、゙、ケ

とかこんな感じ。
で、これ前々から気にはなっていたんだけども、ずっと放置していて、まあいい加減直したいなと。
そこでまず、この文字化けの文字コードはなんだろうと。
SJISでもUTFでもないんだよなーっていじってたらでましたEUC。

mysql> grant lock tables on information_schema.* to root;
ERROR 1044 (42000): ユーザー ‘root’@’localhost’ の ‘information_schema’ データベースへのアクセスを拒否します

EUCとかどこにも使ってる覚えないんですけど、っていうかサーバ基本的にUTF8なんですけど、っていうことでしらべていたらこちらに答えが。

んで、「/etc/my.conf」の設定行をコメントアウトして、MySQLをリスタート、経過観察を繰り返すこと数回。

わ、わかりました。

以下のように、コメントアウトして試したところ、文字化けしたエラーメッセージが出なくなりました。

[mysqld]
#language = /usr/local/mysql/share/mysql/japanese

でも、日本語のエラーメッセージではなく、デフォルトの英語に戻ってしまった。

気になって、エラーメッセージを出力するソースを見てみたところ、Shift-JISとEUC-JPしか、用意されていないことが判明しました。
UTF-8の要求しても、EUC-JPの出力で返されていたので、文字化けが起こるのも当然だな

はい、うちでもlanguage設定しています。
MySQLはUTF-8で設定しています。
文字化けの文字コードはEUCでした。
完全に一致。

よし。コメントアウトして終わりと。

information_schemaのmysqldumpがうまくいかない

先日MySQLを5.0から5.1にバージョンアップしました。
出てることに気づいてなかったんです。
別にあげなくても困らないんですけど、なんとなくあたらしもの好きということで。
5.5はdebianだとexperimentalだったのでやめました。

で、まあ、5.1にしたらちょいちょい問題が出たんですけど、まあエラーログ眺めてなんとかしたんですよ。
skip-bdbオプションあったらうごかないとか。(たぶん削除されたんでしょう)
default-character-setがdeprecatedになってcharacter_set_server使えとか。

そんなこんなでとりあえずうごかしはじめて問題なさそうだったので数日、ふとroot宛てのメールを見ると日々cronで回しているmysqlのバックアップさんからエラー通知。

mysqldump: Got error: 1044: _桼____ ‘root’@’localhost’ __ ‘information_schema’ _ǡ____١____ؤΥ____________ݤ__ޤ_ when using LOCK TABLES

なんか化け化けですけど、とりあえずエラーコード1044ってことでいいすかね。

でまあ、ぐぐってみたら結構でてくる。
正しいエラーメッセージはこうらしい。

mysqldump: Got error: 1044: Access denied for user ‘root’@’localhost’ to database ‘information_schema’ when using LOCK TABLES

権限が無いといっているようにみえる。
rootなんですけど。。。

んで、解決策としては、mysqldumpのオプションに、–single-transactionをつければいいらしい。
LOCK TABLES権限をユーザに与えてもいいって書いてるところもあるんだけど、rootでやってるから全権限あるんすよね。
一応権限確認したら all on *.* だったし。
ということで、試してみたらいけた。

mysqldump –add-drop-database –add-drop-table -e –add-locks –quick –quote-names -u root –password=XXXXXXXXXX –single-transaction information_schema > /backup/information_schema.sql

みたいな感じで。
rootにgrantはしっぱいした。
ほかのユーザならうまくいくのかもね。

MySQLのテーブルの修復

この間久しぶりにCounterize IIの画面を開いた。
全然アクセス数とか気にしなくなっていたので気づくのが遅れたのだけども、いつからかわからないけどもずっとアクセスが0という扱いになっていた。
さすがにアクセス0ということはないので、おそらくデータベースに異常が発生しているんじゃないかと思った。
プラグインの異常ということも考えたけども、ぐぐってみても別にそういう話はヒットしなかったからだ。

で、テーブルの構造とかに間違いがないかを調べていたら、なにやら変なエラーが発生した。
ERROR 145 (HY000)
どういうエラーなのか調べてみたら、どうやらテーブルが破損しているということらしい。
MyISAMテーブルのチェックはmyisamchkでできる。
データベースのデータ格納ディレクトリで

myisamchk -e *.MYI

とかすればチェックできる。
でしらべてみると

Checking MyISAM file: wp_Counterize.MYI
Data records:  267703   Deleted blocks:       0
myisamchk: warning: 9 clients are using or haven't closed the table properly
- check file-size
myisamchk: warning: Size of datafile is: 12830392        Should be: 12830056
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
myisamchk: error: Found 267710 keys of 267703
- check records and index references
myisamchk: error: Record-count is not ok; is 267710       Should be: 267703
myisamchk: warning: Found     267710 parts                Should be: 267703 parts
MyISAM-table 'wp_Counterize.MYI' is corrupted
Fix it using switch "-r" or "-o"

とか出てきた。
そこで、

myisamchk -r wp_Counterize

としたところ、治った模様。

ところで、MySQLさんはテーブルに異常が発生していたら勝手に通知してくれたり修復してくれたりしないのだろうか。
まったくもって気づかなかった。
ログにこっそりはき出されていたりするのかな。
メール通知オプションとかほしいな。
あるのかもしれないけど調べる気もとりあえず今はないでござる。