DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール
4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範（まつのぶよしのり）氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています（英語のドキュメントも作成中とのこと）。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求
mysqlコマンドをより便利に安全にするための小粒なTIPS集｜サイバーエージェント 公式エンジニアブログ
初めまして。2010年の3月に入社した oinume です。新年1月からウィルス性胃腸炎に罹りながらもなんとかこのエントリーを書いています。今回は、mysqlコマンドに関する自分が今まで学んだ＆教えてもらった細かい実践的なTIPSを紹介します。小粒ですが何かの役に立てば幸いです。 edit (¥e)コマンド mysqlプロンプトにいながら任意のエディタでSQLが編集できちゃいます。具体的には、mysqlコマンドでプロンプト待ちの状態で mysql> edit のように edit または ¥e と入力すると、環境変数EDITORで設定してあるエディタが立ち上がりSQLが編集可能になります。編集が終わったらエディタを終了して ; とやればSQLが実行されます。viなどターミナルで動くエディタに慣れている人は長いSQLを編集する時に重宝する機能でしょう。この技は前職の同僚に教えてもらって、以降便
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
BLACKHOLEストレージエンジンを使ってInnoDBなテーブルの暖気運転をする - （ひ）メモ
どうもこんにちは。小太り男子中年のサーバーエンジニアです。 先日行われたhbstudy#13の [twitter:@nippondanji]さんのセッション(スライド) で、「BLACKHOLEストレージエンジンを使えば、InnoDBなテーブルの暖気運転(テーブルデータを空読みして、buffer poolに乗っける)ができる」という話があったので、あなるほどーと思い試してみました。 CREATE TABLE _preload LIKE huge_table; ALTER TABLE _preload ENGINE = BLACKHOLE; INSERT INTO _preload SELECT * FROM huge_table; DROP TABLE _preload;なるほどなるほど。
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
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
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でCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング！
明けましておめでとうございます。今年もコンピューター道に邁進して参りますのでよろしくお願いします！ さて、今年一発目のネタはMySQL利用時におけるZFSのチューニングについて取り上げようと思う。Solarisに搭載されている機能の中でも最も注目度の高いものの一つであるZFSであるが、MySQLのバックエンドとしてはあまり利用されていないように思う。（そもそもSolarisのユーザー数自体がそれほど多くないという話もあるが。）ZFSは優れたファイルシステムであり、ファイルシステム自体にスナップショット機能が搭載されていたり容量の限界に先が見えない（充分すぎるほど余裕がある）といった管理上のメリットがあり、DBAにとっては垂涎のファイルシステムであると言える。（Linuxで利用出来ないのが難点だが、ZFSを使うためにSolarisを使うのもアリだろう。） MySQL利用時におけるZFSのチュ
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ
MySQL InnoDBだけで全文検索 - SH2の日記
実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
Amazon Relational Database Service (Amazon RDS)
Amazon Relational Database Service Easy to manage relational databases optimized for total cost of ownership Amazon Relational Database Service (Amazon RDS) is an easy-to-manage relational database service optimized for total cost of ownership. It is simple to set up, operate, and scale with demand. Amazon RDS automates the undifferentiated database management tasks, such as provisioning, configur
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
SQL pie chart
My other half says I’m losing it. But I think that as an enthusiast kernel developer she doesn’t have the right to criticize people. (“I like user space better!” – she exclaims upon reading this). Shown below is a (single query) SQL-generated pie chart. I will walk through the steps towards making this happen, and conclude with what, I hope you’ll agree, are real-world, useful usage samples. +----
InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース
日本時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
