OSX 10.7 Lion で Rails と MySQL - NullPointer's
MacBook Air買いました。そしてLionでRails開発環境を作成していきなりハマるｗ rubyはrvmで1.8.7、railsは2.3.11、gemは1.3.5というちょっと古い環境。 まずMySQLデータベースサーバ。MySQLのサイトにおいてある10.6用64bit版のdmgが普通に使えるようだ。インストールしてMySQLを起動。 次に、MySQLドライバをgemでインストール $ env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_configマイグレーションすると… $ rake db:migrate rake aborted! uninitialized constant MysqlCompat::MysqlRes失敗した失敗した
「MySQL Casual Talks vol.2」に参加してきたよ、のメモ - 元RX-7乗りの適当な日々
第1回に引き続き、"あまりカジュアルではない？"が定説となりつつあるｗ「MySQL Casual Talks」の第2回が開催されたので、行ってきました。前回に引き続き面白かったので、自分のメモ書きを貼り付けておきます。 (全然追いついてないメモも多いし、スピード感たっぷりだったので間違った記載もあるかもですが、そこはご了承を...) # 例によって、発表資料が出揃ったらそちらを見ていただいた方が良いです。 ちなみに、第1回のメモエントリは、、 「MySQL Casual Talks vol.1」に参加してきたよ、のメモ - 元RX-7乗りの適当な日々 追記 このエントリでもまとめ的に、公開された資料も紹介させていただいておりますｗ MySQLでNoSQL (@oinume) View more presentations from Kazuhiro Oinuma 生沼さん、実はMySQLは
変数とストアドプロシージャについて - 日向夏特殊応援部隊
追記しました (2011-08-08T16:57:50Z) 割と弊社では MySQL の event scheduler を使ってみたり、ストアドプロシージャ、トリガーなど積極的に使っています。 今回はストアドプロシージャを書く上で、変数を色々使うのですが備忘録としてメモっておきます。 MySQL における変数には幾つか種類があります。 システム変数 (c.f. @@version) ユーザー変数 (c.f. @var_name) ローカル変数 (c.f. DECLARE var_name INT, ストアドプロシージャ内で使える) これら変数の特徴は下記です。(MySQL 5.1.50 で確認) -- システム変数 ユーザー変数 ローカル変数 スコープ GLOBAL *1 SESSION LOCAL 型 なし なし あり 宣言 なし なし あり 設定 SET GLOBAL / SET S
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
オープンソース開発者がDeNAを選ぶ理由
This document discusses the history and capabilities of Q4M, an open-source message queue plugin for MySQL. It was created in 2008 by Cybozu to provide a robust, fast messaging system accessible via SQL. Major Japanese companies like DeNA, Livedoor and Mixi use Q4M for asynchronous communication between services. The document also covers related projects like Mycached, a memcached-like plugin, and
僕は木になりたい。。。 : gem install mysql にハマる - livedoor Blog（ブログ）
Rails2.2.2では、mysqlがデフォルトでは使えず、 gem install mysql をやれと言われました。 やってみる。 $ sudo gem install mysql Building native extensions. This could take a while... ERROR: Error installing mysql: ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb install mysql checking for mysql_query() in -lmysqlclient... no checking for main() in -lm... yes checking for mysql_query() in -lmysqlclient...
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ！」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって？
「Mobage」巨大サーバーを支えるDeNAのMySQL活用とは｜【Tech総研】
MobageなどのデータベースとしてMySQLを採用しているDeNAは、このほどMySQLコミュニティ最大のイベントで、「Corporate Contributor of the Year 2011」を受賞した。そこで示されたDeNAの世界に通用する技術力とは──。 オープンソース・データベースとして世界中で使われているMySQL。大規模なトランザクションを処理するサイト構築には不可欠の技術だが、株式会社ディー・エヌ・エー（DeNA）はMySQLを徹底して使い倒し、独自の拡張技術を開発することを通して、その可用性を高めてきた、日本を代表するユーザー企業の一つとして知られている。現在、Mobage（モバゲー）サービスを動かすために、約700台のMySQLサーバーが稼働しており、その数は世界的にも有数のものだ。 4月中旬に米サンタクララで開かれたMySQLコミュニティ最大のイベント、MySQL
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 MySQLの次期バージョンとPostgreSQLの次期バージョンにどのような新機能が追加されるのか、昨日、一昨日の2本の記事で紹介しました。 MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演 PostgreSQLの現状と次期バージョン9.1の新機能。MySQL Conference & Expo 2011 この2つのデータベースの次期バージョンに共通しているのが、NoSQLの機能を取り込んでいることです。NoSQLに対するリレーショナルデータベースによる反撃が始まっています。 リレーショナルデータベースがNoSQLを取り込み始めた MySQLの次期バージョンであるMySQL 5.6に搭載予定の新機能の1
今年は計画的にいきたいー社会人3年目を迎えてー - As a Futurist...
3,4 月とえらいドタバタして、年度を振り返ったりするのがすっかり遅くなってしまいました。毎年毎年重ねていくと、あとで Connecting the Dots するときに参考になるかなーと思うので、今の気持ちを素直に綴っておこうと思っています。 社会人 2 年目どうだった？ 1 年目は文字通り右も左もわからず、右往左往してたわけですが、おかげさまでその 1 年目の貴重な体験もあって 2 年目はおそろしく落ち着いて仕事ができました。幸運(?)なことにほっといても勝手に仕事の方からやってくるけど、それに負けずに自分で突っ込んでほじくり返して手を広げて、興味の赴くままにいろんな仕事をできて、引き続き楽しい 2 年目でした。まさに「やりたいようにやれる」環境な感じです。 んで、この 1 年は結構ブログでのアウトプットができた気がしたので実際数えてみました。 mysql> select date_f
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
MySQL 5.6登場！！新機能速攻レビュー
現在、米国で行われているMySQL Conference & Expoにあわせて、新しい開発版であるMySQL 5.6が発表された。MySQL 5.5における新機能もかなりのものだったが、MySQL 5.6の進化は質・量ともに勝とも劣らない内容となっている。そこで、今日は簡単に、MySQL 5.6で追加された新機能の概要について見てみよう。開発版なので利用にあたっては十分な注意が必要（予期なく予定が変更される可能性あり）だが、次期正式版のリリースに向けて是非試してみて欲しい。 InnoDB関連MySQL 5.5で大幅な進化を遂げたInnoDBだが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ
DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール
4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範（まつのぶよしのり）氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています（英語のドキュメントも作成中とのこと）。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
優れたMySQL DBAを見分ける27+3の質問
「優れたPerlプログラマを見分ける27の質問」の日本語訳というエントリが人気だったので、MySQL版をやってみた。題して、「優れたMySQL DBAを見分ける27+3の質問（漢バージョン）」。腕に覚えのある人はぜひ試してみて欲しい。 MySQLのサーバープロセスはいくつある？ rootユーザーのパスワードを忘れたときの回復手順 MySQLをオンラインバックアップする方法を3つ。（もっとでも可） InnoDBのデータファイルが作成可能な場所はどこか。 InnoDBのデフォルトの分離レベルは？ ネクストキーロックについて説明せよ。 ロールバックセグメントにはどのようなデータが格納されるか？ InnoDBでデッドロックが発生したときの挙動、および詳細な状態を確認する方法。 MyISAMがサポートしている特殊なインデックス2つ。 MySQLにおけるテーブル1行あたりの最大サイズ。 構成可能なレプ
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
MySQL(InnoDB)でCOUNTしたくないとき - かみぽのメモ
たとえば、MySQL を使ったお手軽メッセージキュー実装 - ドワンゴ 研究開発ブログに出てくるようなInnoDBをメッセージキューのように使っているときに、キューにどれだけメッセージが溜まってるかを確認したいとき、普通に考えるとCOUNTすると思う。 SELECT COUNT(*) AS count FROM test_queue;この軽い気持ちでしたCOUNTが、もしうっかりキューに100万レコードぐらいあったりするとInnoDBだとPRIMARYキー総なめとかしちゃってレスポンスにかかる0.1秒ぐらいのあいだ罪悪感に苛まれることでしょう。 このとき冷静に考えると、もしキューが1件も処理されていなければ、idはauto_incrementなので特に細工していなければ SELECT MAX(id) AS count FROM test_queue;これも全体のレコード数に等しいでしょう。
Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる
最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？ 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Twitterにおける大規模システム構築、3つの原則