ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
KLab
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！
MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
MySQL 5.1.46リリース InnoDB Pluginが正式版に - SH2の日記
出ました。今回は機能追加が1件、バグ修正が55件あります。バグ修正のうちセキュリティに関するものが1件、パーティショニングに関するものが5件、レプリケーションに関するものが7件となっています。 MySQL 5.1.38から本体に付属するようになったInnoDB Pluginですが、バージョンが1.0.7に上がりRCからGA(Generally Available、正式版)となりました。ついに正式リリースです。というわけで何度か繰り返している話題ですが、今回はInnoDB Pluginについて再度おさらいをしておきたいと思います。 InnoDB Pluginの使い方 MySQL 5.1.38以降であればInnoDB Pluginを使うように設定するのは簡単です。/etc/my.cnfに以下の設定を書き加えることでInnoDB Pluginが有効化されます。 ignore-builtin-in
InnoDB で fsync しない方法と、そのメリット - kazuhoのメモ置き場
InnoDB はデフォルトでは同期I/O *1だけど、 innodb_flush_method=nosyncっていう隠しオプションがあって、それを有効にすると MyISAM みたく fsync しなくなるよ。ってソースコードちら見した自分が言ってた。 この設定がうれしいのって、どういう時だろう？ MySQL – Wikipedia にも書いてあるけど、スレーブ運用してて「クラッシュしたらリカバリで数時間かかるし、データ一貫性チェックするくらいだったらバックアップからリストアして再開しちゃうもんね〜」的な向きにはおすすめなのかしらん。 とは言え、fsync しないってことは OS のページキャッシュに書込みデータが滞留することになる → buffer_pool 削る必要が出てくる → 無駄な I/O が増える、わけで、設定するメリットがあるかどうかは知らない。swappiness=0 にしと
InnoDBのファイルサイズ管理
最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺） InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
あるあるおハマり大事典 - InnoDBなのに行ロックしないの - （ひ）メモ
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" wh
MySQL 5.1.38 リリース ＆ リリースノートの InnoDB Plugin に関する部分の超訳 - sakaikの日々雑感～(T)編
MySQL 5.1.38 がリリースされました。5.1シリーズはここ数ヶ月は毎月月初に必ずリリースされていて、MySQLリリース管理が安定したことを感じさせられます。 http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=147 今回のリリースノートには、いつもの「変更点」の箇条書きだけでなく、今回のリリースから加えられた「InnoDB Plugin」についての説明が長々と書かれています。 英語は外国語にしか見えない私にとって（←当たり前だ）自分の理解のために例によって「超訳」してみました。 訳なんて言葉を使うとバチがあたりそうなので「私の理解を、なるべく原文の話の筋に沿って私の言葉で説明してみました」くらいの感じだと思って下さい。誤りや勘違いなどに気づいたかたは教えて下さい。 原文はここ：http://dev.mysq
MySQL InnoDBにおけるロック競合の解析手順 - SH2の日記
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて
show innodb status でチェックする値 - kazuhoのメモ置き場
show innodb status\G して Buffer pool hit rate が 997/1000 以上だった良い、というのは、ディスクバウンドのデータベースの話なのかな。個人的には、FILE I/O の reads/s の方を気にしている。ちなみに以下は、もうダメダメなパターン。Buffer pool hit rate は 1000/1000 だけど一秒間に 44 回も HDD から読み込んでいる (O_DIRECT設定してる) わけで、実態は青息吐息 (MyISAM も使ってたりするので)。というわけで Pathtraq のメンテナンスを開始します。 -------- FILE I/O -------- I/O thread 0 state: waiting for i/o request (insert buffer thread) I/O thread 1 state:
MySQL 5 の場合はmytopよりinnotopのほうがいいかも - （ひ）メモ
MySQLのモニタするのに便利なmytopなんですが、MySQL 5に対して使うと、クエリの割合表示が全部ゼロになってしまったります。 これは、MySQL 5.0.2でSHOW STATUS文が変更され、GLOBALかSESSIONというオプションを指定できるようになったことに起因します。このオプションを省略した際はSESSIONを指定したときと同じ動作となり、SHOW STATUS文で得られるのは自分自身の接続についての情報のみとなります。 mytopはオプションなしのSHOW STATUS文を使っているので、MySQL 5ではmytop自身の接続についての情報しか得られず、その影響として、クエリの割合表示が全部ゼロになってしまったりするわけです。 対応は簡単で、mytopのSHOW STATUSをSHOW GLOBAL STATUSに書き換えればいい(書き換えるとMySQL 4.1以前
フツーな日常 - InnoDBを使うときのパフォーマンスチューニング
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
Kazuho@Cybozu Labs: MySQL のウォームアップ (InnoDB編)
« DBIx::Printf と LIKE 式 | メイン | メッセージキュー事始め in Perl - コマンドラインクライアントを作ってみた » 2007年10月11日 MySQL のウォームアップ (InnoDB編) サーバの起動直後はデータがメモリ上にないためデータベースの応答速度が遅い、というのは良く知られた話かと思います。MySQL の場合、使っているエンジンが MyISAM であれば、各データファイルをあらかじめ cat ... > /dev/null するなりしてバッファキャッシュに載せておけばいいのですが、InnoDB は独自のキャッシュを持っているのでそういうわけにもいかないように思います。 具体的には、パフォーマンスを最大限発揮するためには OS のキャッシュにではなく、InnoDB のバッファプールにデータをロードすべきであるという点。それに、たとえ OS のキャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InnoDBの主キーはクラスターインデックスだということを意識しよう | 株式会社ビーグッド・テクノロジー／障害監視 運用保守 インフラ構築 Tripwire MySQL システム開発
株式会社スタイルズ