MySQL 5.5 Update #denatech
Upcoming SlideShare
Loading in...5
×
 

MySQL 5.5 Update #denatech

on

  • 9,924 views

Dena Technology Seminar #2 で使用したスライドです。 http://engineer.dena.jp/2010/06/dena-technology-seminar-2.html

Dena Technology Seminar #2 で使用したスライドです。 http://engineer.dena.jp/2010/06/dena-technology-seminar-2.html

Statistics

Views

Total Views
9,924
Views on SlideShare
9,268
Embed Views
656

Actions

Likes
9
Downloads
134
Comments
0

7 Embeds 656

http://engineer.dena.jp 636
http://d.hatena.ne.jp 8
http://theoldreader.com 4
http://localhost 3
http://webcache.googleusercontent.com 2
http://www.newsblur.com 2
http://www.onlydoo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MySQL 5.5 Update #denatech MySQL 5.5 Update #denatech Presentation Transcript

  • MySQL Update What's cool and new in MySQL 5.5 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  • 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。 ● 現時点( 2010 年 6 月)の段階では、 MySQL 5.5 は マイルストーンリリース( β 版)です。機能や実装 については、予告無く変更される場合がありますので ご注意ください。
  • 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – http://www.google.com/profles/mikiya.okuno ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに – 現在は日本オラクルに在席。
  • MySQL 5.5 の新機能( 5.1 との差分) ● MySQL 5.4 – InnoDB の性能改善 – DTrace Probe の追加 – SHOW ENGINE INNODB STATUS の拡張 – 設定値のデフォルト値を変更 ● MySQL 5.5 – InnoDB の機能・性能改善( InnoDB Plugin ) – メタデータのロック改善 – Semi-Synchronous Replication – 4 バイト UTF-8 対応 – RANGE/LIST COLUMNS パーティショニング – PERFORMANCE_SCHEMA – XML 機能の拡充( LOAD XML 文など) – SIGNAL/RESIGNAL など多数
  • InnoDB 性能改善!!
  • InnoDB と MySQL 各バージョンの対応 ● MySQL 5.1 – InnoDB Plugin 1.0 が利用可能。 ● MySQL 5.1.46 で GA 版に。 – 既存のビルトイン InnoDB がデフォルト。 ● MySQL 5.4 – ビルトイン InnoDB をベースにして性能改善。 – 改善の内容は InnoDB Plugin に移植された。 ● MySQL 5.5 – InnoDB Plugin 1.1 がビルトインに。
  • InnoDB Plugin 1.0 ● Fast Index Creation ● データ圧縮 ● INFORMATION_SCHEMA の追加 ● 使い易さの改善 – オンライン変更出来るパラメータの増加 – TRUNCATE TABLE による .ibd ファイルの再作成 – etc ● 性能改善 – クラッシュリカバリ時間の短縮 – グループコミット – I/O の多重化 – etc
  • InnoDB Plugin 1.0 の使い方 ● MySQL 5.1.46 以降で利用可能。 ● my.cnf に以下の 2 行を追加して再起動するだけ。 – ignore-builtin-innodb – plugin- load=innodb=ha_innodb_plugin.so;innodb_trx=h a_innodb_plugin.so;innodb_locks=ha_innodb_pl ugin.so;innodb_lock_waits=ha_innodb_plugin.so; innodb_cmp=ha_innodb_plugin.so;innodb_cmp_ reset=ha_innodb_plugin.so;innodb_cmpmem=h a_innodb_plugin.so;innodb_cmpmem_reset=ha_ innodb_plugin.so ● 既存のデータファイルは互換性あり。
  • Fast Index Creation ● セカンダリインデックスの作成が高速化 – プライマリキーの作成・削除には影響なし ● 特別な書式はなし – ALTER TABLE .. ADD INDEX や CREATE INDEX が単純 に高速化 ● 現在の挙動 – 新しい定義のテーブルを作成してデータを全てコピー。 – コピー完了後に古いテーブルを破棄。 – コピー中、テーブルは読み取り専用に。 ● 高速化した挙動 – 該当のインデックスツーリーだけを作成。 – 作成中、テーブルは読み取り専用に。 – 時間が大幅に短縮。
  • Fast Index Creation - つづき 従来の動作 PK Fast Index Creation = セカンダリ クラスタ インデックス PK インデックス = セカンダリ クラスタ インデックス インデックス すべてコピー 追加の セカンダリ ここだけ PK 追加の インデックス 新規作成 = セカンダリ クラスタ セカンダリ インデックス インデックス インデックス
  • データ圧縮 ● 行ごとにデータを圧縮 – データサイズ縮小 – I/O 減少 ● 使い方 – innodb_fle_format=Barracuda – innodb_fle_per_table – CREATE TABLE (...) ENGINE INNODB ROW_FORMAT=Compressed; ● 仕組みとか性能とか – sh2 氏の日記を見よ!! ● http://d.hatena.ne.jp/sh2/20090628 ● http://d.hatena.ne.jp/sh2/20090705
  • もうひとつの新フォーマット DYNAMIC!! ● TEXT が完全にページ外に。 – 1 行あたり 8KB までという制限が緩和。 – 元々は先頭の 768 バイトをページ内に格納。 ● 11 カラム目でエラーになる可能性があった。 ● 使い方 – innodb_fle_format=Barracuda – innodb_fle_per_table – CREATE TABLE (...) ENGINE INNODB ROW_FORMAT=Dynamic;
  • グループコミット ● InnoDB Plugin 1.0.4 において、「バイナリログを有効に するとグループコミットが効かなくなる問題」が修正 – 参考:  InnoDB Plugin 1.0.4 - InnoDB 史上極めて重要な リリース - open database life – http://opendatabaselife.blogspot.com/2009/08/inno db-plugin-104-innodb.html
  • クラッシュリカバリ時間の短縮 ● 鍵の本 P.364 コラム「クラッシュリカバリがいつま でも終わらない」参照 ● リカバリ時に用いるリストの構造を改良 ● とあるテストではリカバリ時間が 30 分の 1 以下に短 縮という報告あり。 – 参照: InnoDB recovery is now faster…much faster! http://blogs.innodb.com/wp/2010/04/innodb- performance-recovery/
  • InnoDB Plugin 1.1 ● 性能改善 !! – 複数のバッファプールインスタンス – 複数のロールバックセグメント – fush_list のロックを独立 – パージスレッドが独立 – random delete の性能改善 – Linux におけるネイティブ非同期 I/O のサポート – PERFORMANCE_SCHEMA のサポート
  • MySQL Conference & Expo ● http://en.oreilly.com/mysql2010/public/schedule /proceedings – 2010 年 4 月開催。 – スライドが公開されている。 – ベンチマーク結果など多数収録。 – MySQL 5.5 + InnoDB Plugin 1.1 の改善が目の当た りに!!( Mikael Ronstrom のスライドは必見)
  • 4 バイト UTF8 !!
  • MySQL 5.5 における UTF-8 ● MySQL 5.1 の UTF-8 – 基本多言語面( BMP )のみをサポート – 1 文字あたり最大 3 バイトまで – 文字コード名は utf8 – 4 バイトに割り当てられた文字を使いたい場合に は、 binary 文字コードで代用。(ソート順が・・・) ● MySQL 5.5 の UTF-8 – 追加面をサポート。 Unicode で定義されている漢字をす べて利用可能に!! – 以前のバージョンと互換のある文字コードと 4 バイト対応 の文字コードの二刀流 ● utf8: 以前と互換性あり ● utf8mb4: 4 バイト対応
  • Semi- Synchronous レプリケーション!!
  • レプリケーションの問題点と解決法 ● 非同期なのでマスターがクラッシュするとマスターに しか存在しないデータが発生する。 – スレーブの昇格が難しい。 ● 一部のデータが失われる。 ● マスター復旧後、最悪データのコピーをしなければ いけない。 ● Semi-Synchronous Replication では、マスターが COMMIT をしてクライアントへ応答を返す前に、最 低でもひとつのスレーブに更新を転送する。
  • MySQL 5.1 のレプリケーション
  • Semi-Synchronous レプリケーション
  • COLUMNS PARTITIONING !!
  • 今までと何が違うのか? ● パーティション式を通じ ● カラムの値をそのまま評 て結果を整数値に変換。 価。 ● DATE=>TO_DAYS() ● DATE=> 直接比較 ● 単一の値。 ● 複数の値を利用可。
  • RANGE COLUMNS パーティショニング例 1 create table t1 ( id int unsigned not null auto_increment, year_ smallint not null, month_ tinyint unsigned not null, primary key(id,year_,month_) ) partition by range columns (year_,month_) ( partition p1 values less than (2000, 4), partition p2 values less than (2001, 8), partition p3 values less than (2004, 11), partition p4 values less than (2008, 2), partition p5 values less than (2010, 3), partition p6 values less than (2011, 4), partition p7 values less than (maxvalue, maxvalue) );
  • EXPLAIN - RANGE COLUMNS mysql> explain partitions -> select * from t1 -> where year_ = 2008G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 partitions: p4,p5 type: index possible_keys: NULL key: PRIMARY key_len: 7 ref: NULL rows: 8193 Extra: Using where; Using index 1 row in set (0.00 sec)
  • RANGE COLUMNS パーティショニング例 2 create table t2 ( id int unsigned not null auto_increment, mydate date not null, primary key(id,mydate) ) partition by range columns (mydate) ( partition p1 values less than ('2000-04-01'), partition p2 values less than ('2001-08-01'), partition p3 values less than ('2004-11-01'), partition p4 values less than ('2008-01-01'), partition p5 values less than ('2010-03-01'), partition p6 values less than ('2011-04-01'), partition p7 values less than (maxvalue) );
  • LIST COLUMNS パーティショニング例 create table t3 ( id int unsigned not null auto_increment, gender char(10), flag tinyint unsigned not null, primary key (id, gender, flag) ) partition by list columns (gender, flag) ( partition p1 values in (('male', 0)), partition p2 values in (('female', 0)), partition p3 values in (('male', 1)), partition p4 values in (('female', 1)), partition p5 values in (('unknown', 0), ('unknown',1)) );
  • DTrace!!
  • DTrace Probes!! ● Solaris 10 で搭載された機能。 – Solaris/Mac OS X/FreeBSD で利用可能 ● カーネル / ユーザープロセスをトレース。 ● プローブと呼ばれる観測点を対象のプログラムに動的 に埋め込む。 ● プローブの種類に応じたプロバイダ。 ● D 言語と呼ばれるプログラムで操作 ● 参考 – D 言語基本文法最速マスター( DTrace のほう) http://nippondanji.blogspot.com/2010/02/ddtrace.html – DTrace による MySQL 解析ことはじめ http://www.slideshare.net/nippondanji/dtracemysql-3588894
  • PERFORMANCE SCHEMA !!
  • PERFORMANCE_SCHEMA とは。 ● DTrace に似た情報収集と表示の仕組み。 ● プロファイリングに利用可能。 – 情報は相当マニアックなので開発者向けかも。 ● P_S のアーキテクチャー – ストレージエンジンとして実装 – ソースコード中の随所にしかけられた「 Instrument 」か ら情報を収集。 – 統計情報は P_S 内に保管される。 – P_S ストレージエンジンを通じて、 SELECT によりデー タを取得。 ● 各種集計関数が利用可能 – P_S の操作は P_S テーブルを UPDATE することで行う。
  • 使い方。 ● MySQL 5.5.3 以降 ● my.cnf の [mysqld] セクションに performance_schema と書いて再起動。 ● PERFORMANCE_SCHEMA データベースのテーブル にアクセスするだけ。 – SETUP_* テーブルで ON/OFF を切り換え可能。
  • P_S の仕組み SELECT ... FROM PERFORMANCE_SCHEMA.EVENTS_WAITS_CURRENT...; SQL でアクセス 行データとして統計情報を取得 PERFORMANCE mysqld 内の随所に SCHEMA 仕掛けられた Storage Engine Instruments
  • SIGNAL !! RESIGNAL !!
  • SIGNAL ● ストアドルーチン内で自発的にエラーを発生させる。 delimiter // create trigger t4_bi before insert on t4 for each row begin if NEW.a >= 100 then signal SQLSTATE VALUE '42000' set MESSAGE_TEXT = 'The column `a` value should be less than 100.'; end if; end;// delimiter ;
  • RESIGNAL ● HANDLER 内で SIGNAL を再度発生させる。 DROP TABLE IF EXISTS xx; delimiter // CREATE PROCEDURE p () BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN SET @error_count = @error_count + 1; IF @a = 0 THEN RESIGNAL; END IF; END; DROP TABLE xx; END// delimiter ; SET @error_count = 0; SET @a = 0; CALL p();
  • MySQL 5.5 総評!!
  • MySQL 5.5 は正しい進歩 !! ● 性能が向上しつつ利便性も向上 – 日本人待望の 4 バイト UTF-8 。 – InnoDB の飛躍的な性能改善。 – Semi-Synchronous Replication – パーティショニングの改善 – DTrace/PERFORMANCE_SCHEMA – など 全てのユーザーに自信を持って お勧め出来るバージョン!!
  • トラブル シューティング!!
  • MySQL の開発目標 1. 安定性 トラブルなんて 2. パフォーマンス 起きるの? 3. 使いやすさ
  • 起きるんです。。。 バックアップ不具合 OS のエラー Table is full Out Of Memory MySQL Enterprise Monitor 接続エラー テーブルコラプション リストア出来ない デッドロック レプリケーション停止 文字化け サーバが起動しない 性能劣化 スレーブの遅延 起動に時間がかかる クラッシュ クエリの実行結果がおかしい ログインできない Too many connections データロスト SQL インジェクション
  • トラブルに打ち勝て!! ● トラブルとは想定外の事象 ● ゆえにトラブルシューティングにセオリーなし!! ● 唯一の対策は、 MySQL をよく知ること。 – 仕組み – 仕様(本来あるべき姿) – ソースコード 彼(かれ)を知り己(おのれ)を知れば、 百戦しても殆(あやう)からず。
  • トラブルシューティングの心構え! ● 仕様を理解する。 – 何が正常で何が異常なのか? – どのような仕組みになっているのか? ● 自分でやってみる。 – 再現が出来ればこちらのもの! – 素早く再現環境を作成する能力が必要。 ● ソースコードを読む。 – 最終的にはソースコードに全てが書いてある。 ● OS に詳しくなる。 – 問題が OS からやってくることも多い。
  • そして・・・ つづきは書籍にて!! 「エキスパートのための MySQL[ 運用 + 管理 ] トラブルシューティングガイド」
  • Q!! & A!!