MySQL 初めてのチューニングPostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)Hironobu Suzuki
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
MySQL 5.5新機能徹底解説
今年も残すところあとわずかとなった。2010年もIT業界にとっては変化の多い一年だったが、皆さんにとっては良い年だっただろうか？既に何度かMySQL 5.5の新機能については取り上げたが、ついに正式版がリリースされたということでここで改めて新機能を解説し、今年最後のエントリを締めくくろうと思う。 MySQL 5.5にはこれでもかっ！というぐらい新機能が追加されている。しかもいずれもナイスなものばかりだ。一般的には、ソフトウェアに新機能が追加されると重くなったり安定性が低下する事例が後を絶たないのだが、MySQL 5.5に関してはそのようなことは全くないので安心して利用して頂きたい！ InnoDBの大幅な改善種々ある改善点の中でも特に目をひくのがInnoDBストレージエンジンへの改良だ。実は、InnoDBはMySQL 5.1が最初にリリースされたときから、2回アップデートが行われている。My
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
MySQLコミュニティ騒然！MySQL 5.5.4が与えるインパクト。
先週、MySQL Conference & Expo 2010が開催され、盛況のうちに終了した。カンファレンスに合わせる形で、MySQL 5.5.3および5.5.4がリリースされたのだが、これが目を見張るような進化を遂げている。特に性能面での進化には目を見張るものがある！Jeremy ZawodnyやMark Calleghanといったコミュニティの重鎮たちも「非常にエキサイティングなリリースだ！」などと表して歓迎の意を表している。 というわけで、本日はMySQL 5.5.3/5.5.4の新機能および変更点についてレビューしてみよう！ おさらい。 〜 MySQL 5.5の既存の機能 〜MySQL 5.5が登場したとき、その新機能については以前にもエントリで紹介したが、ここで改めておさらいしてみよう。MySQL 5.5は、正確にいうと現在最新バージョンであるMySQL 5.1の「次の次」のバ
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の自動変換を丁重にお断りするためのたった１種類の呪文 - sakaikの日々雑感～(T)編
先日の『これだけは覚えておきたい!!MySQL の６つの自動変換』 http://d.hatena.ne.jp/sakaik/20100225/mysqlautochange にはたくさんの反響をいただいた。 時にこちらの意図と違っちゃうこともあるけれどもケナゲに気を使ってくれる MySQL が、これほどに皆さんにも愛されていることが判り、MySQLファンの一人として嬉しい限りである。 さて、そのエントリの最後に、 なお、「SQLモード」を指定するとこれらの動作を変更することができる。SQLモードについては気が向いたらいつか紹介してみたい。 と書いたところ、速攻でキムラデービーの木村明治氏が補足エントリーを書いてくださった。 ○キムラデービーブログ [勝手に補足]これだけは覚えておきたい!!MySQL の６つの自動変換 http://blog.kimuradb.com/?eid=83851
これだけは覚えておきたい!!MySQL の６つの自動変換 - sakaikの日々雑感～(T)編
MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する６つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 １．[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ（unsignedの場合は43億弱）。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ
CLOSE_WAITのセッションを早く消す方法 - つれづれなる・・・
原因はおそらくwebサーバ〜DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは tcp_keepalive_time TCPセッションが確立されて検査が実施されるまでの時間 時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する tcp_keepalive_intvl 次の検査を実行するときの待ち時間 tcp_keepalive_probes 検査の回数のそれぞれの値を小さくしてあげればよい。変更方法は vi で :wq する
MySQL Cheat Sheet 1.0
5 コメント: hika69 さんのコメント... MySQL Cheat Sheetのリンクが切れているようです。ほしいです！ 2011/04/02 12:54:00 Mikiya Okuno さんのコメント... Hikariさん、 今引越しをしたところで、まだ鯖を配備し終えてないのです。今しばらくお待ちを！ 2011/04/04 14:43:00 Mikiya Okuno さんのコメント... Hikariさん、 おまたせしました。ダウンロード可能になりました。 2011/04/09 0:05:00 Unknown さんのコメント... このコメントは投稿者によって削除されました。 2016/07/21 17:48:00 Mikiya Okuno さんのコメント... すみません。本文中でリンクしているサイトは、ドメイン切れのため消失してしまいました。下記のリンクをご利用ください。
KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Manual :: 13.6.10.1 Clustered and Se
ricollab Web Tech Blog » Blog Archive » MySQLパーティショニングについて（その2：性能検証編）
こんにちは、濱田です。 前回から時間が経ってしまいましたが、今回は「性能検証編」ということで、パーティションドテーブルに対して実際にデータを挿入・参照することでパーティショニングの性能面を検証してみようと思います。 性能検証環境 使用したマシンのスペックは以下の通りです。 OS CentOS 5.3 32bit (on Windows XP Pro SP3 32bit via VMware Server 2.0.0) CPU Core2 Duo E8300 2.83GHz (VMには1CPUを割り当て) Memory 3.25GB (VMには512MBを割り当て) MySQL のバージョンおよび設定は以下の通りです。なお、MySQL サーバおよびクライアントは同一マシン上で動作させました。 MySQL 5.1.35-community (設定は my-medium.cnf をそのまま使用)
MySQL InnoDBだけで全文検索 - SH2の日記
実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy
2008-07-10 - 知のレバレッジを最大化せよ「MySQLレプリケーションの運用管理ツールMaatkit」
MySQLのレプリケーション設定はそんなに難しくないのですが、大規模に運用しようとすると、ちゃんと動作できているのかどうか、もし障害が発生したときにどうやって復旧すべきかの手順を定める必要もあり、運用手順の策定と共有が重要な課題事項になってきます。そんな中、このperlでできたMaatkitは非常に強力な管理ツールとなってくれるようです。 ・・・これは、、すごく便利じゃないすかね!!! http://www.maatkit.org/ mk-table-checksum テーブルが同一データをもっているかどうかを効率的にチェックできます。いろいろレプリケーションエラーを無視していると障害が結果的に発生していても気づかないものですが、もしバックアップ用途にレプリケーションをとっているのだとしたら、定期的にこれでチェックすべし。 mk-table-sync サーバ間でのテーブルの差異を復旧してく
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
カカクコム社内勉強会に参加 - mir the developer
id:kiskeさんにお誘いいただいて先週金曜日にカカクコムさんの社内勉強会でお話させていただきました。貴重な機会をいただきありがとうございました。 自由に話してOKですよとのことだったので、何にしようかなと少し考えた結果、こんなスライドができあがりました。 MySQLのパフォーマンスの話View more presentations from ikdttr. MySQLも今となってはかなり広く使われていて、パラメータチューニングとかも一通りのことは皆さんご存知だろうと思ったので「チューニングをする際にソースを読んで調べたいと思ったらどうしたらいいか」といったようなテーマに対する答えの一例見たいな感じの内容になりました。 普段使っている/参照しているサーバ変数やステータス変数がどのように実装されていて、それらをソース上で追いかけるにはどうしたらいいか、みたいな感じですね。 勉強会ではgdb
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
table_cache, max_connections, open_files_limit の関係 - tmtms のメモ
昔はマニュアルに書いてあったような気がしたけど、最近のマニュアルには見当たらないのでメモ。 mysqld が同時に使用可能なファイル数は open_files_limit というパラメータで指定します。ただし、mysqld は最低でも table_cache*2+max_connections+10 --- (a) は必要だと考えるので、open_files_limit が (a) よりも小さければ、黙って (a) の値まで大きくします。table_cache を2倍しているのは、MyISAM が1テーブルにつき2ファイル使用するためでしょう。10 を足しているのは標準入出力エラー出力と、ログファイル等の分でしょうか。 また、max_connections*5 --- (b) の方が (a) よりも大きければ、open_files_limit は (b) になります。 (a), (b) よ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.mysqlpracticewiki.com/index.php/MySQL%E3%82%B5%E3%83%BC%E3%83%90%E3%81%8C%E6%B6%88%E8%B2%BB%E3%81%99%E3%82%8B%E3%83%A1%E3%83%A2%E3%83%AA
http://www.mysql.gr.jp/Manual/mysql-3.21.31/manual_Performance.html