ときどき「Plugin 'FEDERATED' is disabled.」で検索してくる方がいらっしゃるようなので。 MySQL 5.1.26以降、FEDERATEDストレージエンジンはデフォルトで無効化されるようになりました。そのためMySQL 5.1のバイナリディストリビューションを使用している場合、mysqldの起動時に以下のようなNoteがエラーログに出力されます。これは正常な動作です。 090925 11:11:38 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 090925 11:11:38 [Note] Plugin 'FEDERATED' is disabled. InnoDB: The InnoDB memory heap is disabled InnoDB: Neither

MySQLのJDBCドライバ、Connector/Jの5.1.10がリリースされました。 今回のバグ修正はBug#47974の1件のみです。これは5.1.9におけるデグレードで、TCP 3306番以外の非標準ポートへの接続ができなくなるという致命的なものです。5.1.9を誤って使うことのないよう、注意してください。

出ました。今回はバグ修正が20件あり、そのうちパーティショニング機能に関するものが4件、レプリケーションに関するものが9件となっています。 今回のバグ修正のうちBug#28976、正確にはBug#28976を取り巻く状況は覚えておいた方が良いと思います。解説します。 ステートメントベースのバイナリログを使用している場合、一つのトランザクション内でトランザクション対応のテーブルとトランザクション非対応のテーブルを両方更新するには、次のようにしなければなりません。まず最初にMyISAMなどトランザクション非対応のテーブルを更新し、次にInnoDBなどトランザクション対応のテーブルを更新します。 なぜこうしなければならないのかというと、InnoDB → MyISAMの順番で更新を行った場合、MyISAMテーブルの更新内容が他のコネクションから即座に見えるようになる一方で、この更新内容はCOMMI

MySQLのJDBCドライバ、Connector/Jの5.1.9がリリースされました。 今回は11件のバグが修正されています。前回のようなセキュリティ関連の修正は無いようです。件数が少ないので一通りバグレポートを読んでみましたが、あくまで個人的な意見として、現在システムが問題なく稼動しているのであればアップデートの必要は無いと思います。 5.1.7のリリースから5.1.8までは9ヶ月もかかっていたのですが、5.1.8から5.1.9は2ヶ月に短縮されました。この調子で四半期に一度くらいはメンテナンスリリースが続くと良いですね。

今回はデータベースのネタをお休みして、噂のプログラミング言語Noopを試してみました。 速報：グーグルが新言語「Noop」を公開。JavaVMで動作 − Blog on Publickey JVMで動作する新言語「Noop」- Google開発者らによる新プロジェクト | エンタープライズ | マイコミジャーナル 以下、NoopでHello World!を動かすまでの手順です。 JDKのインストール NoopはJava VM上で動作するので、まずJava SE Development Kit(JDK)をインストールします。 インストールが済んだら、C:\Program Files\Java\jdk1.6.0_16\binにパスを通しておきます。 TortoiseHgのインストール NoopはMercurialでバージョン管理されているので、Windows用のクライアントとしてTortois

出ました。MySQL 5.4系列にも、このバージョンからInnoDB Pluginが同梱されるようになりました。 元々MySQL 5.4はInnoDBの性能向上が主な改善点だったのですが、MySQL 5.1でもInnoDB Pluginを使えるようになったので特長が薄れてしまっています。とはいえ、MySQL 5.4には他にも改善点があります。私が注目しているのは以下の二点です。 SQLオプティマイザの強化。Batched Key Accessというテクニックにより、いくつかのテーブル結合が高速化されます。 準同期レプリケーションインタフェースのサポート。スレーブ側に更新データが届いたことを保証できるため、レプリケーションをDRBDのような可用性向上のための手段として用いることができるようになります。ただしこれはインタフェースのみのサポートであり、準同期レプリケーション自体は本体とは別個にプ

少し前に話題になった、MySQLのRethinkDBストレージエンジンを試してみました。 RethinkDBはSSD向けに最適化されたMySQL用ストレージエンジン SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現 − Blog on Publickey RethinkDBは、SSD向けに最適化されているところが特長です。 インストール時の注意事項 RethinkDBはMySQL 5.1のプラグイン形式を採用しているので、インストール自体はinstall pluginコマンドを打つだけです。ただし、プラグインがglibcのバージョン2.7以上を要求しているため、使用できるディストリビューションがかなり限られています。 例えば、Red Hat Enterprise Linux 5(CentOS 5)のglibcは2.5なので動かすことができませ

X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (2009/03/25) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (本記事) MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケ

出ました。今回は仕様変更が4件、バグ修正が49件あります。そのうちレプリケーション関連で仕様変更が1件とバグ修正が4件、パーティショニング関連でバグ修正が3件あります。 今回のリリースから、配布物になんとInnoDB Pluginが含まれるようになりました。もちろん従来のInnoDBストレージエンジンも残されており、選んで使えるようになっています。InnoDB Pluginのバージョンは1.0.4で、これはまだベータ版とされています。 従来のInnoDBストレージエンジンと比べて、InnoDB Pluginには以下の機能強化が施されています。このうちいくつかは本ブログでもすでにご紹介しているものです。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCH

WindowsでMySQL 5.1をちょっと試してみたいという方向けのインストール手順書です。Webで検索するとMySQLのインストール手順書はたくさん見つかるのですが、今回ご紹介する手順にはこんな特長があります。 インストール時点でMySQLの知識が不要 起動・停止が簡単 レジストリを汚さない サービスを作らない アンインストールが簡単 サンプルデータベース付き MySQL ZIP版をダウンロードする MySQLのダウンロードサイトでは、Windows用のバイナリとして以下の3種類が用意されています。 普通はMSI版を利用するのですが、ちょっと試してみたいだけという場合はZIP版(Without installer (unzip in C:\))の方が便利です。今回はZIP版をダウンロードします。 アーカイブをC:ドライブ直下に展開する ダウンロードしたmysql-noinstall-5

データベース負荷テストツールまとめの第2回です。 前回はTPC-Bベース、TPC-Wベースのものから6つのツールをご紹介しました。今回はTPC-Cベースのものについて見ていきたいと思います。 tpcc-mysql 対応RDBMS：MySQL 対応OS：Linuxなど 言語：C 作者：Percona Inc. ライセンス：不明(ライセンスに関する記述がない) トランザクション仕様：TPC-Cベース URL：https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql tpcc-mysqlはMySQLのコンサル会社であるPercona Inc.によって開発されたベンチマークツールで、TPC-Cをベースとしています。TPC-Cの仕様やtpcc-mysqlについては以前のエントリで詳しく扱っているので、そちらをご覧ください。 tpc

出ました。 今回は37件のバグ修正があり、そのうち7件がレプリケーション関連、さらにそのうち2件がImportant Changeになっています。Important Changeの2件について、内容を簡単にご紹介します。 RESET MASTER文とRESET SLAVE文が、SHOW SLAVE STATUSにおける以下の値をリセットするようになりました。Last_IO_Error、Last_IO_Errno、Last_SQL_Error、Last_SQL_Errno。(Bug#44270) レプリケーションのSLAVE側において、以下のエラーが無視されるようになりました。ER_LOCK_WAIT_TIMEOUT、ER_LOCK_DEADLOCK、ER_XA_RBDEADLOCK。これらのエラーはMASTER側において同時並行性の問題によって起こるものであり、SLAVE側で同じエラーを再

Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS：PostgreSQL 対応OS：Linuxなど 言語：C 作者：石井達夫氏 ライセンス：独自(BSDライセンスに近い) トランザ

これまで数回に渡ってInnoDB Pluginのエントリを書いてきたので、InnoDB Pluginを試してみたくなったという方がいるかもしれませんね。そこで本日はそのような方がいることを期待して、InnoDB Pluginを組み込んだMySQLの簡単なビルド手順をご紹介します。本手順には以下のような特長があります。 MySQLの長いconfigureオプションを覚えなくてよい。というかMySQLが何なのか知らなくてもできるレベル RPMができるのでインストール/アンインストールが簡単。試してみて飽きたらアンインストール可能 今後バージョンが上がってもおそらく手順は変わらない コピペでおｋ 対象OSはRed Hat Enterprise Linux 5とCentOS 5です。 一般ユーザでrpmbuidコマンドが使えるようにする(初回のみ) $ cd $ echo "%_topdir $H

MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次

出ました。MySQL 5.1.36には機能追加・変更が4件、バグ修正が50件あります。このうちサーバがクラッシュするバグが11件、またレプリケーションに関するImportant Changeが2件出ており、いつもより多い印象を受けます。 今回のポイントはBug #44352です。cp932およびsjisの環境で、upper()、lower()ファンクションが誤動作するというバグです。 mysql> create table t (c1 varchar(10)) character set cp932; Query OK, 0 rows affected (0.02 sec) mysql> insert into t (c1) values ('ビタミン'); Query OK, 1 row affected (0.00 sec) mysql> select upper(c1) from t

InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに

出ました。 今回は This release does not differ from 5.4.0 except that binary distributions are available or all MySQL-supported platforms, including Windows binaries with scalability improvements enabled. ということで、これまで一部のプラットフォーム、しかも64bit版でしか提供されていなかったバイナリディストリビューションがすべてのプラットフォームに対して用意されたところがポイントです。先日のエントリの補足でInnoDB Pluginのビルド手順をまとめていたのですが、MySQL 5.4が気軽に使えるならこちらの方が良いですね。

Changed jobs, now at Monty Program AB Sergey Petrunia氏はMySQLのクエリオプティマイザの開発者です。参考のためにカンファレンス資料をいくつかリンクしておきます。 MySQL Conference & Expo 2009のセッション内容と配布資料(PDF) MySQL Conference & Expo 2008のセッション内容と配布資料(PDF) クエリオプティマイザは現在でもかなり開発が活発なコンポーネントです。今後の動向が気になりますね。

データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて