今年も残すところあとわずかとなった。2010年もIT業界にとっては変化の多い一年だったが、皆さんにとっては良い年だっただろうか？既に何度かMySQL 5.5の新機能については取り上げたが、ついに正式版がリリースされたということでここで改めて新機能を解説し、今年最後のエントリを締めくくろうと思う。 MySQL 5.5にはこれでもかっ！というぐらい新機能が追加されている。しかもいずれもナイスなものばかりだ。一般的には、ソフトウェアに新機能が追加されると重くなったり安定性が低下する事例が後を絶たないのだが、MySQL 5.5に関してはそのようなことは全くないので安心して利用して頂きたい！ InnoDBの大幅な改善種々ある改善点の中でも特に目をひくのがInnoDBストレージエンジンへの改良だ。実は、InnoDBはMySQL 5.1が最初にリリースされたときから、2回アップデートが行われている。My

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

リファレンスの抜粋ですが、最近心臓止まりかけた件に関連するのでmemoっておく。 ● --replicate-do-table=db_name.table_name 指定したテーブルに対するクエリのみレプリケーションを限定するようスレーブスレッドに指示する。複数のテーブルを指定するには、コマンドを複数回、各テーブルに 1 回ずつ使用する。これは、--replicate-do-db とは対照的に、データベースをまたがった更新用に使用する。この一覧の後の説明を参照のこと。 上記のようにガチでテーブル名を指定するような方法と、 ● --replicate-wild-do-table=db_name.table_name 指定したワイルドカードパターンに一致するテーブルに対するクエリのみを、レプリケーションすることをスレーブスレッドに指示する。複数のテーブルを指定するには、コマンドを複数回、各テー

ちょっとやる機会があったのでメモ。 前提 サーバA（元々マスター。現スレーブ。新サーバと交換した） サーバB（元々スレーブ。昇格して現マスター） サーバC（スレーブ） ※my.cnfにはMasterの情報は書かない派。 サーバAを再度マスターに、サーバBをスレーブに落とす。 旧サーバA、サーバB、Cともに稼働年数同じぐらいで、「逝くときはぁ一緒だよーっ☆」されても困るので マスターに更新がかからないように、プログラムなど止めておく 手順 # サーバBのプロセスが流れていないか確認 svB# mysql mysql> SHOW PROCESSLIST; # 念の為サーバBの更新停止 mysql> FLUSH TABLES WITH READ LOCK; ※ロックが外れるのでmysqlから出ない事。 mysql> SHOW MASTER STATUS\G;; ※Fileの値とPositionの

MySQLのrootのパスワードを忘れてしまった場合でも、以下の 対処をすることでパスワードの変更を行うことが出来ます。 (1)MySQLサービスの停止 ●Windows 「コントロールパネル」→「管理コンソール」→「サービス」の画面を起動して、 「MySQL」サービスを停止してください。 ●LINUX 以下のコマンドを実行して、デーモンを停止してください。 #/etc/init.d/mysql stop (2)パスワード無しでログイン出来るようにMySQLを起動 ●Windows コマンドプロンプトを起動して以下のコマンドを実行してください。 mysqld-nt --skip-grant-tables ※応答待ちで止まりますが、そのままで問題ありません。 ●LINUX 以下のコマンドを実行して、MySQLを起動してください。 #mysqld_safe --skip-grant-table

MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -

InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を

2012年6月のエントリの続きです。前回は同期レプリケーションによるネットワーク遅延のある環境において、MySQLの性能がどの程度低下するのかということを確認しました。その中でも特にsync_binlogが1に設定されている場合、性能が大きく低下するということが分かりました。参考としてAmazon RDSのマルチAZデプロイメントにおいては、性能と信頼性のトレードオフを考慮した結果、sync_binlogがデフォルトで0に設定されているということを調査しました。 タイトルでネタバレしていますが、MySQLの次期バージョン、MySQL 5.6でこのsync_binlog=1の性能が大きく改善します。前回と同じ負荷テストをMySQL 5.5.25からMySQL 5.6.6-labsに差し替えて行った結果を、以下に示します。 前回のMySQL 5.5.25と異なり、sync_binlog=1にお

待望のMySQL 5.6が正式にリリースされた。正式版の最初のバージョンは5.6.10である。コミュニティ版（MySQL Community Server）は下記のページからダウンロードできるので、ぜひ今すぐダウンロードして頂きたい。 MySQL Downloads MySQL 5.6のリリースにあわせて、GUIツールであるMySQL Workbenchやドライバも新しいバージョンがリリースされており、MySQL 5.6対応となっている。それらの周辺ソフトウェアもチェックして頂けると幸いである。 新機能について正式版の機能はリリース候補版の頃から特に変更はない。（リリース候補版まで到達したということは、正式版の機能セットは固まったということであり、大きな機能の変更はないことを意味するからだ。）なので新機能については、リリース候補版が出たときに書いたエントリを参照して頂きたい。 漢(オトコ)