InnoDBメモ

ブログ | 2010/11/27 13:26
パスは、Macportsでインストールしたもの。

[バックアップ]
mysqldumpでも、バックアップを取るようにする。
生データのバックアップでは、
/opt/local/var/db/mysql5/ibdata1
/opt/local/var/db/mysql5/ib_logfile0
/opt/local/var/db/mysql5/ib_logfile1
このあたりは必須。
http://dev.mysql.com/doc/refman/5.1/ja/innodb-ba...

my.cnfで、
innodb_file_per_table
を記述している場合も。
http://dev.mysql.com/doc/refman/5.1/ja/multiple-...

後から、innodb_file_per_tableを記述した場合は、OPTIMIZE TABLEすると作成される。
mysql> USE dbname;
mysql> OPTIMIZE TABLE table;
mysqlcheckでやる場合、
/opt/local/bin/mysqlcheck5 --user root --password=xxxxxx  -ao dbname [table1 table2 ...]

[my.cnf]
/opt/local/shar/mysql5/mysql/
の中に、いくつかサンプルがあるので参考に。後は検索しつつ。
http://www.mysqlpracticewiki.com/index.php/My.cn...

後で変えるのがやっかいそうな、innodb_data_file_path は悩むところだけれど、innodb_file_per_tableにすれば、膨張しないだろうから、デフォルトの10Mでいってみよう。
innodb_file_per_table
innodb_data_file_path = ibdata1:10M:autoextend

innodb_log_file_size のサイズを変えたときは、
ib_logfile0,ib_logfile1を移動するなりリネームするなり削除するなりして、MySQLを再起動。

[InnoDB Plugin]
http://nippondanji.blogspot.com/2010/03/innodb-p...
http://d.hatena.ne.jp/sh2/20100427

my.cnfに、下記を書く。(MySQL 5.1.38~, 正式版はMySQL 5.1.46~)
ignore-builtin-innodb  
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so

動いているかの確認は、
mysql> select @@innodb_version;

[移行]
http://dev.mysql.com/doc/refman/5.1/ja/convertin...
mysql> ALTER TABLE table ENGINE=INNODB;
or 新しいテーブルを作って、
SET UNIQUE_CHECKS=0;
INSERT INTO new_table SELECT * FROM old_table;
SET UNIQUE_CHECKS=1;
するとか。

実際の移行イメージは、
  • 事前準備として、MySQL 5.1.46以上に上げて、InnoDBを有効にする。
で、サイト毎に様子を見ながら移行。影響の小さいものからやるのがよいだろう。
  • サイトをメンテナンス中にする。
  • MyISAMのテーブルをバックアップ。
  • ALTER TABLEする。
  • サイト再開。
というところだろうか。1サイト、1時間以内でいけそうな気はするが、レプリケーションが壊れそう。

▼追記 2010/11/27 22:49
ううむ、Tigerの32bitだと、
innodb_buffer_pool_size を大きくできない。2Gも2000MもInnoDBが立ち上がらなかった。1536Mにしたら立ち上がった。
http://dev.mysql.com/doc/refman/5.1/ja/innodb-co...

snow leopardにすれば、64bitで動く。
InnoDB化を済ませて、様子を見つつ、Masterをどうするか考えよう。
▼追記 2010/11/28 16:59
30maps系のInnoDB化は、ほぼ終了。今のところ、いい感じで動いているように見える。

FULLTEXTを使っている全文検索系のMyISAMテーブルをどうするかを研究しよう。FULLTEXT系のテーブルが壊れたときのREPAIRは(これがしばしばおこる)、とても時間がかかってやっかいだから、InnoDBでの転置インデックス化を取り組んでみる。
▼追記 2010/11/29 03:18
rottelも完了。

InnoDB化で、レプリケーションの遅延がほとんど発生しなくなった。効果絶大だった。InnoDBの癖を把握して、徐々にクエリーも手を加えていこう。とりあえずは、全文検索を実装する。
▼追記 2010/11/29 13:22
メモリとのバランスに不安が残る。
apacheとmysqlは、サーバーを分けた方がいいのかもしれないけど、まだしない。
とりあえず、メモリが貧弱なマシンの innodb_buffer_pool_size を下げよう。
▼追記 2010/12/1 02:34
テーブルが大きくなってきて、大量のデータ挿入時の遅延が大きくなってきた。
ちょっと調べると、レプリケーション フォーマットなんていうもの発見。
http://dev.mysql.com/doc/refman/5.1/ja/replicati...

STATEMENTになっていたから、ROWに変更してみたけれど、速度は似たようなものなので、mixedにしとく。

http://nippondanji.blogspot.com/2009/03/mysql10....
にあるように、「一度に大量の更新をしない」ことですね。

検索インデックス作成のような大量のデータの更新は、usleep(300000) ...0.3秒とかを挟みながら、ゆっくり動かす。1日で20万件くらいは更新できるんじゃなかろうか。
▼追記 2010/12/1 23:50
レプリケーションのマニュアルにあるように、RAND()とかをつかったクエリーはやめた方がいい。
http://dev.mysql.com/doc/refman/5.1/ja/replicati...

UPLOAD table SET rid=RAND();
こういうような。各サーバーで値が違って構わなかったので(どちらかと言えば、そっちの方がランダムでいい)、そういうクエリーが存在していたのだけれど、InnoDBにして、1台のレプリケーションがそれ原因でしばしば止まった。MyISAMでは、遅延こそすれ動いていたけれども。

データの同一性という点では、こういうのもNG.
UPDATE table SET ts=UNIX_TIMESTAMP()
レプリケーション フォーマットがROWなら、同一になるようだけれど。

あと、
innodb_buffer_pool_size
innodb_log_file_size
は、Masterとslaveで同一にした方がいいとのこと。ほんとかな?
http://nippondanji.blogspot.com/2009/03/mysql10....

徐々に買い増ししていくスタイルだと、最新のものはどんどんスペックが上がっていくので、古い低スペックなものに揃えるのは、ちょっと悩ましい。

古いものはApache用にして、新しいものをMySQL用にするとかいう流れでいくべきなのかしら。そのあたりはmacmini群を眺めながらゆっくり検討。
▼追記 2010/12/6 22:48
InnoDBにして、phpMyAdminがかなり重たい。
サイドバーのテーブルリストの表示に、かなり時間がかかっている感じ。
いずれ調査。
縮小 拡大

ログインしておくと、後で編集が可能です。

Rottel内コンテンツ

ユーザー一覧

Rottelとは?
利用規約
開発飲料
利用者の声
ヘルプ
close