言及するのが既に周回遅れ気味だが、いますぐコマンドプロンプトを捨てて、Cygwinを使うべき１０+の理由という記事がとても人気だったようだ。 Cygwinはご存知の方も多いだろうが、元々はCygnus Support（後にCygnus Solutionsに改名）という会社が開発した、Windows向けのGNU関連のツール群だ。Cygnusという名前にはGNUの３文字が含まれているが、これは「GNUのシノニム」というのが名前の由来だからだ。Cygnusが開発したWindows向けのGNUツール群＝Cygwinというわけだ。CygwinはまさにGNUオペレーティングシステムの一部のWindows移植版なのである。このへんのことはCygwinのFAQにも書いてある。余談だが、Cygwinの対抗馬としてはMinGWが出てくるが、こちらは「Minimalist GNU for Windows」の略だ

今、Linuxデスクトップ界には大きな変化が起きている。デスクトップ向けに利用される二大ディストリビューションであるUbuntuとFedoraにおいて、いずれもデフォルトのデスクトップ環境が従来型のGNOMEではなくなってしまったのだ。4月にリリースされたUbuntu 11.04にはUnityが、5月にリリースされたFedora 15にはGNOME3がそれぞれ搭載されている。（GNOMEそのものが激変してしまったのである！） Linuxデスクトップのシェアはとても小さい。このブログの読者を含め、ほとんどの人にとってはLinuxデスクトップにどのような変化が起きたとしても、そんなのはどうでもいいことだろう。だが、二大ディストリビューションで同時に変化が、しかもエポックメイキングな変化が訪れたのはただごとではない。筆者には、この変化が新たな時代の幕開けに思えて仕方がないのである。今日は、それぞ

Inspired by モテる女子力を磨くための4つの心得「オムライスを食べられない女をアピールせよ」等 こんにちは、自由恋愛マネジメントを専攻している日本男児ギークです。私は特許も秘密もありませんしタダですが、自由恋愛に関してはプロフェッショナル。今回は、モテるGNU女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2～3世代前のライセンスを適用するあえて2～3世代前のソフトウェアライセンスを使うようにしましょう。そして飲み会の場で好みのハッカーな男がいたら話しかけ、わざとらしくライセンスの互換性を確認してみましょう。そして「あ～ん！　このライセンス本当にマジでチョームカつくんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「ライセンスとか詳しくなくてぇ～！ ずっとコレ使ってるんですけどぉ～！ GPLと互換性がなくて使い

べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。

随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー

先月中旬の話になるが、マイコミジャーナルで紹介されていた「事例に学ぶ オープンソース知財セミナー2010」というセミナーに参加してきた。（主催はオージス総研）サブタイトルは「オープンソースに潜む法的リスクとその対策のヒント」という謳い文句であり、オープンソース独特の法的リスクの話が聞けるかも知れないと思い申し込んだ。だが、結果は見事に裏切られた！ ひとことで言うと、今回のセミナーはオープンソースのセミナーではなかった！というのが拙者の正直な感想である。あまりにも酷い内容だったと言って差し支えない。酷かったのは各々のプレゼンの質などではなく、その欺瞞に満ちたメッセージである。そのようなメッセージを放置すると、オープンソースに対する誤った知識が広まる恐れがあるので、本エントリにて批判させて頂こうと思う。 キナ臭い基調講演基調講演は本セミナーを主催したオージス総研の常務が行なった。滑り出しはオー

InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

MySQLで接続関係の問題、具体的に言うとAborted_clientsやAborted_connectionsというステータス変数が増え続けてしまうような現象に遭遇することがある。MySQLは、そういったネットワーク関係の問題をあまりたくさんログに記録しないようになっている。DoS攻撃などでログが溢れかえってしまわないようにするためだ。そんなとき、試して頂きたいのがmysqlsniffer。 mysqlsnifferとは。http://hackmysql.com/mysqlsniffer mysqlsnifferは、tcpdumpのようにネットワークインターフェイスからパケットをキャプチャするプログラムだが、tcpdumpとはMySQLのプロトコルを理解するという点で異なる。というかMySQLのプロトコル専門のキャプチャプログラムだ。OSのroot権限さえあれば、MySQLサーバーに対し

Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M

MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール

巷ではプログラミング言語の最速マスターが流行ってるので、MySQLも参戦。ただし管理者向け。 まずはダウンロードとインストールダウンロードサイト http://dev.mysql.com/downloads/ バイナリにはインストールパッケージ（Windows=MSI、Mac=DMG、Linux=RPMとか）とアーカイブ（*NIX=tar.gz/Windows=zip）があるけど、初心者は黙ってパッケージをチョイス。インストールはウィザードに従うだけ。英語だけどそこはガマン！ パッケージリポジトリがあるOSを使ってるなら、リポジトリからインストールするのもありだ。例えば、 shell> sudo yum install mysqlとか shell$gt; sudo apt-get install mysqlとか。これは楽チンだけどMySQLのバージョンがちょっと古くなるので注意。 もちろん

誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ