MySQL 5.1.30で、レプリケーションをしていて、トラブル発生。

MySQL 5.1.30で、レプリケーションをしていて、トラブル発生。

[ERROR] Error reading packet from server: Could not find first log file name in binary log index file ( server_errno=1236)
[ERROR] Got fatal error 1236: 'Could not find first log file name in binary log index file' from master when reading data from binary log

レプリケーションやってて、これは初めての症状。
masterで、対象のファイル。mysqlbinlogでみても、そのポジション以降のデータはある。

悩むこと２時間くらい。

masterの、mysql-bin.indexが

-rw-rw---- 1 mysql mysql 0 6月 30 03:00 mysql-bin.index

？
なんでゼロバイト？
手書きするのも気持ち悪いけど、しかたない。
mysql-bin.indexに、ファイル名を手書きしてあげると、slaveが復旧した！
  

tritonn(MySQL+Senna)で問題発生

tritonn-1.0.12-mysql-5.0.67-linux-x86_64.tar.gz

を開発マシンに。

mysql> use test;
Database changed

mysql> create table tritonn_test (name varchar( 10 ) not null) engine = myisam;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into tritonn_test (name) values (1);
Query OK, 1 row affected (0.00 sec)

mysql> select name from tritonn_test;
+------+
| name |
+------+
| 1 |
+------+
1 row in set (0.00 sec)

mysql> select distinct name from tritonn_test;
+------+
| name |
+------+
| 1 |
+------+
1 row in set (0.00 sec)

mysql> insert into tritonn_test (name) values (2);
Query OK, 1 row affected (0.00 sec)

mysql> select name from tritonn_test;
+------+
| name |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.01 sec)

mysql> select distinct name from tritonn_test;
ERROR 5 (HY000): Out of memory (Needed 2095128 bytes)

distinct使うと落ちる。。。

開発者mirさんの「Tritonn: 近況」によると、

従来のMySQL 5.0向けのTritonn(MyISAM+Senna)は大きなトラブル(落ちるバグなど)も無かったのでしばらくアップデートしていませんでしたが、こちらも来月あたりにアップデート版をリリースしようと思っています。

とのことなので、深追いはせずに、次のバージョンまでまとうっと
tritonn-1.0.10の5.0.51系だったら、問題なしだったので。
  

献本頂きました「PHP×携帯サイト 実践アプリケーション集」

日頃から、技術交流をはじめ、公私ともに仲良くしてくださってるマイネットジャパンの技術陣から、ケータイの技術本が出るということで、献本頂きました。ありがとうございます。

著者は、「katy・newsingの母 平島さん」「ITキング 伊藤さん」「絶対品質のPM 中元さん」（キャッチフレーズはマイネットジャパン メンバー紹介より）

正直、どんだけ会社の宣伝満載なんだろうと思って本を開きましたw（失礼

宣伝はほぼなく、一冊でこんなにもアプリケーションのサンプルのっけるかーって言うくらいのってます。

以下のサンプルアプリが収録されています
※サンプルコードCD付き
・ニュースサイトRSS表示
・簡易BBSアプリ
・絵文字対応BBS
・携帯ブログ
・写メールアルバム
・携帯電話にメール
・GPSとのマッシュアップ
・携帯SNS

Webな技術者向けの本です。

PCサイトを中心に携わっていて、
携帯サイトをずっと作ろうと思っていたが、まだ手を出せてない人。
ケータイサイト作ってるけど、絵文字まだ対応してないとか、
いろいろと満載なので、多くの人に実用的な内容になってます。


PHP×携帯サイト 実践アプリケーション集
著者：株式会社マイネット・ジャパン
販売元：ソフトバンククリエイティブ
発売日：2009-06-27
クチコミを見る
  

MySQL 5.4.0 betaまとめ

■新機能・マニュアル
MySQL 5.4 の概要（英語）
http://dev.mysql.com/tech-resources/articles/mysql-54.html

MySQL 5.4 の特徴のまとめ（英語）
http://dev.mysql.com/doc/mysql-5.4-features/en/index.html

MySQL 5.4 の特徴のまとめ の超超訳
http://d.hatena.ne.jp/sakaik/20090422/p1

MySQL 5.4 Reference Manual（英語）
http://dev.mysql.com/doc/refman/5.4/en/

MySQL 5.4!! MySQL Cluster 7.0!!
http://nippondanji.blogspot.com/2009/04/mysql-54-mysql-cluster-70.html


■ノウハウ
MySQL5.4.0にして、劇的にパフォーマンスUP
http://online.livedoor.biz/archives/51841362.html

MySQL5.1.30から、MySQL5.4.0betaアップグレード手順：簡易版
http://online.livedoor.biz/archives/51841721.html

MySQL5.4.0betaのアップグレードにおける、InnoDBでつまづいたところ
http://online.livedoor.biz/archives/51841679.html

MySQL 5.4.0インストール時の注意事項
http://online.livedoor.biz/archives/51844241.html


■ディスク別パフォーマンス比較
RAID vs SSD vs FusionIO | MySQL Performance Blog（英語）
http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/


■ダウンロード
MySQL 5.4 Downloads
http://dev.mysql.com/downloads/mysql/5.4.html


現時点ではまだベータなので、ご利用は計確定に。。  

18kのプログラムがサイトを落とす。apacheの脆弱性

Apacheに新たな脆弱性発見

この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。

ためしに、手元のサーバにテストでslowlorisでDDoS攻撃をやってみた。

処理前/server-status：まだまだサーバは受け付ける事ができる状態。

.407 requests/sec - 379 B/second - 930 B/request
1 requests currently being processed, 7 idle workers

___W____........................................................
................................................................
................................................................
...............................................................

投下

$ perl ./slowloris.pl -dns dev -port 80 -timeout 2000 -num 500 -tcpto 5

/server-statusが、Rでうまる。

.286 requests/sec - 292 B/second - 1024 B/request
153 requests currently being processed, 0 idle workers

RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRWSS.....................................
................................................................

ハイあうとーorz...
自宅サーババージョンはちょっと古いんだけど、

# /usr/sbin/httpd -v
Server version: Apache/2.2.9 (Unix)
Server built: Jul 14 2008 15:36:01

最新版の2.2.11でも、NGとのこと。

18kのperlのソースコードで、たいがいのサイト落としてしまうね。
困った困った。  

MySQL 5.4.0インストール時の注意事項

またまたmysql-5.4.0-betaのはなし。
どんだけ、MySQL 5.4.0すきやねんって言う状態だが、

インストールは「MySQL5.1.30から、MySQL5.4.0betaアップグレード手順：簡易版」こちらをみてもらうとして、インストールで、さっきはまったこと。

mysql-5.4.0-beta-linux-x86_64-glibc23

での、出来事。

開発マシンに入れた。

cannot execute binary file

とかゆうて、うごかない。。。

悩むこと３０分。

はっ、この開発マシン32bitだ！

いやーーー。オレよく気づいた！

・32bit/64bitのマシンが混在している（はず）
・今公開されている、MySQL5.4.0betaは、64bitのみ。

皆さんも気をつけて。

2009/06/26追記：
MySQL5.4.1Betaが公開されました。
これで、32bitにも入れることが可能になりました  

MeCabで複数のユーザ辞書を指定するには

MeCabで、ユーザ辞書を指定するには、

.mecabrc

の

userdic =

に、辞書ファイルを指定するんだけど、
複数指定するには、

http://mecab.sourceforge.net/dic.html

によると、

userdic = /home/foo/bar/foo.dic,/home/foo/bar2/usr.dic,/home/foo/bar3/bar.dic

とかいてるけど、「,」ではなく、「:」のようだ。。

userdic = /home/foo/bar/foo.dic:/home/foo/bar2/usr.dic:/home/foo/bar3/bar.dic

  

MySQL5.1.30から、MySQL5.4.0betaアップグレード手順：簡易版

環境や、やり方、ポリシーなど、人によって違うので、
こんなアップグレードはダメだ！と批判があるかもしれないが。
簡単に関連ファイルの上書きでバージョンアップした手順。

ちなみに、バイナリ版のMySQL5.1.30と、MySQL5.4.0betaで作業を行っている。

0.データベースの停止
例：/etc/rc.d/init.d/mysql stop

1.バックアップの作成
例：cp -r /usr/local/mysql /usr/local/mysql.5.1.30

2.MySQL5.4.0beta
例：mysql-5.4.0-beta-linux-x86_64-glibc23.tar.gz をダウンロード
tar zxvf mysql-5.4.0-beta-linux-x86_64-glibc23.tar.gz
cd mysql-5.4.0-beta-linux-x86_64-glibc23
\cp -r mysql-5.4.0-beta-linux-x86_64-glibc23/* /usr/local/mysql

3.権限設定変更
例：chown -R mysql:mysql /usr/local/mysql

4.起動
例：/etc/rc.d/init.d/mysql start

5.エラーがないか確認
例：cat /usr/local/mysql/data/$HOSTNAME.err

6.アップグレード
例：/usr/local/mysql/bin/mysql_upgrade

7.バージョン確認
例：
mysql> select version();
+----------------+
| version() |
+----------------+
| 5.4.0-beta-log |
+----------------+
1 row in set (0.00 sec)


※レプリケーションしているslaveサーバだと、
/usr/local/mysql/data/master.infoとかを、
移動しておいて、正常に稼動しているのを確認してから、
mysqlをとめて、master.infoをもどして、mysqlを起動するといい。
でないと、起動直後にレプリケーションはじめてしまう。
  

MySQL5.4.0betaのアップグレードにおける、InnoDBでつまづいたところ

まいどです。
フォートラベルでは、２０台のうち、１０台くらいMySQL5.4.0にしました。
ＣＰＵ使用率減って、処理も早くなって(ﾟДﾟ)ｳﾏｰ！
アクセスアップしますように（＝人＝）ナムー

今回MySQL5.130から、5.4.0betaにバージョンアップしたときに、InnoDB関連のエラーが出た。。
MyISAM/MyISAM パーティショニングを主に使ってきたので、
はっきりいって、InnoDBはあまり使っていないので、ノウハウが少ない。
識者の人には、当たり前の設定済みの設定であったり、エラーなのかもしれないし、恥ずかしいはなしだが。

MySQL5.4.0にアップグレード後、

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 134217728 bytes!
090619 15:14:01 [ERROR] Plugin 'InnoDB' init function returned error.
090619 15:14:01 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

こんなエラーが出ちゃった。
「innodbのログファイルのサイズがちゃうやんけ！( ﾟдﾟ)ゴラア」
まぁそんなこといいたいようだ。

-rw-r----- 1 mysql mysql 5242880 6月 18 12:06 ib_logfile0
-rw-r----- 1 mysql mysql 5242880 6月 18 02:08 ib_logfile1

（ちっ、ログやし消して起動しちゃえ）

rm -f ib_logfile0 ib_logfile1
/etc/rc.d/init.d/mysql start

を！！ちゃんと起動して、InnoDBも認識したぜ！

-rw-rw---- 1 mysql mysql 134217728 6月 19 15:15 ib_logfile0
-rw-rw---- 1 mysql mysql 134217728 6月 19 15:15 ib_logfile1
-rw-rw---- 1 mysql mysql 134217728 6月 19 15:15 ib_logfile2

原因はこちら。
http://dev.mysql.com/doc/mysql-5.4-features/en/availability-installation.html

If you upgrade to MySQL 5.4 from an existing MySQL 5.1 installation, an issue may occur due to InnoDB log file configuration changes. MySQL 5.4 increases the default value of innodb_log_files_in_group from 2 to 3. It also increases the default value of innodb_log_file_size from 5MB to 128MB and the minimum value of innodb_log_file_size from 1MB to 32MB.

日本語訳

5.1から、5.4にアップグレードするなら、InnoDBのコンフィグ次第では、問題起きるかも知れへんで。
innodb_log_files_in_groupのデフォルトが、2から3にかえたことと、innodb_log_file_sizeのデフォルトが、5MBから128MB。
そして、innodb_log_file_sizeの最小値を1MBから32MBまで増やしたで気をつけなはれ。

まぁそんな感じのようだ。
で、InnoDBの設定を十分にmy.cnfにかいてなかったしな。。InnoDBにつても勉強しないとなあ。

多くの人が遭遇する問題かどうかわからんけど、とりあえずお気をつけください。  

MySQL5.4.0にして、劇的にパフォーマンスUP←イマココ

フォートラベルでは、データベースにMySQLを２０台ほど使っています。

・ユーザさんが投稿したテキスト
・クリックなど大量のログ
・広告表示のインプレッションログ
・宿泊予約サイトの比較用の大量のデータ
それ以外にも沢山。書き出すと、きりがないくらいたくさんの
いろんなデータが蓄積されています。

新機能の開発だけではなく、より表示速度を上げるためや、大量のデータを処理する為に、
日々SQLや、PHPの処理の改善、テーブル構造の検討、サーバの設定変更、ネットワーク、サーバ構成を考え直したりもしています。

時には、RCや、betaのバージョンのMySQLをいれることも。
今回、数千万件のデータを処理するMySQLが一台いるのですが、
さすがに毎日毎日大量のデータを処理しているため、
こういうのはプログラムのチューニングをするのがなかなか不安たっぷりです。

MySQL5.4での目玉は、
・パーティショニング（5.1からありましたが）
・マルチコアのCPU効率アップ
・joinのパフォーマンスアップ

書き出すときりがないくらい気になる項目ばかりです。
パーティショニングは、導入して１年半になりますが、
使い方次第ではめっちゃくちゃすごいです。
５０００万件のtableのselectに２分かかってた処理が０．０５秒くらいになったりとか、パーティショニングしだいでガッツポーズが出るくらいの効果がありました。

今回MySQL5.4.0で、自社のベンチマークでかなりいい感じだったので、
一番データ量の多い、サーバにいれてみました。
で、これが導入前後のCPU使用率。

処理は全くかえていません。
無事流れていたSQLも修正なしに動きました。
CPUの使い方が半分くらいになりました。
これはやばいです。

さあ、4.x、5.0、5.1の皆さん、5.4の世界へ！！

ただし、バージョンアップは計画的に。。
バックアップ取ってね。

PS
innodbつかってるひとは気をつけて。。
この話は後日。