MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ
LINEAR HASHパーティショニングってなんだ？
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
圧縮MyISAMテーブルで商品マスターを運用する方法
商品マスターのように参照専門で利用するテーブルならば、圧縮MyISAMが非常に適していることが多い。その方が容量が小さくなるし、ディスクI/Oが減るので高速化が期待出来るからだ。圧縮MyISAMを利用する時の問題点は、MySQLサーバ起動中にテーブルの圧縮を行えない点であろう。（正確には行えなくもないが、操作は慎重を期する必要がある。）また、圧縮MyISAMテーブルはひとたび圧縮してしまった後は、更新を加えることが出来ないのだが、如何に商品マスターといえども、一日に一度程度の頻度で更新をかけないといけないかも知れないので、これまた問題である。圧縮MyISAMテーブルを用いた運用は利点がある一方で、このような問題があるため難しい。そこで、今日は圧縮MyISAMテーブルで商品マスターを運用する方法について紹介しよう。 商品マスター作成用のMySQLサーバを用意する。オンライントランザクションを
MySQL 5.4!! MySQL Cluster 7.0!!
Oracleによる買収の報道とちょうど時期が重なってしまったのだが、実は今MySQL Conference & Expoの真っ最中なのである。買収のニュースのインパクトが大きすぎて霞んでしまいそうになるが、MySQL Conference & Expoにおいてなんと新しいバージョンのMySQLが発表された。MySQL 5.4である。次期バージョンは6.0とされていただけに驚いた人も多いだろうが、5.4は5.1から性能を改善し、6.0の機能をちょっとだけ先取りしたバージョンなのである。（そのバージョン番号の通り、5.1と6.0の中間的なバージョンというわけである。） MySQL 5.4の新規機能は次の通り。 InnoDBのスケーラビリティ改善（Googleの貢献！） SHOW ENGINE INNODB STATUSの拡張。（さらなる情報の表示） DTrace用Probeの追加（Solari
Distribution Awareness - MySQL Clusterにおけるスキーマチューニングの定石
MySQL Clusterはデータノードが増えると性能が低下する？？？ そのような噂を聞いたことがないだろうか。この噂は事実を含んでいる面もあるが、殆どの場合は適切にスキーマを設計していないことが原因で起きる。実はMySQL Clusterはその性能を遺憾なく発揮するためにはスキーマの設計が非常に大事なのである。 MySQL Clusterは複数のデータノード（ノードグループ）に対して主キーの値に基づいて行単位で分散されている。主キーに偏りがなければ各データノードに格納される行数は均等になる。つまり、MySQL ClusterはSharding（アプリケーションパーティショニング/Level2分散）を自ら行っていると言えるだろう。 MySQL Clusterでは主キーによるルックアップは、どのデータノードにデータが格納されているかが主キーから分かるため非常に高速である。逆に、主キー以外のキ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
DBT-2によるベンチマーク手順
DBT-2とはTPC-Cライクなオープンソースのベンチマークソフトで、OLTP系の負荷を擬似的に作り出すように設計されている。細かい更新系の処理を測定したい時には便利なベンチマークツールである。しかしながら、DBT-2の実行手順は多少面倒くさく、さらにREADMEには偽の（？）情報まで含まれている上にDBT-2の実行手順はあまりWeb上では解説されていない。そこで、今日は簡単ではあるがDBT-2によるベンチマークのやり方を紹介しよう。（以下の例では利用するデータベースをMySQL、DBT-2のバージョンを0.40であると仮定している。） 1. ダウンロード次のページからDBT-2をダウンロードしよう。 http://osdldbt.sourceforge.net/ 2. 補助パッケージのインストール以下のperlパッケージ類はconfigureスクリプトでは「足りないよ」と言ってくれないの
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
高速SSDの落とし穴。データベースで利用するときはご注意を！
今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。 MySQL Performance Blogでインテル製SSDを使って検証した結果がレポートされている。 インテル製SSDはめっぽう早い。彼らのテストでは一秒間に5250回もの書き込みが出来たそうだ。しかしそれはライトバックキャッシュが有効になっているときの話であって、ライトバックキャッシュを無効にすると書き込みは秒間1200回まで低下したらしい。（それでも高速だが。） で、このインテル製SSDのライトバックキャッシュはくせ者で、バッテリー等で保護されていない。つまり、ライトバックキャッシュにダーティな（まだディスクへの書き出しが完了していない
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
最強のMySQL HA化手法 - Semi-Synchronous Replication
MySQL 6.0で搭載される予定の機能の一つに、Semi-Synchronous Replicationというものがある。コイツを使うととんでもなく凄いHA化ができるので、今日はその方法を紹介しよう。 まずはSemi-Synchronous Replicationの機能説明から。そもそもSemi-Synchrounousってナニ？どうして完全な同期でもなく非同期でもなくSemi-Synchronousなの？という疑問をまずは解消したいと思う。さっそく次の図を見て欲しい。 これはSemi-Synchronous Replicationの動作を図で表したものである。図だけではなんだかよく分からないと思うので、以下に各ステップの詳細を説明する。 アプリケーション（クライアント）からトランザクションをCOMMIT要求を出す。 バイナリログを更新する。 ストレージエンジン（テーブル）を更新する。
チャットで役立つ英略語12個
外国人とチャットするときに独特なのは略語の存在だ。略語は通常の会話では使えないし、少し時間をかけて書くことができるEメールやブログなどでもあまり出てこない。主にチャット特有の表現であると言えるだろう。 コンピュータギークであれば海外の開発者たちとチャットする機会が多いと思うが、海外のギークたちは主に英語を利用する。コンピュータのメッカはやはりシリコンバレーだし、英語のドキュメントも非常に多い。したがって国境を越えたギーク同士のチャットで使われるのは英語である。 ただでさえ英語は難しい。そしてチャットに流れるメッセージは非常に・・・いや、非情なほど速い。その上見慣れない略語に翻弄していては到底チャットのペースに追いつくことができず、何かしら発言したくてもできなくなってしまうだろう。 というわけで、今日は英語のチャットで頻出する略語を10個紹介しよう。外人とチャットするときにはぜひ利用して欲し
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
MySQL Clusterへの接続方法
どうやってたくさんあるSQLノードに接続すればいいんだ？ ロードバランスは？ フェイルオーバーは？ ということがあると思う。このテーマを扱ったドキュメントはありそうだちょうど良いものが見あたらない。おそらくこの点が明確でないために「よし、最近サイトのトラフィックも増えてきたことだし、いっちょMySQL Clusterを試してみようか！」という気にならず、多くの人が利用を躊躇ってしまっているのではないだろうか？なので今日はこの点について5パターンのソリューションを紹介したいと思う。 その前に、「MySQL Clusterって何だ？シラネーヨ！」って人は、MySQL Clusterの特徴やセットアップ方法などを以前にThinkITへ投稿したのでそちらを参照して貰いたい。 http://www.thinkit.co.jp/article/95/ では本題。 1. mysqldをアプリと共存恐らく
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
プロファイリングで快適MySQLチューニング生活
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
MySQL6.0における新しいJOIN最適化手法 - BKA
MySQL 6.0では新たなJOIN最適化手法であるBKA - Batched Key Accessの実装が進んでいる。BKAとは、読んで字のごとくキーを用いたアクセスをバッチ（ひとまとまりの）処理にすることである。現在のバージョンのMySQLでは、2つのテーブルをJOINする際、一つ目のテーブルから選択した行に対して、逐一2つめのテーブルから行が一つずつフェッチされる。例えば次のクエリを用いてテーブルt1とt2をJOINする際には以下のような流れで行われる。 mysql> SELECT * FROM t1 LEFT JOIN t2 ON t1.a=t2.b WHERE t1.c > 1000 AND t1.c <= 2000; t1からWHERE句の条件（1000 < c <= 2000）に適合する行をフェッチする。 条件に合う行が1000行あったとする。 1行目のt1.aと同じt2.b
MySQL 5.1のスロークエリログ
MySQL 5.1で追加されたメジャーな機能の影に隠れた、地味だが便利な改善がある。それがスロークエリログに関する仕様である。MySQL 5.0まではスロークエリログは1秒未満のクエリを捕捉することが出来なかった。が、MySQL 5.1では1マイクロ秒までのクエリを記録できるようになっている。従って、0.5秒かかるけど大量に実行されてパフォーマンスに大きな影響を与えている！というようなクエリの発見が出来るようになった。1秒未満のクエリを追跡したい場合、例えば以下のような設定をする。 [mysqld] slow_query_log=ON slow_query_log_file=mysql-slow.log long_query_time=0.1 MySQL 5.0まではlog_slow_queryというオプションだったのが、MySQL 5.1ではslow_query_logというオプション名
2008年を振り返って・・・MySQL Cluster 6.3
2008年はMySQLにとっては激動の一年であり、実に様々なできごとがあった。その中でも特に大きなニュースといえば、 Sun Microsystems IncによるMySQL AB買収。 Drizzleプロジェクト立ち上げ MySQL Clusterの分離 MySQL 5.1リリース MySQL User Conference Japan 2008開催 だろう。UCJ2008の資料はイベントのホームページからダウンロードできるので、是非入手して見て欲しい。 http://jp.sun.com/company/events/mysql/report.html この中で、個人的にもっとも刺激的なニュースを挙げると、MySQL Clusterの分離だろう。 MySQL Clusterは依然としてMySQLとセットでリリースされているが、基本的にはMySQLとは違うペースで開発が進むことになった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
