Planet MySQL http://www.planetmysql.org/ Sat, 07 Nov 2009 12:30:02 +0000 jp Planet MySQL - http://www.planetmysql.org/ XtraBackup Windows版 tag:blogger.com,1999:blog-7661288799334918410.post-5274568261047943188 http://buildup-db.blogspot.com/2009/11/xtrabackup-windows.html 今回は、速報なので短いです。「Linuxだけでたまたま動いていた感」のあるXtraBackupですが、私がいろいろ直しているうちに、最新revisionはWindowsでも動くようになったそうです！次のリリースではWindows版も出てくると思います。乞うご期待！！「そうです」というのは、私はWindowsの開発環境を持っていないし良く分からないので、寄せられたスタックトレースだけを頼りに気合いで直しています。しかし、それで良く動いたものです。。。。
「Linuxだけでたまたま動いていた感」のあるXtraBackupですが、私がいろいろ直しているうちに、最新revisionはWindowsでも動くようになったそうです！次のリリースではWindows版も出てくると思います。乞うご期待！！

「そうです」というのは、私はWindowsの開発環境を持っていないし良く分からないので、寄せられたスタックトレースだけを頼りに気合いで直しています。しかし、それで良く動いたものです。。。。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 06 Nov 2009 08:34:00 +0000 Yasufumi Kinoshita [ohamari][mysql] あるあるおハマり大事典 - InnoDBなのに行ロックしないの http://d.hatena.ne.jp/hirose31/20091106/1257493652 http://d.hatena.ne.jp/hirose31/20091106/1257493652 drop table if exists t; create table t ( iid int ,nid int ,bid binary(3) ,msg varchar(69) ,key (iid) ,key (bid) ) ENGINE=InnoDB; insert into t values (1,1,1,"ichi"),(2,2,2,"ni"),(3,3,3,"san") ,(4,4,4,"si"),(5,5,5,"go"),(6,6,6,"roku") ; なテーブルとデータで、2つ端末を用意して update しあいっこしてみます。 まず、これ↓は両方ともupdateが完了してスコっと返ってきます。行レベルロック++ begin; update t set msg = "t1" where iid = 1; と begin; update t set msg = "t2" where iid = 2; これ↓は、where句で使っているのが、インデックスがはられていないカラムなので、後発のクエリはすぐ返らず(先発のがcommit or rollback or タイムアウトするまで)待たされます。これも期待通り。 begin; update t set msg = "t1" where nid = 1; と begin; update t set msg = "t2" where nid = 2; で、おハマりしたのがこれ↓。intじゃなくてbinary型なんだけどちゃんとインデックスははってあるのになんでか後発のが待たされてしまいます。 begin; update t set msg = "t1" where bid = 1; と begin; update t set msg = "t2" where bid = 2; さて、どうして行レベルロックにならずに後発のクエリが待たされるのでしょうか？ 答えはこのあとすぐ！！ まだだよー そろそろいくよー explain select * from t where bid = 1\G とかするとわかるんですが、なんと「type: ALL」でフルテーブルスキャンになってます。なのでテーブル全体にロックがかかってると。 フルスキャンになる理由は、数値型→binary型への型変換がかかるせいかなと思います。 なので、 begin; update t set msg = "zero" where bid = '1\0\0'; と begin; update t set msg = "zero" where bid = '2\0\0'; とすると、後発のもすぐに返ってきます。 bid = 1 でもちゃんとマッチするので、型変換のことをずっぽし見落としてました＞＜ 今回も id:kazuhooku さんに多大なるご支援、ご協力を賜りましてほんとうにありがとうございました。 
drop table if exists t;

create table t (
  iid int
 ,nid int
 ,bid binary(3)
 ,msg varchar(69)
 ,key (iid)
 ,key (bid)
) ENGINE=InnoDB;

insert into t values
 (1,1,1,"ichi"),(2,2,2,"ni"),(3,3,3,"san")
,(4,4,4,"si"),(5,5,5,"go"),(6,6,6,"roku")
;

なテーブルとデータで、2つ端末を用意して update しあいっこしてみます。


まず、これ↓は両方ともupdateが完了してスコっと返ってきます。行レベルロック++

begin;
update t set msg = "t1" where iid = 1;
と
begin;
update t set msg = "t2" where iid = 2;

これ↓は、where句で使っているのが、インデックスがはられていないカラムなので、後発のクエリはすぐ返らず(先発のがcommit or rollback or タイムアウトするまで)待たされます。これも期待通り。

begin;
update t set msg = "t1" where nid = 1;
と
begin;
update t set msg = "t2" where nid = 2;

で、おハマりしたのがこれ↓。intじゃなくてbinary型なんだけどちゃんとインデックスははってあるのになんでか後発のが待たされてしまいます。

begin;
update t set msg = "t1" where bid = 1;
と
begin;
update t set msg = "t2" where bid = 2;

さて、どうして行レベルロックにならずに後発のクエリが待たされるのでしょうか？

答えはこのあとすぐ！！

















まだだよー

















そろそろいくよー

















explain select * from t where bid = 1\G

とかするとわかるんですが、なんと「type: ALL」でフルテーブルスキャンになってます。なのでテーブル全体にロックがかかってると。

フルスキャンになる理由は、数値型→binary型への型変換がかかるせいかなと思います。

なので、

begin;
update t set msg = "zero" where bid = '1\0\0';
と
begin;
update t set msg = "zero" where bid = '2\0\0';

とすると、後発のもすぐに返ってきます。

bid = 1 でもちゃんとマッチするので、型変換のことをずっぽし見落としてました＞＜

今回も id:kazuhooku さんに多大なるご支援、ご協力を賜りましてほんとうにありがとうございました。


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 06 Nov 2009 07:47:32 +0000 ひろせ まさあき Opensource Conference 2009 Tokyo/Fallに参加しました! http://blogs.mysql.com/teamapac/?p=255 http://blogs.mysql.com/teamapac/2009/11/04/opensource-conference-2009-tokyofall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ サン・マイクロシステムズは年間スポンサーとしてOSCを応援しています。去る10月30、31日に蒲田にて開催されたOpensource Conference 2009 Tokyo/Fall にサン・マイクロシステムズも参加しました。 この度のOSCは、2日間で約1,600名の参加者を迎え、大盛況のうちに幕を閉じました。 今回、サン・マイクロシステムズ企業セッション枠にはMySQLシニアエバンジェリストの梶山によるセッションが、また、MyNAコミュニティ枠でMySQLシニアサポートエンジニアの木村によるセッションがありました。 また、サン･マイクロシステムズの企業ブースでは、MySQLチームのメンバーが皆様をお迎えしました!ブースでは、MyQL 製品をはじめ、GlassFishやSun Open SSO製品をご紹介しました。システム運用管理、最適化、パフォーマンスチューニングを迅速に、かつ簡単に可能にする監視ツールであるMySQL Enterprise Monitor のデモもご覧いただきました。木村のセッションでも少しご案内しましたが、これは、MySQL コミュニティ版には含まれないEnterprise ツールです。この機会にぜひ、MySQL監視ツールについてももっと知っていただければ幸いです。 ブースにお立ちよりいただいた皆様、どうもありがとうございました! MySQLマスコットのイルカ(Sakila)は相変わらず、OSCでも大人気でした。 今後ともどうぞよろしくお願いたします。 三橋 サン・マイクロシステムズは年間スポンサーとしてOSCを応援しています。去る10月30、31日に蒲田にて開催されたOpensource Conference 2009 Tokyo/Fall にサン・マイクロシステムズも参加しました。
この度のOSCは、2日間で約1,600名の参加者を迎え、大盛況のうちに幕を閉じました。

今回、サン・マイクロシステムズ企業セッション枠にはMySQLシニアエバンジェリストの梶山によるセッションが、また、MyNAコミュニティ枠でMySQLシニアサポートエンジニアの木村によるセッションがありました。
また、サン･マイクロシステムズの企業ブースでは、MySQLチームのメンバーが皆様をお迎えしました!ブースでは、MyQL 製品をはじめ、GlassFishやSun Open SSO製品をご紹介しました。システム運用管理、最適化、パフォーマンスチューニングを迅速に、かつ簡単に可能にする監視ツールであるMySQL Enterprise Monitor のデモもご覧いただきました。木村のセッションでも少しご案内しましたが、これは、MySQL コミュニティ版には含まれないEnterprise ツールです。この機会にぜひ、MySQL監視ツールについてももっと知っていただければ幸いです。

ブースにお立ちよりいただいた皆様、どうもありがとうございました!
MySQLマスコットのイルカ(Sakila)は相変わらず、OSCでも大人気でした。

今後ともどうぞよろしくお願いたします。

三橋


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Wed, 04 Nov 2009 09:41:04 +0000 TeamApac 1 MySQL Clusterが苦手とするJOINを如何にして克服するべきか。 tag:blogger.com,1999:blog-1906500952232920237.post-4880651998551099912 http://nippondanji.blogspot.com/2009/11/mysql-clusterjoin.html シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコードのフェッチはネットワークを経由しなければいけないのでここがボトルネックになってしまう。例えば、2つのNDBストレージエンジン（MySQL Cluster）のテーブルをJOINする場合を考えよう。外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要があるとする。その場合、外部表から1回（1回のスキャンオペレーションでデータをフェッチできる）、内部表からM回のフェッチをしなければならない。1回のフェッチにつき、ネットワーク上をパケットが往復するわけであるから、InnoDBやMyISAMのように同一ホストから（特にメモリ上のキャッシュから）データをフェッチする場合と比べてJOINは不利なのである。ではMySQL ClusterにおいてJOINを高速化するにはどうすればいいだろうか？単純に「ネットワーク接続を高速化すればいいじゃないか。10GbEのNICを使えば？」などと思うかも知れない。それはある意味正しいが、正しいアプローチではないと思う。確かにJOINの性能は向上するのだが、10GbEとてレイテンシは無視できないので同一ホスト上のメモリからデータをフェッチする場合より遅いのは明らかである。少し話はそれるが、何かを処理するユニットを増強して（もしくはたくさん並べて）何とかしてしまおうというのは、いかにもBruteなやり方である。確かにハードウェアの性能向上はBruteなやり方でも良いと思うし、Bruteなやり方で成功した事例もたくさんある。例えばグラフィックスチップにたくさんの演算回路（シェーダ）を組み込んだり、ハイエンドサーバにCPUを満載したり、安価なマシンを並べてスケールアウトしたり。しかし、Bruteなアプローチではシステムの性能の限界はハードウェアの性能の限界によって頭打ちしてしまうことになる。だが一方で、ソフトウェアの性能向上を考える場合には、同じ条件のハードウェアで如何に高速化するかということを検討しなければならないと思う。つまり、もっとSmartなやり方でないといけない。ハードウェアはBruteに。ソフトウェアはSmartに。それがシステムを高速化する際のコツだろう。そんなわけで話は戻るが、つまり単純にネットワーク接続を高速化するのは、一定の効果は上がるがすぐに限界を迎えてしまう可能性が高いのである。現時点でも実装可能かつスマートなアプローチは、レプリケーションを利用することである。Kaj Arno氏のエントリでも紹介されているが、MySQL Clusterから通常のMySQL Serverへのレプリケーションを行い、JOINを伴う複雑なSELECTに関してはスレーブで実行することにより、複雑なSELECTを高速化するというテクニックが存在する。（詳細はKaj氏のブログエントリの図を参照して頂きたい。）スレーブへのレプリケーションは非同期なので、厳密な最新のデータに対するクエリは実行出来ないが、厳密な最新のデータが必要ない場合この方法は大抵うまくいく。システムの構築がちょっと面倒臭くなる以外弊害もない。複雑なクエリは集計データなどに利用されることが多いので、適用出来るシーンも多いだろう。この方法で気をつけるべきポイントは、replicate[-wild]-do-tableやreplicate[-wild]-ignore-tableオプションを利用して、複製するテーブルを限定することである。そうしないとndb_apply_statusテーブルへの更新が出来ないというエラーに見舞われてしまうことになる。MySQL Clusterテーブルを更新すると、バイナリログは自動的にmysql.ndb_apply_statusテーブルへの更新が含まれてしまう。このテーブルはNDBストレージエンジンで定義されているテーブルでMySQL Cluster同士のレプリケーションに利用されるのだが、MySQL Clusterから通常のMySQL Serverへレプリケーションする場合には不要などころかエラーの元凶になるだけなのできっちりとフィルタリングしておこう。例えば、worldデータベースに存在するテーブルだけを対象にしたい場合は、スレーブのmy.cnfに次のようにreplicate-wild-do-tableを使って記述するといいだろう。[mysqld]replicate-wild-do-table=world.%MySQL ClusterのSQLノード上で新規にテーブルを作成する場合、つまりCREATE TABLE tbl(...) ENGINE NDB;とした場合に、スレーブ側ではデフォルトのストレージエンジンが使用されることになる点にも注意したい。（通常のMySQL ServerにはNDBストレージエンジンは含まれていないからだ。）--storage-engineオプションを好みのもの（InnoDB等）に設定しておこう。しかし、MySQL Clusterの開発者たちは、JOINが遅いという現状をいつまでも放置しておくつもりはない。将来的にはMySQL ClusterのJOIN性能は大幅に改善される予定である。まず、近い将来に搭載される機能として挙げられるのがBKA（Batched Key Access）というJOIN最適化手法である。この方法では、これまで1+M回必要だったデータのフェッチが、最も効率的な場合にはたったの2回にまで減少する。2つのNDBテーブルのJOINにおいて外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要がある場合、BKAの動作は次のようになる。外部表からM行フェッチ（一回のスキャン）JOINに利用するキーの値をリストアップする。リストアップされたキーをNDBストレージエンジンにPush-Downする。内部表からN行フェッチ（一回のスキャン）内部表からレコードをフェッチする際、ICT（Index Condition Pushdown）という機能が利用されるのだが、ICTではストレージエンジンに対してフェッチしたい行を含むキーを一気に送信し、レコードを一気にフェッチするのである。その結果、MySQL Clusterではネットワーク上のパケット往復の回数が劇的に減少し、JOINの性能が向上するというわけだ。従って、BKAが実装された暁には、通常のMySQL Serverへレプリケーションするといった面倒な運用は一切不要になるだろう。少なくとも他のストレージエンジンと同等程度までJOINの性能が改善するはずであるから。BKAブラボー！！と思うかも知れない。しかし、そんなところで終わるようなMySQL Cluster開発チームではないのである！！実装されるのはかなり先になるだろうが、MySQL ClusterのJOINを劇的に高速化することが出来ると予想される機能が実装される見込みである。それはDbspjと呼ばれる機能であり、言うなれば「分散JOIN」とでも呼ぶべきシロモノである。かなり貪欲な性能の追求である。MySQL Clusterは分散型のRDBMSであるから、JOINの処理も分散して行えば良いじゃないかと考えるのが人情というもであるが、一方でそのような機能を実装するのは難しいということもまた事実である。（従って現時点ではそのような機能は実装されていない。）しかし難しいというのを理由にして諦めないのが真の漢。MySQL Cluster開発チームはこの難題にチャレンジしており、既に初期段階のテスト結果が開発者Jonas Oreland氏のブログで公表されている。ぶっちゃけ通常のJOINと比べると格段に速い。MySQL Clusterの正式リリースに搭載されるのはずっと先になるだろうが、楽しみな機能の一つである。 MySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。

ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコードのフェッチはネットワークを経由しなければいけないのでここがボトルネックになってしまう。

例えば、2つのNDBストレージエンジン（MySQL Cluster）のテーブルをJOINする場合を考えよう。外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要があるとする。その場合、外部表から1回（1回のスキャンオペレーションでデータをフェッチできる）、内部表からM回のフェッチをしなければならない。1回のフェッチにつき、ネットワーク上をパケットが往復するわけであるから、InnoDBやMyISAMのように同一ホストから（特にメモリ上のキャッシュから）データをフェッチする場合と比べてJOINは不利なのである。

ではMySQL ClusterにおいてJOINを高速化するにはどうすればいいだろうか？

単純に「ネットワーク接続を高速化すればいいじゃないか。10GbEのNICを使えば？」などと思うかも知れない。それはある意味正しいが、正しいアプローチではないと思う。確かにJOINの性能は向上するのだが、10GbEとてレイテンシは無視できないので同一ホスト上のメモリからデータをフェッチする場合より遅いのは明らかである。

少し話はそれるが、何かを処理するユニットを増強して（もしくはたくさん並べて）何とかしてしまおうというのは、いかにもBruteなやり方である。確かにハードウェアの性能向上はBruteなやり方でも良いと思うし、Bruteなやり方で成功した事例もたくさんある。例えばグラフィックスチップにたくさんの演算回路（シェーダ）を組み込んだり、ハイエンドサーバにCPUを満載したり、安価なマシンを並べてスケールアウトしたり。しかし、Bruteなアプローチではシステムの性能の限界はハードウェアの性能の限界によって頭打ちしてしまうことになる。だが一方で、ソフトウェアの性能向上を考える場合には、同じ条件のハードウェアで如何に高速化するかということを検討しなければならないと思う。つまり、もっとSmartなやり方でないといけない。ハードウェアはBruteに。ソフトウェアはSmartに。それがシステムを高速化する際のコツだろう。

そんなわけで話は戻るが、つまり単純にネットワーク接続を高速化するのは、一定の効果は上がるがすぐに限界を迎えてしまう可能性が高いのである。

現時点でも実装可能かつスマートなアプローチは、レプリケーションを利用することである。Kaj Arno氏のエントリでも紹介されているが、MySQL Clusterから通常のMySQL Serverへのレプリケーションを行い、JOINを伴う複雑なSELECTに関してはスレーブで実行することにより、複雑なSELECTを高速化するというテクニックが存在する。（詳細はKaj氏のブログエントリの図を参照して頂きたい。）スレーブへのレプリケーションは非同期なので、厳密な最新のデータに対するクエリは実行出来ないが、厳密な最新のデータが必要ない場合この方法は大抵うまくいく。システムの構築がちょっと面倒臭くなる以外弊害もない。複雑なクエリは集計データなどに利用されることが多いので、適用出来るシーンも多いだろう。

この方法で気をつけるべきポイントは、replicate[-wild]-do-tableやreplicate[-wild]-ignore-tableオプションを利用して、複製するテーブルを限定することである。そうしないとndb_apply_statusテーブルへの更新が出来ないというエラーに見舞われてしまうことになる。MySQL Clusterテーブルを更新すると、バイナリログは自動的にmysql.ndb_apply_statusテーブルへの更新が含まれてしまう。このテーブルはNDBストレージエンジンで定義されているテーブルでMySQL Cluster同士のレプリケーションに利用されるのだが、MySQL Clusterから通常のMySQL Serverへレプリケーションする場合には不要などころかエラーの元凶になるだけなのできっちりとフィルタリングしておこう。例えば、worldデータベースに存在するテーブルだけを対象にしたい場合は、スレーブのmy.cnfに次のようにreplicate-wild-do-tableを使って記述するといいだろう。

[mysqld]
replicate-wild-do-table=world.%

MySQL ClusterのSQLノード上で新規にテーブルを作成する場合、つまりCREATE TABLE tbl(...) ENGINE NDB;とした場合に、スレーブ側ではデフォルトのストレージエンジンが使用されることになる点にも注意したい。（通常のMySQL ServerにはNDBストレージエンジンは含まれていないからだ。）--storage-engineオプションを好みのもの（InnoDB等）に設定しておこう。

しかし、MySQL Clusterの開発者たちは、JOINが遅いという現状をいつまでも放置しておくつもりはない。

将来的にはMySQL ClusterのJOIN性能は大幅に改善される予定である。まず、近い将来に搭載される機能として挙げられるのがBKA（Batched Key Access）というJOIN最適化手法である。この方法では、これまで1+M回必要だったデータのフェッチが、最も効率的な場合にはたったの2回にまで減少する。2つのNDBテーブルのJOINにおいて外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要がある場合、BKAの動作は次のようになる。
  1. 外部表からM行フェッチ（一回のスキャン）
  2. JOINに利用するキーの値をリストアップする。
  3. リストアップされたキーをNDBストレージエンジンにPush-Downする。
  4. 内部表からN行フェッチ（一回のスキャン）
内部表からレコードをフェッチする際、ICT（Index Condition Pushdown）という機能が利用されるのだが、ICTではストレージエンジンに対してフェッチしたい行を含むキーを一気に送信し、レコードを一気にフェッチするのである。その結果、MySQL Clusterではネットワーク上のパケット往復の回数が劇的に減少し、JOINの性能が向上するというわけだ。従って、BKAが実装された暁には、通常のMySQL Serverへレプリケーションするといった面倒な運用は一切不要になるだろう。少なくとも他のストレージエンジンと同等程度までJOINの性能が改善するはずであるから。

BKAブラボー！！と思うかも知れない。
しかし、そんなところで終わるようなMySQL Cluster開発チームではないのである！！

実装されるのはかなり先になるだろうが、MySQL ClusterのJOINを劇的に高速化することが出来ると予想される機能が実装される見込みである。それはDbspjと呼ばれる機能であり、言うなれば「分散JOIN」とでも呼ぶべきシロモノである。かなり貪欲な性能の追求である。MySQL Clusterは分散型のRDBMSであるから、JOINの処理も分散して行えば良いじゃないかと考えるのが人情というもであるが、一方でそのような機能を実装するのは難しいということもまた事実である。（従って現時点ではそのような機能は実装されていない。）しかし難しいというのを理由にして諦めないのが真の漢。MySQL Cluster開発チームはこの難題にチャレンジしており、既に初期段階のテスト結果が開発者Jonas Oreland氏のブログで公表されている。ぶっちゃけ通常のJOINと比べると格段に速い。MySQL Clusterの正式リリースに搭載されるのはずっと先になるだろうが、楽しみな機能の一つである。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Wed, 04 Nov 2009 03:27:00 +0000 Mikiya Okuno roadmap mysql cluster mysql performance tuning [MySQL][Spider]Spider-2.8リリース tag:blogger.com,1999:blog-1243249875644802246.post-5855763114895604282 http://wild-growth-ja.blogspot.com/2009/11/mysqlspiderspider-28.html Spiderストレージエンジンのバージョン 2.8(beta)をリリースしました。Spiderストレージエンジンは、database sharding用のストレージエンジンです。http://spiderformysql.com/今回の主な変更は以下です。・テーブルパラメータに「link_status」を追加しました。　このパラメータにより、alter table文を利用してリンクの障害状況を変更することができます。　なお、Spiderのリンク障害状況管理は、テーブル単位で行われます。それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。 Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・テーブルパラメータに「link_status」を追加しました。
　このパラメータにより、alter table文を利用してリンクの障害状況を変更することができます。
　なお、Spiderのリンク障害状況管理は、テーブル単位で行われます。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 03 Nov 2009 22:11:00 +0000 斯波健徳 MySQL Spider 今週末はKOF(関西オープンソース決戦)2009 http://blog.kimuradb.com/?eid=817245 http://blog.kimuradb.com/?eid=817245 先週末はOSC2009Tokyo/Fallでしたが、今週末は場所を大阪に移し、関西オープンソース決戦(KOF)2009が11/6(Fri), 11/7(Sat)に行われます。 まずは11/6(Fri)にOSC2009Tokyo/Fallで行ったものと同じセミナーを行いますので、ご興味のある方は是非ご参加ください。 MySQL Workbenchを使ってみよう！〜MySQL GUI Toolsのご紹介〜
まずは11/6(Fri)にOSC2009Tokyo/Fallで行ったものと同じセミナーを行いますので、ご興味のある方は是非ご参加ください。

MySQL Workbenchを使ってみよう！〜MySQL GUI Toolsのご紹介〜
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 02 Nov 2009 14:51:26 +0000 MeijiK オープンソース GPLソフトウェアのパッチをBSDライセンスで提供することの意義 tag:blogger.com,1999:blog-1906500952232920237.post-1352708119926518083 http://nippondanji.blogspot.com/2009/11/gplbsd.html 先日の投稿「GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、単独で動かないパッチに元のと違うライセンスをつける感覚がよくわからない。という疑問が生じたらしい（ブコメ参照）ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろう。パッチのライセンスがBSDライセンスであれば、その機能をGPL以外のライセンスのソフトウェア、例えばBSDライセンスのPostgreSQLなどに追加するということも可能である。つまり、パッチをBSDライセンスにすることで、MySQLとPostgreSQLに同じ機能を追加するということが出来るわけだ。第二に、MySQLはデュアルライセンスなので、BSDライセンスで提供されたパッチであればGPL版とコマーシャルライセンス版の両方に機能を追加することが出来る。従って、BSDライセンスのパッチはMySQLにとっては都合が良いのである。（MySQLがデュアルライセンスを貫く以上、GPLで提供されたパッチは適用出来ないのである。）ちなみに、GPLソフトウェアであるMySQL 6.0からforkしたDrizzleも、全てのContributionはBSDライセンスのもとに行われている。（Drizzleに提供された全てのソースコードはBSDライセンスが適用されている。）従って、Drizzleに追加された全ての機能は、GPL版、コマーシャルライセンス版のいずれのMySQLにも取り込むことが出来るのである。また、DrizzleにContributeされたコードは、PostgreSQLなどの他のライセンスのRDBMSソフトウェアにも取り込むことが出来るので、PostgreSQLerの人は是非Drizzleのソースコードを覗いて見ると良いのではないだろうか。ただし、Drizzleでは積極的に外部のライブラリを取り込んで利用しようという方針があるので、外部のGPLが適用されたライブラリに依存した機能については、BSDライセンスによる利用は出来ない点には注意が必要である。（もちろん元のMySQL 6.0から残っているコードはPostgreSQLに取り込むことは出来ないので注意しよう。）さて、ここまで書くと「GPLよりBSDライセンスの方が優れている」ということを言い出す人が居るかも知れないので、この点について少し捕捉しておく。GPLとBSDライセンスを比較するのはハッキリ言って無意味である。確かにBSDライセンスの方が再利用出来るソフトウェアの範囲が広い。（商用、無償、プロプラエタリ、OSSを問わず利用可能である。）しかし一方で、GPLはソフトウェアの利用者に（それをカスタマイズすることを含めて）未来永劫最大限の自由を約束するライセンスであり、GPLを継承することによって再利用可能な場面が限定されることは、その自由を約束するために必要な措置なのである。つまり、GPLとBSDライセンスはそれぞれ異なる属性を持ったライセンス（かたやCopyleft、かたやPermissive）であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。 先日の投稿「GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、
単独で動かないパッチに元のと違うライセンスをつける感覚がよくわからない。
という疑問が生じたらしい（ブコメ参照）ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。

まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろう。パッチのライセンスがBSDライセンスであれば、その機能をGPL以外のライセンスのソフトウェア、例えばBSDライセンスのPostgreSQLなどに追加するということも可能である。つまり、パッチをBSDライセンスにすることで、MySQLとPostgreSQLに同じ機能を追加するということが出来るわけだ。

第二に、MySQLはデュアルライセンスなので、BSDライセンスで提供されたパッチであればGPL版とコマーシャルライセンス版の両方に機能を追加することが出来る。従って、BSDライセンスのパッチはMySQLにとっては都合が良いのである。（MySQLがデュアルライセンスを貫く以上、GPLで提供されたパッチは適用出来ないのである。）

ちなみに、GPLソフトウェアであるMySQL 6.0からforkしたDrizzleも、全てのContributionはBSDライセンスのもとに行われている。（Drizzleに提供された全てのソースコードはBSDライセンスが適用されている。）従って、Drizzleに追加された全ての機能は、GPL版、コマーシャルライセンス版のいずれのMySQLにも取り込むことが出来るのである。また、DrizzleにContributeされたコードは、PostgreSQLなどの他のライセンスのRDBMSソフトウェアにも取り込むことが出来るので、PostgreSQLerの人は是非Drizzleのソースコードを覗いて見ると良いのではないだろうか。ただし、Drizzleでは積極的に外部のライブラリを取り込んで利用しようという方針があるので、外部のGPLが適用されたライブラリに依存した機能については、BSDライセンスによる利用は出来ない点には注意が必要である。（もちろん元のMySQL 6.0から残っているコードはPostgreSQLに取り込むことは出来ないので注意しよう。）

さて、ここまで書くと「GPLよりBSDライセンスの方が優れている」ということを言い出す人が居るかも知れないので、この点について少し捕捉しておく。GPLとBSDライセンスを比較するのはハッキリ言って無意味である。確かにBSDライセンスの方が再利用出来るソフトウェアの範囲が広い。（商用、無償、プロプラエタリ、OSSを問わず利用可能である。）しかし一方で、GPLはソフトウェアの利用者に（それをカスタマイズすることを含めて）未来永劫最大限の自由を約束するライセンスであり、GPLを継承することによって再利用可能な場面が限定されることは、その自由を約束するために必要な措置なのである。つまり、GPLとBSDライセンスはそれぞれ異なる属性を持ったライセンス（かたやCopyleft、かたやPermissive）であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 01 Nov 2009 23:54:00 +0000 Mikiya Okuno oss mysql gpl postgresql OSC2009Tokyo/Fall 二日目 http://blog.kimuradb.com/?eid=817219 http://blog.kimuradb.com/?eid=817219 今回の会場となった日本工学院専門学校　蒲田キャンパス12号館は、各部屋がガラス張りで明るい感じです。校舎も綺麗。 展示はスポンサー展示も含めて2F, セミナーは3F. 廊下も広く導線もこんがらがず、会場提供感謝です。木村はサンのブースとMyNA/Firebirdのブース運営が主で、今回はあまりセミナー見学ができなかったのが少し残念でした。夕方にブースを全部みてまわりました。Sugar CRMからforkしたというvTigerは興味深かったですね。日本語化プロジェクトもすすんでいるということで、無償で使いたい方は是非！ OS自作ということでは、本と本人のユニークさが際だつ川合さんが有名ですが、安価なハードに、個人で読み切れるソースコードで実装されたKOZOSが気になりました。私も一時期、組み込み関連の仕事をしていたことがあるのですが、なかなかよいレファレンスがないんですよね。組み込みOS. すぐにでもやりたいですが、諸般の事情により、とりあえずメモ。



展示はスポンサー展示も含めて2F, セミナーは3F. 廊下も広く導線もこんがらがず、会場提供感謝です。木村はサンのブースとMyNA/Firebirdのブース運営が主で、今回はあまりセミナー見学ができなかったのが少し残念でした。夕方にブースを全部みてまわりました。Sugar CRMからforkしたというvTigerは興味深かったですね。日本語化プロジェクトもすすんでいるということで、無償で使いたい方は是非！

OS自作ということでは、本と本人のユニークさが際だつ川合さんが有名ですが、安価なハードに、個人で読み切れるソースコードで実装されたKOZOSが気になりました。私も一時期、組み込み関連の仕事をしていたことがあるのですが、なかなかよいレファレンスがないんですよね。組み込みOS. すぐにでもやりたいですが、諸般の事情により、とりあえずメモ。





PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sat, 31 Oct 2009 12:58:50 +0000 MeijiK MySQL OSC2009Tokyo/Fall 一日目 http://blog.kimuradb.com/?eid=817213 http://blog.kimuradb.com/?eid=817213 一日目はセミナーを行わせていただきました。ざっくりWorkbenchは上記Flashでお楽しみください。
一日目はセミナーを行わせていただきました。ざっくりWorkbenchは上記Flashでお楽しみください。
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 30 Oct 2009 12:28:27 +0000 MeijiK MySQL [MySQL][Spider]Spider-2.7リリース tag:blogger.com,1999:blog-1243249875644802246.post-8628662283418159585 http://wild-growth-ja.blogspot.com/2009/10/mysqlspiderspider-27.html Spiderストレージエンジンのバージョン 2.7(beta)をリリースしました。Spiderストレージエンジンは、database sharding用のストレージエンジンです。http://spiderformysql.com/今回の主な変更は以下です。・１Spiderテーブルに付き、複数リンクを生成し、ロックなし参照時にロードバランスするようになりました。ロードバランスのルールは((サーバID + スレッドID) % リンク数)で決定されます。　複数リンクを生成するには、「host」「user」「table」「server」「socket」「wrapper」「database」「password」のテーブルパラメータを記述する際に、半角スペース区切りで複数記述してください。　例：「host 'h1 h2 h3'」今後、SpiderでActive-Activeのクラスタ構成ができるようにするための、機能追加を行っていく予定です。それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。 Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・１Spiderテーブルに付き、複数リンクを生成し、ロックなし参照時にロードバランスするようになりました。ロードバランスのルールは((サーバID + スレッドID) % リンク数)で決定されます。
　複数リンクを生成するには、「host」「user」「table」「server」「socket」「wrapper」「database」「password」のテーブルパラメータを記述する際に、半角スペース区切りで複数記述してください。
　例：「host 'h1 h2 h3'」

今後、SpiderでActive-Activeのクラスタ構成ができるようにするための、機能追加を行っていく予定です。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Thu, 29 Oct 2009 18:28:00 +0000 斯波健徳 MySQL Spider GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。 tag:blogger.com,1999:blog-1906500952232920237.post-3912693617247541661 http://nippondanji.blogspot.com/2009/10/gplmysqlbsd.html Googleがリリースしている有名なMySQL 5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか？！ホントにそんなこと出来るのか？！Googleは何か間違ってるんじゃないか？！などと疑問に思われることだろう。結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。以下、GPLv2の日本語訳より抜粋。http://sourceforge.jp/projects/opensource/wiki/licenses/GNU_General_Public_License以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立 した著作物であると合理的に考えられるならば、あなたがそれらを別の著作物として分けて頒布する場合、そういった部分にはこの契約書とその条件は適用されない。しかし、あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わなければならない。というのは、この契約書が他の契約者に与える許可は『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべてを保護するからである。 よって、すべてあなたによって書かれた著作物に対し、権利を主張したりあなたの権利に異議を申し立てることはこの節の意図するところではない。むしろ、その趣旨は『プログラム』を基にした派生物ないし集合著作物の頒布を管理す る権利を行使するということにある。つまり、パッチとしてオリジナルのGPLソフトウェアから完全に切り離された部分に関しては、GPLが適用されないわけである。ただし、そのパッチをGPLソフトウェアに適用するためには、そのパッチはGPL互換のライセンス（例えばBSDライセンスなど）でリリースしなければならない。そして、それをオリジナルのGPLソフトウェアと合体した時点でGPLが適用される。つまり、GPLソフトウェア ＋ BSDLパッチ ＝ 改変されたGPLソフトウェアという関係が成り立つわけである。従って、件のGoogleパッチがBSDLでリリースされているのは、一切問題はないというわけであり、Googleパッチに含まれるソースコードはBSDライセンスで利用することが可能である。なぜ上記のような条項がGPLに盛り込まれているのか？と疑問を持たれることだろう。もし上記の条項がなければ、全ての変更はGPLを適用したソフトウェアで行わなければならず、従って他のライセンスでリリースされた優秀なソフトウェアやライブラリをGPLソフトウェアと組み合わせて利用することが出来ないという事態になってしまう。例えそれがFSFが作成した他のライセンス、例えばLGPLなどを適用したソフトウェアであっても！である。上記の条項があれば、ライセンス上は安全に他のGPL互換のライセンス（BSDライセンスなど）のソフトウェアとGPLライセンスのソフトウェアを組み合わせて別のソフトウェアを開発することが可能になる。まったくもってややこしい話であるが、オープンソースソフトウェアに携わる人間としてライセンスの組み合わせは避けて通ることが出来ない問題であり、数あるオープンソースライセンスの中でも最もシェアが多いのはGPLなので、GPLの互換性に関する知識は身につけておく必要があるだろう。GPLが嫌いな人は「GPL汚染」などと揶揄してとかくGPLソフトウェアに対して脊髄反射的な嫌悪を示すことが多いのだが、それはきっと未知なるものに畏怖の念を抱くのは人間の性だからであり、しっかりライセンスを読んでよく理解すれば何も恐れる必要はないのである。 有名なMySQL 5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか？！ホントにそんなこと出来るのか？！Googleは何か間違ってるんじゃないか？！などと疑問に思われることだろう。

結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。

以下、GPLv2の日本語訳より抜粋。
http://sourceforge.jp/projects/opensource/wiki/licenses/GNU_General_Public_License
以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立 した著作物であると合理的に考えられるならば、あなたがそれらを別の著作物として分けて頒布する場合、そういった部分にはこの契約書とその条件は適用されない。しかし、あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わなければならない。というのは、この契約書が他の契約者に与える許可は『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべてを保護するからである。 よって、すべてあなたによって書かれた著作物に対し、権利を主張したりあなたの権利に異議を申し立てることはこの節の意図するところではない。むしろ、その趣旨は『プログラム』を基にした派生物ないし集合著作物の頒布を管理す る権利を行使するということにある。

つまり、パッチとしてオリジナルのGPLソフトウェアから完全に切り離された部分に関しては、GPLが適用されないわけである。ただし、そのパッチをGPLソフトウェアに適用するためには、そのパッチはGPL互換のライセンス（例えばBSDライセンスなど）でリリースしなければならない。そして、それをオリジナルのGPLソフトウェアと合体した時点でGPLが適用される。つまり、

GPLソフトウェア ＋ BSDLパッチ ＝ 改変されたGPLソフトウェア

という関係が成り立つわけである。従って、件のGoogleパッチがBSDLでリリースされているのは、一切問題はないというわけであり、Googleパッチに含まれるソースコードはBSDライセンスで利用することが可能である。

なぜ上記のような条項がGPLに盛り込まれているのか？と疑問を持たれることだろう。もし上記の条項がなければ、全ての変更はGPLを適用したソフトウェアで行わなければならず、従って他のライセンスでリリースされた優秀なソフトウェアやライブラリをGPLソフトウェアと組み合わせて利用することが出来ないという事態になってしまう。例えそれがFSFが作成した他のライセンス、例えばLGPLなどを適用したソフトウェアであっても！である。上記の条項があれば、ライセンス上は安全に他のGPL互換のライセンス（BSDライセンスなど）のソフトウェアとGPLライセンスのソフトウェアを組み合わせて別のソフトウェアを開発することが可能になる。

まったくもってややこしい話であるが、オープンソースソフトウェアに携わる人間としてライセンスの組み合わせは避けて通ることが出来ない問題であり、数あるオープンソースライセンスの中でも最もシェアが多いのはGPLなので、GPLの互換性に関する知識は身につけておく必要があるだろう。GPLが嫌いな人は「GPL汚染」などと揶揄してとかくGPLソフトウェアに対して脊髄反射的な嫌悪を示すことが多いのだが、それはきっと未知なるものに畏怖の念を抱くのは人間の性だからであり、しっかりライセンスを読んでよく理解すれば何も恐れる必要はないのである。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Thu, 29 Oct 2009 17:21:00 +0000 Mikiya Okuno mysql gpl (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 http://d.hatena.ne.jp/kazuhooku/20091029/1256775791 http://d.hatena.ne.jp/kazuhooku/20091029/1256775791 InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベース専用サーバ (on linux) の場合は、 [mysqld] ... innodb_buffer_pool_size=3072M # innodbに割り振るメモリ。実メモリの75%程度 innodb_log_buffer_size=256M # あまり大きくしても意味がないような気がする... innodb_flush_log_at_trx_commit=0 # 毎秒１回データをディスクに書き出し innodb_flush_method=O_DIRECT innodb_file_per_table ... あたりが自分の好み。/etc/sysctl.conf も編集して、 vm.swappiness = 5 とか書いておくと、InnoDBのバッファプールがスワップアウトされる可能性が減って幸せになれる（ことがあるかも）。 linux 以外、あるいは Apache と同居させるような小規模な運用では、O_DIRECT せずに innodb_buffer_pool_size=512M # 実メモリの10-20%? innodb_log_buffer_size=128M innodb_flush_log_at_trx_commit=0 innodb_file_per_table として、OSのバッファキャッシュを使うという手もあると思う。そんなにいっぱいデータベース立てた経験ないけど、ベストプラクティスがどのあたりなのか興味があるので、あえて書いてみた。 なお、SATA HDDを使ってるようなケースでは、 % sudo hdparm -W 0 /dev/sda # 必要なら sdb や sdc も。 して、ディスクの書き込みバッファを無効化しておく必要がある（そうでないと電源断時にデータが壊れる）。これはデータベースソフトウェアに限らない話だけど。 参考: Open database life: MyISAMとInnoDBのどちらを使うべきか MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.4 InnoDB 起動オプションとシステム変数 MySQL5開拓団 - ストレージエンジンの吟味 (2) / KLab株式会社 Red Hat Knowledgebase: システムがメモリのキャッシュやバッファを解放せずにデータをスワップするのはなぜですか？

InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。

そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。

他のパラメータも含めて書いておくと、データベース専用サーバ (on linux) の場合は、

[mysqld]
...
innodb_buffer_pool_size=3072M     # innodbに割り振るメモリ。実メモリの75%程度
innodb_log_buffer_size=256M       # あまり大きくしても意味がないような気がする...
innodb_flush_log_at_trx_commit=0  # 毎秒１回データをディスクに書き出し
innodb_flush_method=O_DIRECT
innodb_file_per_table
...

あたりが自分の好み。/etc/sysctl.conf も編集して、

vm.swappiness = 5

とか書いておくと、InnoDBのバッファプールがスワップアウトされる可能性が減って幸せになれる（ことがあるかも）。

linux 以外、あるいは Apache と同居させるような小規模な運用では、O_DIRECT せずに

innodb_buffer_pool_size=512M      # 実メモリの10-20%?
innodb_log_buffer_size=128M
innodb_flush_log_at_trx_commit=0
innodb_file_per_table

として、OSのバッファキャッシュを使うという手もあると思う。そんなにいっぱいデータベース立てた経験ないけど、ベストプラクティスがどのあたりなのか興味があるので、あえて書いてみた。


なお、SATA HDDを使ってるようなケースでは、

% sudo hdparm -W 0 /dev/sda  # 必要なら sdb や sdc も。

して、ディスクの書き込みバッファを無効化しておく必要がある（そうでないと電源断時にデータが壊れる）。これはデータベースソフトウェアに限らない話だけど。


参考:

Open database life: MyISAMとInnoDBのどちらを使うべきか

MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.4 InnoDB 起動オプションとシステム変数

MySQL5開拓団 - ストレージエンジンの吟味 (2) / KLab株式会社

Red Hat Knowledgebase: システムがメモリのキャッシュやバッファを解放せずにデータをスワップするのはなぜですか？


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Thu, 29 Oct 2009 00:23:11 +0000 Kazuho Oku MySQLerのTwitterアカウントまとめ。 tag:blogger.com,1999:blog-1906500952232920237.post-828746493839010520 http://nippondanji.blogspot.com/2009/10/mysqlertwitter.html 松信氏の、MyISAMとInnoDBのどちらを使うべきかTwitterで話題になってたので簡単にまとめました。というエントリが人気を博しているが、松信氏が言うように最近はTwitterでMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitter、猫も杓子もTwitterという雰囲気である。従ってMySQLもTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ？！」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に入ってみたい人はぜひフォローして頂きたい。まずはオフィシャルなアカウント関係から。オフィシャルなアカウントメッセージを一方的に発信するだけなので、話題に入るのではなく、情報源として、つまりRT（Re−Tweet）の対象として活用して頂きたい。@mysql基本中の基本。新しいリリースやWebinarの告知などが行われる。特にバージョンアップによる新機能の追加は、話のネタには持ってこいなのでMySQLerは必ずフォローしよう。@planetmysql_jpこちらもMySQLerフォロー必須のアカウントである。コレはPlanet MySQL日本語版のフィードを呟くボットアカウントで、Planet MySQL日本語版に登録されているブログに記事が投稿される度にフィードを読み取って呟いてくれる。ブログ記事にツッコミを入れたりコメントしたり友人に広めたりするのに持ってこいだろう。なお、MySQL関連のブログを書いている人は是非Planet MySQLに登録しよう。ブログは見る人が居てナンボであるが、Planet MySQLに登録することでより多くの人に見て貰える機会が増えるからである。MySQLブロガーがPlanet MySQLに登録し、MySQLer全員がそのRSSを購読したり@planetmysql_jpをフォローすれば品質の高い情報交換が出来るようになるだろう。関連リンクPlanet MySQL日本語版 http://jp.planet.mysql.com/@planetmysqlこちらはPlanet MySQL英語版のボットアカウントである。英語が堪能なら是非こちらのアカウントもフォローしよう。英語圏におけるMySQLブログ記事の投稿数は相当なものであり、非常に質の高い情報が飛び交っている。英語の練習にもどうぞ。関連リンクPlanet MySQL英語版 http://planet.mysql.com/では続いて日本人MySQLerのアカウントを紹介しよう。友好的な人が多いので、気軽にフォローして突っ込んでみて頂きたい。@tmtms言わずと知れたとみた まさひろ氏。MyNAの会長にして日本最古参MySQLerのひとり。MySQL徹底入門の著者、MySQLにおける日本語文字コードの初期実装、なおかつ超^128重要なモジュールであるMySQL/Rubyの開発者としても知られる偉人である。（しかし本人は奇策・・・もとい気さくなひと）Rubykaigi 2009では「MySQL/Ruby終了のお知らせ」という楽しいプレゼンをして話題を呼んだ。これからはPure-Ruby実装であるRuby/MySQLを継続されるそうなので頑張って頂きたい。関連リンクMySQL/Ruby http://www.tmtm.org/en/mysql/ruby/README_ja.htmlRuby/MySQL http://www.tmtm.org/ja/ruby/mysql/README.htmlMySQL/Ruby終了のお知らせ http://www.slideshare.net/tmtm/mysqlrubyしあわせプログラマ http://d.hatena.ne.jp/tmtms/@sakaikMyNAのMLでおなじみの坂井氏。MySQL 徹底入門 第2版や、その他数多くのMySQL関連書籍の共著者として知られる。関連リンクsakaikの日々雑感～(C)編 http://d.hatena.ne.jp/sakaik/@ikdttrMySQLにおいて日本語フルテキストインデックスを使った検索を可能とする「Sennaストレージエンジン」の開発者である池田氏。最近はMySQL 5.1対応版の開発に忙しいらしい。早くでないかと心待ちにする毎日である。池田氏をフォローしたら「リリースマダー？」と呟くのを忘れてはならない。関連リンクTritonnプロジェクト http://qwik.jp/tritonn/mir the developer http://d.hatena.ne.jp/mir/@hirohama日本におけるMySQL Clusterの第一人者にして実力者の廣濱氏。カメラ好き、ガジェット好き、女好き^H^H^H^H。MySQL Clusterについて語ることの出来る貴重な人材である。関連リンクhirohama.mysql http://www.hirohama.biz/mysql/@kazuho天才エンジニアとして国際的な評価も高いサイボウズ・ラボの奥一穂氏。Q4Mストレージエンジン、Pacificドライバなど秀逸なソフトウェアを世に送り出している。ツッコミも的確で示唆的である。しかしそれでいて茶目っ気を忘れないというのが心憎い。関連リンクKazuho@Cybozu Labs http://developer.cybozu.co.jp/kazuho/コンピュータは想像力を刺激する 奥一穂さんのエンジニアライフ http://okyuu.com/ja/special/engineer07-kazuho彼氏がMyISAMを使ってた。別れたい... http://d.hatena.ne.jp/kazuhooku/20091027Q4M http://q4m.31tools.com/Pacificという名前の分散ストレージを作り始めた件 http://developer.cybozu.co.jp/kazuho/2009/06/pacific-18c7.html@yonekawaサイボウズ株式会社の米川氏。サイボウズはMySQLを利用するプロプラエタリソフトウェアの代表格である。関連リンクHappy Software Development http://yonekawa.livejournal.com/サイボウズ 職種別 社員インタビュー 開発本部 開発部 米川健一 http://cybozu.co.jp/company/job/recruitment/voice/11yonekawa.html@sh2ndOracleおよびInnoDBのエキスパート平塚氏。ブログでは度々気合いの入ったベンチマークなどをしてくれるのでwktk度高し。Rethink DBを真っ先に試すなど、人柱としても秀逸である。関連リンクSH2の日記 http://d.hatena.ne.jp/sh2/MySQL RethinkDB 0.1 試してみました http://d.hatena.ne.jp/sh2/20090916@kentokushibaスパイダーマンこと斯波氏。SPIDERストレージエンジンの開発者として有名である。最近はVertical Partitioningエンジン（カラムごとにパーティショニングをするタイプのストレージエンジン）の開発も精力的に行っている。関連リンクWild Growth日本語版 http://wild-growth-ja.blogspot.com/SPIDER for MySQL http://spiderformysql.com/Vertical Partitioning for MySQL http://launchpad.net/vpformysql@kazeburo大規模分散野郎Aチーム。Mixiの長野氏。Mixiのインフラを支える職人的DBAである。関連リンク横浜から渋谷方面に通勤するWeb EngineerのBlog http://blog.nomadscafe.jp/インフラエンジニア検討会2008 mixiや楽天の「中の人」、インフラエンジニアを語る http://www.atmarkit.co.jp/news/200812/08/infla.htmlmixi Engineer's Blog http://alpha.mixi.co.jp/blog/@tmaesakaMixiの前坂氏。Drizzleやmemcachedなどのプロジェクトにおいて精力的に活動している。長きにわたりニュージーランドに在住しているため英語はペラペラである。最近はTokyo Cabinetにデータを格納するDrizzle用ストレージエンジンであるBlitzDBの開発に勤しんでいる。関連リンクオープンソースの活動「すごく、いい」 前坂徹さんのエンジニアライフ http://okyuu.com/ja/special/engineer08-tmaesaka前坂氏のブログ（英語） http://torum.net/バイリンガルの独り言 http://ja.torum.net/BlitzDB https://launchpad.net/blitzdbDrizzle https://launchpad.net/drizzlememcached http://www.danga.com/memcached@stanakaとあるはてな社員こと田中氏。はてなを果てしなくスケーリング（注：ダジャレではありません。）関連リンクとあるはてな社員の日記 http://d.hatena.ne.jp/stanaka/@tokuhiromえとらぼ松野氏。だまってコードを書く人。関連リンクTokuLog 改めB日記 http://d.hatena.ne.jp/tokuhirom/広がれエンジニアの輪 第2回 松野徳大 -- 「だまってコードを書けよ」 http://jibun.atmarkit.co.jp/lcom01/rensai/comrade02/comrade01.html@hirose31えとらぼのひろせまさあき氏。ブログのネタはいつも秀逸。関連リンク(ひ)メモ http://d.hatena.ne.jp/hirose31/「ブラックボックスは不安でしょ」　ひろせまさあきさんのエンジニアライフ http://okyuu.com/ja/special/特集_No_okyuu_No_Life_第3回@ichii386GREEの一井氏。InnoDBラブなMySQLerが多い中で異色のMyISAMラヴ!!な逸材。一井氏曰く、分析計の処理にはMyISAMの取り回しの手軽さが便利とのこと。関連リンクいちいの日記 http://d.hatena.ne.jp/ichii386/Ethna×PHP (LLフレームワークBOOKS)お次はMySQLの中の人。まずは日本人から。@matsunobu言わずと知れたMySQLのコンサルタント松信氏。数多くの書籍を執筆し、印税でウハウハしているMySQLの普及に大きく貢献している。最近受けたOkyuu.comのインタビュー記事では、「夢はエンジニアに強い影響を与える本を書くこと」と述べているのは感心する志である。この調子でこれからも頑張って頂きたい。関連リンク夢はエンジニアに強い影響を与える本を書くこと　松信嘉範さんのエンジニアライフ http://okyuu.com/ja/special/engineer09-matsunobuOpen Database Life http://opendatabaselife.blogspot.com/@rkajiyamaトレーナーから技術支援まで幅広くこなすタフガイ梶山氏。日本語の（Webを含む）セミナーやイベントではまず梶山氏が登場するので、ご存じの方も多いのではないだろうか。APAC地域担当であるため、かなりの期間を海外で過ごしている。@meijik同じMySQLサポートエンジニアにしてキムラデービー代表の木村氏。カレーが大好きで、ランチはカレー率が非常に高い。ブログにもカレーの記事が満載である。たまにDB Magazine等の雑誌に記事を投稿している。また、OSS RDBMSとしてはMySQLだけでなくFirebird関連の活動も活発に行っている。現在Firebird（徹底）入門書籍執筆中。関連リンクキムラデービーブログ http://blog.kimuradb.com適材適所のデータベース選択が重要--Firebird日本ユーザー会 http://japan.zdnet.com/sp/interview/story/0,2000056426,20354736,00.htm@nippondanjiいわゆる俺。フォロー歓迎。続いて英語圏の中の人たち。英語が堪能ならぜひフォローを。@brianakerOSSの申し子Brian Aker氏。MySQLの各種ストレージエンジン（FEDERATED、ARCHIVE、Blackhole）、memcached、Drizzle、Gearmanなど、様々な実績を残している天才プログラマである。使用しているエディタはvim。MySQLに入社する条件として「絶対にノベルティのTシャツは着ない」というものを提示した頑固者。彼の語り口は非常にマイルドで、それでいて常に論理的である。Aker氏は尊子Richard Stallmanとディベートを行ったのだが、尊子よりも主張が論理的ですらあるように感じてしまうから驚きである。俺は二人とも大好きだ！関連リンクBRIAN AKER DEBATES WITH RICHARD STALLMAN http://www.bytebot.net/blog/archives/2009/10/25/brian-aker-debates-with-richard-stallmanBrian "Krow" Aker's Idle Thoughts http://krow.livejournal.com/@stewartsmith元MySQL Clusterの開発者にして、Drizzleの開発者Stewart Smith氏。写真ではオッサンっぽく見える場合もあるが実は結構若い。もちろん技術的にはエキスパートであり、彼のブログでは度々参考になる情報が掲載されているから見逃せない。関連リンクRamblings http://www.flamingspork.com/blog/@kajarnoMySQLコミュニティ担当副社長のKaj Arno氏。MySQLのスポークスパーソン的存在。MySQL ABがコミュニティと良好な関係を保ってこられたのは彼の功績によるところが大きい。Bad Newsを魔法のようにGood Newsに変えるともっぱらの噂である。関連リンクブログ http://blogs.mysql.com/kaj/@datacharmerMySQLコミュニティ担当のGiuseppe Maxia氏。Datacharmerというのは彼のニックネーム。ジュゼッペ氏はMySQL::Sandboxの作者としても知られる。MySQL::Sandboxは相当便利なので使うべし！関連リンクブログ http://datacharmer.blogspot.com/MySQL::Sandbox http://mysqlsandbox.net/@LenzGr同じくMySQLコミュニティ担当のLenz Grimmer氏。Planet MySQLを管理しているのは彼である。さらに中の人を紹介するが、以下はサポートチームの面々である。詳しい説明は省略する。@maximuscub俺の上司のLachlan。若くてマッチョなオーストラリア人。@adamtdixonAPAC地区でMySQL Clusterを担当しているAdam。@geertjanvdkEMEA地区でMySQL Clusterを担当しているGeert。@lathiat見たまんまギークなTrent。かなりの早口なので、脳をオーバークロックしている疑いが持たれている。@garypendergast長期休暇取得中のGary。今はイタリアを放浪しているらしい。しかし仕事はチョッパ。以下はその他の英語圏のMySQL関連アカウント。@jzawodn誉れ高き名著「High Performance MySQL」の著者、Jeremy Zawodny氏。元米Yahoo!のDBA。MySQLのレプリケーションで参照系の負荷を分散できる！ということを、実際のシステムで証明して見せたのは彼が最初ではないだろうか。関連リンクブログ http://jeremy.zawodny.com/blog/@martenmickos元MySQL ABのCEO、Marten Mickos氏。MySQLは技術者集団だが、Mickos氏は経営のプロ。惜しい人物を放出したものである。@launchpad_netMySQLの公開リポジトリをホスティングしているLaunchpadの公式アカウント。関連リンクLaunchpad http://launchpad.net/@KickfireMySQLを用いたDWHアプライアンスを販売している米Kickfire社の公式アカウント。KickfireはDWH用のストレージエンジンであるが、興味深いのは「SQLチップ」なるものを用いた専用のハードウェアで動作するるところ。汎用CPUでは達成できない性能を叩き出す。関連リンクKickfire http://www.kickfire.com/@webyogMySQLのGUIを販売するWebyog社のアカウント。関連リンクWebyog http://www.webyog.com/@PerconaMySQL Performance Blogでお馴染みのPercona社のアカウント。InnoDBの達人である木下氏が所属する会社でもある。（木下氏はPercona社にてXtraDBやXtraBackupの開発に勤しんでいる。オトコ的には木下氏にも呟いて貰いたいところである。）関連リンクPercona http://www.percona.com/MySQL Performance Blog http://www.mysqlperformanceblog.com/DB改造屋雑記 http://buildup-db.blogspot.com/というわけで、思いつくままにMySQLerなTwitterアカウントを並べてみたが、是非皆さんも彼らをフォローしてみて頂きたい。データベースを開発や運用でどう上手に使いこなすかということは、システム屋ないしはWeb系のエンジニアにとって非常に重要な課題である。Twitterを活用して情報を仕入れたりディスカッションに参加したりして、ぜひスキルアップに役立てて貰いたいものである。ここに挙げたアカウントはほんの一部であることを断っておく。実際にはまだまだこんなものではなくもっと大勢の優秀なMySQLerが存在する。もし、「この人が抜けてるだろ！」とか「俺も載せろ！」という方がいらっしゃったら、Twitterで@nippondanjiへこっそりとダイレクトメッセージを送って頂きたい。
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。

というエントリが人気を博しているが、松信氏が言うように最近はTwitterでMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitter、猫も杓子もTwitterという雰囲気である。従ってMySQLもTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。

しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ？！」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に入ってみたい人はぜひフォローして頂きたい。

まずはオフィシャルなアカウント関係から。オフィシャルなアカウントメッセージを一方的に発信するだけなので、話題に入るのではなく、情報源として、つまりRT（Re−Tweet）の対象として活用して頂きたい。

@mysql

基本中の基本。新しいリリースやWebinarの告知などが行われる。特にバージョンアップによる新機能の追加は、話のネタには持ってこいなのでMySQLerは必ずフォローしよう。

@planetmysql_jp

こちらもMySQLerフォロー必須のアカウントである。コレはPlanet MySQL日本語版のフィードを呟くボットアカウントで、Planet MySQL日本語版に登録されているブログに記事が投稿される度にフィードを読み取って呟いてくれる。ブログ記事にツッコミを入れたりコメントしたり友人に広めたりするのに持ってこいだろう。

なお、MySQL関連のブログを書いている人は是非Planet MySQLに登録しよう。ブログは見る人が居てナンボであるが、Planet MySQLに登録することでより多くの人に見て貰える機会が増えるからである。MySQLブロガーがPlanet MySQLに登録し、MySQLer全員がそのRSSを購読したり@planetmysql_jpをフォローすれば品質の高い情報交換が出来るようになるだろう。

関連リンク

@planetmysql

こちらはPlanet MySQL英語版のボットアカウントである。英語が堪能なら是非こちらのアカウントもフォローしよう。英語圏におけるMySQLブログ記事の投稿数は相当なものであり、非常に質の高い情報が飛び交っている。英語の練習にもどうぞ。

関連リンク

では続いて日本人MySQLerのアカウントを紹介しよう。友好的な人が多いので、気軽にフォローして突っ込んでみて頂きたい。

@tmtms

言わずと知れたとみた まさひろ氏。MyNAの会長にして日本最古参MySQLerのひとり。MySQL徹底入門の著者、MySQLにおける日本語文字コードの初期実装、なおかつ超^128重要なモジュールであるMySQL/Rubyの開発者としても知られる偉人である。（しかし本人は奇策・・・もとい気さくなひと）Rubykaigi 2009では「MySQL/Ruby終了のお知らせ」という楽しいプレゼンをして話題を呼んだ。これからはPure-Ruby実装であるRuby/MySQLを継続されるそうなので頑張って頂きたい。


関連リンク

@sakaik

MyNAのMLでおなじみの坂井氏。MySQL 徹底入門 第2版や、その他数多くのMySQL関連書籍の共著者として知られる。

関連リンク

@ikdttr

MySQLにおいて日本語フルテキストインデックスを使った検索を可能とする「Sennaストレージエンジン」の開発者である池田氏。最近はMySQL 5.1対応版の開発に忙しいらしい。早くでないかと心待ちにする毎日である。池田氏をフォローしたら「リリースマダー？」と呟くのを忘れてはならない。

関連リンク

@hirohama

日本におけるMySQL Clusterの第一人者にして実力者の廣濱氏。カメラ好き、ガジェット好き、女好き^H^H^H^H。MySQL Clusterについて語ることの出来る貴重な人材である。

関連リンク

@kazuho

天才エンジニアとして国際的な評価も高いサイボウズ・ラボの奥一穂氏。Q4Mストレージエンジン、Pacificドライバなど秀逸なソフトウェアを世に送り出している。ツッコミも的確で示唆的である。しかしそれでいて茶目っ気を忘れないというのが心憎い。

関連リンク

@yonekawa

サイボウズ株式会社の米川氏。サイボウズはMySQLを利用するプロプラエタリソフトウェアの代表格である。

関連リンク

@sh2nd

OracleおよびInnoDBのエキスパート平塚氏。ブログでは度々気合いの入ったベンチマークなどをしてくれるのでwktk度高し。Rethink DBを真っ先に試すなど、人柱としても秀逸である。

関連リンク

@kentokushiba

スパイダーマンこと斯波氏。SPIDERストレージエンジンの開発者として有名である。最近はVertical Partitioningエンジン（カラムごとにパーティショニングをするタイプのストレージエンジン）の開発も精力的に行っている。

関連リンク

@kazeburo

大規模分散野郎Aチーム。Mixiの長野氏。Mixiのインフラを支える職人的DBAである。

関連リンク

@tmaesaka

Mixiの前坂氏。Drizzleやmemcachedなどのプロジェクトにおいて精力的に活動している。長きにわたりニュージーランドに在住しているため英語はペラペラである。最近はTokyo Cabinetにデータを格納するDrizzle用ストレージエンジンであるBlitzDBの開発に勤しんでいる。

関連リンク

@stanaka

とあるはてな社員こと田中氏。はてなを果てしなくスケーリング（注：ダジャレではありません。）

関連リンク

@tokuhirom

えとらぼ松野氏。だまってコードを書く人。

関連リンク

@hirose31

えとらぼのひろせまさあき氏。ブログのネタはいつも秀逸。

関連リンク

@ichii386


GREEの一井氏。InnoDBラブなMySQLerが多い中で異色のMyISAMラヴ!!な逸材。一井氏曰く、分析計の処理にはMyISAMの取り回しの手軽さが便利とのこと。


関連リンク



お次はMySQLの中の人。まずは日本人から。

@matsunobu

言わずと知れたMySQLのコンサルタント松信氏。数多くの書籍を執筆し、印税でウハウハしているMySQLの普及に大きく貢献している。最近受けたOkyuu.comのインタビュー記事では、「夢はエンジニアに強い影響を与える本を書くこと」と述べているのは感心する志である。この調子でこれからも頑張って頂きたい。

関連リンク


@rkajiyama

トレーナーから技術支援まで幅広くこなすタフガイ梶山氏。日本語の（Webを含む）セミナーやイベントではまず梶山氏が登場するので、ご存じの方も多いのではないだろうか。APAC地域担当であるため、かなりの期間を海外で過ごしている。

@meijik

同じMySQLサポートエンジニアにしてキムラデービー代表の木村氏。カレーが大好きで、ランチはカレー率が非常に高い。ブログにもカレーの記事が満載である。たまにDB Magazine等の雑誌に記事を投稿している。また、OSS RDBMSとしてはMySQLだけでなくFirebird関連の活動も活発に行っている。現在Firebird（徹底）入門書籍執筆中。

関連リンク


@nippondanji

いわゆる俺。フォロー歓迎。


続いて英語圏の中の人たち。英語が堪能ならぜひフォローを。

@brianaker

OSSの申し子Brian Aker氏。MySQLの各種ストレージエンジン（FEDERATED、ARCHIVE、Blackhole）、memcached、Drizzle、Gearmanなど、様々な実績を残している天才プログラマである。使用しているエディタはvim。MySQLに入社する条件として「絶対にノベルティのTシャツは着ない」というものを提示した頑固者。彼の語り口は非常にマイルドで、それでいて常に論理的である。Aker氏は尊子Richard Stallmanとディベートを行ったのだが、尊子よりも主張が論理的ですらあるように感じてしまうから驚きである。俺は二人とも大好きだ！

関連リンク

@stewartsmith

元MySQL Clusterの開発者にして、Drizzleの開発者Stewart Smith氏。写真ではオッサンっぽく見える場合もあるが実は結構若い。もちろん技術的にはエキスパートであり、彼のブログでは度々参考になる情報が掲載されているから見逃せない。

関連リンク

@kajarno

MySQLコミュニティ担当副社長のKaj Arno氏。MySQLのスポークスパーソン的存在。MySQL ABがコミュニティと良好な関係を保ってこられたのは彼の功績によるところが大きい。Bad Newsを魔法のようにGood Newsに変えるともっぱらの噂である。

関連リンク

@datacharmer

MySQLコミュニティ担当のGiuseppe Maxia氏。Datacharmerというのは彼のニックネーム。ジュゼッペ氏はMySQL::Sandboxの作者としても知られる。MySQL::Sandboxは相当便利なので使うべし！

関連リンク

@LenzGr

同じくMySQLコミュニティ担当のLenz Grimmer氏。Planet MySQLを管理しているのは彼である。


さらに中の人を紹介するが、以下はサポートチームの面々である。詳しい説明は省略する。

@maximuscub

俺の上司のLachlan。若くてマッチョなオーストラリア人。

@adamtdixon

APAC地区でMySQL Clusterを担当しているAdam。

@geertjanvdk

EMEA地区でMySQL Clusterを担当しているGeert。

@lathiat

見たまんまギークなTrent。かなりの早口なので、脳をオーバークロックしている疑いが持たれている。

@garypendergast

長期休暇取得中のGary。今はイタリアを放浪しているらしい。しかし仕事はチョッパ。


以下はその他の英語圏のMySQL関連アカウント。

@jzawodn

誉れ高き名著「High Performance MySQL」の著者、Jeremy Zawodny氏。元米Yahoo!のDBA。MySQLのレプリケーションで参照系の負荷を分散できる！ということを、実際のシステムで証明して見せたのは彼が最初ではないだろうか。

関連リンク

@martenmickos

元MySQL ABのCEO、Marten Mickos氏。MySQLは技術者集団だが、Mickos氏は経営のプロ。惜しい人物を放出したものである。

@launchpad_net

MySQLの公開リポジトリをホスティングしているLaunchpadの公式アカウント。

関連リンク

@Kickfire

MySQLを用いたDWHアプライアンスを販売している米Kickfire社の公式アカウント。KickfireはDWH用のストレージエンジンであるが、興味深いのは「SQLチップ」なるものを用いた専用のハードウェアで動作するるところ。汎用CPUでは達成できない性能を叩き出す。

関連リンク

@webyog

MySQLのGUIを販売するWebyog社のアカウント。

関連リンク

@Percona

MySQL Performance Blogでお馴染みのPercona社のアカウント。InnoDBの達人である木下氏が所属する会社でもある。（木下氏はPercona社にてXtraDBやXtraBackupの開発に勤しんでいる。オトコ的には木下氏にも呟いて貰いたいところである。）

関連リンク

というわけで、思いつくままにMySQLerなTwitterアカウントを並べてみたが、是非皆さんも彼らをフォローしてみて頂きたい。データベースを開発や運用でどう上手に使いこなすかということは、システム屋ないしはWeb系のエンジニアにとって非常に重要な課題である。Twitterを活用して情報を仕入れたりディスカッションに参加したりして、ぜひスキルアップに役立てて貰いたいものである。ここに挙げたアカウントはほんの一部であることを断っておく。実際にはまだまだこんなものではなくもっと大勢の優秀なMySQLerが存在する。もし、「この人が抜けてるだろ！」とか「俺も載せろ！」という方がいらっしゃったら、Twitterで@nippondanjiへこっそりとダイレクトメッセージを送って頂きたい。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Wed, 28 Oct 2009 14:29:00 +0000 Mikiya Okuno mysql twitter 一家に一冊。あのオプションなんだっけ？と思った時のために備えて。- #書評_ - MySQL全機能バイブル tag:blogger.com,1999:blog-1906500952232920237.post-7575233764412740027 http://nippondanji.blogspot.com/2009/10/mysql.html 著者鈴木啓修様より献本御礼。（←一度言ってみたかったｗ）本書は鈴木氏の前著である「MySQL全機能リファレンス」からのアップデートであるが、この度は最新バージョンであるMySQL 5.1対応になっての登場である。今の時代、一家に一台テレビがあるように、はたまたパソコンがあるように、いやいや冷蔵庫があるように、一家に一冊本書があってもいいのではなかろうか。MySQLがオフィシャルに提供しているリファレンスマニュアルを除いて、MySQLをここまで網羅的に解説している書籍を私は知らない。その網羅性は目次だけで13ページも費やしていることからも、容易に想像出来ることだろう。もくじを見ただけでもその網羅性がよく分かるだろう。このもくじを書いただけで既に腕がつりそうである。Chapter 01 イントロダクション■■　概要1-01 MySQL™とは1-02 MySQLの概要1-03 データベースシステムの構造1-04 ストレージエンジンChapter 02 MySQLの内部構造■■　プロセスとメモリ構造2-01 プロセス構造2-02 メモリ構造■■　問い合わせ処理2-03 問い合わせ処理2-04 プランナ2-05 MyISAMのエクゼキュータ処理■■　データベースディレクトリの構造2-06 データベースディレクトリの構造■■　テーブルの構造2-07 MyISAM型2-08 InnoDB型■■　トランザクションの隔離レベル2-09 トランザクションの隔離レベル■■　INSERT DELAYED文2-10 INSERT DELAYED文■■　クエリキャッシュ（Query Cache）2-11 クエリキャッシュ（Query Cache）Chapter 03 MySQLのインストール3-01 インストール準備3-02 インストールChapter 04 MySQLサーバ管理■■　イントロダクション4-01 MySQLサーバ管理■■　初期設定4-02 初期設定■■　サーバの起動/停止4-03 MySQLサーバの起動と停止4-04 MySQLサーバの起動4-05 MySQLサーバの停止4-06 MySQLサーバをデーモンとして起動する■■　データベースユーザ管理4-07 MySQLにおけるデータベースユーザの概念4-08 データベースユーザの管理■■　システム変数の設定4-09 システム変数の設定4-10 サーバの動作に関するシステム変数4-11 通信関連のシステム変数4-12 問い合わせ処理に関するシステム変数4-13 ストレージエンジン関連のシステム変数4-14 ログ関連のシステム変数4-15 表示や文字コードに関連するシステム変数4-16 SQL_MODE4-17 レプリケーション関連のシステム変数4-18 その他のシステム変数■■　ストレージエンジン4-19 MyISAM型4-20 InnoDB型4-21 MEMORY型（旧 HEAP型）4-22 パーティション■■　ログ4-23 ログファイル4-24 バイナリログ（binary log）4-25 スロークエリのログ（slow query log）4-26 一般クエリログ（general query log）■■　データベースのダンプ/リストア4-27 データベースのダンプ/リストア（再構築）4-28 ファイル群のコピーによるダンプ/リストア4-29 mysqldumpによるダンプ/リストア■■　管理ツール4-30 mysqladminとは4-31 データベースの作成/削除4-32 サーバの情報表示4-33 FLOSH/RELOAD4-34 パスワードの変更4-35 スレーブ機能の開始/停止4-36 mysqlcheck■■　文字コード4-37 MySQLのサポートする文字コード4-38 文字コードの設定と確認■■　レプリケーション4-39 レプリケーションとは4-40 MySQLにおけるレプリケーションの仕組み4-41 レプリケーションの設定4-42 運用/管理■■　クエリキャッシュ4-43 クエリキャッシュ（Query Cache）Chapter 05 mysqlの使い方■■　mysqlの使い方5-01 mysqlの使い方■■　mysqlの起動オプション5-02 MySQLサーバとの接続と切断5-03 表示と結果出力5-04 バッチ処理とSQL文の実行5-05 実行制御■■　mysqlのメタコマンド5-06 再接続と切断5-07 表示の制御5-08 バッチファイルの処理,および結果のファイル出力5-09 SQL文の編集と表示5-10 プロンプト5-11 接続中のセッション情報を表示Chapter 06 SQL■■　SQL6-01 SQL文一覧6-02 語彙■■　データベースの作成/削除/接続6-03 データベースの作成 CREATE DATABASE6-04 データベースの削除 DROP DATABASE6-05 データベースの属性変更 ALTER DATABASE6-06 データベースの一覧表示 SHOW DATABASES6-07 データベースへの接続 USE■■　テーブルの作成/削除6-08 テーブルの作成 CREATE TABLE6-09 テーブルの削除 DROP TABLE■■　テーブルの情報表示6-10 テーブル定義（テーブルスキーマ）の表示 SHOW CREATE TABLE6-11 列の属性を表示 SHOW COLUMNS FROM/SHOW FIELDS FROM/DESCRIBE/DESC6-12 テーブルの一覧表示 SHOW TABLES6-13 テーブルの情報表示 SHOW TALBE STATUS■■　テーブルの属性変更6-14 テーブル属性の変更 ALTER TABLE6-15 列の追加と削除 ALTER TABLE ADD COLUMN/ALTER TABLE DROP COLUMN6-16 インデックスの追加と削除 ALTER TABLE ADD INDEX|CREATE INDEX/ALTER TABLE DROP INDEX|DROP INDEX6-17 主キーの追加と削除 ALTER TABLE ADD PRIMARY KEY/ALTER TABLE DROP PRIMARY KEY6-18 一意性制約の追加 ALTER TABLE ADD UNIQUE6-19 外部キー制約の追加と削除 ALTER TABLE ADD FOREIGN KEY/ALTER TABLE DROP FOREIGN KEY6-20 デフォルト値の設定と削除 ALTER TABLE ALTER SET DEFAULT/ALTER TABLE ALTER DROP DEFAULT6-21 列定義、列名の変更 ALTER TABLE MODIFY COLUMN/ALTER TABLE CHANGE COLUMN6-22 テーブル名の変更 ALTER TABLE RENAME6-23 テーブル名の変更 RENAME TABLE■■　データベースユーザの作成と削除6-24 データベースユーザの作成と削除 CREATE USER/DROP USER■■　データベースユーザの管理6-25 データベースユーザの権限設定と削除 GRANT/REVOKE6-26 データベースユーザの権限表示 SHOW GRANTS■■　データの挿入6-27 データの挿入 INSERT6-28 データの挿入 REPLACE■■　SELECT6-29 データの検索 SELECT6-30 重複する行を削除 DISTINCT6-31 FROM句6-32 テーブル結合 CROSS JOIN/INNER JOIN/OUTER JOIN6-33 WHERE句6-34 グループ化 GROUP BY, HAVING6-35 検索結果の並び替え ORDER BY6-36 検索結果の出力範囲を指定 LIMIT, OFFSET6-37 排他的六句と共有ロック FOR UPDATE/LOCK IN SHARE MODE6-38 問い合わせの結合 UNION6-39 副問い合わせ■■　データの更新6-40 データの更新 UPDATE■■　データの削除6-41 データの削除 DELETE6-42 全データの削除 TRUNCATE■■　式や関数の実行6-43 式や関数の実行 DO■■　プリペアードステートメント6-44 プリペアードステートメントの準備、実行、削除 PREPARE/EXECUTE/DEALLOCATE PREPARE■■　問い合わせ計画の表示6-45 問い合わせ計画の表示 EXPLAIN■■　ストアドプロシージャ・ストアドファンクション6-46 ストアドプロシージャ・ストアドファンクションの定義表示 SHOW CREATE PROCEDURE/SHOW CREATE FUNCTION6-47 ストアドプロシージャ・ストアドファンクションの状態表示 SHOW PROCEDURE STATUS/SHOW FUNCTION STATUS■■　インデックスの表示6-48 インデックスの表示 SHOW INDEX/SHOW KEYS■■　インデックス情報の更新6-49 インデックス情報の更新 ANALYZE TABLE■■　ビュー6-50 ビューの作成、変更、削除 CREATE VIEW/ALTER VIEW/DROP VIEW6-51 ビューの定義表示 SHOW CREATE VIEW■■　トリガ6-52 トリガの定義、変更、削除 CREATE TRIGGER/ALTER TRIGGER/DROP TRIGGER6-53 トリガの定義表示 SHOW TRIGGERS■■　テーブルの最適化6-54 テーブルの最適化 OPTIMIZE TABLE■■　テーブルの検査と修復6-55 テーブルの検査 CHECK TABLE6-56 テーブルの修復 REPAIR TABLE■■　トランザクション6-57 トランザクション BEGIN|START TRANSACTION/COMMIT/ROLLBACK6-58 セーブポイントの設定とロールバック SAVEPOINT/ROLLBACK TO SAVEPOINT6-59 トランザクションの分離レベル設定 SET TRANSACTION ISOLATION LEVEL■■　ロック6-60 テーブルのロックと解除 LOCK TABLES/UNLOCK TABLES■■　テーブルデータのインポートとエクスポート6-61 テーブルデータのインポート LOAD DATA INFILE6-62 テーブルデータのエクスポート SELECT INTO OUTFILE/SELECT INTO DUMPFILE■■　テーブルのバックアップとリストア6-63 テーブルのバックアップ BACKUP TABLE6-64 テーブルのリストア RESTORE TABLE■■　ログの管理6-65 ログの切り換え FLUSH LOGS6-66 バイナリログ一覧表示 SHOW BINARY LOGS/SHOW MASTER LOGS6-67 バイナリログの内容表示 SHOW BINLOG EVENTS6-68 バイナリログの全削除 RESET MASTER6-69 バイナリログの削除 PURGE MASTER LOGS■■　サーバの制御と状態表示6-70 スレッドの情報表示とKILL SHOW PROCESSLIST/KILL6-71 システム変数の変更 SET|SET OPTION6-72 システム変数の表示 SHOW VARIABLES6-73 データベースサーバの状態表示 SHOW STATUS6-74 各種情報やログのリセット FLUSH6-75 権限テーブルの再読込み FLUSH PRIVILEGES6-76 クエリキャッシュの出フラグメント FLUSH QUERY CACHE6-77 テーブルのクローズ FLUSH TABLES|FLUSH TABLE/FLUSH TABLES WITH READ LOCK6-78 ステータス情報のリセット FLUSH STATUS6-79 問い合わせ実行回数のリセット FLUSH USER_RESOURCES■■　レプリケーション6-80 レプリケーションに関するスレッドの状態表示 SHOW PROCESSLIST6-81 マスターサーバの状態表示 SHOW MASTER STATUS6-82 接続しているスレーブの一覧表示 SHOW SLAVE HOSTS6-83 スレーブ機能の起動と停止 START SLAVE (SLAVE START) / STOP SLAVE (SLAVE STOP)6-84 スレーブの状態表示 SHOW SLAVE STATUS6-85 スレーブ機能のリセット RESET SLAVE6-86 マスターサーバの変更 CHANGE MASTERChapter 07 データ型、演算子と関数■■　データ型7-01 MySQLがサポートするデータ型7-02 数値データ型7-03 文字データ型7-04 ENUM型、SET型7-05 BLOB（BINARY LARGE OBJECT）型7-06 日付/時刻データ型7-07 ビット型■■　演算子7-08 MySQLのサポートする演算子7-09 論理演算子7-10 比較演算子7-11 算術演算子7-12 日付/時刻演算子7-13 COLUMNパターンマッチング■■　関数7-14 MySQLがサポートする関数7-15 算術関数7-16 集約関数7-17 文字列関数7-18 日付/時刻関数7-19 型変換関数7-20 その他の関数Chapter 08 ストアドプロシージャ・ストアドファンクション■■　概要8-01 ストアドプロシージャ・ストアドファンクションとは8-02 ストアドプロシージャ・ストアドファンクションの定義と実行、削除■■　プログラミングの基本8-03 ローカル変数宣言と値の代入8-04 SELECT INTO文■■　制御構造8-05 条件分岐と場合分け8-06 ループ処理8-07 ハンドラー■■　カーソル8-08 カーソル8-09 カーソル変数の宣言とオープン、クローズ DECLARE CURSOR FOR/OPEN/CLOSE8-10 FETCH文によるカーソル行の取得 FETCH8-11 カーソルを使った例この本は、とても簡潔な（悪い言い方をすると淡々とした）文体で書き進められている。リファレンスなので淡々としているのは当然と言えば当然なのであるが、それでいて説明が明快なのは感心するところである。しかし本書の真の価値は文章ではないと断言する！本書を手にとって少しめくればすぐに気付くであろう。その図表の多さに。そう、この本の真の価値は図表にある。文章による説明は必要最低限であるのだが、その代わり豊富な図表が補って余りあるぐらい雄弁にMySQLの各種機能を説明してくれるのである。文章をいちいち読むのではなく、図表で素早く内容を理解できるというのは、リファレンス本にとって至上命題の一つであろう。また、図表以外に目をひくのがコマンドやSQL文の実行例の多さである。各種機能の説明には必ずと言って良いほどSQLやコマンドの実行結果が掲載されている。説明を読んだだけではちょっとピンと来ないな・・・と思うような機能であっても、実行例を見れば一目瞭然という寸法である。本書の内容を改めて見てみると、MySQLには膨大な機能があるんだなということに気付く。もちろん本書ではカバーされていない機能もあるが、それにしても膨大な機能である。（MySQLは高速だが機能が少ないと言う定説を疑いたくなるぐらいである。）その膨大な機能の説明を成し遂げた鈴木氏の努力は、並大抵のものではないと言えよう。ちなみに、本書の最後には「参考書籍」が紹介されているのだが、その中には私（つまりこのブログの筆者）が執筆した出版予定の書籍（仮題：MySQLエキスパートトラブルシューティングガイド）が紹介されている。まだ出版されていない（鈴木氏に原稿を見せたということもない）書籍を「参考書籍」として紹介するというのは前代未聞の所業ではないだろうかと思うのだが、鈴木氏曰く「参考にした書籍ではなく、参考になる書籍という意味で掲載するからOK!」ということらしい。※この点については鈴木氏本人より「誤解を招く表現」との指摘があったので修正させて頂く。この文面からすると鈴木氏は架空の内容を参考にしたように読み取れるがそうではない。鈴木氏は次の2点を見て「この書籍なら参考にするに値する」と判断して下さったそう。ブログに掲載した原稿のプチ抜粋個人的に見せた書籍の「もくじ」（内容は送っていない）オモシロおかしく書いたつもりが、思わぬ茶々になってしまって面目ないです＞鈴木氏MySQLエキスパートトラブルシューティングガイド（仮題）では、本書で取り上げられていない機能、例えばSHOW INNODB STATUSの見方やINFORMATION_SCHEMA、プロファイリング、トレースファイル、DTraceプローブなども解説するので乞うご期待。そんなわけで、本書は網羅的で図表や実行例を駆使してとても分かり易いMySQLのリファレンスであり、初心者から上級者まで幅広い方々におすすめである。 MySQL全機能バイブル ~現場で役立つAtoZ~著者鈴木啓修様より献本御礼。（←一度言ってみたかったｗ）

本書は鈴木氏の前著である「MySQL全機能リファレンス」からのアップデートであるが、この度は最新バージョンであるMySQL 5.1対応になっての登場である。

今の時代、一家に一台テレビがあるように、はたまたパソコンがあるように、いやいや冷蔵庫があるように、一家に一冊本書があってもいいのではなかろうか。MySQLがオフィシャルに提供しているリファレンスマニュアルを除いて、MySQLをここまで網羅的に解説している書籍を私は知らない。その網羅性は目次だけで13ページも費やしていることからも、容易に想像出来ることだろう。

もくじを見ただけでもその網羅性がよく分かるだろう。このもくじを書いただけで既に腕がつりそうである。

Chapter 01 イントロダクション
■■　概要
1-01 MySQL™とは
1-02 MySQLの概要
1-03 データベースシステムの構造
1-04 ストレージエンジン
Chapter 02 MySQLの内部構造
■■　プロセスとメモリ構造
2-01 プロセス構造
2-02 メモリ構造
■■　問い合わせ処理
2-03 問い合わせ処理
2-04 プランナ
2-05 MyISAMのエクゼキュータ処理
■■　データベースディレクトリの構造
2-06 データベースディレクトリの構造
■■　テーブルの構造
2-07 MyISAM型
2-08 InnoDB型
■■　トランザクションの隔離レベル
2-09 トランザクションの隔離レベル
■■　INSERT DELAYED文
2-10 INSERT DELAYED文
■■　クエリキャッシュ（Query Cache）
2-11 クエリキャッシュ（Query Cache）
Chapter 03 MySQLのインストール
3-01 インストール準備
3-02 インストール
Chapter 04 MySQLサーバ管理
■■　イントロダクション
4-01 MySQLサーバ管理
■■　初期設定
4-02 初期設定
■■　サーバの起動/停止
4-03 MySQLサーバの起動と停止
4-04 MySQLサーバの起動
4-05 MySQLサーバの停止
4-06 MySQLサーバをデーモンとして起動する
■■　データベースユーザ管理
4-07 MySQLにおけるデータベースユーザの概念
4-08 データベースユーザの管理
■■　システム変数の設定
4-09 システム変数の設定
4-10 サーバの動作に関するシステム変数
4-11 通信関連のシステム変数
4-12 問い合わせ処理に関するシステム変数
4-13 ストレージエンジン関連のシステム変数
4-14 ログ関連のシステム変数
4-15 表示や文字コードに関連するシステム変数
4-16 SQL_MODE
4-17 レプリケーション関連のシステム変数
4-18 その他のシステム変数
■■　ストレージエンジン
4-19 MyISAM型
4-20 InnoDB型
4-21 MEMORY型（旧 HEAP型）
4-22 パーティション
■■　ログ
4-23 ログファイル
4-24 バイナリログ（binary log）
4-25 スロークエリのログ（slow query log）
4-26 一般クエリログ（general query log）
■■　データベースのダンプ/リストア
4-27 データベースのダンプ/リストア（再構築）
4-28 ファイル群のコピーによるダンプ/リストア
4-29 mysqldumpによるダンプ/リストア
■■　管理ツール
4-30 mysqladminとは
4-31 データベースの作成/削除
4-32 サーバの情報表示
4-33 FLOSH/RELOAD
4-34 パスワードの変更
4-35 スレーブ機能の開始/停止
4-36 mysqlcheck
■■　文字コード
4-37 MySQLのサポートする文字コード
4-38 文字コードの設定と確認
■■　レプリケーション
4-39 レプリケーションとは
4-40 MySQLにおけるレプリケーションの仕組み
4-41 レプリケーションの設定
4-42 運用/管理
■■　クエリキャッシュ
4-43 クエリキャッシュ（Query Cache）
Chapter 05 mysqlの使い方
■■　mysqlの使い方
5-01 mysqlの使い方
■■　mysqlの起動オプション
5-02 MySQLサーバとの接続と切断
5-03 表示と結果出力
5-04 バッチ処理とSQL文の実行
5-05 実行制御
■■　mysqlのメタコマンド
5-06 再接続と切断
5-07 表示の制御
5-08 バッチファイルの処理,および結果のファイル出力
5-09 SQL文の編集と表示
5-10 プロンプト
5-11 接続中のセッション情報を表示
Chapter 06 SQL
■■　SQL
6-01 SQL文一覧
6-02 語彙
■■　データベースの作成/削除/接続
6-03 データベースの作成 CREATE DATABASE
6-04 データベースの削除 DROP DATABASE
6-05 データベースの属性変更 ALTER DATABASE
6-06 データベースの一覧表示 SHOW DATABASES
6-07 データベースへの接続 USE
■■　テーブルの作成/削除
6-08 テーブルの作成 CREATE TABLE
6-09 テーブルの削除 DROP TABLE
■■　テーブルの情報表示
6-10 テーブル定義（テーブルスキーマ）の表示 SHOW CREATE TABLE
6-11 列の属性を表示 SHOW COLUMNS FROM/SHOW FIELDS FROM/DESCRIBE/DESC
6-12 テーブルの一覧表示 SHOW TABLES
6-13 テーブルの情報表示 SHOW TALBE STATUS
■■　テーブルの属性変更
6-14 テーブル属性の変更 ALTER TABLE
6-15 列の追加と削除 ALTER TABLE ADD COLUMN/ALTER TABLE DROP COLUMN
6-16 インデックスの追加と削除 ALTER TABLE ADD INDEX|CREATE INDEX/ALTER TABLE DROP INDEX|DROP INDEX
6-17 主キーの追加と削除 ALTER TABLE ADD PRIMARY KEY/ALTER TABLE DROP PRIMARY KEY
6-18 一意性制約の追加 ALTER TABLE ADD UNIQUE
6-19 外部キー制約の追加と削除 ALTER TABLE ADD FOREIGN KEY/ALTER TABLE DROP FOREIGN KEY
6-20 デフォルト値の設定と削除 ALTER TABLE ALTER SET DEFAULT/ALTER TABLE ALTER DROP DEFAULT
6-21 列定義、列名の変更 ALTER TABLE MODIFY COLUMN/ALTER TABLE CHANGE COLUMN
6-22 テーブル名の変更 ALTER TABLE RENAME
6-23 テーブル名の変更 RENAME TABLE
■■　データベースユーザの作成と削除
6-24 データベースユーザの作成と削除 CREATE USER/DROP USER
■■　データベースユーザの管理
6-25 データベースユーザの権限設定と削除 GRANT/REVOKE
6-26 データベースユーザの権限表示 SHOW GRANTS
■■　データの挿入
6-27 データの挿入 INSERT
6-28 データの挿入 REPLACE
■■　SELECT
6-29 データの検索 SELECT
6-30 重複する行を削除 DISTINCT
6-31 FROM句
6-32 テーブル結合 CROSS JOIN/INNER JOIN/OUTER JOIN
6-33 WHERE句
6-34 グループ化 GROUP BY, HAVING
6-35 検索結果の並び替え ORDER BY
6-36 検索結果の出力範囲を指定 LIMIT, OFFSET
6-37 排他的六句と共有ロック FOR UPDATE/LOCK IN SHARE MODE
6-38 問い合わせの結合 UNION
6-39 副問い合わせ
■■　データの更新
6-40 データの更新 UPDATE
■■　データの削除
6-41 データの削除 DELETE
6-42 全データの削除 TRUNCATE
■■　式や関数の実行
6-43 式や関数の実行 DO
■■　プリペアードステートメント
6-44 プリペアードステートメントの準備、実行、削除 PREPARE/EXECUTE/DEALLOCATE PREPARE
■■　問い合わせ計画の表示
6-45 問い合わせ計画の表示 EXPLAIN
■■　ストアドプロシージャ・ストアドファンクション
6-46 ストアドプロシージャ・ストアドファンクションの定義表示 SHOW CREATE PROCEDURE/SHOW CREATE FUNCTION
6-47 ストアドプロシージャ・ストアドファンクションの状態表示 SHOW PROCEDURE STATUS/SHOW FUNCTION STATUS
■■　インデックスの表示
6-48 インデックスの表示 SHOW INDEX/SHOW KEYS
■■　インデックス情報の更新
6-49 インデックス情報の更新 ANALYZE TABLE
■■　ビュー
6-50 ビューの作成、変更、削除 CREATE VIEW/ALTER VIEW/DROP VIEW
6-51 ビューの定義表示 SHOW CREATE VIEW
■■　トリガ
6-52 トリガの定義、変更、削除 CREATE TRIGGER/ALTER TRIGGER/DROP TRIGGER
6-53 トリガの定義表示 SHOW TRIGGERS
■■　テーブルの最適化
6-54 テーブルの最適化 OPTIMIZE TABLE
■■　テーブルの検査と修復
6-55 テーブルの検査 CHECK TABLE
6-56 テーブルの修復 REPAIR TABLE
■■　トランザクション
6-57 トランザクション BEGIN|START TRANSACTION/COMMIT/ROLLBACK
6-58 セーブポイントの設定とロールバック SAVEPOINT/ROLLBACK TO SAVEPOINT
6-59 トランザクションの分離レベル設定 SET TRANSACTION ISOLATION LEVEL
■■　ロック
6-60 テーブルのロックと解除 LOCK TABLES/UNLOCK TABLES
■■　テーブルデータのインポートとエクスポート
6-61 テーブルデータのインポート LOAD DATA INFILE
6-62 テーブルデータのエクスポート SELECT INTO OUTFILE/SELECT INTO DUMPFILE
■■　テーブルのバックアップとリストア
6-63 テーブルのバックアップ BACKUP TABLE
6-64 テーブルのリストア RESTORE TABLE
■■　ログの管理
6-65 ログの切り換え FLUSH LOGS
6-66 バイナリログ一覧表示 SHOW BINARY LOGS/SHOW MASTER LOGS
6-67 バイナリログの内容表示 SHOW BINLOG EVENTS
6-68 バイナリログの全削除 RESET MASTER
6-69 バイナリログの削除 PURGE MASTER LOGS
■■　サーバの制御と状態表示
6-70 スレッドの情報表示とKILL SHOW PROCESSLIST/KILL
6-71 システム変数の変更 SET|SET OPTION
6-72 システム変数の表示 SHOW VARIABLES
6-73 データベースサーバの状態表示 SHOW STATUS
6-74 各種情報やログのリセット FLUSH
6-75 権限テーブルの再読込み FLUSH PRIVILEGES
6-76 クエリキャッシュの出フラグメント FLUSH QUERY CACHE
6-77 テーブルのクローズ FLUSH TABLES|FLUSH TABLE/FLUSH TABLES WITH READ LOCK
6-78 ステータス情報のリセット FLUSH STATUS
6-79 問い合わせ実行回数のリセット FLUSH USER_RESOURCES
■■　レプリケーション
6-80 レプリケーションに関するスレッドの状態表示 SHOW PROCESSLIST
6-81 マスターサーバの状態表示 SHOW MASTER STATUS
6-82 接続しているスレーブの一覧表示 SHOW SLAVE HOSTS
6-83 スレーブ機能の起動と停止 START SLAVE (SLAVE START) / STOP SLAVE (SLAVE STOP)
6-84 スレーブの状態表示 SHOW SLAVE STATUS
6-85 スレーブ機能のリセット RESET SLAVE
6-86 マスターサーバの変更 CHANGE MASTER
Chapter 07 データ型、演算子と関数
■■　データ型
7-01 MySQLがサポートするデータ型
7-02 数値データ型
7-03 文字データ型
7-04 ENUM型、SET型
7-05 BLOB（BINARY LARGE OBJECT）型
7-06 日付/時刻データ型
7-07 ビット型
■■　演算子
7-08 MySQLのサポートする演算子
7-09 論理演算子
7-10 比較演算子
7-11 算術演算子
7-12 日付/時刻演算子
7-13 COLUMNパターンマッチング
■■　関数
7-14 MySQLがサポートする関数
7-15 算術関数
7-16 集約関数
7-17 文字列関数
7-18 日付/時刻関数
7-19 型変換関数
7-20 その他の関数
Chapter 08 ストアドプロシージャ・ストアドファンクション
■■　概要
8-01 ストアドプロシージャ・ストアドファンクションとは
8-02 ストアドプロシージャ・ストアドファンクションの定義と実行、削除
■■　プログラミングの基本
8-03 ローカル変数宣言と値の代入
8-04 SELECT INTO文
■■　制御構造
8-05 条件分岐と場合分け
8-06 ループ処理
8-07 ハンドラー
■■　カーソル
8-08 カーソル
8-09 カーソル変数の宣言とオープン、クローズ DECLARE CURSOR FOR/OPEN/CLOSE
8-10 FETCH文によるカーソル行の取得 FETCH
8-11 カーソルを使った例

この本は、とても簡潔な（悪い言い方をすると淡々とした）文体で書き進められている。リファレンスなので淡々としているのは当然と言えば当然なのであるが、それでいて説明が明快なのは感心するところである。しかし本書の真の価値は文章ではないと断言する！本書を手にとって少しめくればすぐに気付くであろう。その図表の多さに。

そう、この本の真の価値は図表にある。文章による説明は必要最低限であるのだが、その代わり豊富な図表が補って余りあるぐらい雄弁にMySQLの各種機能を説明してくれるのである。文章をいちいち読むのではなく、図表で素早く内容を理解できるというのは、リファレンス本にとって至上命題の一つであろう。また、図表以外に目をひくのがコマンドやSQL文の実行例の多さである。各種機能の説明には必ずと言って良いほどSQLやコマンドの実行結果が掲載されている。説明を読んだだけではちょっとピンと来ないな・・・と思うような機能であっても、実行例を見れば一目瞭然という寸法である。

本書の内容を改めて見てみると、MySQLには膨大な機能があるんだなということに気付く。もちろん本書ではカバーされていない機能もあるが、それにしても膨大な機能である。（MySQLは高速だが機能が少ないと言う定説を疑いたくなるぐらいである。）その膨大な機能の説明を成し遂げた鈴木氏の努力は、並大抵のものではないと言えよう。

ちなみに、本書の最後には「参考書籍」が紹介されているのだが、その中には私（つまりこのブログの筆者）が執筆した出版予定の書籍（仮題：MySQLエキスパートトラブルシューティングガイド）が紹介されている。まだ出版されていない（鈴木氏に原稿を見せたということもない）書籍を「参考書籍」として紹介するというのは前代未聞の所業ではないだろうかと思うのだが、鈴木氏曰く「参考にした書籍ではなく、参考になる書籍という意味で掲載するからOK!」ということらしい。
※この点については鈴木氏本人より「誤解を招く表現」との指摘があったので修正させて頂く。この文面からすると鈴木氏は架空の内容を参考にしたように読み取れるがそうではない。鈴木氏は次の2点を見て「この書籍なら参考にするに値する」と判断して下さったそう。
オモシロおかしく書いたつもりが、思わぬ茶々になってしまって面目ないです＞鈴木氏
MySQLエキスパートトラブルシューティングガイド（仮題）では、本書で取り上げられていない機能、例えばSHOW INNODB STATUSの見方やINFORMATION_SCHEMA、プロファイリング、トレースファイル、DTraceプローブなども解説するので乞うご期待。

そんなわけで、本書は網羅的で図表や実行例を駆使してとても分かり易いMySQLのリファレンスであり、初心者から上級者まで幅広い方々におすすめである。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 27 Oct 2009 18:18:00 +0000 Mikiya Okuno mysql MyISAMとInnoDBのどちらを使うべきか tag:blogger.com,1999:blog-8317896764605662628.post-2291370513315457937 http://opendatabaselife.blogspot.com/2009/10/myisaminnodb.html Twitterで話題になってたので簡単にまとめました。●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない・全文検索 (TritonnやSphinx)・GIS●InnoDBの利点(MyISAMの欠点)▲障害対応系・クラッシュしても再起動するだけでリカバリができる・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)・オンラインバックアップができる・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い▲性能系・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。・主キー検索が高速 (クラスタ索引のため)・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い・インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い▲従来は欠点だったが、InnoDB Pluginによって改善されたもの・グループコミットが無効化されるため同時更新性能が著しく低下していた・I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった・CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)▲ほか・InnoDBでは外部キーが使える●MyISAMの利点・WHERE条件無しのSELECT COUNT(*)が一瞬で返る(InnoDBの場合はテーブルをなめる必要がある)・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い(InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)・OSコピーによってテーブルの移動が極めて簡単にできる・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)・リードオンリーのテーブルであれば圧縮できる・ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)・InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい▲ソリューションによって緩和できるもの・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる　自分は、特別な事情が無い限り、5.1最新版に含まれるInnoDB Pluginを勧めています。ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアントから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert BufferのようなI/O最適化の仕組みが無い(詳しくは「Linux-DBシステム構築/運用入門」の9章あたりを参考にしてください)ので、InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。　ちなみに、マスターをInnoDBにして、スレーブをMyISAMにするのは以前Postしたように特別な注意が必要です。
●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない
・全文検索 (TritonnやSphinx)
・GIS

●InnoDBの利点(MyISAMの欠点)
▲障害対応系
・クラッシュしても再起動するだけでリカバリができる
・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)
・オンラインバックアップができる
・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い

▲性能系
・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。
・主キー検索が高速 (クラスタ索引のため)
・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い
・インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)
・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い

▲従来は欠点だったが、InnoDB Pluginによって改善されたもの
・グループコミットが無効化されるため同時更新性能が著しく低下していた
・I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった
・CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった
・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)

▲ほか
・InnoDBでは外部キーが使える


●MyISAMの利点
・WHERE条件無しのSELECT COUNT(*)が一瞬で返る
(InnoDBの場合はテーブルをなめる必要がある)
・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い
(InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)
・OSコピーによってテーブルの移動が極めて簡単にできる
・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)
・リードオンリーのテーブルであれば圧縮できる
・ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)
・InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい

▲ソリューションによって緩和できるもの
・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる
・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる


　自分は、特別な事情が無い限り、5.1最新版に含まれるInnoDB Pluginを勧めています。ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアントから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert BufferのようなI/O最適化の仕組みが無い(詳しくは「Linux-DBシステム構築/運用入門」の9章あたりを参考にしてください)ので、InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。
　ちなみに、マスターをInnoDBにして、スレーブをMyISAMにするのは以前Postしたように特別な注意が必要です。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 27 Oct 2009 10:32:00 +0000 Yoshinori Matsunobu mysql 彼氏がMyISAM使ってた。別れたい… http://d.hatena.ne.jp/kazuhooku/20091027/1256638805 http://d.hatena.ne.jp/kazuhooku/20091027/1256638805 追記: マジメな比較はこちら：Open database life: MyISAMとInnoDBのどちらを使うべきか MyISAMだとPostgreSQLと並べられた時なんか恥ずかしいｗｗ 下向いちゃうしｗｗ ウェブサイトにはせめてInnoDB使って欲しい・・・ 勉強会とかで発表されたら・・・・もう最悪ｗｗ せめて普通にトランザクションやMVCCぐらいは対応して欲しい。 常識的に考えて欲しいだけなんです！ MyISAMでテーブルロックしちゃった時の遅さとか分かる？ あのね？たとえばピーク時10〜20並行ぐらいで書込みとか行くでしょ？ それぞれ別の接続で来るわけじゃない？ みんな普通にグループコミットやアシッドネス期待してるわけでしょ？ MyISAMでテーブル壊れてリペアしてたら大恥かくでしょうがｗｗ じゃあ MyISAM はどういう用途に適しているのか。待て！　次号！*1 参考: 彼氏が軽自動車に乗ってた。別れたい… *1：詳しい人が解説してくれるらしいぉ ^o^

追記: マジメな比較はこちら：Open database life: MyISAMとInnoDBのどちらを使うべきか

MyISAMだとPostgreSQLと並べられた時なんか恥ずかしいｗｗ

下向いちゃうしｗｗ

ウェブサイトにはせめてInnoDB使って欲しい・・・

勉強会とかで発表されたら・・・・もう最悪ｗｗ

せめて普通にトランザクションやMVCCぐらいは対応して欲しい。

常識的に考えて欲しいだけなんです！

MyISAMでテーブルロックしちゃった時の遅さとか分かる？

あのね？たとえばピーク時10〜20並行ぐらいで書込みとか行くでしょ？

それぞれ別の接続で来るわけじゃない？

みんな普通にグループコミットやアシッドネス期待してるわけでしょ？

MyISAMでテーブル壊れてリペアしてたら大恥かくでしょうがｗｗ

じゃあ MyISAM はどういう用途に適しているのか。待て！　次号！*1

参考: 彼氏が軽自動車に乗ってた。別れたい…

*1：詳しい人が解説してくれるらしいぉ ^o^


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 27 Oct 2009 10:20:05 +0000 Kazuho Oku [mysql]MySQL 5.1.40 と MySQL 5.0.87 リリース http://d.hatena.ne.jp/sakaik/20091027/p1 http://d.hatena.ne.jp/sakaik/20091027/p1 　一週間ほど前に MySQL 5.1.40 が、そして今週はMySQL 5.0.87 がリリースされました。 　 ○MySQL 5.1.40 リリース http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=153 ○MySQL 5.0.87 リリース http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=154 　MySQL 5.0.87 は修正数も少なくな ... PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 27 Oct 2009 00:00:00 +0000 Sakai Kei [mysql]松信さんの奥さんのエントリがすごい http://d.hatena.ne.jp/sakaik/20091027/p2 http://d.hatena.ne.jp/sakaik/20091027/p2 　気づいたら twitter で MyISAM vs InnoDB の話題が盛り上がっていました。その流れで、奥さんの愛のある MyISAM 礼賛(?)の記事： ○彼氏がMyISAM使ってた。別れたい… http://d.hatena.ne.jp/kazuhooku/20091027/1256638805 　勢いがあります。こういう文章をさくっと数分で書いてしまうセンスが羨ましい。 　末尾に「待て！　次号」とあり、その「次号」を松信さんがこれまた数分でさくっと。　すごい。 ○彼女が・・・ 　 ... PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 27 Oct 2009 00:00:00 +0000 Sakai Kei Okyuu.comからインタビューを受けました tag:blogger.com,1999:blog-8317896764605662628.post-3415995515814849515 http://opendatabaselife.blogspot.com/2009/10/okyuucom.html 　先日カカクコムさんが運営しているサイト「Okyuu.com」からインタビューを受け、その記事が公開されました。　私は幼少の頃から技術者魂全開、というキャラとは程遠く、気づいたらこの業界でDB技術系の仕事をしていた、という程度なのですが、趣味と仕事が完全に一致したという恵まれた方はむしろ少数派で、多くの方は生活のために(それと多少の興味と一致して)この業界で仕事をしているのだと思います。この業界はコードを書くのが趣味でなければ生きていけない、というプレッシャーをひしひしと感じさせますが、そうでない人にとっても活躍の場はあるのだ、という安心感を持っていただけると幸いです。　インタビュー記事について、少しだけ補足をしたいと思います。・お金を払うユーザーを大切にするのは当然ですが、無償で使うユーザーを無視しているわけではありません。そもそも無償で使うユーザーを無視するようではOSSビジネスは成立しません。多くの利用者が試し、時に地雷を踏みそれを修復するサイクルを繰り返すことで、ようやくお金を払っても良いかなという品質に達すると考えています。誰も使っていないプロダクト(地雷を踏むリスクが高い)にお金を払うユーザーは、昨今では非常に少ないのではないでしょうか。・第3者企業がOSS製品をさんざん利用した挙句、ちょっと機能を追加してクローズドソースにして「自社製品です」と言い張って販売するのは、私は「邪道」のビジネスだと考えています。もちろん程度問題で、ユーティリティライブラリ程度なら全然いいと思いますが、コアの機能がもろにOSSを使っているのなら、それを拡張してクローズドソースにして販売するくらいなら本家にフィードバックしろよ、と思うわけです。・OSSに貢献する道は、パッチを書くだけではありません。たとえば新バージョンのバグを見つけてバグレポート上で再現手順を報告するというのも立派な貢献です。こうしたバグ報告によって製品の品質は徐々に上がっていきます。その意味では、会社としてはお金を出せないしパッチを書くほどのスキルは無いけどOSSに貢献したい、というような方は、できるだけ新しいバージョンを積極的に使って、バグを見つけて報告するのが良いのではないかと思います。ただし、セキュリティ上の脆弱性に関しては、バグフィックスよりも先にBlog等で発信して一般に認知されたりすると、攻撃の対象になりかねないので気をつけて頂きたいと思います(MySQLのバグレポートでは、脆弱性の問題については、報告を受けた後に一般ユーザーが閲覧できないように権限設定されます)。 公開されました。
　私は幼少の頃から技術者魂全開、というキャラとは程遠く、気づいたらこの業界でDB技術系の仕事をしていた、という程度なのですが、趣味と仕事が完全に一致したという恵まれた方はむしろ少数派で、多くの方は生活のために(それと多少の興味と一致して)この業界で仕事をしているのだと思います。この業界はコードを書くのが趣味でなければ生きていけない、というプレッシャーをひしひしと感じさせますが、そうでない人にとっても活躍の場はあるのだ、という安心感を持っていただけると幸いです。
　インタビュー記事について、少しだけ補足をしたいと思います。

・お金を払うユーザーを大切にするのは当然ですが、無償で使うユーザーを無視しているわけではありません。そもそも無償で使うユーザーを無視するようではOSSビジネスは成立しません。多くの利用者が試し、時に地雷を踏みそれを修復するサイクルを繰り返すことで、ようやくお金を払っても良いかなという品質に達すると考えています。誰も使っていないプロダクト(地雷を踏むリスクが高い)にお金を払うユーザーは、昨今では非常に少ないのではないでしょうか。

・第3者企業がOSS製品をさんざん利用した挙句、ちょっと機能を追加してクローズドソースにして「自社製品です」と言い張って販売するのは、私は「邪道」のビジネスだと考えています。もちろん程度問題で、ユーティリティライブラリ程度なら全然いいと思いますが、コアの機能がもろにOSSを使っているのなら、それを拡張してクローズドソースにして販売するくらいなら本家にフィードバックしろよ、と思うわけです。

・OSSに貢献する道は、パッチを書くだけではありません。たとえば新バージョンのバグを見つけてバグレポート上で再現手順を報告するというのも立派な貢献です。こうしたバグ報告によって製品の品質は徐々に上がっていきます。その意味では、会社としてはお金を出せないしパッチを書くほどのスキルは無いけどOSSに貢献したい、というような方は、できるだけ新しいバージョンを積極的に使って、バグを見つけて報告するのが良いのではないかと思います。ただし、セキュリティ上の脆弱性に関しては、バグフィックスよりも先にBlog等で発信して一般に認知されたりすると、攻撃の対象になりかねないので気をつけて頂きたいと思います(MySQLのバグレポートでは、脆弱性の問題については、報告を受けた後に一般ユーザーが閲覧できないように権限設定されます)。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 26 Oct 2009 11:17:00 +0000 Yoshinori Matsunobu mysql interview MySQL Clusterソースコード探検隊！ tag:blogger.com,1999:blog-1906500952232920237.post-8100024635476926445 http://nippondanji.blogspot.com/2009/10/mysql-cluster_26.html これまで「MySQL Clusterの進化とその構造について」および「NDBカーネルブロックの種類」について説明した。今日はその続きとしてMySQL Clusterのソースコードについて紹介しようと思う。シグナルを交換し合うマルチプルステートマシンは間違いなくこれからの時代にフィットするアーキテクチャなので、MySQL Clusterに興味を持たれた方が「膨大なMySQL Clusterのソースコードを探検する場合にどの入り口から入ればいいのか」ということを判断する一助になればと思う。とりとめなく書いてるのであんまりまとまってないかも知れないが、その点は容赦して頂きたい。まず、ソースコードの入手方法であるが、これは最新のソースツリーをBazaarで入手する方法と、MySQLのWebページからダウンロードする方法の2つがある。Bazaarで入手するには、次のコマンドを実行すれば良い。（Bazaarを事前にインストールしておこう。）shell> bzr branch lp:~mysql/mysql-server/mysql-cluster-7.0するとカレントディレクトリ以下にソースコードがコピーされる。結構時間がかかるので注意しよう。MySQLのWebページからダウンロードするには、次のページをブラウザでアクセスしよう。http://dev.mysql.com/downloads/cluster.htmlするとプラットフォームの選択メニューが出てくるので、ZIP形式のソースコードが欲しければWindowsを、TAR形式のものが欲しければLinuxを選択しよう。一番小さいファイルがソースコードである。ソースコードのファイルはmysql-cluster-gpl-VERSION.tar.gzというような名前になっている。MySQL Clusterのソースコードが含まれる場所は次の2つである。src-top-dir/storage/ndbsrc-top-dir/sqlsrc-top-dirはソースコードのトップディレクトリ、つまりZIPまたはTARファイルを展開したときに作成されるディレクトリ（mysql-cluster-gpl-VERSIONというような名前のディレクトリ）のことである。storage/ndbにはndbdやndb_mgmdといったコマンドのソースコードが収められている。つまりSQLノードを除く全てのコマンドのソースコードはここにある。一方、sqlディレクトリにはSQLノードのソースコードが格納されている。ファイル名はha_ndbcluster*。（*はワイルドカード。）ここは元々mysqldのソースコードが収められているディレクトリなので、そこに居候しているのである。（将来的にはstorage/ndbへ移動したいらしいが、タスクの優先順位は低くなかなかそうならない。）肝心のNDBカーネルのソースコードはstorage/ndb以下にあるのでこちらを中心に説明する。ha_ndbcluster*には、ストレージエンジンとしてMySQL Clusterへアクセスする際に必要なソースコード、つまりmysqldがNDB APIを通じてNDBにアクセスするためのロジックが記述されているので、ストレージエンジンAPIおよびNDB API興味のある人は覗いて見るといいだろう。ここからは、NDBカーネルのソースコードを見る際のポイントについて列挙しよう。NDBカーネルのソースコードの位置は、storage/ndb/src/kernelである。main()関数を含むmain.cppはこのディレクトリである。ndbdの初期化プロセスについて知りたい場合には、main.cppを見よう。ヘッダファイル類はstorage/ndb/include/kernel配下に収められている。C++のヘッダファイルはstorage/ndb/src/kernel以下にも含まれているが、共通のヘッダファイルはこちらのディレクトリに含まれているので注意しよう。storage/ndb/src/kernel/vmには、PLEX仮想実行環境のソースコードが含まれている。最も重要なのはSimulatedBlock.[c|h]ppで、ここで定義されているSimulatedBLockクラスはこれらは全てのブロックの親クラスとなる。つまり、NDBDカーネル内の各ブロックは、SimulatedBlockクラスを継承しているのである。また、SimulatedBlockが交換するメッセージは、VMSignal.[c|h]ppで定義されている。（シグナルを表すクラスはSignalである。）面白いことに、SimulatedBlockは他のあらゆるカーネルブロックへ、sendSignal()関数を通じてシグナルを送信することが出来る。同じプロセス内のブロックであろうが、他のホストで動作しているブロックであろうが、同じ方法（関数）でシグナルを送信することが出来るのである。storage/ndb/src/kernel/blocksには各ブロックのソースコードが含まれている。ブロックごとにサブディレクトリに分かれているので見易いだろう。ここで定義されている各カーネルブロックは、上記の通りSimulatedBlockクラスを継承している。各カーネルブロックの動作を定義しているこのディレクトリは、NDBのソースコードの心臓部と言っていいだろう。storage/ndb/include/kernel/BlockNumbers.hには、各カーネルブロックのIDが定義されている。ブロック番号は16ビット符号無し整数なのだが、同じく16ビット符号無し整数であるノードIDと組み合わせることで、32ビットの符号無し整数としてクラスタ全体を通じたID（BlockReference）を合成することが出来る。storage/ndb/include/kernel/RefConvert.hppにはノードIDとブロック番号からBlockReferenceへ変換するロジックおよびその逆が定義されている。（ただのビット演算だけどね！）storage/ndb/src/kernel/SimBlockList.cppには、作成したカーネルブロックのインスタンス化と、そのインスタンスへのポインタをリストにして保管しておくためのロジックが記述されている。ただし、NDBカーネルの各ブロックはインスタンス化された段階ではまだ初期化されず、その後STTORシグナルを受け取った時点で初期化が始まる点には注意したい。storage/ndb/include/kernel/GlobalSignalNumbers.hでは、各シグナルにつけられた番号が記述されている。実に700種類以上のシグナルが定義されている！（2009年10月現在）storage/ndb/include/kernel/signaldataディレクトリには、シグナルにおいて送信されるデータ（ペイロード）を定義するクラスのソースコードが格納されている。シグナルが送信するデータはフリーフォーマット（単なるワード列）なので、頻繁に利用されるデータについてはその構造が定義されているのである。storage/ndb/src/common/transporterディレクトリには、トランスポーターに関するソースコードが格納されている。トランスポーターとは、MySQL Clusterの各ノード同士が通信し合うための仮想的なインターフェイスである。これにより、通信する実際のプロトコル（TCP/IPなのかSCIなのか）に因らないロジックの記述が可能になる。storage/ndb/src/mgmsrvディレクトリには、管理ノードのソースコードが格納されている。特に重要なのはstorage/ndb/src/mgmsrv/ConfigInfo.cppで、このファイルには各種設定パラメーターとそのデフォルト値に関する記述がなされている。また、storage/ndb/src/mgmclientにはndb_mgmコマンドのソースコードが、storage/ndb/src/mgmapiにはNDB MGM API（設定情報をやり取りするためのAPI）のソースコードが格納されている。storage/ndb/src/ndbapiディレクトリには、NDB APIに関するソースコードが格納されている。そんなわけでMySQL Clusterのソースコードのレイアウトについてとりとめもなく紹介してみた。「よし、ソースコードを見るか！」と思った時に参考にして頂けると幸いである。 MySQL Clusterの進化とその構造について」および「NDBカーネルブロックの種類」について説明した。今日はその続きとしてMySQL Clusterのソースコードについて紹介しようと思う。シグナルを交換し合うマルチプルステートマシンは間違いなくこれからの時代にフィットするアーキテクチャなので、MySQL Clusterに興味を持たれた方が「膨大なMySQL Clusterのソースコードを探検する場合にどの入り口から入ればいいのか」ということを判断する一助になればと思う。とりとめなく書いてるのであんまりまとまってないかも知れないが、その点は容赦して頂きたい。

まず、ソースコードの入手方法であるが、これは最新のソースツリーをBazaarで入手する方法と、MySQLのWebページからダウンロードする方法の2つがある。Bazaarで入手するには、次のコマンドを実行すれば良い。（Bazaarを事前にインストールしておこう。）

shell> bzr branch lp:~mysql/mysql-server/mysql-cluster-7.0

するとカレントディレクトリ以下にソースコードがコピーされる。結構時間がかかるので注意しよう。

MySQLのWebページからダウンロードするには、次のページをブラウザでアクセスしよう。

http://dev.mysql.com/downloads/cluster.html

するとプラットフォームの選択メニューが出てくるので、ZIP形式のソースコードが欲しければWindowsを、TAR形式のものが欲しければLinuxを選択しよう。一番小さいファイルがソースコードである。ソースコードのファイルはmysql-cluster-gpl-VERSION.tar.gzというような名前になっている。

MySQL Clusterのソースコードが含まれる場所は次の2つである。

  • src-top-dir/storage/ndb
  • src-top-dir/sql

src-top-dirはソースコードのトップディレクトリ、つまりZIPまたはTARファイルを展開したときに作成されるディレクトリ（mysql-cluster-gpl-VERSIONというような名前のディレクトリ）のことである。

storage/ndbにはndbdやndb_mgmdといったコマンドのソースコードが収められている。つまりSQLノードを除く全てのコマンドのソースコードはここにある。一方、sqlディレクトリにはSQLノードのソースコードが格納されている。ファイル名はha_ndbcluster*。（*はワイルドカード。）ここは元々mysqldのソースコードが収められているディレクトリなので、そこに居候しているのである。（将来的にはstorage/ndbへ移動したいらしいが、タスクの優先順位は低くなかなかそうならない。）肝心のNDBカーネルのソースコードはstorage/ndb以下にあるのでこちらを中心に説明する。ha_ndbcluster*には、ストレージエンジンとしてMySQL Clusterへアクセスする際に必要なソースコード、つまりmysqldがNDB APIを通じてNDBにアクセスするためのロジックが記述されているので、ストレージエンジンAPIおよびNDB API興味のある人は覗いて見るといいだろう。

ここからは、NDBカーネルのソースコードを見る際のポイントについて列挙しよう。

  • NDBカーネルのソースコードの位置は、storage/ndb/src/kernelである。main()関数を含むmain.cppはこのディレクトリである。ndbdの初期化プロセスについて知りたい場合には、main.cppを見よう。
  • ヘッダファイル類はstorage/ndb/include/kernel配下に収められている。C++のヘッダファイルはstorage/ndb/src/kernel以下にも含まれているが、共通のヘッダファイルはこちらのディレクトリに含まれているので注意しよう。
  • storage/ndb/src/kernel/vmには、PLEX仮想実行環境のソースコードが含まれている。最も重要なのはSimulatedBlock.[c|h]ppで、ここで定義されているSimulatedBLockクラスはこれらは全てのブロックの親クラスとなる。つまり、NDBDカーネル内の各ブロックは、SimulatedBlockクラスを継承しているのである。また、SimulatedBlockが交換するメッセージは、VMSignal.[c|h]ppで定義されている。（シグナルを表すクラスはSignalである。）面白いことに、SimulatedBlockは他のあらゆるカーネルブロックへ、sendSignal()関数を通じてシグナルを送信することが出来る。同じプロセス内のブロックであろうが、他のホストで動作しているブロックであろうが、同じ方法（関数）でシグナルを送信することが出来るのである。
  • storage/ndb/src/kernel/blocksには各ブロックのソースコードが含まれている。ブロックごとにサブディレクトリに分かれているので見易いだろう。ここで定義されている各カーネルブロックは、上記の通りSimulatedBlockクラスを継承している。各カーネルブロックの動作を定義しているこのディレクトリは、NDBのソースコードの心臓部と言っていいだろう。
  • storage/ndb/include/kernel/BlockNumbers.hには、各カーネルブロックのIDが定義されている。ブロック番号は16ビット符号無し整数なのだが、同じく16ビット符号無し整数であるノードIDと組み合わせることで、32ビットの符号無し整数としてクラスタ全体を通じたID（BlockReference）を合成することが出来る。storage/ndb/include/kernel/RefConvert.hppにはノードIDとブロック番号からBlockReferenceへ変換するロジックおよびその逆が定義されている。（ただのビット演算だけどね！）
  • storage/ndb/src/kernel/SimBlockList.cppには、作成したカーネルブロックのインスタンス化と、そのインスタンスへのポインタをリストにして保管しておくためのロジックが記述されている。ただし、NDBカーネルの各ブロックはインスタンス化された段階ではまだ初期化されず、その後STTORシグナルを受け取った時点で初期化が始まる点には注意したい。
  • storage/ndb/include/kernel/GlobalSignalNumbers.hでは、各シグナルにつけられた番号が記述されている。実に700種類以上のシグナルが定義されている！（2009年10月現在）
  • storage/ndb/include/kernel/signaldataディレクトリには、シグナルにおいて送信されるデータ（ペイロード）を定義するクラスのソースコードが格納されている。シグナルが送信するデータはフリーフォーマット（単なるワード列）なので、頻繁に利用されるデータについてはその構造が定義されているのである。
  • storage/ndb/src/common/transporterディレクトリには、トランスポーターに関するソースコードが格納されている。トランスポーターとは、MySQL Clusterの各ノード同士が通信し合うための仮想的なインターフェイスである。これにより、通信する実際のプロトコル（TCP/IPなのかSCIなのか）に因らないロジックの記述が可能になる。
  • storage/ndb/src/mgmsrvディレクトリには、管理ノードのソースコードが格納されている。特に重要なのはstorage/ndb/src/mgmsrv/ConfigInfo.cppで、このファイルには各種設定パラメーターとそのデフォルト値に関する記述がなされている。また、storage/ndb/src/mgmclientにはndb_mgmコマンドのソースコードが、storage/ndb/src/mgmapiにはNDB MGM API（設定情報をやり取りするためのAPI）のソースコードが格納されている。
  • storage/ndb/src/ndbapiディレクトリには、NDB APIに関するソースコードが格納されている。
そんなわけでMySQL Clusterのソースコードのレイアウトについてとりとめもなく紹介してみた。「よし、ソースコードを見るか！」と思った時に参考にして頂けると幸いである。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 26 Oct 2009 00:32:00 +0000 Mikiya Okuno mysql cluster mysql [mysql]mysqld_multiの設定例 http://d.hatena.ne.jp/kamipo/20091023/1256281969 http://d.hatena.ne.jp/kamipo/20091023/1256281969 mysqld_multiでググると、そんなにブクマされてるわけでもないのに いつもid:sasata299のブログが一番上に出てくる。 mysqld_multiで複数のmysqldの一括管理 - (゜∀゜)o彡 sasata299’s blog これはもう、はてダでmysqld_multiのエントリ書いたら勝つる！ そこでmysqld_multiの設定例です。 mysql入れてbinにPATH通したらshellで下記のコマンドを打ち込んでください。 % mysqld_multi --example わかりやすい設定例が表示されました。よかったですね！ 参考 MySQL :: MySQL 5.1 リファレンスマニュアル :: 4.3.3 mysqld_multi ? 複数のMySQL サーバ管理

mysqld_multiでググると、そんなにブクマされてるわけでもないのに

いつもid:sasata299のブログが一番上に出てくる。

これはもう、はてダでmysqld_multiのエントリ書いたら勝つる！


そこでmysqld_multiの設定例です。

mysql入れてbinにPATH通したらshellで下記のコマンドを打ち込んでください。

% mysqld_multi --example

わかりやすい設定例が表示されました。よかったですね！


参考

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 23 Oct 2009 07:12:49 +0000 Kamizono Ryuta mysql [mysql] レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン http://d.hatena.ne.jp/hirose31/20091023/1256259405 http://d.hatena.ne.jp/hirose31/20091023/1256259405 MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバックの作業が煩雑になる DBサーバは、並べるだけで済むWebサーバと違う アクセスが捌けなくなりそうなときは: MySQLやアプリのチューニングで乗り越える どーしても突破できないときは、スケールアップを考える それでもどーしても突破できないときは、水平パーティショニングを考える それでもそれでもどーしても突破できないときは、垂直パーティショニングを考える レプリケーションの世界の話 db1とdb2は双方向レプリケーションしている db2はdb1のマスタ db1はdb2のマスタ マスタの指定では、サーバ固有のIPアドレス(=db1やdb2のIPアドレス)を使う。浮動IPアドレス(後述)のdb0などは指定しない。 双方向レプリケーションしている理由 例えば「プライマリがフリーズしたのでリセットして復帰した場合」など、プライマリだったサーバが短い時間の後に復帰した場合の復旧作業を楽にするため。詳しくは後述。 経験上、「短時間の停止」は割とよくあることなので、復帰手順を簡単にしたい。 用語の整理: プライマリとセカンダリとバックアップ プライマリとは、更新系クエリを受け付ける唯一のサーバのこと プライマリの実体というか正体というかは浮動IPアドレス セカンダリとは、参照系のクエリを受け付けるサーバのこと バックアップとは、実サービスには使わないスレーブのこと クライアントは、プライマリのVIPに向けて更新系クエリを発行する プライマリのVIPはひとつのサーバにしか付与されないので、更新系クエリを受け付け処理するのは、ただ一つのサーバということになる クライアントはlvsを介してセカンダリに参照系クエリを発行する セカンダリが停止しても参照系クエリを処理できるように、ロードバランサを介してセカンダリとプライマリでアクティブ/バックアップ構成にするか、重み付けのロードバランスにする。 セカンダリは set global read_only = 1 して、更新系クエリが来てしまっても受け入れないようにする（事故防止） バックアップの用途: 日次のスナップショットの採取に (7世代ぐらい保存する) for db in ALL_DB; do mysqldump --opt --no-autocommit --hex-blob -master-data=2 --database $db | gzip -c > YYYYMMDD/$db.gz; done 集計などに 実サービスには投入していないので、重いクエリを発行してもOK。 障害時の対応手順 プライマリが再起不能 プライマリにデータの消失を伴う故障が発生した場合 RAID配下のディスクが複数台同時に故障した RAIDコントローラが故障した 作業概要 プライマリがダウンした時点で、(自動的に)セカンダリがプライマリに昇格する 旧プライマリは故障解消後、バックアップからのまるごとコピーを使って復旧する。 プライマリがダウン ★サービス停止★ (更新系のみ停止) <セカンダリをプライマリに昇格> →更新、参照共に新プライマリに行く ★新プライマリ復旧★ ★サービス仮復旧★ 旧セカンダリとバックアップで、SHOW SLAVE STATUSのExec_Master_Log_Posを比較する ▼(A):旧セカンダリExec_Pos = バックアップExec_Pos: 旧セカンダリとバックアップのデータの同期点がとれたので次のステップ(C)へ移る→ ▼旧セカンダリExec_Pos > バックアップExec_Pos: 旧セカンダリとバックアップで、SHOW SLAVE STATUSのRead_Master_Log_Posを比較する ▼旧セカンダリRead_Pos = バックアップRead_Pos: Exec_Posが同じになるまで待って、ステップ(A)へ移る→ ▼旧セカンダリRead_Pos > バックアップRead_Pos: 旧セカンダリとバックアップのrelayログをmysqlbinlogで見て比較し、差分のクエリをバックアップに対して手動で発行する。 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→ ▼旧セカンダリRead_Pos < バックアップRead_Pos: (B):あんまり起こらないはず、起こるとちょっとまずいシチュエーション。。。 旧セカンダリとバックアップのrelayログをmysqlbinlogで見て比較し、差分のクエリを旧セカンダリに対して手動で発行する。 旧セカンダリは既に新プライマリとして更新系クエリを受け付けているので、差分の確認とその適用は、新プライマリになった後で受け付けたクエリも加味して慎重に検討する必要がある。 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→ ▼旧セカンダリExec_Pos < バックアップExec_Pos: 起こるとちょっとまずいシチュエーション 旧セカンダリとバックアップで、SHOW SLAVE STATUSのRead_Master_Log_Posを比較する ▼旧セカンダリRead_Pos = バックアップRead_Pos: 起こり得ない。 プライマリに昇格する際にReadとExecが同じになるまで待っているので、Execが旧セカンダリ < バックアップで、Readが旧セカンダリ = バックアップになるのはあり得ない。待てばバックアップのExec_Posが進むはずなので。 ▼旧セカンダリRead_Pos > バックアップRead_Pos: Exec_Pos < Read_Pos なのであり得ない ▼旧セカンダリRead_Pos < バックアップRead_Pos: 起こるとちょっとまずいシチュエーション ステップ(B)へ移る→ バックアップの復旧 (C):バックアップのmysqldを停止して、<丸ごとバックアップを採取>する master.infoを編集して、新プライマリのスレーブになるようにする Master_Host を新プライマリの個有名(db0ではなくdb2など)に変更 新プライマリは昇格時にバイナリログをローテートしているので、以下の通りに変更する Master_Log_Fileは新しいログファイル名 Read_Master_Log_Posは4 バックアップのmysqldを起動する ★バックアップ復旧★ 新セカンダリの復旧 新セカンダリのサーバのセットアップができたら スレーブのロードバランスグループに入らないようにする iptables -I INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306 (C)で採取した丸ごとバックアップを展開する master.infoを編集して、新プライマリのスレーブになるようにする Master_Host を新プライマリの個有名(db0ではなくdb2など)に変更 新プライマリは昇格時にバイナリログをローテートしているので、以下の通りに変更する Master_Log_Fileは新しいログファイル名 Read_Master_Log_Posは4 新セカンダリのmysqldを起動する 新プライマリと同期するまで待つ 新セカンダリでSHOW MASTER STATUSし、新プライマリで、そのPosにCHANGE MASTER TOする CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000XXX', MASTER_LOG_POS = XXX; 新プライマリで START SLAVE レプリケーションが追いついたのを確認してスレーブのロードバランスグループに入れる iptables -D INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306 ★新セカンダリ復旧★ ★サービス完全復旧★ プライマリが短時間停止 比較的短時間の停止 OS rebootした ハングアップしたのでリセットした 作業概要 プライマリがダウンした時点で、(自動的に)セカンダリがプライマリに昇格する 旧プライマリは復帰後、レプリケーションを再開し、追いついたらセカンダリとして参照系クエリを処理するようにする プライマリがダウン ★サービス停止★ (更新系のみ停止) <セカンダリをプライマリに昇格> →更新、参照共に新プライマリに行く ★新プライマリ復旧★ ★サービス仮復旧★ 旧セカンダリとバックアップで、SHOW SLAVE STATUSのExec_Master_Log_Posを比較する (以下↑の手順と同じ) 旧プライマリを起動する 新プライマリのスレーブにならないようにする そのためにmaster.infoを別の名前にrenameしてからmysqldを起動する スレーブのロードバランスグループに入らないようにする iptables -I INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306 -s にはlvsのアドレスを指定する 新プライマリのSHOW SLAVE STATUSのExec_Master_Log_Posと旧プライマリの1つ前のバイナリログの最後のend_log_posを比較 mysqlbinlog $(ls -1tr mysql-bin.[0-9]*|head -n -1|tail -n 1) | grep end_log_pos | tail -n 1 ▼(A):新プライマリExec_Pos = 旧プライマリend_log_pos: ステップ(B)へ移る→ ▼新プライマリExec_Pos > 旧プライマリend_log_pos: ありえない。 ▼新プライマリExec_Pos < 旧プライマリend_log_pos: 新プライマリのSHOW SLAVE STATUSのRead_Master_Log_Posと旧プライマリの1つ前のバイナリログの最後のend_log_posを比較 ▼新プライマリRead_Pos = 旧プライマリend_log_pos: Exec_Posが同じになるまで待って、ステップ(A)へ移る→ ▼新プライマリRead_Pos > 旧プライマリend_log_pos: ありえない。 ▼新プライマリRead_Pos < 旧プライマリend_log_pos: 起こるとちょっとまずいシチュエーション。 新プライマリリレーログと旧プライマリのバイナリログをmysqlbinlogで見て比較し、差分のクエリを新プライマリに対して手動で発行する。 新プライマリは既に更新系クエリを受け付けているので、差分の確認とその適用は、新プライマリになった後で受け付けたクエリも加味して慎重に検討する必要がある。 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→ (B):旧プライマリを新プライマリのスレーブにする SET GLOBAL READ_ONLY = 1 する 旧プライマリのmysqld停止 旧プライマリの先の手順でrenameしたmaster.infoを元に戻す 旧プライマリのmysqld開始 新プライマリ→旧プライマリのレプリケーションが開始される レプリケーションが追いついたのを確認してスレーブのロードバランスグループに入れる iptables -D INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306 ★新セカンダリ復旧★ ★サービス完全復旧★ セカンダリが再起不能 セカンダリがダウンすると、参照系のクエリはプライマリに流れるようにしているので、セカンダリがダウンしてもサービスには影響なし。 作業概要 バックアップで<まるごとバックアップを採取する> バックアップはサービスに使ってないので止めても影響なし それをセカンダリに展開して、mysqldを起動 セカンダリが短時間停止 作業概要 mysqldを立上げるだけでOK 共通手順 <セカンダリをプライマリに昇格> プライマリの浮動IPアドレスを付与する ip addr add PRIMARY_IPADDR/16 broadcast 192.0.2.255 dev bond0:0 send_arp PRIMARY_IPADDR $(ip link show bond0 | grep 'ether' | awk '{print $2}') 255.255.255.255 ff:ff:ff:ff:ff:ff ちなみに剥奪するのは ip addr del PRIMARY_IPADDR/16 dev bond0:0 Read_Master_Log_Pos が Exec_Master_Log_Pos と同じになるまで待つ SHOW SLAVE STATUS の結果をメモる STOP SLAVE FLUSH LOGS binlogをローテートするため SET GLOBAL READ_ONLY = 0 <まるごとバックアップを採取する> cd /db tar --exclude 'mysql-bin.*' -cvpf mysql.tar mysql

MySQLで、レプリケーションベースのHAな構成について考えたメモです。

3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。

今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。

ゴール

  • マスタが落ちてもぐーすか寝ていられるようにしたい
  • リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい
  • めんどくさいのはいや

基本構成、方針

f:id:hirose31:20091022205812p:image

  • 2台＋1台
    • サービスで使うのは2台 (db1, db2)
    • もう1台は管理用 (db3)
  • スレーブを多数並べる構成にはしない
    • 台数増えると管理コストが上がる
    • マスタダウン時のフェイルオーバとそのフェイルバックの作業が煩雑になる
      • DBサーバは、並べるだけで済むWebサーバと違う
  • アクセスが捌けなくなりそうなときは:
    • MySQLやアプリのチューニングで乗り越える
    • どーしても突破できないときは、スケールアップを考える
    • それでもどーしても突破できないときは、水平パーティショニングを考える
    • それでもそれでもどーしても突破できないときは、垂直パーティショニングを考える

レプリケーションの世界の話

  • db1とdb2は双方向レプリケーションしている
    • db2はdb1のマスタ
    • db1はdb2のマスタ
    • マスタの指定では、サーバ固有のIPアドレス(=db1やdb2のIPアドレス)を使う。浮動IPアドレス(後述)のdb0などは指定しない。
  • 双方向レプリケーションしている理由
    • 例えば「プライマリがフリーズしたのでリセットして復帰した場合」など、プライマリだったサーバが短い時間の後に復帰した場合の復旧作業を楽にするため。詳しくは後述。
    • 経験上、「短時間の停止」は割とよくあることなので、復帰手順を簡単にしたい。

用語の整理: プライマリとセカンダリとバックアップ

  • プライマリとは、更新系クエリを受け付ける唯一のサーバのこと
    • プライマリの実体というか正体というかは浮動IPアドレス
  • セカンダリとは、参照系のクエリを受け付けるサーバのこと
  • バックアップとは、実サービスには使わないスレーブのこと
  • クライアントは、プライマリのVIPに向けて更新系クエリを発行する
    • プライマリのVIPはひとつのサーバにしか付与されないので、更新系クエリを受け付け処理するのは、ただ一つのサーバということになる
  • クライアントはlvsを介してセカンダリに参照系クエリを発行する
    • セカンダリが停止しても参照系クエリを処理できるように、ロードバランサを介してセカンダリとプライマリでアクティブ/バックアップ構成にするか、重み付けのロードバランスにする。
    • セカンダリは set global read_only = 1 して、更新系クエリが来てしまっても受け入れないようにする（事故防止）
  • バックアップの用途:
    • 日次のスナップショットの採取に (7世代ぐらい保存する)
      • for db in ALL_DB; do mysqldump --opt --no-autocommit --hex-blob -master-data=2 --database $db | gzip -c > YYYYMMDD/$db.gz; done
    • 集計などに
      • 実サービスには投入していないので、重いクエリを発行してもOK。

障害時の対応手順

プライマリが再起不能
  • プライマリにデータの消失を伴う故障が発生した場合
    • RAID配下のディスクが複数台同時に故障した
    • RAIDコントローラが故障した
  • 作業概要
    • プライマリがダウンした時点で、(自動的に)セカンダリがプライマリに昇格する
    • 旧プライマリは故障解消後、バックアップからのまるごとコピーを使って復旧する。
  • プライマリがダウン
  • ★サービス停止★ (更新系のみ停止)
  • <セカンダリをプライマリに昇格>
    • →更新、参照共に新プライマリに行く
  • ★新プライマリ復旧★
  • ★サービス仮復旧★
  • 旧セカンダリとバックアップで、SHOW SLAVE STATUSのExec_Master_Log_Posを比較する
    • ▼(A):旧セカンダリExec_Pos = バックアップExec_Pos:
      • 旧セカンダリとバックアップのデータの同期点がとれたので次のステップ(C)へ移る→
    • ▼旧セカンダリExec_Pos > バックアップExec_Pos:
      • 旧セカンダリとバックアップで、SHOW SLAVE STATUSのRead_Master_Log_Posを比較する
        • ▼旧セカンダリRead_Pos = バックアップRead_Pos:
          • Exec_Posが同じになるまで待って、ステップ(A)へ移る→
        • ▼旧セカンダリRead_Pos > バックアップRead_Pos:
          • 旧セカンダリとバックアップのrelayログをmysqlbinlogで見て比較し、差分のクエリをバックアップに対して手動で発行する。
          • 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→
        • ▼旧セカンダリRead_Pos < バックアップRead_Pos:
          • (B):あんまり起こらないはず、起こるとちょっとまずいシチュエーション。。。
          • 旧セカンダリとバックアップのrelayログをmysqlbinlogで見て比較し、差分のクエリを旧セカンダリに対して手動で発行する。
          • 旧セカンダリは既に新プライマリとして更新系クエリを受け付けているので、差分の確認とその適用は、新プライマリになった後で受け付けたクエリも加味して慎重に検討する必要がある。
          • 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→
    • ▼旧セカンダリExec_Pos < バックアップExec_Pos:
      • 起こるとちょっとまずいシチュエーション
      • 旧セカンダリとバックアップで、SHOW SLAVE STATUSのRead_Master_Log_Posを比較する
        • ▼旧セカンダリRead_Pos = バックアップRead_Pos:
          • 起こり得ない。
            • プライマリに昇格する際にReadとExecが同じになるまで待っているので、Execが旧セカンダリ < バックアップで、Readが旧セカンダリ = バックアップになるのはあり得ない。待てばバックアップのExec_Posが進むはずなので。
        • ▼旧セカンダリRead_Pos > バックアップRead_Pos:
          • Exec_Pos < Read_Pos なのであり得ない
        • ▼旧セカンダリRead_Pos < バックアップRead_Pos:
          • 起こるとちょっとまずいシチュエーション
          • ステップ(B)へ移る→
  • バックアップの復旧
    • (C):バックアップのmysqldを停止して、<丸ごとバックアップを採取>する
    • master.infoを編集して、新プライマリのスレーブになるようにする
      • Master_Host を新プライマリの個有名(db0ではなくdb2など)に変更
      • 新プライマリは昇格時にバイナリログをローテートしているので、以下の通りに変更する
        • Master_Log_Fileは新しいログファイル名
        • Read_Master_Log_Posは4
    • バックアップのmysqldを起動する
  • ★バックアップ復旧★
  • 新セカンダリの復旧
    • 新セカンダリのサーバのセットアップができたら
    • スレーブのロードバランスグループに入らないようにする
      • iptables -I INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306
    • (C)で採取した丸ごとバックアップを展開する
    • master.infoを編集して、新プライマリのスレーブになるようにする
      • Master_Host を新プライマリの個有名(db0ではなくdb2など)に変更
      • 新プライマリは昇格時にバイナリログをローテートしているので、以下の通りに変更する
        • Master_Log_Fileは新しいログファイル名
        • Read_Master_Log_Posは4
    • 新セカンダリのmysqldを起動する
    • 新プライマリと同期するまで待つ
    • 新セカンダリでSHOW MASTER STATUSし、新プライマリで、そのPosにCHANGE MASTER TOする
      • CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000XXX', MASTER_LOG_POS = XXX;
    • 新プライマリで START SLAVE
    • レプリケーションが追いついたのを確認してスレーブのロードバランスグループに入れる
      • iptables -D INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306
  • ★新セカンダリ復旧★
  • ★サービス完全復旧★
プライマリが短時間停止
  • 比較的短時間の停止
    • OS rebootした
    • ハングアップしたのでリセットした
  • 作業概要
    • プライマリがダウンした時点で、(自動的に)セカンダリがプライマリに昇格する
    • 旧プライマリは復帰後、レプリケーションを再開し、追いついたらセカンダリとして参照系クエリを処理するようにする
  • プライマリがダウン
  • ★サービス停止★ (更新系のみ停止)
  • <セカンダリをプライマリに昇格>
    • →更新、参照共に新プライマリに行く
  • ★新プライマリ復旧★
  • ★サービス仮復旧★
  • 旧セカンダリとバックアップで、SHOW SLAVE STATUSのExec_Master_Log_Posを比較する
    • (以下↑の手順と同じ)
  • 旧プライマリを起動する
    • 新プライマリのスレーブにならないようにする
      • そのためにmaster.infoを別の名前にrenameしてからmysqldを起動する
    • スレーブのロードバランスグループに入らないようにする
      • iptables -I INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306
      • -s にはlvsのアドレスを指定する
  • 新プライマリのSHOW SLAVE STATUSのExec_Master_Log_Posと旧プライマリの1つ前のバイナリログの最後のend_log_posを比較
    • mysqlbinlog $(ls -1tr mysql-bin.[0-9]*|head -n -1|tail -n 1) | grep end_log_pos | tail -n 1
    • ▼(A):新プライマリExec_Pos = 旧プライマリend_log_pos:
      • ステップ(B)へ移る→
    • ▼新プライマリExec_Pos > 旧プライマリend_log_pos:
      • ありえない。
    • ▼新プライマリExec_Pos < 旧プライマリend_log_pos:
      • 新プライマリのSHOW SLAVE STATUSのRead_Master_Log_Posと旧プライマリの1つ前のバイナリログの最後のend_log_posを比較
        • ▼新プライマリRead_Pos = 旧プライマリend_log_pos:
          • Exec_Posが同じになるまで待って、ステップ(A)へ移る→
        • ▼新プライマリRead_Pos > 旧プライマリend_log_pos:
          • ありえない。
        • ▼新プライマリRead_Pos < 旧プライマリend_log_pos:
          • 起こるとちょっとまずいシチュエーション。
          • 新プライマリリレーログと旧プライマリのバイナリログをmysqlbinlogで見て比較し、差分のクエリを新プライマリに対して手動で発行する。
          • 新プライマリは既に更新系クエリを受け付けているので、差分の確認とその適用は、新プライマリになった後で受け付けたクエリも加味して慎重に検討する必要がある。
          • 後、Exec_Posが同じになるまで待って、ステップ(A)へ移る→
  • (B):旧プライマリを新プライマリのスレーブにする
    • SET GLOBAL READ_ONLY = 1 する
    • 旧プライマリのmysqld停止
    • 旧プライマリの先の手順でrenameしたmaster.infoを元に戻す
    • 旧プライマリのmysqld開始
      • 新プライマリ→旧プライマリのレプリケーションが開始される
    • レプリケーションが追いついたのを確認してスレーブのロードバランスグループに入れる
      • iptables -D INPUT -j REJECT -p tcp -s 192.0.2.60/30 --dport 3306
  • ★新セカンダリ復旧★
  • ★サービス完全復旧★
セカンダリが再起不能

セカンダリがダウンすると、参照系のクエリはプライマリに流れるようにしているので、セカンダリがダウンしてもサービスには影響なし。

  • 作業概要
    • バックアップで<まるごとバックアップを採取する>
      • バックアップはサービスに使ってないので止めても影響なし
    • それをセカンダリに展開して、mysqldを起動
セカンダリが短時間停止
  • 作業概要
    • mysqldを立上げるだけでOK

共通手順

<セカンダリをプライマリに昇格>
  • プライマリの浮動IPアドレスを付与する
    • ip addr add PRIMARY_IPADDR/16 broadcast 192.0.2.255 dev bond0:0
    • send_arp PRIMARY_IPADDR $(ip link show bond0 | grep 'ether' | awk '{print $2}') 255.255.255.255 ff:ff:ff:ff:ff:ff
    • ちなみに剥奪するのは ip addr del PRIMARY_IPADDR/16 dev bond0:0
  • Read_Master_Log_Pos が Exec_Master_Log_Pos と同じになるまで待つ
  • SHOW SLAVE STATUS の結果をメモる
  • STOP SLAVE
  • FLUSH LOGS
    • binlogをローテートするため
  • SET GLOBAL READ_ONLY = 0
<まるごとバックアップを採取する>
cd /db
tar --exclude 'mysql-bin.*' -cvpf mysql.tar mysql

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 23 Oct 2009 00:56:45 +0000 ひろせ まさあき MySQL 5.1.40リリース http://d.hatena.ne.jp/sh2/20091023 http://d.hatena.ne.jp/sh2/20091023 出ました。今回はバグ修正が48件あり、そのうちパーティショニング機能に関するものが5件、レプリケーション機能に関するものが6件あります。サーバクラッシュ系のバグ修正がいくつかありますが、いずれも発生条件が極めて複雑であり、通常の運用で当たることはまずないのではないかと思います。 今回ちょっと気になったバグとして、Bug#44369があります。 mysql&#62; create table test (DB_ROW_ID int) engine = innodb; ERROR 1005 (HY000): Can&#39;t create table &#39;scott.test&#39; (errno: -1) mysql&#62; create table test (db_row_id int) engine = innodb; Query OK, 0 rows affected (0.01 sec) InnoDBでは特定のカラム名を持ったテーブルが作れないという仕様があるのですが、そのカラム名のチェックが不十分なため、小文字で指定するとテーブルが作れてしまうというバグです。 私はそもそもこのようなカラム名の制限があることを、今まで知りませんでした。確認したところMySQL 5.1.40では以下の3つが予約語として定義されており、InnoDBテーブルのカラム名として指定できないようになっています。 DB_ROW_ID DB_TRX_ID DB_ROLL_PTR これらはソースの storage/innobase/dict/dict0dict.c 内で定義されています。 /******************************************************************** If the given column name is reserved for InnoDB system columns, return TRUE. */ ibool dict_col_name_is_reserved( /*======================*/ /* out: TRUE if name is reserved */ const char* name) /* in: column name */ { /* This check reminds that if a new system column is added to the program, it should be dealt with here. */ #if DATA_N_SYS_COLS != 3 #error &#34;DATA_N_SYS_COLS != 3&#34; #endif static const char* reserved_names[] = { &#34;DB_ROW_ID&#34;, &#34;DB_TRX_ID&#34;, &#34;DB_ROLL_PTR&#34; }; ulint i; for (i = 0; i &#60; UT_ARR_SIZE(reserved_names); i++) { if (innobase_strcasecmp(name, reserved_names[i]) == 0) { return(TRUE); } } return(FALSE); } ご注意ください。 mysql> create table test (DB_ROW_ID int) engine = innodb; ERROR 1005 (HY000): Can't create table 'scott.test' (errno: -1) mysql> create table test (db_row_id int) engine = innodb; Query OK, 0 rows affected (0.01 sec) InnoDBでは特定のカラム名を持ったテーブルが作れないという仕様があるのですが、そのカラム名のチェックが不十分なため、小文字で指定するとテーブルが作れてしまうというバグです。 私はそもそもこのようなカラム名の制限があることを、今まで知りませんでした。確認したところMySQL 5.1.40では以下の3つが予約語として定義されており、InnoDBテーブルのカラム名として指定できないようになっています。 DB_ROW_ID DB_TRX_ID DB_ROLL_PTR これらはソースの storage/innobase/dict/dict0dict.c 内で定義されています。 /******************************************************************** If the given column name is reserved for InnoDB system columns, return TRUE. */ ibool dict_col_name_is_reserved( /*======================*/ /* out: TRUE if name is reserved */ const char* name) /* in: column name */ { /* This check reminds that if a new system column is added to the program, it should be dealt with here. */ #if DATA_N_SYS_COLS != 3 #error "DATA_N_SYS_COLS != 3" #endif static const char* reserved_names[] = { "DB_ROW_ID", "DB_TRX_ID", "DB_ROLL_PTR" }; ulint i; for (i = 0; i < UT_ARR_SIZE(reserved_names); i++) { if (innobase_strcasecmp(name, reserved_names[i]) == 0) { return(TRUE); } } return(FALSE); } ご注意ください。
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Fri, 23 Oct 2009 00:00:00 +0000 Sadao Hiratsuka MySQL Clusterカーネルの中身を覗いてみよう。 tag:blogger.com,1999:blog-1906500952232920237.post-6912023366957535134 http://nippondanji.blogspot.com/2009/10/mysql-cluster_23.html MySQL Clusterのデータノードであるndbd（もしくはndbmtd）プロセスは、内部的にはマルチプルステートマシン（ブロック）がシグナル（もしくはメッセージ）を交換するという構造になっており、高い同時実行性を実現しているということについては前回述べた通りである。今日は、ndbd内部にどのようなカーネルブロックが存在するかということについて大まかに説明しよう。前回の話を踏まえて読んで頂ければ、何となくイメージだけでも掴めるのではないかと思う。まずは次の絵を見て頂きたい。これは俺の脳内から引っ張り出したndbdの構造のイメージ図である。矢印はブロック同士の相関関係（シグナルの送受信など）を示すのだが、この絵に描かれているものは非常に省略されたものであり、実際にはもっと複雑に絡み合っているのだということを覚えておいて欲しい。例えばQMGRやDBDICTといったブロックは、他のブロック全てとシグナル交換をするのだが、それを全て描くと何が何だか分からなくなるので省いているわけである。もし全てを描いたなら、思わず「それ何てスパゲティ？」と叫んでしまうこと請け合いである。というわけで、以下淡々と各ブロックについて簡単に説明しよう。MySQL Clusterの各ブロックは、いくつかのカテゴリに分類することが出来るので、以下ではそのカテゴリごとに説明している。NDBカーネルを管理するブロックCMVMI・・・Cluster Manager Virtual Machine Interfaceの略。OSへのリクエストを処理したり、ndb_mgmd（管理ノード）と通信をしてndbdの構成を決定する。NDBCNTR・・・NDB CordiNaToRの略。NDBコントローラーか？と思ってしまいがちだが、コーディネーターの意味。役割はndbd起動時の初期化とシャットダウン。QMGR・・・クラスタマネージャブロック。ハートビートを通じて各ブロックの状態を管理している。NDBカーネルの親玉的存在。NDBFS・・・ファイルシステムへのI/Oを一手に引き受けるブロック。このブロックのおかげでファイルへの非同期I/Oが容易に実装できている。ローカルノード（自ノード）のデータを管理するブロック。DBLQH・・・ローカル・クエリ・ハンドラ。自ノードに対するトランザクションを処理する。MySQL Clusterのndbmtdでマルチスレッド化されたのはこのブロック。図を見れば分かると思うが、このブロックの負荷はかなり高い。（次いで負荷が高いのはDBTC）DBACC・・・自ノードの主キーを管理するブロック。ACCはアクセスの意味。DBTUP・・・データを管理するブロック。TUPはタプルの意味。DBTUX・・・TUple indeXの略。OrderedIndexを管理する。DBUTIL・・・トランザクション管理やデータ管理のための便利な機能が詰まったユーティリティブロック。並列分散処理のためのブロックDBDICT・・・ディクショナリブロック。テーブルやテーブルスペース、ログファイルのメタデータの管理を一手に引き受ける。SQLノードが直接アクセス出来るブロックである。DBTC・・・Transaction Cordinatorの略。SQLノードからリクエストされたトランザクションの面倒を始まりから終わりまで面倒を見るブロックである。該当するデータが自ノードの担当でなければ、別のデータノードへ要求を送ったりする。DBDIH・・・DIstribution Handlerの略。レプリカを管理し、どのフラグメント（パーティション）がどのノードに格納されているかについて責任を持つ。また、LCPやGCPといった処理を行うのもこのノードである。TRIX・・・TRansactions and IndeXesの略。このブロックは内部的なトリガとユニークインデックスを管理する。MySQL Clusterはデータが複数のノードに分散しているので、行の一意性を保証するのにはどうしても分割の対象となる主キーが必要となるため、サポートテーブルという別の内部テーブルが作成される。実テーブルと内部テーブルは、トリガによって同期されるというわけである。ディスク型テーブル用のブロックPGMAN・・・バッファページを管理するブロック。名前の由来はPaGe MANagerである。TSMAN・・・テーブルスペースを管理するブロック。名前の由来はTableSpace MANagerである。LGMAN・・・ログファイルグループを管理するブロック。名前の由来はLogfile Group MANagerである。バックアップ関係BACKUP・・・オンラインバックアップの実行。RESTORE・・・取得したバックアップのリストア。ndb_restoreコマンドからデータを受け取ってリストアする。ndb_restoreコマンドは、一種のSQLノードとして動作する。SUMA・・・SUbscription MAnager。MySQL Server（mysqld）へバイナリログの元になるデータを送信する。以上がNDBカーネルブロックの概要である。ブロック同士がシグナルを交換して実現しているのは「データベース管理システム」である。各カーネルブロックは、データベース管理システムに必要な機能の要素ひとつひとつを具現化したものであると考えられるので、どのようなブロックが存在するかということはデータベースエンジニアにとって興味深いものとなっているのではないだろうか。また、MySQL Clusterのログにはブロック名がたくさん登場するので、ブロックの役割について知っていればログを見る際に役立つはずである。次回は、MySQL Clusterのソースコードのレイアウトについて説明する予定である。 前回述べた通りである。今日は、ndbd内部にどのようなカーネルブロックが存在するかということについて大まかに説明しよう。前回の話を踏まえて読んで頂ければ、何となくイメージだけでも掴めるのではないかと思う。まずは次の絵を見て頂きたい。これは俺の脳内から引っ張り出したndbdの構造のイメージ図である。




矢印はブロック同士の相関関係（シグナルの送受信など）を示すのだが、この絵に描かれているものは非常に省略されたものであり、実際にはもっと複雑に絡み合っているのだということを覚えておいて欲しい。例えばQMGRやDBDICTといったブロックは、他のブロック全てとシグナル交換をするのだが、それを全て描くと何が何だか分からなくなるので省いているわけである。もし全てを描いたなら、思わず「それ何てスパゲティ？」と叫んでしまうこと請け合いである。

というわけで、以下淡々と各ブロックについて簡単に説明しよう。MySQL Clusterの各ブロックは、いくつかのカテゴリに分類することが出来るので、以下ではそのカテゴリごとに説明している。

NDBカーネルを管理するブロック
  • CMVMI・・・Cluster Manager Virtual Machine Interfaceの略。OSへのリクエストを処理したり、ndb_mgmd（管理ノード）と通信をしてndbdの構成を決定する。
  • NDBCNTR・・・NDB CordiNaToRの略。NDBコントローラーか？と思ってしまいがちだが、コーディネーターの意味。役割はndbd起動時の初期化とシャットダウン。
  • QMGR・・・クラスタマネージャブロック。ハートビートを通じて各ブロックの状態を管理している。NDBカーネルの親玉的存在。
  • NDBFS・・・ファイルシステムへのI/Oを一手に引き受けるブロック。このブロックのおかげでファイルへの非同期I/Oが容易に実装できている。
ローカルノード（自ノード）のデータを管理するブロック。
  • DBLQH・・・ローカル・クエリ・ハンドラ。自ノードに対するトランザクションを処理する。MySQL Clusterのndbmtdでマルチスレッド化されたのはこのブロック。図を見れば分かると思うが、このブロックの負荷はかなり高い。（次いで負荷が高いのはDBTC）
  • DBACC・・・自ノードの主キーを管理するブロック。ACCはアクセスの意味。
  • DBTUP・・・データを管理するブロック。TUPはタプルの意味。
  • DBTUX・・・TUple indeXの略。OrderedIndexを管理する。
  • DBUTIL・・・トランザクション管理やデータ管理のための便利な機能が詰まったユーティリティブロック。
並列分散処理のためのブロック
  • DBDICT・・・ディクショナリブロック。テーブルやテーブルスペース、ログファイルのメタデータの管理を一手に引き受ける。SQLノードが直接アクセス出来るブロックである。
  • DBTC・・・Transaction Cordinatorの略。SQLノードからリクエストされたトランザクションの面倒を始まりから終わりまで面倒を見るブロックである。該当するデータが自ノードの担当でなければ、別のデータノードへ要求を送ったりする。
  • DBDIH・・・DIstribution Handlerの略。レプリカを管理し、どのフラグメント（パーティション）がどのノードに格納されているかについて責任を持つ。また、LCPやGCPといった処理を行うのもこのノードである。
  • TRIX・・・TRansactions and IndeXesの略。このブロックは内部的なトリガとユニークインデックスを管理する。MySQL Clusterはデータが複数のノードに分散しているので、行の一意性を保証するのにはどうしても分割の対象となる主キーが必要となるため、サポートテーブルという別の内部テーブルが作成される。実テーブルと内部テーブルは、トリガによって同期されるというわけである。
ディスク型テーブル用のブロック
  • PGMAN・・・バッファページを管理するブロック。名前の由来はPaGe MANagerである。
  • TSMAN・・・テーブルスペースを管理するブロック。名前の由来はTableSpace MANagerである。
  • LGMAN・・・ログファイルグループを管理するブロック。名前の由来はLogfile Group MANagerである。
バックアップ関係
  • BACKUP・・・オンラインバックアップの実行。
  • RESTORE・・・取得したバックアップのリストア。ndb_restoreコマンドからデータを受け取ってリストアする。ndb_restoreコマンドは、一種のSQLノードとして動作する。
  • SUMA・・・SUbscription MAnager。MySQL Server（mysqld）へバイナリログの元になるデータを送信する。
以上がNDBカーネルブロックの概要である。

ブロック同士がシグナルを交換して実現しているのは「データベース管理システム」である。各カーネルブロックは、データベース管理システムに必要な機能の要素ひとつひとつを具現化したものであると考えられるので、どのようなブロックが存在するかということはデータベースエンジニアにとって興味深いものとなっているのではないだろうか。また、MySQL Clusterのログにはブロック名がたくさん登場するので、ブロックの役割について知っていればログを見る際に役立つはずである。次回は、MySQL Clusterのソースコードのレイアウトについて説明する予定である。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Thu, 22 Oct 2009 23:09:00 +0000 Mikiya Okuno mysql cluster mysql [MySQL]MySQLで実行したクエリのログを検索したい http://d.hatena.ne.jp/rin1024/20091021/1256082650 http://d.hatena.ne.jp/rin1024/20091021/1256082650 mysqlで実行されたクエリは， ↑キーおしてったら見れるけど， これをgrepで検索ってできないのかなー． あったら便利そう． [追記]普通にできるじゃん.. ユーザごとに実行ログファイルが下記にある /home/ユーザ名/.mysql_history なので grep &#34;select&#34; ~/.mysql_history とかすればselectした履歴とか普通にみれる． my.cnfのMYSQL_HISTFILEで全体の履歴の設定も出来るっぽい？ http://www.mysql.gr.jp/Manual/mysql-4.00.11/manual.ja_Environment_variables.html 知らない事だらけだ [追記2] id:tokuhiromさんから「C-r じゃだめなんだろか」ってツッコミいただきました． やりたかったことまんまでした＞＜ ツッコミありがとうございます．．．

f:id:rin1024:20091021090109g:image

mysqlで実行されたクエリは，

↑キーおしてったら見れるけど，

これをgrepで検索ってできないのかなー．

あったら便利そう．


[追記]普通にできるじゃん..

ユーザごとに実行ログファイルが下記にある

/home/ユーザ名/.mysql_history

なので

grep "select" ~/.mysql_history

とかすればselectした履歴とか普通にみれる．


my.cnfのMYSQL_HISTFILEで全体の履歴の設定も出来るっぽい？

http://www.mysql.gr.jp/Manual/mysql-4.00.11/manual.ja_Environment_variables.html


知らない事だらけだ


[追記2]

id:tokuhiromさんから「C-r じゃだめなんだろか」ってツッコミいただきました．

やりたかったことまんまでした＞＜

ツッコミありがとうございます．．．


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 20 Oct 2009 23:50:50 +0000 Yuki Anai MySQL Cluster進化の歴史 tag:blogger.com,1999:blog-1906500952232920237.post-6946436941005200632 http://nippondanji.blogspot.com/2009/10/mysql-cluster.html MySQL Cluster開発者の一人であるFrazer Clement氏がその歴史についてとても興味深いエントリを自身のブログで綴っているのだが、いかんせん英語の長文で日本人には辛いかも知れないので今日はその日本語訳を皆さんにも紹介しようと思う。進化の歴史とその結果生じた構造を知ることにより、MySQL Clusterの仕組みに興味を持って頂けると幸いである。（わかり辛いところにはところどころ訳者による注釈を入れてある。ただし翻訳は結構大ざっぱなので、英語が達者であれば細かいニュアンスなどはオリジナルのエントリを参照して頂きたい。なお、日本語訳をすることに関してはFrazer氏の了解を得ているのであしからず。）NDB（MySQL Clusterの略称。元々はNetwork DBという名称であった。）の開発の正確な歴史について、きっと他の誰かのほうが上手く解説できると思うのだが、限られて曖昧かも知れないが私の見解を以下に述べようと思う。NDBは元々、EricssonのPLEXというプログラム言語が使われている環境で（EricssonのAXE交換機用に）開発された。PLEXはマルチプルステートマシン（ブロックと呼ばれる）がメッセージ（シグナルと呼ばれる）を互いに交換し合うことによって、いくつかのシステムレベルの起動、再起動、およびメッセージクラスなどのタスクを実行する構造になっている。各ブロックは内部に状態を持っており、シグナルごとにそれを処理するルーチンが定義されているという具合である。ただしブロックがサブルーチンに対してサポートしている抽象化（訳者注：定義出来る機能の実装）はごく限られたものであった。（私＝FrazerはPLEXについて、それがどのように進化したかをもっと詳しく聞きたいと思っている。）このことは、AXEのプロセッサのデザインにそのまま反映されている。AXEは常識とは異なり、シグナルバッファがソフトウェアではなくハードウェアとしてシリコン上に実装されているのである。このような「ハードコーディング」がされているため、当初NDBは最長で25 x 32ビット長のシグナルしかサポート出来なかった。PLEXの仮想実行環境（VM）がUNIX上のプロセスとして実行された。ブロック上で実行されるPLEXのコードはVM用のコードに逐次解釈（interpret）され、シグナルはVMによってブロックへ転送された。これにより、PLEXベースのシステムのUNIX上での開発が始まったのである。その結果、PLEXベースのシステムが容易にUNIXソフトウェアと通信することが可能になった。それぞれのVMのインスタンスはシングルスレッドのプロセスで、送られて来たシグナルをブロック内に定義されている処理シグナル処理ルーチンへ振り分けるという仕組みになっていた。&nbsp;PLEXからC++への変換システムが設計された。ブロックが巨大なC++のクラスに変換され、シグナル処理用のメンバ関数とブロックごとのグローバルな状態がメンバ変数が定義された。PLEX環境における限られた命名規則と抽象化された機能が、C++クラス内にC言語スタイルの機能として実装された。VM環境は元々のPLEX/AXE環境から分岐し、NDBのベースとして独自の進化路線をとった。その結果、NDBはOSの各種サービス（通信、ディスクI/Oなど）へアクセスすることが可能となった。PLEXコードの逐次解釈（インタプリタ）機能は取り除かれ、PLEXのコードはすべてC++のコードに書き直された。VMインスタンスは各種通信経路を用いて相互に通信出来るようになり、分散システムを形成するようになった。このぐらいの時期にNDBとその開発チームがEricssonを去ることになった。（訳者注：Ericossonはベンチャー企業であるAlzato社を作ってNDBを独立した製品にし、さらにその後Alzato社がMySQL ABに買収されることになる。）ブロックの共通した機能がベースまたはユーティリティクラスへと抽象化された。これにより、ハードウェアやシステムに起因した制限が緩和され、抽象化の度合いが上昇することになる。現在では、ブロックはPLEXの（負の）遺産に悩まされることなく、C++の抽象化機能を活用して実装されている。元々存在していたブロックは全て作り直された。マルチスレッドのNDBデーモン（ndbmtd）が開発された。ブロックの各インスタンスが異なるスレッドで実行されるようになった。といってもこれは急激な変更ではなく、PLEX実行環境で元々採用されていた「1つのブロックを1つのプロセッサとして実装する」という設計への回帰である。（訳者注：ndbmtd内にはおよそ20種のブロックが存在し、それらが予め定められた数のスレッドで実行されている。）というわけで、現在NDBはシグナルモデルを利用してブロックがお互いに通信するような仕組みになっているのである。シグナルはもはや25ワード長に制限されていない。シングルスレッド版のNDBデーモン（ndbd）もあり、それは全てのブロックが一つのスレッドを共有しているが、VM同士の通信やディスクI/Oなどのための専用のスレッドが実装されている。（訳者注：I/Oなどのスレッドが別途あるという意味では厳密にシングルスレッドプロセスであるわけではない。）いずれの場合にしても、ひとつひとつのブロックはシングルスレッドのままであり、スレッドは複数のブロックによって共有されている。（訳者注：スレッド対ブロックは1対Nの関係である。）このようなブロック-シグナルモデルは、ErlangやHoareのCSPを思い起こさせる。つまり、同時実行性がシーケンシャルなプロセスがお互いに明示的なメッセージを交換し合うことによってモデル化されているようなシステムである。これは共有メモリモデル、つまりメモリへのアクセス整合性をロックやメモリ保護機能、アトミック命令などで保証するというモデルとは対照的である。もしくは、ブロック-シグナルモデルはMPIやActiveオブジェクト/Actorモデルに似ているとも言える。明確なメッセージ交換によって同期または通信を行うのはコストが掛かる。つまり、実行時により多くのメモリコピーが発生するということである。プログラム設計時には、潜在的な同時実行制御はメッセージ交換および状態遷移というモデルで明示的に表現されていなければならず、マルチスレッドセーフな共有メモリとロックを用いたモデルよりも多くのソースコードを改変または記述する必要が生じてしまう。しかしながら、これらのデメリットはコードの見通しがよくなるという利点によって十分に報われると思う。ステートマシン間の同期はとても見通しが良く、同期のためのコストを容易に理解することができる。明確なメッセージ交換をスレッドまたはプロセスの通信手段として利用すれば、ごく僅かな部分だけをマルチスレッドの（スレッドセーフな）カーネルとして実装するだけで済み、そのカーネルは正しく最適化されているということが保証されるであろう。そして多くのコードがシングルスレッドのスタイルで（マルチスレッドを意識する必要なく）記述することが出来る。マルチスレッドのためにライブラリを作り直す必要もない。（訳者注：ブロックがシグナルに応答する各種ロジックは全てシングルスレッドで実行されるからである。）その結果、プロセッサとシステムアーキテクチャに依存したコードおよびトレードオフが最小化されるのである。内部的には、NDBのVMはブロック同士の通信は非同期のものだけをサポートしているが、そのような非同期のメッセージ交換を用いることは多くのメリットがある。第一に、メッセージを送信したスレッドは、そのメッセージの処理が送信先のブロックにおいて完了するのを待たなくても良いので、他に多くの作業ができる。同じスレッドを共有している他のブロックにメッセージを送った場合は自らが送信したメッセージを即座に処理するということもあるだろう。これにより、CPU内のデータおよび命令キャッシュが最大限に活用され、コンテキストスイッチが減少し、デッドロックの可能性が低減することになる。ブロッキングI/O（ネットワークおよびディスク）は専用のスレッドプールへ処理が割り振られるため、シグナルを処理するスレッドがブロックすることは絶対にない。（ただし保留中のシグナルがなくなった場合にはスレッドが停止する）システムの応答性は、優先付けされたジョブキューを使い、どのジョブを先に処理するべきかということを決定して各種ジョブに掛かる時間を最小化することによって実現している。形式的な見方をすれば、スレッド同士が相互作用する必要のある状況は、スレッドが同時に実行されている状態とほぼ同等まで減少することが可能となる。つまり、スレッド同士の同期はシグナル処理の境界だけで必要なのである。このように、前述のような制限は、（シングルスレッド処理に起因する）システムの正しさやタイミング特性（応答性の向上）を容易にするのである。しかしながら、このような非同期で、イベントドリブンなスタイルの開発はとても難しいというのもまた事実である。全てのブロッキング操作（ディスクアクセス、ブロックされる通信、他のスレッドやプロセスへの要求など）をリクエストとレスポンスのペアとして実装しなければならないからである。また、広く一般的に使われる数多くのデータ構造やアルゴリズムは単一の（その処理を開始したスレッドの）スタックを（データを格納したり関数の引数を渡したりするために）利用するという前提に立っているが、このようなメッセージ交換によりシステムを実装するとそれらのデータ構造やアルゴリズムを活用することが出来ない。また、非同期のスタイルで開発されたソフトウェアはこまごまとした詳細が分からず、つかみ所がないため新しい機能を設計するのは時として難しい場合がある。その上、抽象化の深いレイヤーでのコードであっても、並列化が可能なものであれば常に最もレベルの浅い呼び出し元（コールポイント）までリターンしなければならないため、非同期のシステムは構造が平坦になってしまいがちである。（訳者注：つまりスタックが深くなることはない。）このような構造をとることによる副作用は、エラー処理のコードがエラーの発生源になっているブロックに固有のものではないという点である。しかし、まあそれもこのような非同期（の並列）システムをいじる楽しみの一つだと言える。C++環境はそのような抽象化された要素を設計するために、非常に幅広いツールを提供してくれる。そして、個々の改善が将来の作業を易しくしてくれるのである。以上が翻訳である。このように、MySQL Clusterはシグナル（メッセージ）交換を基礎として実装されており、通常の共有メモリ方式の並列ソフトウェアとは大きく構造が異なっている。その結果として、MySQL Clusterは高い同時実行性と素早い応答性を実現しているのである。排他ロックを使わずに同時実行制御をする構造はロックがボトルネックにならないためCPU数に応じてスケールし易く、CPUコア数が増加すると予想されるこれからの時代にはとても有利に働く可能性があり、これからMySQL Clusterがどこまで性能を向上させられるかとても楽しみである。しかし、はっきり言ってMySQL Clusterの構造を理解するのは少し敷居が高い。動作不良を起こした場合に原因を特定するためには、各ブロックのソースコードを行ったり来たりしなければならないので必然的に解析には時間が掛かってしまうし、各ブロックの状態は刻々と変化するので問題の発生条件の特定も難しい。なので慣れるまでは結構大変かも知れない。その内部構造を詳しく知るようになればFrazer氏が言うようにそれもまた魅力になるかも知れないが、構造が分からないうちは単なる苦痛である可能性が高い。というわけで、次回はNDBデーモンの各カーネルブロックについて紹介しようと思う。 Frazer Clement氏がその歴史についてとても興味深いエントリを自身のブログで綴っているのだが、いかんせん英語の長文で日本人には辛いかも知れないので今日はその日本語訳を皆さんにも紹介しようと思う。進化の歴史とその結果生じた構造を知ることにより、MySQL Clusterの仕組みに興味を持って頂けると幸いである。（わかり辛いところにはところどころ訳者による注釈を入れてある。ただし翻訳は結構大ざっぱなので、英語が達者であれば細かいニュアンスなどはオリジナルのエントリを参照して頂きたい。なお、日本語訳をすることに関してはFrazer氏の了解を得ているのであしからず。）
NDB（MySQL Clusterの略称。元々はNetwork DBという名称であった。）の開発の正確な歴史について、きっと他の誰かのほうが上手く解説できると思うのだが、限られて曖昧かも知れないが私の見解を以下に述べようと思う。
  • NDBは元々、EricssonのPLEXというプログラム言語が使われている環境で（EricssonのAXE交換機用に）開発された。PLEXはマルチプルステートマシン（ブロックと呼ばれる）がメッセージ（シグナルと呼ばれる）を互いに交換し合うことによって、いくつかのシステムレベルの起動、再起動、およびメッセージクラスなどのタスクを実行する構造になっている。各ブロックは内部に状態を持っており、シグナルごとにそれを処理するルーチンが定義されているという具合である。ただしブロックがサブルーチンに対してサポートしている抽象化（訳者注：定義出来る機能の実装）はごく限られたものであった。（私＝FrazerはPLEXについて、それがどのように進化したかをもっと詳しく聞きたいと思っている。）このことは、AXEのプロセッサのデザインにそのまま反映されている。AXEは常識とは異なり、シグナルバッファがソフトウェアではなくハードウェアとしてシリコン上に実装されているのである。このような「ハードコーディング」がされているため、当初NDBは最長で25 x 32ビット長のシグナルしかサポート出来なかった。
  • PLEXの仮想実行環境（VM）がUNIX上のプロセスとして実行された。ブロック上で実行されるPLEXのコードはVM用のコードに逐次解釈（interpret）され、シグナルはVMによってブロックへ転送された。これにより、PLEXベースのシステムのUNIX上での開発が始まったのである。その結果、PLEXベースのシステムが容易にUNIXソフトウェアと通信することが可能になった。それぞれのVMのインスタンスはシングルスレッドのプロセスで、送られて来たシグナルをブロック内に定義されている処理シグナル処理ルーチンへ振り分けるという仕組みになっていた。 
  • PLEXからC++への変換システムが設計された。ブロックが巨大なC++のクラスに変換され、シグナル処理用のメンバ関数とブロックごとのグローバルな状態がメンバ変数が定義された。PLEX環境における限られた命名規則と抽象化された機能が、C++クラス内にC言語スタイルの機能として実装された。
  • VM環境は元々のPLEX/AXE環境から分岐し、NDBのベースとして独自の進化路線をとった。その結果、NDBはOSの各種サービス（通信、ディスクI/Oなど）へアクセスすることが可能となった。PLEXコードの逐次解釈（インタプリタ）機能は取り除かれ、PLEXのコードはすべてC++のコードに書き直された。VMインスタンスは各種通信経路を用いて相互に通信出来るようになり、分散システムを形成するようになった。
  • このぐらいの時期にNDBとその開発チームがEricssonを去ることになった。（訳者注：Ericossonはベンチャー企業であるAlzato社を作ってNDBを独立した製品にし、さらにその後Alzato社がMySQL ABに買収されることになる。）
  • ブロックの共通した機能がベースまたはユーティリティクラスへと抽象化された。これにより、ハードウェアやシステムに起因した制限が緩和され、抽象化の度合いが上昇することになる。現在では、ブロックはPLEXの（負の）遺産に悩まされることなく、C++の抽象化機能を活用して実装されている。元々存在していたブロックは全て作り直された。
  • マルチスレッドのNDBデーモン（ndbmtd）が開発された。ブロックの各インスタンスが異なるスレッドで実行されるようになった。といってもこれは急激な変更ではなく、PLEX実行環境で元々採用されていた「1つのブロックを1つのプロセッサとして実装する」という設計への回帰である。（訳者注：ndbmtd内にはおよそ20種のブロックが存在し、それらが予め定められた数のスレッドで実行されている。）
というわけで、現在NDBはシグナルモデルを利用してブロックがお互いに通信するような仕組みになっているのである。シグナルはもはや25ワード長に制限されていない。シングルスレッド版のNDBデーモン（ndbd）もあり、それは全てのブロックが一つのスレッドを共有しているが、VM同士の通信やディスクI/Oなどのための専用のスレッドが実装されている。（訳者注：I/Oなどのスレッドが別途あるという意味では厳密にシングルスレッドプロセスであるわけではない。）いずれの場合にしても、ひとつひとつのブロックはシングルスレッドのままであり、スレッドは複数のブロックによって共有されている。（訳者注：スレッド対ブロックは1対Nの関係である。）

このようなブロック-シグナルモデルは、ErlangやHoareのCSPを思い起こさせる。つまり、同時実行性がシーケンシャルなプロセスがお互いに明示的なメッセージを交換し合うことによってモデル化されているようなシステムである。これは共有メモリモデル、つまりメモリへのアクセス整合性をロックやメモリ保護機能、アトミック命令などで保証するというモデルとは対照的である。もしくは、ブロック-シグナルモデルはMPIやActiveオブジェクト/Actorモデルに似ているとも言える。

明確なメッセージ交換によって同期または通信を行うのはコストが掛かる。つまり、実行時により多くのメモリコピーが発生するということである。プログラム設計時には、潜在的な同時実行制御はメッセージ交換および状態遷移というモデルで明示的に表現されていなければならず、マルチスレッドセーフな共有メモリとロックを用いたモデルよりも多くのソースコードを改変または記述する必要が生じてしまう。

しかしながら、これらのデメリットはコードの見通しがよくなるという利点によって十分に報われると思う。ステートマシン間の同期はとても見通しが良く、同期のためのコストを容易に理解することができる。明確なメッセージ交換をスレッドまたはプロセスの通信手段として利用すれば、ごく僅かな部分だけをマルチスレッドの（スレッドセーフな）カーネルとして実装するだけで済み、そのカーネルは正しく最適化されているということが保証されるであろう。そして多くのコードがシングルスレッドのスタイルで（マルチスレッドを意識する必要なく）記述することが出来る。マルチスレッドのためにライブラリを作り直す必要もない。（訳者注：ブロックがシグナルに応答する各種ロジックは全てシングルスレッドで実行されるからである。）その結果、プロセッサとシステムアーキテクチャに依存したコードおよびトレードオフが最小化されるのである。

内部的には、NDBのVMはブロック同士の通信は非同期のものだけをサポートしているが、そのような非同期のメッセージ交換を用いることは多くのメリットがある。第一に、メッセージを送信したスレッドは、そのメッセージの処理が送信先のブロックにおいて完了するのを待たなくても良いので、他に多くの作業ができる。同じスレッドを共有している他のブロックにメッセージを送った場合は自らが送信したメッセージを即座に処理するということもあるだろう。これにより、CPU内のデータおよび命令キャッシュが最大限に活用され、コンテキストスイッチが減少し、デッドロックの可能性が低減することになる。ブロッキングI/O（ネットワークおよびディスク）は専用のスレッドプールへ処理が割り振られるため、シグナルを処理するスレッドがブロックすることは絶対にない。（ただし保留中のシグナルがなくなった場合にはスレッドが停止する）システムの応答性は、優先付けされたジョブキューを使い、どのジョブを先に処理するべきかということを決定して各種ジョブに掛かる時間を最小化することによって実現している。形式的な見方をすれば、スレッド同士が相互作用する必要のある状況は、スレッドが同時に実行されている状態とほぼ同等まで減少することが可能となる。つまり、スレッド同士の同期はシグナル処理の境界だけで必要なのである。このように、前述のような制限は、（シングルスレッド処理に起因する）システムの正しさやタイミング特性（応答性の向上）を容易にするのである。

しかしながら、このような非同期で、イベントドリブンなスタイルの開発はとても難しいというのもまた事実である。全てのブロッキング操作（ディスクアクセス、ブロックされる通信、他のスレッドやプロセスへの要求など）をリクエストとレスポンスのペアとして実装しなければならないからである。また、広く一般的に使われる数多くのデータ構造やアルゴリズムは単一の（その処理を開始したスレッドの）スタックを（データを格納したり関数の引数を渡したりするために）利用するという前提に立っているが、このようなメッセージ交換によりシステムを実装するとそれらのデータ構造やアルゴリズムを活用することが出来ない。また、非同期のスタイルで開発されたソフトウェアはこまごまとした詳細が分からず、つかみ所がないため新しい機能を設計するのは時として難しい場合がある。その上、抽象化の深いレイヤーでのコードであっても、並列化が可能なものであれば常に最もレベルの浅い呼び出し元（コールポイント）までリターンしなければならないため、非同期のシステムは構造が平坦になってしまいがちである。（訳者注：つまりスタックが深くなることはない。）このような構造をとることによる副作用は、エラー処理のコードがエラーの発生源になっているブロックに固有のものではないという点である。しかし、まあそれもこのような非同期（の並列）システムをいじる楽しみの一つだと言える。C++環境はそのような抽象化された要素を設計するために、非常に幅広いツールを提供してくれる。そして、個々の改善が将来の作業を易しくしてくれるのである。
以上が翻訳である。このように、MySQL Clusterはシグナル（メッセージ）交換を基礎として実装されており、通常の共有メモリ方式の並列ソフトウェアとは大きく構造が異なっている。その結果として、MySQL Clusterは高い同時実行性と素早い応答性を実現しているのである。排他ロックを使わずに同時実行制御をする構造はロックがボトルネックにならないためCPU数に応じてスケールし易く、CPUコア数が増加すると予想されるこれからの時代にはとても有利に働く可能性があり、これからMySQL Clusterがどこまで性能を向上させられるかとても楽しみである。

しかし、はっきり言ってMySQL Clusterの構造を理解するのは少し敷居が高い。動作不良を起こした場合に原因を特定するためには、各ブロックのソースコードを行ったり来たりしなければならないので必然的に解析には時間が掛かってしまうし、各ブロックの状態は刻々と変化するので問題の発生条件の特定も難しい。なので慣れるまでは結構大変かも知れない。その内部構造を詳しく知るようになればFrazer氏が言うようにそれもまた魅力になるかも知れないが、構造が分からないうちは単なる苦痛である可能性が高い。というわけで、次回はNDBデーモンの各カーネルブロックについて紹介しようと思う。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 20 Oct 2009 22:57:00 +0000 Mikiya Okuno mysql cluster mysql いよいよ明日! MySQL Enterprise Enterprise Fall 2009 リリースライブWebセミナー開催 http://blogs.mysql.com/teamapac/?p=251 http://blogs.mysql.com/teamapac/2009/10/19/%E3%81%84%E3%82%88%E3%81%84%E3%82%88%E6%98%8E%E6%97%A5-mysql-enterprise-enterprise-fall-2009-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%96web%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC/ MySQL Enterprise に新機能を追加してさらにパワーアップした MySQL Enterprise Fall 2009 がリリースされました！この新しいバージョンでは、MySQLパフォーマンスのボトルネックを、これまで以上に素早く、そして簡単に発見できるようになります。 サン・マイクロシステムズ株式会社では、この新たに追加された機能を皆様にもっと知っていただけるよう、ライブ Web セミナーを開催します。 この Web セミナーでは、MySQL Enterprise Fall 2009 リリースで強化された機能を中心に解説し、また、弊社エンジニアが皆様のご質問に日本語でお答えします。 是非お気軽にご参加ください！ Webセミナー概要 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【タイトル】    　　MySQL Enterprise Fall 2009 リリースご紹介 【開催日時】    　2009年10月20日 (火) 14:00 ~ 15:00 【講師】　　　　　　サン･マイクロシステムズ株式会社 MySQL シニアエバンジェリスト 梶山 隆輔 【登録 URL】 http://www-jp.mysql.com/news-and-events/web-seminars/display-437.html このリリースでは、MySQL Monitor に含まれる Query Analyzer のグラフィックス機能が強化され、パフォーマンスの最適化がより素早くできるようになっています。新しく追加された相関関係グラフ機能は、重要リソースを過剰に消費しているスパイクを引き起こしているクエリをビジュアル的に解析・突き止めることができるため、パフォーマンスの低下を回避することができます。 この Web セミナーでは、MySQL Enterprise サブスクリプションに新たに追加された新機能を中心にご紹介いたします。 なお、お使いのブラウザおよび OS が Webex に対応しているかは、下記URLよりご確認いただけます。 http://support.webex.com/support/system-requirements.html 三橋 MySQL Enterprise に新機能を追加してさらにパワーアップした MySQL Enterprise Fall 2009 がリリースされました！この新しいバージョンでは、MySQLパフォーマンスのボトルネックを、これまで以上に素早く、そして簡単に発見できるようになります。

サン・マイクロシステムズ株式会社では、この新たに追加された機能を皆様にもっと知っていただけるよう、ライブ Web セミナーを開催します。
この Web セミナーでは、MySQL Enterprise Fall 2009 リリースで強化された機能を中心に解説し、また、弊社エンジニアが皆様のご質問に日本語でお答えします。

是非お気軽にご参加ください！

Webセミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【タイトル】    　　MySQL Enterprise Fall 2009 リリースご紹介
【開催日時】    　2009年10月20日 (火) 14:00 ~ 15:00
【講師】　　　　　　サン･マイクロシステムズ株式会社
MySQL シニアエバンジェリスト
梶山 隆輔
【登録 URL】
http://www-jp.mysql.com/news-and-events/web-seminars/display-437.html

このリリースでは、MySQL Monitor に含まれる Query Analyzer のグラフィックス機能が強化され、パフォーマンスの最適化がより素早くできるようになっています。新しく追加された相関関係グラフ機能は、重要リソースを過剰に消費しているスパイクを引き起こしているクエリをビジュアル的に解析・突き止めることができるため、パフォーマンスの低下を回避することができます。
この Web セミナーでは、MySQL Enterprise サブスクリプションに新たに追加された新機能を中心にご紹介いたします。

なお、お使いのブラウザおよび OS が Webex に対応しているかは、下記URLよりご確認いただけます。
http://support.webex.com/support/system-requirements.html
三橋


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 19 Oct 2009 05:03:20 +0000 TeamApac 日本語エントリー セミナーレポート: マルチコアシステムを最大限に生かすMySQLのスケーラビリティと高可用性実現セミナー http://blogs.mysql.com/teamapac/?p=244 http://blogs.mysql.com/teamapac/2009/10/19/%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88-%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B3%E3%82%A2%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E6%9C%80%E5%A4%A7%E9%99%90%E3%81%AB/ 去る9月9日、楽天証券の木川英一様と住商情報システムの廣濱顕司様をゲストスピーカにお迎えし、東京ミッドタウンにて「マルチコアシステムを最大限に生かすMySQLのスケーラビリティと高可用性実現セミナー　　～機能向上したMySQL Cluster 7.0最新版の詳細と高可用性システムのユーザ導入事例＆実構築例を一挙ご紹介～」セミナーを開催しました。 今日はこのセミナーレポートをお送りします。 セミナーは合計4セッションで、テクノロジーセッションとビジネスセッションの2部構成でした。今回、国内ではMySQL Clusterにフォーカスした初のセミナーということで、豪華ゲストスピーカをお迎えしました。 プログラムは、最初、サン･マイクロシステムズ MySQL ビジネス統括本部長の矢崎博雅による挨拶から始まり、第一部のメインセッションであるMySQL Cluster 7.0 紹介セッション、そしてMySQL Cluster の性能を最大限に引き出すハードウェアとして、サンが誇るx86システムのご紹介セッション。その後、休憩を挟み、いよいよ第2部の豪華ゲストスピーカによる事例紹介セッションへと続きます。はじめてのMySQL Clusterセミナーで、楽天証券さまから事例紹介セッションをいただけることは、弊社として光栄なことでした。また、最後を飾ったのは、MySQL Cluster においては実績・技術力で国内トップクラスの住商情報システム様です。 それでは、個々のセッションについてご報告しましょう。 ご挨拶：サン･マイクロシステムズMySQLビジネス統括本部長　矢崎博雅 2009年8月19日付けの日経コンピュータの顧客満足度調査にて、MySQLはオープン系RDBソフト分野でNo1に選ばれたこと、さらに、現在、ダウンロード数だけでなく、企業顧客においても多数の実績があることをご紹介しました。 『MySQL Cluster 7.0 ご紹介』 サン・マイクロシステムズ株式会社　MySQLシニアエバンジェリスト 梶山 隆輔 このセッションでは、MySQL Cluster最新版の 7.0 の詳細ご紹介です。MySQL Clusterアーキテクチャの基礎情報をはじめ、7.0 で追加された新機能・改善点(データノードのマルチスレッド化や、システム動作中のノード追加、Windowsプラットフォーム対応など)について解説しました。用途別の向き不向きを含め、興味はあるがまだ使ったことがないという方にも、MySQL Cluster がどういったものかよくおわかりいただけたのではないでしょうか? 『MySQL Cluster 7.0に最適なSunのx86プラットフォーム 』 サン・マイクロシステムズ株式会社 プロダクトマネージャー 的場謙一郎 どのシステムにおいても、ハードウェアの選定は大事な検討項目の一つです。弊社がご提供するx86サーバなら、その設計により、省エネ、省スペースに大きく貢献できます。CPU、メモリ、HDDだけでなく、冷却ファンに至るまで、サーバ内部のエネルギーを効率化しています。実際にMySQL Cluster と Sun の x86サーバを組み合わせれば、HAソリューションを低コストで実現することができることをご紹介しました。 『MarketSpeedにおけるMySQL-Cluster適用事例紹介』 楽天証券株式会社 マネージャ 木川　英一 氏 誰もがその名前を知っている、日本最大級のインターネット・ショッピングモールを運営する楽天グループ。その楽天グループのインターネット証券でMySQL Clusterが使用されています! セッションでは、最初、楽天証券についてご紹介いただき、そして「MarketSpeed」の開発背景、MarketSpeedシステム全体、APサーバ内、MarketSpeed-FXシステムの構成のほか、MySQL Clusterの導入理由、実際選定の際の懸念事項、利点などをご説明いただきました。さらに、開発・テスト稼働時でどのような問題が発生し、それについてどう対処したかをご紹介いただきました。本番環境稼働から現在まで、アラートなどは発生しておらず、非常に安定しているとのことです。 『MySQL Cluster構築のポイント』 住商情報システム株式会社　マネージャ 廣濱 顕司 氏 最後のセッションは住商情報システムの廣濱さまです。住商情報システム社とは、MySQL ABだった2003年からパートナーシップ関係を築いていて、MySQL Cluster における実績・技術力は国内ではトップクラスです。MySQL Clusterシステムに関する設計・構築・運用支援サービスを提供し、楽天証券様のMySQL Cluster導入もご担当されました。 住商情報システムは、IPAプロジェクトでのベンチマーク結果など、過去に豊富な実績・経験を持っています。その結果、お客様のヒアリングを基に、最適なノード構成を提案することが可能とのことで、楽天証券様での導入時における構築ポイントをいくつも披露していただきました。 セミナー最後には、豪華プレゼント抽選会を行いました。1等は、先日発売されたばかりのPlaystation 3です。そのほか、BOSE社の高品質PC用スピーカやモバイルヘッドセットなどをご用意しました。当選者の方、おめでとうございます！ 実は、先着50名様にMySQL イルカのぬいぐるみのプレゼントもありました。イルカの名前はSakilaといいます。 当日はたくさんの方にお越しいただきました。どうもありがとうございました！！ また、このセミナーの最初の梶山のセッションについては、近々、オンライン公開する予定です。どうぞお楽しみ！ 三橋 去る9月9日、楽天証券の木川英一様と住商情報システムの廣濱顕司様をゲストスピーカにお迎えし、東京ミッドタウンにて「マルチコアシステムを最大限に生かすMySQLのスケーラビリティと高可用性実現セミナー　　～機能向上したMySQL Cluster 7.0最新版の詳細と高可用性システムのユーザ導入事例＆実構築例を一挙ご紹介～」セミナーを開催しました。

今日はこのセミナーレポートをお送りします。

セミナーは合計4セッションで、テクノロジーセッションとビジネスセッションの2部構成でした。今回、国内ではMySQL Clusterにフォーカスした初のセミナーということで、豪華ゲストスピーカをお迎えしました。

プログラムは、最初、サン･マイクロシステムズ MySQL ビジネス統括本部長の矢崎博雅による挨拶から始まり、第一部のメインセッションであるMySQL Cluster 7.0 紹介セッション、そしてMySQL Cluster の性能を最大限に引き出すハードウェアとして、サンが誇るx86システムのご紹介セッション。その後、休憩を挟み、いよいよ第2部の豪華ゲストスピーカによる事例紹介セッションへと続きます。はじめてのMySQL Clusterセミナーで、楽天証券さまから事例紹介セッションをいただけることは、弊社として光栄なことでした。また、最後を飾ったのは、MySQL Cluster においては実績・技術力で国内トップクラスの住商情報システム様です。

それでは、個々のセッションについてご報告しましょう。

ご挨拶：サン･マイクロシステムズMySQLビジネス統括本部長　矢崎博雅
2009年8月19日付けの日経コンピュータの顧客満足度調査にて、MySQLはオープン系RDBソフト分野でNo1に選ばれたこと、さらに、現在、ダウンロード数だけでなく、企業顧客においても多数の実績があることをご紹介しました。

『MySQL Cluster 7.0 ご紹介』
サン・マイクロシステムズ株式会社　MySQLシニアエバンジェリスト
梶山 隆輔

このセッションでは、MySQL Cluster最新版の 7.0 の詳細ご紹介です。MySQL Clusterアーキテクチャの基礎情報をはじめ、7.0 で追加された新機能・改善点(データノードのマルチスレッド化や、システム動作中のノード追加、Windowsプラットフォーム対応など)について解説しました。用途別の向き不向きを含め、興味はあるがまだ使ったことがないという方にも、MySQL Cluster がどういったものかよくおわかりいただけたのではないでしょうか?

『MySQL Cluster 7.0に最適なSunのx86プラットフォーム 』
サン・マイクロシステムズ株式会社 プロダクトマネージャー
的場謙一郎

どのシステムにおいても、ハードウェアの選定は大事な検討項目の一つです。弊社がご提供するx86サーバなら、その設計により、省エネ、省スペースに大きく貢献できます。CPU、メモリ、HDDだけでなく、冷却ファンに至るまで、サーバ内部のエネルギーを効率化しています。実際にMySQL Cluster と Sun の x86サーバを組み合わせれば、HAソリューションを低コストで実現することができることをご紹介しました。

『MarketSpeedにおけるMySQL-Cluster適用事例紹介』
楽天証券株式会社 マネージャ
木川　英一 氏

誰もがその名前を知っている、日本最大級のインターネット・ショッピングモールを運営する楽天グループ。その楽天グループのインターネット証券でMySQL Clusterが使用されています!
セッションでは、最初、楽天証券についてご紹介いただき、そして「MarketSpeed」の開発背景、MarketSpeedシステム全体、APサーバ内、MarketSpeed-FXシステムの構成のほか、MySQL Clusterの導入理由、実際選定の際の懸念事項、利点などをご説明いただきました。さらに、開発・テスト稼働時でどのような問題が発生し、それについてどう対処したかをご紹介いただきました。本番環境稼働から現在まで、アラートなどは発生しておらず、非常に安定しているとのことです。

『MySQL Cluster構築のポイント』
住商情報システム株式会社　マネージャ
廣濱 顕司 氏

最後のセッションは住商情報システムの廣濱さまです。住商情報システム社とは、MySQL ABだった2003年からパートナーシップ関係を築いていて、MySQL Cluster における実績・技術力は国内ではトップクラスです。MySQL Clusterシステムに関する設計・構築・運用支援サービスを提供し、楽天証券様のMySQL Cluster導入もご担当されました。
住商情報システムは、IPAプロジェクトでのベンチマーク結果など、過去に豊富な実績・経験を持っています。その結果、お客様のヒアリングを基に、最適なノード構成を提案することが可能とのことで、楽天証券様での導入時における構築ポイントをいくつも披露していただきました。

セミナー最後には、豪華プレゼント抽選会を行いました。1等は、先日発売されたばかりのPlaystation 3です。そのほか、BOSE社の高品質PC用スピーカやモバイルヘッドセットなどをご用意しました。当選者の方、おめでとうございます！
実は、先着50名様にMySQL イルカのぬいぐるみのプレゼントもありました。イルカの名前はSakilaといいます。

当日はたくさんの方にお越しいただきました。どうもありがとうございました！！

また、このセミナーの最初の梶山のセッションについては、近々、オンライン公開する予定です。どうぞお楽しみ！

三橋


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 19 Oct 2009 04:56:05 +0000 TeamApac 1 日本語エントリー [MySQL][Spider]Spider-2.6リリース tag:blogger.com,1999:blog-1243249875644802246.post-4529468655125795383 http://wild-growth-ja.blogspot.com/2009/10/mysqlspiderspider-26.html Spiderストレージエンジンのバージョン 2.6(beta)をリリースしました。Spiderストレージエンジンは、database sharding用のストレージエンジンです。http://spiderformysql.com/今回の主な変更は以下です。・サーバパラメータに「spider_remote_access_charset」「spider_remote_autocommit」「spider_remote_sql_log_off」「spider_remote_trx_isolation」を追加しました。　Spiderストレージエンジンは、リモートサーバへの接続時これらの情報を合わせて設定するのですが、これらの情報があらかじめわかっていて設定する必要がない場合があります。そのような場合に、これらのパラメータを設定するとリモートサーバへの接続時にこれらの情報を設定する必要がなくなり、接続処理を高速化することができます。それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。Giuseppeさん、バグレポートありがとうございます。 Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・サーバパラメータに「spider_remote_access_charset」「spider_remote_autocommit」「spider_remote_sql_log_off」「spider_remote_trx_isolation」を追加しました。
　Spiderストレージエンジンは、リモートサーバへの接続時これらの情報を合わせて設定するのですが、これらの情報があらかじめわかっていて設定する必要がない場合があります。そのような場合に、これらのパラメータを設定するとリモートサーバへの接続時にこれらの情報を設定する必要がなくなり、接続処理を高速化することができます。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。
Giuseppeさん、バグレポートありがとうございます。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 18 Oct 2009 16:09:00 +0000 斯波健徳 MySQL Spider MySQL 5.4.3-betaリリース http://d.hatena.ne.jp/sh2/20091014 http://d.hatena.ne.jp/sh2/20091014 出ました。今回は仕様変更が3件と、バグ修正が48件あります。 このバージョンから、InnoDBのパラメータについていくつかデフォルト値が変更されました。デフォルト値をMySQL 5.1、MySQL 5.1のInnoDB向けサンプルファイル(my-innodb-heavy-4G.cnf)、MySQL 5.4.0と比較してみると以下のようになります。 パラメータ5.15.1(heavy)5.4.05.4.3 innodb_autoextend_increment8MB8MB64MB8MB innodb_buffer_pool_size8MB2,048MB1,024MB128MB innodb_log_buffer_size1MB8MB16MB8MB innodb_log_file_size5MB256MB128MB5MB innodb_log_files_in_group2332 innodb_read_io_threads--84 innodb_write_io_threads--84 MySQL 5.4.3では全体的に控えめな設定に戻されたようです。私はMySQL 5.4.0のアグレッシブなデフォルト値が好きなのですが(笑)、デフォルト設定でいきなりメモリを1GBも取られたり、InnoDBのログファイルでディスクを128MB×3も確保されてしまうのはさすがに問題視されたのかもしれませんね。そもそもMyISAMしか使わない場合は完全に無駄ですし。 ちなみにOracle Databaseと比較すると、Database Configuration Assistantで何もカスタマイズせずにデータベースを作成した場合、innodb_buffer_pool_sizeに相当するSGA_TARGETが物理メモリの30%、innodb_log_file_sizeに相当するREDOログファイルが50MB×3となります。このことからもMySQL 5.4.0のアグレッシブさが分かると思います。 MySQL 5.1、MySQL 5.1のInnoDB向けサンプルファイル(my-innodb-heavy-4G.cnf)、MySQL 5.4.0と比較してみると以下のようになります。 パラメータ5.15.1(heavy)5.4.05.4.3 innodb_autoextend_increment8MB8MB64MB8MB innodb_buffer_pool_size8MB2,048MB1,024MB128MB innodb_log_buffer_size1MB8MB16MB8MB innodb_log_file_size5MB256MB128MB5MB innodb_log_files_in_group2332 innodb_read_io_threads--84 innodb_write_io_threads--84 MySQL 5.4.3では全体的に控えめな設定に戻されたようです。私はMySQL 5.4.0のアグレッシブなデフォルト値が好きなのですが(笑)、デフォルト設定でいきなりメモリを1GBも取られたり、InnoDBのログファイルでディスクを128MB×3も確保されてしまうのはさすがに問題視されたのかもしれませんね。そもそもMyISAMしか使わない場合は完全に無駄ですし。 ちなみにOracle Databaseと比較すると、Database Configuration Assistantで何もカスタマイズせずにデータベースを作成した場合、innodb_buffer_pool_sizeに相当するSGA_TARGETが物理メモリの30%、innodb_log_file_sizeに相当するREDOログファイルが50MB×3となります。このことからもMySQL 5.4.0のアグレッシブさが分かると思います。
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Wed, 14 Oct 2009 00:00:00 +0000 Sadao Hiratsuka [MySQL][VP]Vartical Partitioning-0.6リリース tag:blogger.com,1999:blog-1243249875644802246.post-6069324255942936323 http://wild-growth-ja.blogspot.com/2009/10/mysqlvpvartical-partitioning-06.html Vertical Partitioningストレージエンジンのバージョン 0.6(alpha)をリリースしました。Vertical Partitioningストレージエンジンは、テーブルのVertical Partitioning用のストレージエンジンです。http://launchpad.net/vpformysql今回の主な変更は以下です。・UDF「vp_copy_tables」を追加しました。　Vertical Partitioningテーブルに新しいテーブルを追加した際に、そのテーブルに対してデータを同期させたりするためのUDFです。・テーブルパラメータに「choose_ignore_table_list」「choose_ignore_table_list_for_lock」「zero_record_update_mode」を追加しました。　Vertical Partitioningテーブルに新しいテーブルを追加した際などに、そのテーブルに対して検索を行わないようにするパラメータです。また、ロックを伴う検索と伴わない検索で利用する子テーブルを分ける為に使用することもできます。・サーバパラメータに「vp_udf_ct_bulk_insert_interval」「vp_udf_ct_bulk_insert_rows」を追加しました。　vp_copy_tablesの利用中にコピーの負荷を他のコネクションから動的に変更するためのパラメータです。利用例-------------------------------------------------------------------------------初期状態：&nbsp;&nbsp;&nbsp;&nbsp;create table tbl_a(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;col_a int not null,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;col_b varchar(20),&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;col_c int not null,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;primary key(col_a),&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key idx1(col_c, col_a)&nbsp;&nbsp;&nbsp;&nbsp;)engine=VP comment='tnl "tbl_b tbl_c"';テーブル追加：&nbsp;&nbsp;&nbsp;&nbsp;alter table tbl_a comment='tnl "tbl_b tbl_c tbl_d", cit "3", cil "3", zru "1"';コピー：&nbsp;&nbsp;&nbsp;&nbsp;select vp_copy_tables("tbl_a", "tbl_c", "tbl_d");後処理：&nbsp;&nbsp;&nbsp;&nbsp;alter table tbl_a comment='tnl "tbl_b tbl_c tbl_d"';-------------------------------------------------------------------------------それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。 Vertical Partitioningストレージエンジンは、テーブルのVertical Partitioning用のストレージエンジンです。
http://launchpad.net/vpformysql

今回の主な変更は以下です。
・UDF「vp_copy_tables」を追加しました。
　Vertical Partitioningテーブルに新しいテーブルを追加した際に、そのテーブルに対してデータを同期させたりするためのUDFです。

・テーブルパラメータに「choose_ignore_table_list」「choose_ignore_table_list_for_lock」「zero_record_update_mode」を追加しました。
　Vertical Partitioningテーブルに新しいテーブルを追加した際などに、そのテーブルに対して検索を行わないようにするパラメータです。また、ロックを伴う検索と伴わない検索で利用する子テーブルを分ける為に使用することもできます。

・サーバパラメータに「vp_udf_ct_bulk_insert_interval」「vp_udf_ct_bulk_insert_rows」を追加しました。
　vp_copy_tablesの利用中にコピーの負荷を他のコネクションから動的に変更するためのパラメータです。

利用例
-------------------------------------------------------------------------------
初期状態：
    create table tbl_a(
      col_a int not null,
      col_b varchar(20),
      col_c int not null,
      primary key(col_a),
      key idx1(col_c, col_a)
    )engine=VP comment='tnl "tbl_b tbl_c"';

テーブル追加：
    alter table tbl_a comment='tnl "tbl_b tbl_c tbl_d", cit "3", cil "3", zru "1"';

コピー：
    select vp_copy_tables("tbl_a", "tbl_c", "tbl_d");

後処理：
    alter table tbl_a comment='tnl "tbl_b tbl_c tbl_d"';
-------------------------------------------------------------------------------

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 13 Oct 2009 16:50:00 +0000 斯波健徳 VP MySQL [MySQL] MySQL公式トレーニング日本語化のお知らせ http://d.hatena.ne.jp/mir/20091013/p1 http://d.hatena.ne.jp/mir/20091013/p1 またまた更新が滞ってしまいました。でも忙しいのは良いことですよね。 さて本題。ちょっと宣伝が入っていますが、ぜひお知らせいたしたく。 これまで英語のスライドとテキスト(教材)でお届けしていたMySQL公式トレーニングですが（※講義自体は日本語）、なんと今月のトレーニングからスライドとテキストも日本語化されました！ 日本語化されたトレーニングコースは以下のコースです。 MySQLデータベース管理 I・II (英語名称 MySQL for Database Administrators） (まだHAとPerformanceコースについては教材は英語のままです） ということで早速先週、日本語教材での「MySQLデータベース管理 I・II」を弊社(住商情報システム)にて開催させていただき、私も講師として5日間登壇させていただきました。 途中台風の影響で開始時間が遅れるなどハプニングもありましたが、何とか最終日まで無事催すことができ、また概ねご好評いただけたように思います（ご参加いただいた方ありがとうございました）。 教材が日本語化されたことでより一層分かりやすいトレーニングが今後は国内でも(弊社に限らず)開催されるようになると思います。MySQLトレーニングにご関心のある方はこの機会にぜひ受講してみてはどうでしょうか。:) 弊社開催のMySQLトレーニングについては以下に詳細が記載されています。 http://www.scs.co.jp/mysql/training.html ちなみに次回のDBA向けコースの開催は2009/12/7-12/11です。

またまた更新が滞ってしまいました。でも忙しいのは良いことですよね。

さて本題。ちょっと宣伝が入っていますが、ぜひお知らせいたしたく。

これまで英語のスライドとテキスト(教材)でお届けしていたMySQL公式トレーニングですが（※講義自体は日本語）、なんと今月のトレーニングからスライドとテキストも日本語化されました！

日本語化されたトレーニングコースは以下のコースです。

  • MySQLデータベース管理 I・II (英語名称 MySQL for Database Administrators）

(まだHAとPerformanceコースについては教材は英語のままです）

ということで早速先週、日本語教材での「MySQLデータベース管理 I・II」を弊社(住商情報システム)にて開催させていただき、私も講師として5日間登壇させていただきました。

途中台風の影響で開始時間が遅れるなどハプニングもありましたが、何とか最終日まで無事催すことができ、また概ねご好評いただけたように思います（ご参加いただいた方ありがとうございました）。

教材が日本語化されたことでより一層分かりやすいトレーニングが今後は国内でも(弊社に限らず)開催されるようになると思います。MySQLトレーニングにご関心のある方はこの機会にぜひ受講してみてはどうでしょうか。:)

弊社開催のMySQLトレーニングについては以下に詳細が記載されています。

ちなみに次回のDBA向けコースの開催は2009/12/7-12/11です。


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 13 Oct 2009 00:00:00 +0000 Tetsuro Ikeda [mysql]MySQL 5.4.3-beta リリース http://d.hatena.ne.jp/sakaik/20091012/mysql543 http://d.hatena.ne.jp/sakaik/20091012/mysql543 　MySQL 5.4.3 がリリースされました。なんかきれいなバージョン番号(笑)。 　http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=151 　チェンジログを精読はしていませんが、なにやらいっぱいパーティショニングやレプリケーションを中心に修正が加えられている雰囲気を感じます。　あと、もちろん MySQL 5.4 の目玉であるパフォーマンス関係の修正も！ 　パラメタのデフォルト値がいくつか変更されているので、以前書いた「 ... PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 12 Oct 2009 00:00:00 +0000 Sakai Kei [mysql]MySQL 5.5 情報 http://d.hatena.ne.jp/sakaik/20091011/p2 http://d.hatena.ne.jp/sakaik/20091011/p2 　昨日あたりから、MySQL 5.5 ブランチへのコミットが開始されました。 MySQL バージョン 5.4 シリーズの正式リリースに向けて一定の見通しが立ってきたということでしょうか。 　MySQL バージョン 5.5 シリーズの更新はまだほとんどされていませんが、現在分かっているのは以下２点。 dtoa ライブラリの導入：　文字列と数値の変換ライブラリ。文字列やDECIMALとFLOAT/DOUBLE の間の変換の役割を負う。仕組みが以前とは違うので、以前と異なる結果を返す可能性がある。以前と ... PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 11 Oct 2009 00:00:00 +0000 Sakai Kei InnoDBの超高負荷更新処理安定性 tag:blogger.com,1999:blog-7661288799334918410.post-5451654090115871742 http://buildup-db.blogspot.com/2009/10/innodb.html 最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。今回もサクサクとポイントだけ。（IOスレッドを増やす　とか、他でも語られている既知のものは省略します。）今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイものを溜め込まない」 ということです。まず、最大スループットを上げるために、更新系で競合を回避するポイントをいくつか。"rseg->mutex" の競合：ロールバックセグメントを増やしましょう。XtraDB には、innodb_extra_rsegments というオプションがあり、InnoDBの初期化の時に限り、指定数の追加ロールバックセグメントを作成できます。information_schema の INNODB_RSEG ビューで状況確認可能です。"index->lock" の競合：その索引全体に対するロックです。5.1のパーティション機能で分割することにより回避できるかも知れません。表定義時に "PARTITION BY HASH(xxxx) PARTITIONS 16" の様にします。db_STRESSの場合、パーティション化するのは HISTORY 表のみで良いでしょう。"dict_operation_lock" の競合：パーティションを利用すると多く発生するようです。tablespaceの空き領域を算出する処理がパーティション分増えてしまうのでしょうか。今回は空き領域表示の正確性よりも性能が大事なので、切ってしまいましょう（ぁ）。XtraDBの次バージョンで innodb_stats_update_need_lock に 0 を指定しましょう。動的パラメータなので、空き領域を正確に知りたいときは 1 に戻せます。以上で db_STRESS のRW=1のスループットがかなり上がったと思います（…）。あ、はい。どうやって競合を確認するか、ですね？以前何処かでお話ししたかもしれませんが、少々乱暴な判断法ですが、SHOW INNODB STATUS を何回か実行して、SEMAPHORE セクションに沢山出てくる行を見て、ソースと照らし合わせて何の競合か判断します。結構、的を射た結論が得られます。さて次はそのスループットを維持／安定化することを考えます。忘れられがちなポイントを３つ挙げます。古いダーティブロックを溜めすぎない：トランザクションログの許容量ぶんよりも古い更新はflushしないままにはしておけません。なので大量に溜め込んでいると、ある時突然大量のデータブロック書き込みが発生する場合があります。普段からコツコツ書き出して減らしてバランスを取る必要があります。Plugin-1.0.4 から追加された innodb_adaptive_flushing かそれともこれを無効化して、XtraDB の "innodb_adaptive_checkpoint = estimate" を指定すると適切な量の書き出しをコンスタントにするようになります。どちらのオプションが最適かは、サーバーの性能と処理内容とその他設定のバランスに依存するようですので、試してみてください。XtraDBだと SHOW INNODB STATUS の出力の LOGセクション に Max checkpoint age と Modified age が表示されるので容易に確認できます。insert bufferを溜めすぎない：InnoDBは主キー以外の索引列に対する変更は、insert bufferに挿入して整合性を取りながら、後で実際の変更を実施します。しかし、InnoDBは insert buffer が buffer pool の半分の大きさまで肥大化しないと本気で処理しないようです。XtraDB のオプション innodb_ibuf_active_contract = 1 でいつも本気で insert buffer を減らそうとします。history listを溜めすぎない：これが起こるのは相当更新の激しい処理です。ロールバックセグメントの中身に対する後処理が新しくエントリを発生するスピードに追いつかずに肥大化した状態かと思われます。ロールバックセグメントが巨大化してしまうと、処理が重くなります。そのpurgeと言う後処理を専任で実行するスレッドをつくると言うアイデアもありますが、db_STRESS は1CPUのpurge threadではその他CPU全ての更新処理は受け止めきれないようです。XtraDBの次のバージョンでは、このpurge threadにさらに子分のスレッドをつけて"purge力"を上げることができます。例えば innodb_use_purge_thread = 4 の様な感じで 親分1+子分3 の構成でpurgeするようになります。(この設定で16コアのマシン上の32セッションの並列処理に対応できました。)苦し紛れの innodb_max_purge_lag 指定はもう必要無くなるのではないでしょうか？以上です。最後のpurge threadの効果を中心とした実際のデータは、近いうちに mysqlperformanceblog で見ることができると思います。では、MySQLマニアの皆さんも快適なベンチマークライフを！（検証用に急に良いマシンを借りれてしまったときに失敗せぬように！）
まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。

今回もサクサクとポイントだけ。
（IOスレッドを増やす　とか、他でも語られている既知のものは省略します。）

今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイものを溜め込まない」 ということです。

まず、最大スループットを上げるために、更新系で競合を回避するポイントをいくつか。

"rseg->mutex" の競合：
ロールバックセグメントを増やしましょう。XtraDB には、innodb_extra_rsegments というオプションがあり、InnoDBの初期化の時に限り、指定数の追加ロールバックセグメントを作成できます。information_schema の INNODB_RSEG ビューで状況確認可能です。

"index->lock" の競合：
その索引全体に対するロックです。5.1のパーティション機能で分割することにより回避できるかも知れません。表定義時に "PARTITION BY HASH(xxxx) PARTITIONS 16" の様にします。db_STRESSの場合、パーティション化するのは HISTORY 表のみで良いでしょう。

"dict_operation_lock" の競合：
パーティションを利用すると多く発生するようです。tablespaceの空き領域を算出する処理がパーティション分増えてしまうのでしょうか。今回は空き領域表示の正確性よりも性能が大事なので、切ってしまいましょう（ぁ）。XtraDBの次バージョンで innodb_stats_update_need_lock に 0 を指定しましょう。動的パラメータなので、空き領域を正確に知りたいときは 1 に戻せます。


以上で db_STRESS のRW=1のスループットがかなり上がったと思います（…）。

あ、はい。どうやって競合を確認するか、ですね？
以前何処かでお話ししたかもしれませんが、少々乱暴な判断法ですが、SHOW INNODB STATUS を何回か実行して、SEMAPHORE セクションに沢山出てくる行を見て、ソースと照らし合わせて何の競合か判断します。結構、的を射た結論が得られます。

さて次はそのスループットを維持／安定化することを考えます。

忘れられがちなポイントを３つ挙げます。

古いダーティブロックを溜めすぎない：
トランザクションログの許容量ぶんよりも古い更新はflushしないままにはしておけません。なので大量に溜め込んでいると、ある時突然大量のデータブロック書き込みが発生する場合があります。普段からコツコツ書き出して減らしてバランスを取る必要があります。
Plugin-1.0.4 から追加された innodb_adaptive_flushing かそれともこれを無効化して、XtraDB の "innodb_adaptive_checkpoint = estimate" を指定すると適切な量の書き出しをコンスタントにするようになります。どちらのオプションが最適かは、サーバーの性能と処理内容とその他設定のバランスに依存するようですので、試してみてください。
XtraDBだと SHOW INNODB STATUS の出力の LOGセクション に Max checkpoint age と Modified age が表示されるので容易に確認できます。

insert bufferを溜めすぎない：
InnoDBは主キー以外の索引列に対する変更は、insert bufferに挿入して整合性を取りながら、後で実際の変更を実施します。しかし、InnoDBは insert buffer が buffer pool の半分の大きさまで肥大化しないと本気で処理しないようです。XtraDB のオプション innodb_ibuf_active_contract = 1 でいつも本気で insert buffer を減らそうとします。

history listを溜めすぎない：
これが起こるのは相当更新の激しい処理です。ロールバックセグメントの中身に対する後処理が新しくエントリを発生するスピードに追いつかずに肥大化した状態かと思われます。ロールバックセグメントが巨大化してしまうと、処理が重くなります。
そのpurgeと言う後処理を専任で実行するスレッドをつくると言うアイデアもありますが、db_STRESS は1CPUのpurge threadではその他CPU全ての更新処理は受け止めきれないようです。
XtraDBの次のバージョンでは、このpurge threadにさらに子分のスレッドをつけて"purge力"を上げることができます。例えば innodb_use_purge_thread = 4 の様な感じで 親分1+子分3 の構成でpurgeするようになります。(この設定で16コアのマシン上の32セッションの並列処理に対応できました。)
苦し紛れの innodb_max_purge_lag 指定はもう必要無くなるのではないでしょうか？


以上です。
最後のpurge threadの効果を中心とした実際のデータは、近いうちに mysqlperformanceblog で見ることができると思います。

では、MySQLマニアの皆さんも快適なベンチマークライフを！
（検証用に急に良いマシンを借りれてしまったときに失敗せぬように！）

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Thu, 08 Oct 2009 16:26:00 +0000 Yasufumi Kinoshita