• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
43,512
On Slideshare
0
From Embeds
0
Number of Embeds
27

Actions

Shares
Downloads
221
Comments
1
Likes
94

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. MySQL 5.6 新機能解説 @ db tech showcase 2012奥野 幹也@nippondanjimikiya (dot) okuno (at) gmail (dot) com
  • 2. 免責事項● 本プレゼンテーションにおいて示されている見解は、私自身 の見解であって、オラクル・コーポレーションの見解を必ず しも反映したものではありません。ご了承ください。
  • 3. 自己紹介● MySQL サポートエンジニア – 2000 年にサン・マイクロシステムズ入社 ● 主にハードウェアのサポートを担当 – 2007 年に MySQL KK へ転職 ● 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 – サポート一筋 12 年● 日々のしごと – MySQL トラブルシューティング全般 – Q&A 回答 など● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
  • 4. MySQL 5.6新機能ダイジェスト
  • 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 (2010年 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
  • 11. 時間の都合上すべてをお見せすることが できません。
  • 12. あまりにもたくさん目覚しい新機能が あるからです!
  • 13. レプリケーション
  • 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.000002G 〜 省略 〜*************************** 3. row *************************** Log_name: mysql-bin.000002 Pos: 151 Event_type: Gtid Server_id: 1End_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 theslave 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:11 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:13034MySQL Replication Failover UtilityFailover Mode = auto Next Interval = Thu Oct 18 22:42:14 2012Master Information------------------Binary Log File Position Binlog_Do_DB Binlog_Ignore_DBmysql-bin.000006 191Replication 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 UtilityFailover Mode = auto Next Interval = Thu Oct 18 22:43:31 2012Master Information------------------Binary Log File Position Binlog_Do_DB Binlog_Ignore_DBmysql-bin.000003 621Replication 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=1log_bin=mysql-bingtid_mode=onlog_slave_updatesdisable_gtid_unsafe_statementsmaster_info_repository=TABLErelay_log_info_repository=TABLEreport_host=hostnamereport_port=3306
  • 28. InnoDB
  • 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 readmysql tables in use 1, locked 1LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1MySQL thread id 1, OS thread handle 0x7f126453c700, query id 53 localhost msandboxupdatingupdate 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 id6426 lock_mode X locks rec but not gap waitingRecord 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 サーバー
  • 37. オプティマイザ
  • 38. 〜 MySQL 5.5 Nested Loop JoinSELECT … 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 Joint1 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 Joint1 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● 相関サブクエリの効率を改善 – 従来のアルゴリズム=外部クエリから1行フェッチするごと に、サブクエリを実行 – 相関のないサブクエリは最初に1度だけ実行されるので遅 くはない● 従来は開発者が JOIN に書き換える必要があった。 – 多くの場合は SELECT DISTINCT で対応可能● Semi Join とは、重複を含まないサブクエリのこと。外部ク エリ1行に対して最大で1行だけマッチする Join のこと。 – SQL には Semi Join に該当する Join はない。
  • 49. MySQL 5.5 の例 - EXPLAINEXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROMCity WHERE Name LIKE A%)G*************************** 1. row *************************** id: 1 select_type: PRIMARY table: Country type: indexpossible_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: ALLpossible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4037 Extra: Using where2 rows in set (0.00 sec)
  • 50. MySQL 5.5 の例 - SELECTmysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECTCity.CountryCode FROM City WHERE Name LIKE A%)G*************************** 1. row ***************************COUNT(1): 711 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 の例 - EXPLAINEXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECTCity.CountryCode FROM City WHERE Name LIKE A%)G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: Country type: indexpossible_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_refpossible_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: ALLpossible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4188 Extra: Using where3 rows in set (0.00 sec)
  • 53. MySQL 5.6 の例 - SELECTmysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECTCity.CountryCode FROM City WHERE Name LIKE A%)G*************************** 1. row ***************************COUNT(1): 711 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 C2ON (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 C2ON (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 (正式版)リリースをお楽しみに。
  • 58. ご静聴ありがとうございました。