Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
8年以上前投稿 修正あり

MySQL 5.7.8 RC2のリリース(MySQL Server Blogより)

MySQL 5.7の2番目のリリース候補版(RC2)が2015/8/3にリリースされた。主な変更内容について紹介する。

原文
The MySQL 5.7.8 Release Candidate is Available | MySQL Server Blog (English)
翻訳依頼者
D98ee74ffe0fafbdc83b23907dda3665 B5aa4f809000b9147289650532e83932
翻訳者
B5aa4f809000b9147289650532e83932 taka-h
翻訳レビュアー
D98ee74ffe0fafbdc83b23907dda3665 doublemarket
原著者への翻訳報告
未報告


免責事項

この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「The MySQL 5.7.8 Release Candidate is Available」(2015/8/3)をユーザが翻訳したものであり、Oracle公式の文書ではありません。


MySQL開発チームは、MySQL 5.7.8、5.7の2番目のリリース候補版(RC2)、がdev.mysql.comでダウンロードできるようになったことをお知らせできてとてもうれしく思っている。("Development Releases"タブをご利用のこと)

5.7.8では500を超えるバグを修正した。これは5.7.7で提供したものに対するものと、5.6の最近マージされたバグ修正に対するものがある。4月に実験室版のリリースでプレビューしたJSONのサポートも追加した。 全ての変更およびバグ修正のリストに関しては5.7.8のリリースノートでみることができる。ここではいくつかの主要なものを紹介する。お楽しみいただきたい!

MySQLへのJSONサポートの追加

MySQLで新たに追加されたJSONのサポートにより、NoSQLの柔軟性とRDBの長所を合わせて利用することができるようになる。

JSONデータ型およびバイナリ格納形式(WL#8132): Knut Anders Hatlenの取組みでバイナリ形式により、サーバーが効率的に保存し、JSONデータを扱い、検索できるようになった。この改修によりJSON型の列を作成できるようにCREATE TABLEALTER TABLEが拡張され、JSON型のフィールドへのINSERTおよび、JSON型フィールドに対するSELECTができるよう、Fieldクラスが拡張された。

サーバーサイドJSON関数(WL#7909): Richard HillegasとDag Wanvikの取組みにより、一連の組込みのJSON関数が導入された。この改修によりユーザーはJSONデータの値を他のリレーショナルなデータから作成し、JSONデータの値からリレーショナルなデータを抽出し、JSON値およびテキストの構造の内部を解析し(妥当性、長さ、深さ、キー)、JSONデータの内部を検索し、操作できるようになった。

JSON比較演算子(WL#8249): Knut Anders Hatlenの取組みによりDATE/TIME/DATETIME比較演算子と同様なJSONの比較演算子が実装され、これによりJSONスカラーとSQLの定数、そしてJSONスカラーとJSONスカラーを比較できるようになった。比較演算子は、WL#7909のスコープで追加されたDOMサポートをベースに実装されている。比較演算子は、SQLの定数をJSONスカラーに変換し、値を比較する。

スカラーのJSON値の順序付け(WL#8539): Knut Anders Hatlenによってソートキーを作成する関数が実装された。これは内部のファイルソート関数がJSON値を適切にソートする為に必要となるものである。ORDER BYによってスカラーのJSON値を並べ替えるとき、WL#8249のJSON比較演算子で定義された順序で結果が返る。

仮想列に対するエクスプレッションアナライザ(WL#8170): Evgeny Potempkinによって、レンジそしてrefオプティマイザが生成列に作成されたインデックスを使いうるようになった。この機能はJSONドキュメントへインデックスを作成し自動的に利用するケースを想定している。

仮想列

マテリアライズしない仮想カラムへのBツリーインデックスのサポート(WL#8149WL#8114): Jimmy Yangによってマテリアライズしない仮想列へのセカンダリインデックスが開発され、これらのインデックスを利用することにより高速な計算済みの値の扱いおよび検索ができるようになった。マテリアライズしない仮想列のサポートに関しては、WL#8114WL#411に記述されている。これらは、実際のInnoDBのインデックスレコードには存在しないが、そのメタデータがInnoDBのシステムテーブルおよびメタデータキャッシュに登録されるように設計されている。仮想列はテーブルに柔軟性および容量の節約をもたらし、またより重要なのは、このような列の追加/削除にテーブルのリビルドが必要ないことである。これらの挙動によりJSONなどのリレーショナルでないデータを格納し、処理するのによりよい選択肢となっている。しかしながら、列自体はマテリアライズされないため、スキャンおよび検索は通常の(マテリアライズされた)列よりも遅くなる。このワークログで、仮想列の値がセカンダリインデックス内にマテリアライズできるようになり、これによって値の検索および処理が簡易化された。これにより仮想カラムの実用上の価値が大きく向上した。また、この開発で仮想生成列へのインデックスの作成は、オンラインな操作となった。

仮想生成列へのインデックス生成のためのストレージエンジンのサポート(WL#8227): Benny WangによりWL#8149のサーバーレイヤのサポートが実装された。例えば、生成列の情報を内部のField::gcol_infoデータ構造体に格納するといったことだ。

仮想列のインデックス値をInnoDBのパージスレッドから計算するコールバック(WL#8481): InnoDBのパージスレッドと呼ばれるサーバーレイヤの関数がJon Olav Hauglidによって実装された。背景: InnoDBは仮想カラムのインデックス値の計算が、WL#8149(マテリアライズしない仮想カラムへのBツリーインデックスのサポート)を実装する為に必要であった。一般には、これはコネクションスレッドによって実施される(WL#8227参照のこと)。しかしながら、これはInnoDBのパージスレッドからも実行され、これらのスレッドはコネクションやセッションと対応づかないため、スレッドまたは、テーブルオブジェクトへのアクセスをもたない。この改修によりパージスレッドが必要な計算を行うのに必要なサーバーレイヤのコールバックが実現された。このワークログでユーザーが観測できる変化は何もなく、WL#8149WL#8227が共に起こるときにのみ関連する。

ページ圧縮

InnoDB: 透過的ページ圧縮(WL#7696): Sunny BainsによりInnoDBのレイヤに圧縮が実装された。この機能はOSおよびファイルシステムの両者で、スパースファイルをサポートしており、かつ"punch hole"をサポートしている(つまり、fallocateする際のFALLOC_FL_PUNCH_HOLEフラグ)場合に有効となる。高レベルのアイデアは、シンプルな16Kのページを仮定しており、これを好きな圧縮アルゴリズムで圧縮し、圧縮されたデータのみを書き出す。データを書き出した後に、元の16Kのブロックの未使用領域をファイルシステムに解放するため"穴をあけ"る。

ユーザー管理

ユーザー名の最大長の拡大(WL#2284): Robert GolebiowskiによりMySQLのユーザー名の最大長が16文字から32文字になった。

CREATE/DROP USERへのIF [NOT] EXISTS句のサポート(WL#8540): Todd FarmerはCREATE USERそしてDROP USER文へのIF [NOT] EXISTS句を実装した。これによりアカウントをレプリケーションを利用して分散させる際に、レプリケーショングループ内のアカウントが(意図せず)同期していないイベントによるレプリケーション失敗をトリガすることなくできるようになる。これはアカウント管理操作のユーザーのスクリプトをシンプルにする。Bug#15287にある機能リクエストも参照して欲しい。

セキュアトランスポートを必須とするサーバーサイドのオプションの追加(WL#7709): Todd Farmerにより、--require_secure_transportサーバーオプションが追加された。これはMySQLサーバーがSSLを利用していないTCP/IPコネクションを拒否できるものだ。MySQLサーバーには、以前は様々なアカウント管理のSQL文の中のREQUIRE SSL句を使って個々のユーザーに対してSSLを必須にする方法しかなかった。

ストレージエンジンの利用の制御

あるストレージエンジンのリストに対するユーザーテーブルの作成を禁止するオプションの提供(WL#8594): Thayumanavar Sachithananthaによる改修により--disabled-storage-enginesコマンドラインオプションが導入され、これによってDBAがあるストレージエンジンのリストを許容しない手段が提供され、ユーザーが特定のストレージエンジンを(誤って)使ってしまうことを抑止できる。これはある顧客が、彼らの環境内で例えばMyISAMの利用を許可しないポリシをもっているユースケースに対応する為に実施された。

スーパーリードオンリー

SUPERユーザーもブロックするスーパーリードオンリー(WL#6799]: Todd Farmerにより新しいオプション--super_read_onlyが導入され、これは--read_onlyオプションを補うものである。--super_read_onlyがONに設定されたときは(自動的に--read_onlyもONに設定される)、サーバーはSUPER権限を持った管理者ユーザに対してもREAD-ONLYとなる。

新しいデータエクスポートユーティリティー

mysqlpump: mysqldumpの機能性の拡張(WL#7755): Marcin BabijとBharathy Satishによってmysqldumpにインスパイアされた(しかし100%互換ではない)新しいMySQLサーバーのユーティリティーが実装された。この新しいツールの主な特徴は並列でバックアップおよびリストア操作ができることである(既存のmysqldumpのサポートは継続される)。

コストモデル

IOを考慮したデータアクセスへのコスト評価関数(WL#7340): Olav Sandståはオプティマイザのコストモデルを拡張し、テーブルの行やインデックスがおおよそどの程度メモリ内にあるか、ストレージエンジンからの見積りを使うようにした。オプティマイザは、メモリにあるデータとディスクから読込む必要があるデータにアクセスする為のコストを計算する際に別のコスト定数を利用するようになる。初期の実装では、これらの2つのコスト定数は同じデフォルト値であるが、メモリバッファにあるデータとディスクからの読込みが必要なデータとでオプティマイザが違うコストを利用するようサーバー管理者が変更できるようになっている。現段階ではデータがメモリにあるか、ディスクからの読込みが必要かどうかの見積りはヒューリスティックである。個々のストレージエンジンで見積りが実装されれば、見積りの精度は劇的に向上するであろう。

オプティマイザヒント

サブクエリの戦略に対するヒント句(WL#8244): Øystein Grøvlenによりサブクエリを実行する戦略を制御する為のヒント句が実装された。これはセミジョインを利用する、しないに関わらず、どのセミジョイン戦略を使うか、そしてセミジョインを利用しない場合は、サブクエリ実体化またはEXISTS戦略(in-to-exists transformation)を利用するかどうか、を含む。この改修はヒント句の為にWL#8016およびWL#8017によって提供される新しい文法と基盤を使っている。この改修はどの特定のセミジョイン戦略をも使わないようにすることが可能であり、この中には--optimizer_switchを利用して無効化することのできない重複除去戦略も含まれる。

可観測性/監視

接続種別の識別(WL#7729): Todd Farmerにより、通常のインターフェース経由で接続種別の情報が明らかになるようになった。PERFORMANCE_SCHEMA.THREADSテーブル、監査ログAPI監査ログファイル、そして一般クエリーログである。現在に至るまで、MySQLはDBAが確立されて使われている接続種別をみるすべがなかった。例えば、SSL接続と暗号化されていないTCP/IP接続またはソケット、共有メモリー、または名前付きパイプの接続の区別などである。

InnoDB: Information_Schema.Filesの実装(WL#7943): Kevin Lewisの取組みにより、内部キャッシュ内にあるInnoDBの全てのデータファイルの為のINFORMATION_SCHEMA.FILESテーブルのデータが提供される。INFORMATION_SCHEMA.FILESテーブルにはいくつかの統計の詳細を含むテーブルスペースのファイルを表す為のフィールドがある。Marco Tusaによって報告されたBug#76182もご覧ください。

パフォーマンススキーマ、スレッド毎の履歴(WL#7795): Marc Alffの取組みによりスレッド毎に履歴のON/OFFを設定できるようになった。現在までは、グローバルコンシューマーフラグが、履歴イベントを記録するかどうかを制御するのに使われてきた。これらのフラグはサーバーに対してグローバルであるため、異なるスレッドへの履歴データは全て収集するか、収集しないかのいずれかである。この機能によりDBAは今やどのセッション、アカウント、ユーザー、ホストに対して履歴データを収集したいかを指定可能となり、これは機能のON/OFFとは別に設定できる。これによりDBAが履歴テーブルにどのようなイベントを記録するかをより正確に制御することが可能となり、このようにして履歴データが実行されたセッションの一部のみで必要であれば、ランタイムのオーバーヘッドを削減することができるだけでなく、パフォーマンススキーマのテーブルへの望まないノイズを削減することができる。ここでのパフォーマンススキーマのテーブルはevents_waits_history_longevents_stages_history_longevents_statements_history_longevents_transactions_history_longであり、これは負荷の高いサーバー(たくさんのイベントを発生させる)のトラブルシューティングの助けとなる。

Fabricのサポート

トランザクション境界の検知(WL#6631): Tatjana Nurnbergによる取組みにより新しいトランザクションが開始されたことを検知するサーバーのフラグが追加された。新しいシステム変数@@session_track_transaction_stateが導入された。ロードバランスされた環境では、いつ新しいトランザクションが開始されたかを知ることが必要で、これによりコネクションプールの異なるコネクションを使ってコネクタにスイッチさせることができる。検知をすべき重要なケースはトランザクションが"フレッシュ"で、読込みや書込みが1つもアタッチされてない場合である。これはコネクタが異なるコネクションを使ってスイッチできるケースに限られる。ステートメントが新しいトランザクションを開始し、読込みか書込みが開始されたら、ロールバックしてしまうためコネクションを動かすことはできない。

サーバーバージョントークンとそのチェック(WL#6940): Vamsikrishna Bhagiの取組みによりDBAやアプリケーションが定義したトークンを元にした一般的な同期機構を導入した。SUPER権限を持ったユーザーはグローバルトークンをサーバーに設定することができ(例えば何らかのID)、クライアントはセッショントークンを設定する。クエリを実行する前に、セッショントークンがグローバルトークンと比較され、2つが一致しなかった場合にエラーを生成する。

書込み/読込みの名前付きロックのロックサービス(WL#8161): Jon Olav Hauglidによる取組みで、WL#6940で必要となるグローバルおよびセッションのバージョントークンリストを保護するためのロックサービスを提供する。

リファクタリング

プロトコルクラスのリファクタリング(WL#7126): Catalin Besleagaによる取組みにより、クライアント-サーバープロトコルをSQL処理から切離す為の最初のステップが実施された。

サーバーのソースからの"高速ミューテックス"の削除(WL#4601): Jon Olav Hauglidの取組みにより、手作りのスピンロックミューテックスの実装である"高速ミューテックス"をサーバーのソースから削除した。多くの欠点があった為である。

テスト基盤

サーバーのサービスをテストする為のプラグイン(WL#8462): Horst Hungerによる取組みにより、新しいサービスAPIをテストする為の、テストプラグインを書くことを目的としたフレームワークが導入された。

デフォルト値の変更

STRICT_MODEのサブモードONがデフォルトとなった(WL#8596): Abhishek Ranjanによる取組みにより、WL#7467の変更がリバートされ、個々のNO_ZERO_DATE、NO_ZERO_IN_DATE、ERROR_FOR_DIVISION_BY_ZERO SQLモードが再度利用できるようになった。これらのモードはデフォルトで有効になっている一連のSQLモードに追加される。WL#7467はこれらのSQLモードをSTRICTモードにマージした。これはSTRICTモードにいくつかのチェックを追加したため、いくつかのSQL文で5.6ではwarningを発生させるものの通っていたものが、5.7では通らなくなった。これはアップグレードのシナリオで、簡単に対処できない問題を引き起こした。Simon Muddにより報告されたBug#75439も参照いただきたい。

コンパイルされた状態でのtable_open_cache_instances変数のデフォルトを増やした(WL#8397): Praveenkumar Hulakundによる取組みにより、コンパイル時の--table_open_cache_instancesのデフォルトを1から16に変更された。これによりマルチコア環境での性能が向上する。

複数のページクリーナーとパージスレッドのデフォルト有効化(WL#8316): Bin Suの取組みによりコンパイル時の--innodb_page_cleanersおよび--innodbpurgethreadsのデフォルトが1から4に変更となった。これによりマルチコア環境での性能および安定性が向上する。

削除および廃止予定

サーバーのコードからのsql-benchの削除(WL#8406): Terje Røstenによる取組みにより、sql-benchのコードが5.7のサーバーのコードから削除された。最近のバージョンに合わせて良くメンテナンスされていないこと、そして内部でテストプロセスの一部として利用しなくなったことから削除することを決断した。Morgan Tockerのブログ投稿も合わせて参照していただきたい。

MYSQL_HOMEを設定する為のmysqld_safe内のDATADIRの利用の削除(WL#7150): Yashwant Sahuの取組みによってmysqld_safe内のDATADIRの利用が削除された。MySQL 5.0から本件に関するwarningがあった。これからはMYSQL_HOMEが設定されていない場合は、BASEDIRに設定される。

バグ修正

我々はMySQL 5.7のDMRサイクルを通じて、MySQLコミュニティーから多数の価値のあるフィードバックを受けた。この入力は大変貴重でありコミュニティーメンバには大いに感謝する!ここではコミュニティーから報告されたバグのうち5.7.8のRC2で修正されたものの主要なものをいくつかご紹介する:

  • Bug#75913, Bug#76446, Bug#76346, Bug#76437, Bug#76436, Bug#76432, Bug#76434, Bug#76445, Bug#76424, Bug#76425, Bug#76419, Bug#76416, Bug#76406, Bug#75782, Bug#75736 — 全てRoel Van de Paarによる報告である。
  • Bug#74891, Bug#76625, Bug#74833, Bug#74854, Bug#74843, Bug#72806, Bug#72807, Bug#72805 — 全てStewart Smithによる報告である。
  • Bug#73953: 不等号条件を含むビューに対するレフトジョインに対して不等号条件を実行しようとすると多くの結果が返るDavid Normanの報告
  • Bug#77276: force indexがgroupbyとorderbyで機能していなかったbombzj bombzjの報告
  • Bug#76748: st_bufferと共にst_intersectsを実行するとサーバーがクラッシュするzkong kongの報告
  • Bug#76401: secure_file_priv = NULLと“”が区別されないtsubasa tanakaの報告
  • Bug#76329: 仮想列の定義でCOLLATEオプションが利用できないMario Beckの報告
  • Bug#76328: 生成列がSHOW CREATE TABLEで正しく表示されないMario Beckの報告
  • Bug#76237: LOAD DATA INFILEがデータベースの文字コードがutf8の場合に特定の行をサイレントに無視するtsubasa tanakaの報告
  • Bug#76182: 新規に作成されたテーブルスペースがINFORMATION_SCHEMAに表示されないMarco Tusaの報告
  • Bug#76164: InnoDBのMeCabの全文検索パーサーが空のエラーメッセージを表示するtsubasa tanakaの報告
  • Bug#75995: mysqld –help –verboseがファイルをロックしようとするDaniël van Eedenの報告
  • Bug#75595: InnoDBのredoログブロックのチェックサムを高速に計算するLaurynas Biveinisの報告
  • Bug#75829: ST_CentroidがMultiPolygonに対して正しくない結果を返すBryan Blakeyの報告
  • Bug#75539: max_allowed_packetのエラーが元のデータを破壊するOli Sennhauserの報告
  • Bug#75372: コード(もしくはインデント)の誤りJoshua Rogersの報告
  • Bug#3083: ユーザー長の制限Dracul Vladの報告
  • Bug#74177: –slave-preserve-commit-orderがスレーブにデッドロックを引き起こしクエリを異常な状態にするKristian Nielsenの報告
  • Bug#74253: ストアドプロシージャ内でgtid_nextを利用し空のトランザクションをコミットすると機能しないDavi Arnautの報告
  • Bug#70860: –tc-heuristic-recoverオプションの値が異常であるLaurynas Biveinisの報告
  • Bug#69425: St_Intersectionが誤った結果を返すIvan Balashovの報告
  • Bug#69538: 空間幾何関数が誤った結果を返すVaclav Novotnyの報告
  • Bug#72056: big DECIMAL型の値の比較の誤りArtem Zaytsevの報告
  • Bug#69903: Mac OS Xにおけるvio_io_wait内のスタックの破損Sergei Glushchenkoの報告
  • Bug#67014: リテラルをselectするビューにジョインする際の評価が正しくないLuke Stevensの報告
  • Bug#67300: テーブルとifを含むビューのレフトジョインが行の値の不一致となるDavid Normanの報告
  • Bug#65936: テーブルとビューのレフトジョインが誤った結果を返すRichard Kojedzinszkyの報告
  • Bug#55265: mysqlslapのオプションである–auto-generate-sql-secondary-indexesが機能しないAndreas Brazaの報告
  • Bug#37703: 高速ミューテックスがある場合とない場合のSysbenchの負荷を利用した性能計測Harita Chilukuriの報告

RC2までに5.7で実施した取組みについて、一連のマイルストーンブログ投稿を通じて確認できる: 5.7.1, 5.7.2, 5.7.3, 5.7.4, 5.7.5, 5.7.6, 5.7.7.

現在のところはここまでである、MySQLを使ってくれてありがとう!

次の記事
The art of command line (日本語訳)
前の記事
MySQL 5.6のパラレルレプリケーションの効用はいかほど?(The Percona Performance Blogより)

Feed small 記事フィード

新着記事Twitterアカウント