MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
SQLインジェクションとは何か？その正体とクラッキング対策。
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
MySQLでVisual Explain
MySQL Workbenchの次期バージョンである6.0のベータ版が公開された。例によってMySQLのダウンロードサイトで公開されているので、新機能が気になる人はゲットして試してみて頂きたい。見た目が若干今流行りのフラットデザインっぽくなってシャレオツ（笑）な感じに仕上がってる。 ベータ版が公開されたのを記念して、Workbenchに搭載されているナイスな機能について紹介したい。そう、Visual Explainだ。Visual Explainとは読んで字のごとく、SQLの実行計画を視覚的に表現したものだ。SQLが複雑になると、その実行計画は理解し辛いものとなる。 今日はVisual Explain基本的な使い方と、それがどのように見えるかを紹介しようと思う。 Visual Explainを使用するには、対象のMySQLのバージョンが5.6以上であり、なおかつWorkbenchのバージョ
はてなのデザイン変更はイノベーションか。
何やらはてなの社長であるjkondo氏がTwitterでおもしろ発言をして話題になっている。 この発言ははてなブックマークの全面的なリニューアルに対する批判的な意見が多いことを受けてのものだ。ただし発言自身はjkondo氏自身のものではなく、増田（はてなAnonymousダイアリー）からの引用なので、厳密にはjkondo氏の言葉ではない。しかし当然ながらjkondo氏が気に入ったり共有したかったフレーズだから引用されたものであろう。（真相は違うかも知れないが、少なくともそういう印象は与えている。） 変化には抵抗勢力（jkondo氏曰く老害）がつきものだ。多数の反対意見は単に変化への拒否反応という可能性もあるが・・・果たしてこのデザイン変更はイノベーションと呼ぶにふさわしいものだろうか。 Short answer もう少し噛み砕いた答えおっと、失礼。少々表現が乱暴になってしまった。それではな
環境省がクソのようなガイドラインを策定しようとしている件
今回はコンピューターの話ではないので、興味がない人はスルーして頂きたい。 環境省が地震などの災害時に被災者が避難所や仮設住宅にペットを持ち込むことができるようにガイドラインを作成しようとしているらしいが、いくらなんでもこれは止めたほうがいいのではないか。こんなことを政府が言い出すのは本当に馬鹿げている。環境省には現実が見えていないのだろうか？あんまりにも腹が立ったので問題点を指摘しておきたいと思う。 避難所がどうなるか最大の問題点は、ペットが持ち込まれた避難所がどうなるかということだ。災害時、避難所はただでさえ人口が過密になる。その上水や食料だって心配だ。人々はストレスに苛まれ、人同士のトラブルも頻発することになる。そこへさらに争いのタネを持ち込もうというのは狂気の沙汰と言える。 災害時、現場はどうだったかはウィキペディアの記事が参考になる。みんな余裕などない。未曾有の災害に遭ったらどうな
書評：「7つのデータベース 7つの世界」
訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。 正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。 何が問題なのか
紹介：【書籍】SQLアンチパターン
リレーショナルデータベースの父、エドガー・F・コッド氏が論文を発表したのは1970年。私が生まれる前の話である。そしてSQLがANSI標準になったのが1986年。RDBMSを、そしてSQLを使ったシステム開発は常に主流で在り続けたと言っても過言ではない。そんな歴史のあるSQLであるが、未だに多くの人はSQLを使いこなせて居ないように見える。 SQLはとても奥が深い。ソートやトランザクションが使用出来るおかげで、リレーショナルモデルを無視して単なるデータの入れ物として使ってもそれなりに便利だったりする。だが、それが今現在多くの悲劇を生んでいる原因でもある。多くの人が同じようにSQLを理解せず、そのため多くの人が同じ悲劇に見舞われる。そう、それがアンチパターンである！ 今回紹介するSQLアンチパターンは、洋書SQL Antipatternsの邦訳版だ。私は元々英語版のファンでであり、人々が陥り
開発スピードアクセル全開ぶっちぎり！日本よ、これが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におけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
いますぐWindowsを捨ててデスクトップでGNU/Linuxを使う10+の理由
言及するのが既に周回遅れ気味だが、いますぐコマンドプロンプトを捨てて、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」の略だ
lessでソースコードに色をつける
シェルの操作中「テキストファイルをちょこっと覗きたいな」と思ったときに抜群に便利なlessコマンドであるが、普段綺麗に色付けされたソースコードを見慣れていると、モノクロのソースコードの見づらさに愕然としてしまう。結局lessを終了して他のエディタで開きなおすことになるのだが、lessでソースコードに色付け（シンタックスハイライト）できれば便利なのになーっ！と思ったことはないだろうか。そう、あるんです！lessでシンタックスハイライトする方法はあるんです！というわけで、今日はその方法を紹介しよう。 GNU Source-highlight結論から言うと、今日紹介する方法はGNU Source-highlightを使う。GNU Source-highlightを使えばイッパツだ。なのでまずGNU Source-highlightをインストールしよう。UbuntuやFedoraならリポジトリにあ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
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だが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ
「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
