Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

MySQL 5.6新機能解説@dbtechshowcase2012

•
•
Mikiya Okuno
Mikiya Okuno
1 of 58
MySQL 5.6 新機能解説 ＠ db tech showcase 2012 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
免責事項 ● 本プレゼンテーションにおいて示されている見解は、私自身 の見解であって、オラクル・コーポレーションの見解を必ず しも反映したものではありません。ご了承ください。
自己紹介 ● MySQL サポートエンジニア – 2000 年にサン・マイクロシステムズ入社 ● 主にハードウェアのサポートを担当 – 2007 年に MySQL KK へ転職 ● 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 – サポート一筋 12 年 ● 日々のしごと – MySQL トラブルシューティング全般 – Q&A 回答 など ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
MySQL 5.6 新機能ダイジェスト
MySQL 5.6 リリース候補版登場！ ● MySQL Connect 2012 において MySQL 5.6 リリース候 補版（ RC ＝ Release Candidate ）が発表された。 – MySQL Connect は Oracle OpenWorld と並んで US で 開催されたイベント ● リリース候補版≒ Feature Fix!! – 約 200 の Worklog に対応 – 機能は開発版（ DRM ＝ Development Milestone Release ）で徐々に追加するという開発モデル ● MySQL 5.5GA （２０１０年 12 月）以来のメジャーアップ デート – マイナーバージョンではありません。 – 正式版（ GA ＝ General Availability ）までしばらくお待ち を！！
レプリケーション ● GTID – Global Transaction ID – スレーブの自動的な昇格が可能に！！ ● クラッシュセーフなスレーブ ● 遅延レプリケーション ● mysqlbinlog コマンドによるバイナリログのバックアップ ● スレーブが使用する NIC の指定 ● マルチスレッドスレーブ – スレーブ SQL スレッドが複数のスレッドで実行可能に！！ – DB 単位での並列処理
InnoDB ● インデックスの追加と削除がオンラインで可能に！！ ● FULLTEXT インデックスのサポート ● .ibd ファイル（テーブル単位のデータファイル）のエクス ポートとインポート – ファイルのコピー＋ α の操作他のサーバーへ移行可能！！ ● ページサイズの指定（ 16KB→4KB/8KB/16KB ） ● インデックス統計情報の改善 ● START TRANSACTION READ ONLY ● ログサイズの上限が増加（ 4GB→512GB ） ● デッドロック検出機能の改善 ● CPU スケーラビリティの向上 ● バッファプールの内容を保存、再起動時に暖機運転 ● memcached インターフェイス
オプティマイザ ● サブクエリの高速化 – semi-join 最適化 – FROM 句のサブクエリの評価遅延 ● EXPLAIN の改善 – SELECT 以外の DML へ対応 ● 各種アルゴリズムの改善 – ORDER BY ... LIMIT の効率化 – Batched Key Access Join – Index Condition Pushdown – Multi Range Read ● オプティマイザトレース
パーティショニング ● パーティションをテーブル同士で交換可能に ● パーティション数の上限増加（ 1024→8192 ） ● 明示的なパーティションの指定 ● テーブルロックの改善 – テーブルロックの対象がテーブル全体からパーティション 単位に
その他 ● セキュリティ関係 ● ジャイアントロックの解消 ● ホストキャッシュの参照 ● OpenGIS 対応 ● 小数点以下の秒への対応 ● ストアドルーチンにおけるエラーハンドリングの改善 – Diagnostic Area 参考：開発スピードアクセル全開ぶっちぎり！日本よ、これが MySQL 5.6 だッ！！ http://nippondanji.blogspot.com/2012/10/mysql-56.html
時間の都合上 すべてをお見せすることが できません。
あまりにもたくさん 目覚しい新機能が あるからです！
レプリケーション
MySQL のレプリケーション アプリケーション 1. COMMIT 4-1. send_ok 接続 スレーブ接続 I/O SQL スレッド 2. スレッド スレッド スレッド バ イ 更 ナリ 5. リレーログ更新 3. テーブル 新 ロ 4-2. バイナリログ 更新 グ 送信 6. 更新の適用 ストレージ バイナリログ リレーログ ストレージ エンジン エンジン マスター スレーブ
MySQL のレプリケーション（つづき） マスター / スレーブ マルチマスター Master Slave Master Master + Slave + Slave カスケード Master Slave Slave 循環型 1:N Master Slave + Slave Master Master + Slave Slave Slave Master + Slave
MySQL 5.5 のおさらい 準同期レプリケーション COMMIT 完了時にはスレーブへ更新が到達している ることが保証されている。 アプリケーション → HA （高可用性）として利用可能か！？ 1. COMMIT 7. send_ok 6-1-2. ack 6-1-1. ack 接続 スレーブ接続 I/O SQL スレッド 2. スレッド スレッド スレッド バ イ 更 ナリ 5. リレーログ更新 3. テーブル 新 ロ 4. バイナリログ 更新 グ 送信 6-2. 更新の適用 ストレージ バイナリログ リレーログ ストレージ エンジン エンジン マスター スレーブ
準同期レプリケーションによる HA ● できるようになったこと ● できなかったこと – マスタークラッシュ時に – スレーブの昇格 スレーブにデータが残 ● 1:N 構成 る – スレーブのクラッシュへ – 1:1 構成 の対応 ● クラッシュ時は再 セットアップ
Global Transaction ID ● トランザクションを一意に識別することができる ID – UUID: トランザクション ID の形式で表現される – 例） 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:123456 ● トランザクション ID はシーケンス – 1:N 環境で、どのスレーブが最も進んでいるか一目瞭然！ ● MASTER_AUTO_POSITION = 1
Global Transaction ID （つづき） mysql> show binlog events in 'mysql-bin.000002'G 〜 省略 〜 *************************** 3. row *************************** Log_name: mysql-bin.000002 Pos: 151 Event_type: Gtid Server_id: 1 End_log_pos: 199 Info: SET @@SESSION.GTID_NEXT= '095E0FF8-18AF-11E2-9E7C- 5C260A2AA986:1' 〜 省略 〜
Global Transaction ID （つづき） mysql> SHOW SLAVE STATUSG *************************** 1. row *************************** 〜略〜 Master_UUID: 095e0ff8-18af-11e2-9e7c-5c260a2aa986 Master_Info_File: /path/to/datadir/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1 Executed_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1 1 row in set (0.00 sec)
マスター昇格時の操作 - ビフォー SHOW BINLOG EVENTS 等でそれぞれのサーバーのバイナリログの内容を比較するなど によって昇格するサーバーの対応するバイナリログポジションを調べて・・・ mysql> change master to master_host='127.0.0.1', -> master_port=13032, -> master_user = 'rsandbox', -> master_password = 'rsandbox', -> master_log_file = 'mysql-bin.123456' , -> master_log_pos = 123456 ; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
マスター昇格時の操作 - アフター mysql> change master to master_host='127.0.0.1', -> master_port=13032, -> master_auto_position = 1 ; Query OK, 0 rows affected (0.03 sec) mysql> start slave user='rsandbox' password='rsandbox'; Query OK, 0 rows affected, 1 warning (0.00 sec)
mysqlfailover ● マスターの自動的なフェイルオーバーを実行するツール ● MySQL Workbench に付属 – MySQL Utilities の一部 ● 他にも便利なツールが！！ – Python 製
mysqlfailover サンプル shell> mysqlfailover --master=root:msandbox@127.0.0.1:13032 --slaves=root:msandbox@127.0.0.1:13033,root:msandbox@127.0.0.1:13034 MySQL Replication Failover Utility Failover Mode = auto Next Interval = Thu Oct 18 22:42:14 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin.000006 191 Replication Health Status +------------+--------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +------------+--------+---------+--------+------------+---------+ | 127.0.0.1 | 13032 | MASTER | UP | ON | OK | | 127.0.0.1 | 13033 | SLAVE | UP | ON | OK | | 127.0.0.1 | 13034 | SLAVE | UP | ON | OK | +------------+--------+---------+--------+------------+---------+ Q-quit R-refresh H-health G-GTID Lists U-UUIDs
mysqlfailover フェイルオーバー MySQL Replication Failover Utility Failover Mode = auto Next Interval = Thu Oct 18 22:43:31 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin.000003 621 Replication Health Status +------------+--------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +------------+--------+---------+--------+------------+---------+ | 127.0.0.1 | 13033 | MASTER | UP | ON | OK | | 127.0.0.1 | 13034 | SLAVE | UP | ON | OK | +------------+--------+---------+--------+------------+---------+ Q-quit R-refresh H-health G-GTID Lists U-UUIDs
クラッシュセーフなスレーブ ● 以前のバージョン ● MySQL 5.6 InnoDB クラッシュセーフ InnoDB レプリケーション情報 ＝ レプリケーション情報 mysql.slave_relay_log_info ＝ テーブル relay_log_info ファイル InnoDB の更新とは非同期
フェイルオーバーのための スレーブ用オプション server_id=1 log_bin=mysql-bin gtid_mode=on log_slave_updates disable_gtid_unsafe_statements master_info_repository=TABLE relay_log_info_repository=TABLE report_host=hostname report_port=3306
InnoDB
オンライン DDL ● MySQL 5.1 ビルトインまで – 新しい定義のテーブルを作成してすべてのデータをコピー – ALTER TABLE 中はテーブルの参照のみ可能 – 更新は ALTER が終わるまでブロックされる ● MySQL 5.1 InnoDB Plugin 〜 5.5 – セカンダリインデックス追加時はデータのコピーをせずイン デックスだけを構築 – インデックス構築中は参照のみ可能 ● MySQL 5.6 – インデックス構築中の更新が可能に！ New – 特殊なオプション等は特に必要なし
テーブルスペースの エクスポート / インポート ● テーブルを .ibd ファイルのコピーで他のマシンへ移行可能 – innodb_file_per_table – MySQL 5.5 まではよくある間違いで、その操作はできな かった。 ● MySQL 5.6 で実施可能に！ – FLUSH TABLES t FOR EXPORT
テーブルスペースの エクスポート / インポート手順 ● 移行元 – FLUSH TABLES t FOR EXPORT; – .ibd ファイルと .cfg ファイルをコピー – UNLOCK TABLES; ● 移行先 – テーブルの入れ物を作っておく ● CREATE TABLE t (…) ENGINE INNODB; ● ALTER TABLE t DISCARD TABLESPACE; – .ibd ファイルと .cfg ファイルをデータベースディレクトリ内 にコピー – ALTER TABLE t IMPORT TABLESPACE;
デッドロック検出機能 ● 検出ロジックが高速に ● エラーログに情報を出力 – innodb_print_all_deadlocks
デッドロックのログサンプル InnoDB: transactions deadlock detected, dumping detailed information. 121018 2:28:28 *** (1) TRANSACTION: TRANSACTION 6426, ACTIVE 16 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1 MySQL thread id 1, OS thread handle 0x7f126453c700, query id 53 localhost msandbox updating update t set b='sss' where a=1 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 6 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 6426 lock_mode X locks rec but not gap waiting Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 00000001; asc ;; 1: len 6; hex 000000001917; asc ;; 2: len 7; hex 13000001890110; asc ;; 3: len 3; hex 747474; asc ttt;; *** (2) TRANSACTION: TRANSACTION 6423, ACTIVE 65 sec starting index read 〜略〜 *** WE ROLL BACK TRANSACTION (2)
CPU スケーラビリティの向上 ● MySQL Connect のキーノートスピーチで言及された数値 – R/W sysbench … MySQL 5.5 比で 151% 改善！ – Read Only sysbench … MySQL 5.5 比で 234% 改善！ – http://medianetwork.oracle.com/video/player/1873154739001 ● kernel_mutex における処理の分散 ● リードオンリートランザクション – 更新の準備が不要なためオーバーヘッドが小さい ● START TRANACTION READ ONLY ● autocommit=1 における SELECT
フラッシュのアルゴリズム改善 ● Adaptive Flushing の細かなチューニング – リソースが不足しそうになるとよりアグレッシブなフラッシュ を開始する low water mark を指定可能に ● innodb_adaptive_flushing_lwm ● innodb_max_dirty_pages_pct_lwm – リソースが逼迫した時の I/O の量を指定可能に ● innodb_io_capacity_max – フラッシュ動作変更の間隔を指定可能 ● innodb_flushing_avg_loops ● フラッシュ専用のバックグラウンドスレッド pager_cleaner – 毎秒起動 – innodb_lru_scan_depth でスレッドが検査するサイズを 指定可能 ● ストレージに合わせたフラッシュ動作 – innodb_flush_neighbors
memcached プラグイン MySQL MySQL MySQL memcached memcached クライアント クライアント クライアント クライアント クライアント ポート 3306 ポート 11211 接続スレッド 接続スレッド SQL パーサ 接続スレッド memcached オプティマイザ等 プラグイン InnoDB MySQL サーバー
オプティマイザ
〜 MySQL 5.5 Nested Loop Join SELECT … FROM t1 JOIN t2 ON … WHERE ... for each row in t1 matching where condition { for each row in t2 matching join and where condition { send joined row to client } }
〜 MySQL 5.5 Block Nested Loop Join t1 t2 スキャン 1. WHERE 句の条件に沿って t1 からレコードをフェッチし バッファに格納 2. バッファが満タンに なったら t2 を スキャンして JOIN 3. t1 のすべての レコードについて くりかえし JOIN Buffer Using Join Buffer...
MySQL 5.6 における オプティマイザ改善点 ● Disk Sweep Multi Range Read (MRR) ● Batched Key Access Join (BKA) ● Index Condition Pushdown (ICP) ● ORDER BY … LIMIT の効率化 ● サブクエリのアルゴリズム改善 – Semi-Join – FROM 句のサブクエリの改善
MRR がない場合 セカンダリインデックス レコード レコードに ランダムアクセス
MRR がある場合 セカンダリインデックス レコード MRR レコードの ROWID を バッファに格納し、 ROWID でソート。 ROWID 順でアクセス。
Batched Key Access Join t1 t2 1. WHERE 句の条件に沿って t1 からレコードをフェッチし バッファに格納 2. バッファが満タンに なったら MRR で t2 から レコードをフェッチして JOIN MRR Scan 4. t1 のすべての 3. ROWID の順で レコードについて t2 からレコードをフェッチ くりかえし JOIN Buffer
Index Condition Pushdown ● 複合インデックスを用いたアクセスの効率化 ● (col1, col2, col3) というインデックスがある場合、これまで は WHERE col1=1 AND col3<10 というような条件では col3 はテーブルからレコードをフェッチする際に評価され なかった。
ICP がない場合 セカンダリインデックス レコード col1 col2 col3 col1=1 のすべての レコードをフェッチ。 : col3 の条件は使われない。 0 20 10 1 3 4 1 3 10 1 3 20 1 8 2 1 9 9 1 9 11 1 9 15 1 11 5 1 11 13 2 1 2 :
ICP がある場合 セカンダリインデックス レコード col1 col2 col3 col1=1 かつ col3<10 の条件に合うレコード : だけをフェッチ。 0 20 10 1 3 4 1 3 10 1 3 20 フェッチされずに 1 8 2 済んだレコード 1 9 9 1 9 11 1 9 15 1 11 5 1 11 13 2 1 2 :
ORDER BY … LIMIT の効率化 ● SELECT column_list FROM single_table ORDER BY non_indexed_colum LIMIT n – というような構造のクエリが速くなる。 – Using sort buffer... ● 従来のアルゴリズム – すべての結果をソートしてから上位の n 個を返す ● MySQL 5.6 のアルゴリズム – ソートバッファに n 個のレコードが確実に格納出来るとわ かっている場合、上位の結果だけをソートバッファに格納 する – ソートバッファに収まらない場合は従来のアルゴリズム
Semi Join ● 相関サブクエリの効率を改善 – 従来のアルゴリズム＝外部クエリから１行フェッチするごと に、サブクエリを実行 – 相関のないサブクエリは最初に１度だけ実行されるので遅 くはない ● 従来は開発者が JOIN に書き換える必要があった。 – 多くの場合は SELECT DISTINCT で対応可能 ● Semi Join とは、重複を含まないサブクエリのこと。外部ク エリ１行に対して最大で１行だけマッチする Join のこと。 – SQL には Semi Join に該当する Join はない。
MySQL 5.5 の例 - EXPLAIN EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: Country type: index possible_keys: NULL key: PRIMARY key_len: 3 ref: NULL rows: 247 Extra: Using where; Using index *************************** 2. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: City type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4037 Extra: Using where 2 rows in set (0.00 sec)
MySQL 5.5 の例 - SELECT mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** COUNT(1): 71 1 row in set (0.26 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+--------+ | Variable_name | Value | +-----------------------+--------+ | Handler_read_first | 240 | | Handler_read_key | 240 | | Handler_read_last | 0 | | Handler_read_next | 239 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 824291 | +-----------------------+--------+ 7 rows in set (0.00 sec)
MySQL 5.6 の例 - EXPLAIN EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: Country type: index possible_keys: PRIMARY key: PRIMARY key_len: 3 ref: NULL rows: 239 Extra: Using where; Using index *************************** 2. row *************************** id: 1 select_type: SIMPLE table: <subquery2> type: eq_ref possible_keys: <auto_key> key: <auto_key> key_len: 3 ref: world.Country.Code rows: 1 Extra: NULL ・・・つづく
MySQL 5.6 の例 - EXPLAIN つづき *************************** 3. row *************************** id: 2 select_type: MATERIALIZED table: City type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4188 Extra: Using where 3 rows in set (0.00 sec)
MySQL 5.6 の例 - SELECT mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** COUNT(1): 71 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 2 | | Handler_read_key | 241 | | Handler_read_last | 0 | | Handler_read_next | 239 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 4080 | +-----------------------+-------+ 7 rows in set (0.00 sec)
FROM 句のサブクエリ ● 評価の遅延 – マテリアライゼーションが実際にレコードが必要な場合だけ 行われるように。 – EXPLAIN が高速化。 – WHERE 句の条件次第ではマテリアライゼーションが不要 に。 ● マテリアライゼーションによって作成されたテンポラリテー ブルにインデックスを作成。
MySQL 5.5 の例 mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2 ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%'; +----------+ | COUNT(1) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 2 | | Handler_read_key | 2 | | Handler_read_last | 0 | | Handler_read_next | 0 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 4320 | +-----------------------+-------+ 7 rows in set (0.00 sec)
MySQL 5.6 の例 mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2 ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%'; +----------+ | COUNT(1) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 1 | | Handler_read_key | 1 | | Handler_read_last | 0 | | Handler_read_next | 0 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 240 | +-----------------------+-------+ 7 rows in set (0.00 sec)
まとめ ● MySQL 5.6 には大幅な新機能が追加された。 – 本日紹介したもの ● レプリケーション ● InnoDB ● オプティマイザ ● MySQL は急速に進化中！！ ● GA （正式版）リリースをお楽しみに。
ご静聴ありがとうございました。

More Related Content

MySQL 5.6新機能解説@dbtechshowcase2012

  • 1. MySQL 5.6 新機能解説 ＠ db tech showcase 2012 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  • 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、私自身 の見解であって、オラクル・コーポレーションの見解を必ず しも反映したものではありません。ご了承ください。
  • 3. 自己紹介 ● MySQL サポートエンジニア – 2000 年にサン・マイクロシステムズ入社 ● 主にハードウェアのサポートを担当 – 2007 年に MySQL KK へ転職 ● 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 – サポート一筋 12 年 ● 日々のしごと – MySQL トラブルシューティング全般 – Q&A 回答 など ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
  • 5. MySQL 5.6 リリース候補版登場！ ● MySQL Connect 2012 において MySQL 5.6 リリース候 補版（ RC ＝ Release Candidate ）が発表された。 – MySQL Connect は Oracle OpenWorld と並んで US で 開催されたイベント ● リリース候補版≒ Feature Fix!! – 約 200 の Worklog に対応 – 機能は開発版（ DRM ＝ Development Milestone Release ）で徐々に追加するという開発モデル ● MySQL 5.5GA （２０１０年 12 月）以来のメジャーアップ デート – マイナーバージョンではありません。 – 正式版（ GA ＝ General Availability ）までしばらくお待ち を！！
  • 6. レプリケーション ● GTID – Global Transaction ID – スレーブの自動的な昇格が可能に！！ ● クラッシュセーフなスレーブ ● 遅延レプリケーション ● mysqlbinlog コマンドによるバイナリログのバックアップ ● スレーブが使用する NIC の指定 ● マルチスレッドスレーブ – スレーブ SQL スレッドが複数のスレッドで実行可能に！！ – DB 単位での並列処理
  • 7. InnoDB ● インデックスの追加と削除がオンラインで可能に！！ ● FULLTEXT インデックスのサポート ● .ibd ファイル（テーブル単位のデータファイル）のエクス ポートとインポート – ファイルのコピー＋ α の操作他のサーバーへ移行可能！！ ● ページサイズの指定（ 16KB→4KB/8KB/16KB ） ● インデックス統計情報の改善 ● START TRANSACTION READ ONLY ● ログサイズの上限が増加（ 4GB→512GB ） ● デッドロック検出機能の改善 ● CPU スケーラビリティの向上 ● バッファプールの内容を保存、再起動時に暖機運転 ● memcached インターフェイス
  • 8. オプティマイザ ● サブクエリの高速化 – semi-join 最適化 – FROM 句のサブクエリの評価遅延 ● EXPLAIN の改善 – SELECT 以外の DML へ対応 ● 各種アルゴリズムの改善 – ORDER BY ... LIMIT の効率化 – Batched Key Access Join – Index Condition Pushdown – Multi Range Read ● オプティマイザトレース
  • 9. パーティショニング ● パーティションをテーブル同士で交換可能に ● パーティション数の上限増加（ 1024→8192 ） ● 明示的なパーティションの指定 ● テーブルロックの改善 – テーブルロックの対象がテーブル全体からパーティション 単位に
  • 10. その他 ● セキュリティ関係 ● ジャイアントロックの解消 ● ホストキャッシュの参照 ● OpenGIS 対応 ● 小数点以下の秒への対応 ● ストアドルーチンにおけるエラーハンドリングの改善 – Diagnostic Area 参考：開発スピードアクセル全開ぶっちぎり！日本よ、これが MySQL 5.6 だッ！！ http://nippondanji.blogspot.com/2012/10/mysql-56.html
  • 14. MySQL のレプリケーション アプリケーション 1. COMMIT 4-1. send_ok 接続 スレーブ接続 I/O SQL スレッド 2. スレッド スレッド スレッド バ イ 更 ナリ 5. リレーログ更新 3. テーブル 新 ロ 4-2. バイナリログ 更新 グ 送信 6. 更新の適用 ストレージ バイナリログ リレーログ ストレージ エンジン エンジン マスター スレーブ
  • 15. MySQL のレプリケーション（つづき） マスター / スレーブ マルチマスター Master Slave Master Master + Slave + Slave カスケード Master Slave Slave 循環型 1:N Master Slave + Slave Master Master + Slave Slave Slave Master + Slave
  • 16. MySQL 5.5 のおさらい 準同期レプリケーション COMMIT 完了時にはスレーブへ更新が到達している ることが保証されている。 アプリケーション → HA （高可用性）として利用可能か！？ 1. COMMIT 7. send_ok 6-1-2. ack 6-1-1. ack 接続 スレーブ接続 I/O SQL スレッド 2. スレッド スレッド スレッド バ イ 更 ナリ 5. リレーログ更新 3. テーブル 新 ロ 4. バイナリログ 更新 グ 送信 6-2. 更新の適用 ストレージ バイナリログ リレーログ ストレージ エンジン エンジン マスター スレーブ
  • 17. 準同期レプリケーションによる HA ● できるようになったこと ● できなかったこと – マスタークラッシュ時に – スレーブの昇格 スレーブにデータが残 ● 1:N 構成 る – スレーブのクラッシュへ – 1:1 構成 の対応 ● クラッシュ時は再 セットアップ
  • 18. Global Transaction ID ● トランザクションを一意に識別することができる ID – UUID: トランザクション ID の形式で表現される – 例） 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:123456 ● トランザクション ID はシーケンス – 1:N 環境で、どのスレーブが最も進んでいるか一目瞭然！ ● MASTER_AUTO_POSITION = 1
  • 19. Global Transaction ID （つづき） mysql> show binlog events in 'mysql-bin.000002'G 〜 省略 〜 *************************** 3. row *************************** Log_name: mysql-bin.000002 Pos: 151 Event_type: Gtid Server_id: 1 End_log_pos: 199 Info: SET @@SESSION.GTID_NEXT= '095E0FF8-18AF-11E2-9E7C- 5C260A2AA986:1' 〜 省略 〜
  • 20. Global Transaction ID （つづき） mysql> SHOW SLAVE STATUSG *************************** 1. row *************************** 〜略〜 Master_UUID: 095e0ff8-18af-11e2-9e7c-5c260a2aa986 Master_Info_File: /path/to/datadir/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1 Executed_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1 1 row in set (0.00 sec)
  • 21. マスター昇格時の操作 - ビフォー SHOW BINLOG EVENTS 等でそれぞれのサーバーのバイナリログの内容を比較するなど によって昇格するサーバーの対応するバイナリログポジションを調べて・・・ mysql> change master to master_host='127.0.0.1', -> master_port=13032, -> master_user = 'rsandbox', -> master_password = 'rsandbox', -> master_log_file = 'mysql-bin.123456' , -> master_log_pos = 123456 ; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
  • 22. マスター昇格時の操作 - アフター mysql> change master to master_host='127.0.0.1', -> master_port=13032, -> master_auto_position = 1 ; Query OK, 0 rows affected (0.03 sec) mysql> start slave user='rsandbox' password='rsandbox'; Query OK, 0 rows affected, 1 warning (0.00 sec)
  • 23. mysqlfailover ● マスターの自動的なフェイルオーバーを実行するツール ● MySQL Workbench に付属 – MySQL Utilities の一部 ● 他にも便利なツールが！！ – Python 製
  • 24. mysqlfailover サンプル shell> mysqlfailover --master=root:msandbox@127.0.0.1:13032 --slaves=root:msandbox@127.0.0.1:13033,root:msandbox@127.0.0.1:13034 MySQL Replication Failover Utility Failover Mode = auto Next Interval = Thu Oct 18 22:42:14 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin.000006 191 Replication Health Status +------------+--------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +------------+--------+---------+--------+------------+---------+ | 127.0.0.1 | 13032 | MASTER | UP | ON | OK | | 127.0.0.1 | 13033 | SLAVE | UP | ON | OK | | 127.0.0.1 | 13034 | SLAVE | UP | ON | OK | +------------+--------+---------+--------+------------+---------+ Q-quit R-refresh H-health G-GTID Lists U-UUIDs
  • 25. mysqlfailover フェイルオーバー MySQL Replication Failover Utility Failover Mode = auto Next Interval = Thu Oct 18 22:43:31 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin.000003 621 Replication Health Status +------------+--------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +------------+--------+---------+--------+------------+---------+ | 127.0.0.1 | 13033 | MASTER | UP | ON | OK | | 127.0.0.1 | 13034 | SLAVE | UP | ON | OK | +------------+--------+---------+--------+------------+---------+ Q-quit R-refresh H-health G-GTID Lists U-UUIDs
  • 26. クラッシュセーフなスレーブ ● 以前のバージョン ● MySQL 5.6 InnoDB クラッシュセーフ InnoDB レプリケーション情報 ＝ レプリケーション情報 mysql.slave_relay_log_info ＝ テーブル relay_log_info ファイル InnoDB の更新とは非同期
  • 27. フェイルオーバーのための スレーブ用オプション server_id=1 log_bin=mysql-bin gtid_mode=on log_slave_updates disable_gtid_unsafe_statements master_info_repository=TABLE relay_log_info_repository=TABLE report_host=hostname report_port=3306
  • 29. オンライン DDL ● MySQL 5.1 ビルトインまで – 新しい定義のテーブルを作成してすべてのデータをコピー – ALTER TABLE 中はテーブルの参照のみ可能 – 更新は ALTER が終わるまでブロックされる ● MySQL 5.1 InnoDB Plugin 〜 5.5 – セカンダリインデックス追加時はデータのコピーをせずイン デックスだけを構築 – インデックス構築中は参照のみ可能 ● MySQL 5.6 – インデックス構築中の更新が可能に！ New – 特殊なオプション等は特に必要なし
  • 30. テーブルスペースの エクスポート / インポート ● テーブルを .ibd ファイルのコピーで他のマシンへ移行可能 – innodb_file_per_table – MySQL 5.5 まではよくある間違いで、その操作はできな かった。 ● MySQL 5.6 で実施可能に！ – FLUSH TABLES t FOR EXPORT
  • 31. テーブルスペースの エクスポート / インポート手順 ● 移行元 – FLUSH TABLES t FOR EXPORT; – .ibd ファイルと .cfg ファイルをコピー – UNLOCK TABLES; ● 移行先 – テーブルの入れ物を作っておく ● CREATE TABLE t (…) ENGINE INNODB; ● ALTER TABLE t DISCARD TABLESPACE; – .ibd ファイルと .cfg ファイルをデータベースディレクトリ内 にコピー – ALTER TABLE t IMPORT TABLESPACE;
  • 32. デッドロック検出機能 ● 検出ロジックが高速に ● エラーログに情報を出力 – innodb_print_all_deadlocks
  • 33. デッドロックのログサンプル InnoDB: transactions deadlock detected, dumping detailed information. 121018 2:28:28 *** (1) TRANSACTION: TRANSACTION 6426, ACTIVE 16 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1 MySQL thread id 1, OS thread handle 0x7f126453c700, query id 53 localhost msandbox updating update t set b='sss' where a=1 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 6 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 6426 lock_mode X locks rec but not gap waiting Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 00000001; asc ;; 1: len 6; hex 000000001917; asc ;; 2: len 7; hex 13000001890110; asc ;; 3: len 3; hex 747474; asc ttt;; *** (2) TRANSACTION: TRANSACTION 6423, ACTIVE 65 sec starting index read 〜略〜 *** WE ROLL BACK TRANSACTION (2)
  • 34. CPU スケーラビリティの向上 ● MySQL Connect のキーノートスピーチで言及された数値 – R/W sysbench … MySQL 5.5 比で 151% 改善！ – Read Only sysbench … MySQL 5.5 比で 234% 改善！ – http://medianetwork.oracle.com/video/player/1873154739001 ● kernel_mutex における処理の分散 ● リードオンリートランザクション – 更新の準備が不要なためオーバーヘッドが小さい ● START TRANACTION READ ONLY ● autocommit=1 における SELECT
  • 35. フラッシュのアルゴリズム改善 ● Adaptive Flushing の細かなチューニング – リソースが不足しそうになるとよりアグレッシブなフラッシュ を開始する low water mark を指定可能に ● innodb_adaptive_flushing_lwm ● innodb_max_dirty_pages_pct_lwm – リソースが逼迫した時の I/O の量を指定可能に ● innodb_io_capacity_max – フラッシュ動作変更の間隔を指定可能 ● innodb_flushing_avg_loops ● フラッシュ専用のバックグラウンドスレッド pager_cleaner – 毎秒起動 – innodb_lru_scan_depth でスレッドが検査するサイズを 指定可能 ● ストレージに合わせたフラッシュ動作 – innodb_flush_neighbors
  • 36. memcached プラグイン MySQL MySQL MySQL memcached memcached クライアント クライアント クライアント クライアント クライアント ポート 3306 ポート 11211 接続スレッド 接続スレッド SQL パーサ 接続スレッド memcached オプティマイザ等 プラグイン InnoDB MySQL サーバー
  • 38. 〜 MySQL 5.5 Nested Loop Join SELECT … FROM t1 JOIN t2 ON … WHERE ... for each row in t1 matching where condition { for each row in t2 matching join and where condition { send joined row to client } }
  • 39. 〜 MySQL 5.5 Block Nested Loop Join t1 t2 スキャン 1. WHERE 句の条件に沿って t1 からレコードをフェッチし バッファに格納 2. バッファが満タンに なったら t2 を スキャンして JOIN 3. t1 のすべての レコードについて くりかえし JOIN Buffer Using Join Buffer...
  • 40. MySQL 5.6 における オプティマイザ改善点 ● Disk Sweep Multi Range Read (MRR) ● Batched Key Access Join (BKA) ● Index Condition Pushdown (ICP) ● ORDER BY … LIMIT の効率化 ● サブクエリのアルゴリズム改善 – Semi-Join – FROM 句のサブクエリの改善
  • 41. MRR がない場合 セカンダリインデックス レコード レコードに ランダムアクセス
  • 42. MRR がある場合 セカンダリインデックス レコード MRR レコードの ROWID を バッファに格納し、 ROWID でソート。 ROWID 順でアクセス。
  • 43. Batched Key Access Join t1 t2 1. WHERE 句の条件に沿って t1 からレコードをフェッチし バッファに格納 2. バッファが満タンに なったら MRR で t2 から レコードをフェッチして JOIN MRR Scan 4. t1 のすべての 3. ROWID の順で レコードについて t2 からレコードをフェッチ くりかえし JOIN Buffer
  • 44. Index Condition Pushdown ● 複合インデックスを用いたアクセスの効率化 ● (col1, col2, col3) というインデックスがある場合、これまで は WHERE col1=1 AND col3<10 というような条件では col3 はテーブルからレコードをフェッチする際に評価され なかった。
  • 45. ICP がない場合 セカンダリインデックス レコード col1 col2 col3 col1=1 のすべての レコードをフェッチ。 : col3 の条件は使われない。 0 20 10 1 3 4 1 3 10 1 3 20 1 8 2 1 9 9 1 9 11 1 9 15 1 11 5 1 11 13 2 1 2 :
  • 46. ICP がある場合 セカンダリインデックス レコード col1 col2 col3 col1=1 かつ col3<10 の条件に合うレコード : だけをフェッチ。 0 20 10 1 3 4 1 3 10 1 3 20 フェッチされずに 1 8 2 済んだレコード 1 9 9 1 9 11 1 9 15 1 11 5 1 11 13 2 1 2 :
  • 47. ORDER BY … LIMIT の効率化 ● SELECT column_list FROM single_table ORDER BY non_indexed_colum LIMIT n – というような構造のクエリが速くなる。 – Using sort buffer... ● 従来のアルゴリズム – すべての結果をソートしてから上位の n 個を返す ● MySQL 5.6 のアルゴリズム – ソートバッファに n 個のレコードが確実に格納出来るとわ かっている場合、上位の結果だけをソートバッファに格納 する – ソートバッファに収まらない場合は従来のアルゴリズム
  • 48. Semi Join ● 相関サブクエリの効率を改善 – 従来のアルゴリズム＝外部クエリから１行フェッチするごと に、サブクエリを実行 – 相関のないサブクエリは最初に１度だけ実行されるので遅 くはない ● 従来は開発者が JOIN に書き換える必要があった。 – 多くの場合は SELECT DISTINCT で対応可能 ● Semi Join とは、重複を含まないサブクエリのこと。外部ク エリ１行に対して最大で１行だけマッチする Join のこと。 – SQL には Semi Join に該当する Join はない。
  • 49. MySQL 5.5 の例 - EXPLAIN EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: Country type: index possible_keys: NULL key: PRIMARY key_len: 3 ref: NULL rows: 247 Extra: Using where; Using index *************************** 2. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: City type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4037 Extra: Using where 2 rows in set (0.00 sec)
  • 50. MySQL 5.5 の例 - SELECT mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** COUNT(1): 71 1 row in set (0.26 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+--------+ | Variable_name | Value | +-----------------------+--------+ | Handler_read_first | 240 | | Handler_read_key | 240 | | Handler_read_last | 0 | | Handler_read_next | 239 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 824291 | +-----------------------+--------+ 7 rows in set (0.00 sec)
  • 51. MySQL 5.6 の例 - EXPLAIN EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: Country type: index possible_keys: PRIMARY key: PRIMARY key_len: 3 ref: NULL rows: 239 Extra: Using where; Using index *************************** 2. row *************************** id: 1 select_type: SIMPLE table: <subquery2> type: eq_ref possible_keys: <auto_key> key: <auto_key> key_len: 3 ref: world.Country.Code rows: 1 Extra: NULL ・・・つづく
  • 52. MySQL 5.6 の例 - EXPLAIN つづき *************************** 3. row *************************** id: 2 select_type: MATERIALIZED table: City type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4188 Extra: Using where 3 rows in set (0.00 sec)
  • 53. MySQL 5.6 の例 - SELECT mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM City WHERE Name LIKE 'A%')G *************************** 1. row *************************** COUNT(1): 71 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 2 | | Handler_read_key | 241 | | Handler_read_last | 0 | | Handler_read_next | 239 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 4080 | +-----------------------+-------+ 7 rows in set (0.00 sec)
  • 54. FROM 句のサブクエリ ● 評価の遅延 – マテリアライゼーションが実際にレコードが必要な場合だけ 行われるように。 – EXPLAIN が高速化。 – WHERE 句の条件次第ではマテリアライゼーションが不要 に。 ● マテリアライゼーションによって作成されたテンポラリテー ブルにインデックスを作成。
  • 55. MySQL 5.5 の例 mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2 ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%'; +----------+ | COUNT(1) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 2 | | Handler_read_key | 2 | | Handler_read_last | 0 | | Handler_read_next | 0 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 4320 | +-----------------------+-------+ 7 rows in set (0.00 sec)
  • 56. MySQL 5.6 の例 mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2 ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%'; +----------+ | COUNT(1) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE 'handler_read%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Handler_read_first | 1 | | Handler_read_key | 1 | | Handler_read_last | 0 | | Handler_read_next | 0 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 240 | +-----------------------+-------+ 7 rows in set (0.00 sec)
  • 57. まとめ ● MySQL 5.6 には大幅な新機能が追加された。 – 本日紹介したもの ● レプリケーション ● InnoDB ● オプティマイザ ● MySQL は急速に進化中！！ ● GA （正式版）リリースをお楽しみに。