MySQL Weekly

毎週月曜朝10時ころ更新、1週間のMySQL情報をまとめます

Update for last week (2019-07-22 ~ 2019-07-28)

8.0.17-5.7.27-5.6.45 MySQL-server-blog MySQL-High-Availability-blog Percona-blog

Release note

8.0.17, 5.7.27, 5.6.45がリリースされました！！！ 新しいMaintenance Release()によって大量のエントリがあるので、重要な、もしくは面白い機能をリストアップします。

今回から更新のあったMySQL High Availability ブログもOrganizationブログに追加しました！ また、Categoryを作成してタグ付けすることにしました。

(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)

Changes in MySQL 8.0.17 (2019-07-22, General Availability)

  • Character Set Support
    • utf8mb4 character-setにutf8mb4_0900_binが追加
  • Componene Notes
    • mysql_current_thread_readerコンポーネントが利用可能
      • 実行中のthreadの情報を取得可能できそう(詳細は未調査)
  • Configuration Notes
    • ホスト名にASCII文字で255文字まで利用可能
  • Debugging Notes
    • LOCK ORDERツールの提供
      • lock-order dependency graphをlock_order_dependencies.txtによって自分で作成することでサーバデザインとして、ロックの順序をコントロールできる(!?)
      • MySQLのコンパイル時(CMAKE時)にWITH_LOCK_ORDERをつけてコンパイルする必要がある
  • Deprecation and Removal Notes (今回のリリースでRemovalはない)
    • FLOAT(M,D), DOUBLE(M,D)のシンタックスがdeprecated
    • 文字列データ型におけるBINARY属性をdeprecated, _bincollationがあるのでこれを利用すること
    • AND, OR, NOT演算子のシノニムである&&, ||, !がdeprecated
    • ZEROFILL属性がdeprecated, プログラムから明示的にLPAD()等を使うように
    • FLOAT,DOUBLE, DECIMALとそのシノニムの型においてUNSIGNED属性はdeprecated
    • FLOAT, DOUBLEとそのシノニムにおいてAUTO_INCREMENTのサポートはdeprecated
    • SQL_CALC_FOUND_ROSとFOUND_ROWS() functionはdeprecated
  • Packageing Notes
    • EL8/Fedora, Debianでmysql-community-serverとdebut, testようのパッケージが分割された
  • Performance Scehma Notes
    • Performance_schemaのinstrumentationにおける、rwlockという名前だったpriority read/write locksはprlockに変更され、wait/synch/prlockから始まるように変更。またunlock操作の情報もていきょうされるようになる
  • Plugin Notes
    • keyring pluginのように--early-plugin-loadオプションを指定してInnoDBが初期化される前に呼ばれる必要のあるプラグインのために、plugin descriptionにPLUGIN_OPT_ALLOW_EARLYflagが利用可能
  • Functionality Added or Changed
  • Bugs Fixed
    • many...

Changes in MySQL 5.7.27 (2019-07-22, General Availability)

おそらく来週

Changes in MySQL 5.6.45 (2019-07-22, General Availability)

P-Rお待ちしていますm(_ _ )m MySQL-weekly repository

Bugs

serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分を見る

条件を適用した検索結果

  • Accelerated AES with ARMv8 Crypto Extensions in yaSSL
    • status: Won't fix
    • ARMv8固有の暗号化拡張(cryptography extensions)を利用することでAESを高速化できるという提案
    • EnvironmentやPlatform \ Caseの部分は伏せ字になっているのか文字化けしているのか、こういうものなのか私の知識ではわからない
    • 経緯を追ってみるとなにやら面白いけど最終的にYaSSL support will be removed in an upcoming release.となって終わっている

Organization blogs

  • MySQL server blog: https://mysqlserverteam.com/
    • The MySQL 8.0.17 Maintenance Release is Generally Available
      • MySQL Server Blogによる8.0.17 Maintenance Releaseの告知
      • Provisioning by Cloning: Clone Pluginについての紹介, Clone local replica, Clone remote replica, Clone Remote provisioning, Clone Replication Coordinates, Suport cloning encrypted databaseが簡単に紹介されている
      • Multi-valued indexes: 1ドキュメント内のJSON arrayの中身の複数の値にindexが貼れるようになった
      • JSON Schema: JSON_SCHEMA_VALID(), JSON_SCHEMA_VALIDATION_REPORT()の追加
      • Optimizer improvements: NOT EXISTS, NOT INがanti-semi-joinに書き換えられるようになった
      • Volcano iterator: Volcano modelに基づいて、コードがシンプルになっている. これはhash joinや EXPLAIN, EXPLAIN ANALYZEを改良するための前準備だそう
      • Character Sets: Character setsとなっているがCollationの話、utf8mb4_binと同等だがソートが速いutf8mb4_0900_binが追加
      • Replication: binlog-cacheから溢れてテンポラリファイルに書き出したbinlogも暗号化されるようになった
      • Group Replication: Clone pluginを取り込んだリカバリ機能
      • Router: MySQL Routerのモニタリング基盤の追加とモニタリング用のRESTインターフェースの追加
      • MTR testsuite: MyISAMが必要だったテストケースを分離
      • Other/Deprecation: いろいろ
    • MySQL Shell 8.0.17 – What’s New?
      • MySQL Shell 8.0.17の新機能紹介
      • 特にドキュメントへのリンクがあるわけではないのでかじょうがきの　変更リストを見たい場合は見ると良さそう
    • MySQL InnoDB Cluster – What’s new in Shell AdminAPI 8.0.17 release
      • MySQL ShellのAdminAPIの新機能紹介
      • AdminAPIを使ったAutomatic Node Provisioningがコマンド付きで詳細に解説されている
    • Clone: Create MySQL instance replica
      • Clone pluginを使ったクローンの作成の解説
      • これに従ってやれば一旦クローンを作成してみることができる
    • MySQL Shell Plugins – Introduction
      • タイトル通りMySQL Shell pluginの導入
      • Shell pluginを使ってJavaScriptでカスタムな情報を加えるサンプルが紹介されている
  • MySQL High Availability blog: https://mysqlhighavailability.com/

    • MySQL 8.0.17 Replication Enhancements

      • Enhanced Group Replication distributed recovery with automated instance cloning.
        • Copy pluginによるによるCloneの作成とGroup Replicationでのmember追加についての紹介
      • Enhanced cross-version inter-operability for Group Replication.
        • Group Replicationにおいて、バージョン間の際をうまく扱うための改善があったらしい、詳細は不明
      • Encryption of conditional and temporary, on-disk, binary log capture cache.
        • bufferから溢れてdiskに落ちたbinlogも暗号化されるようになった
      • Protocol compression support for mysqlbinlog.
        • mysqlbinlogでリモートサーバからbinlogをfetchするときに暗号化することができる

    • MySQL InnoDB Cluster – Automatic Node Provisioning

      • MySQL InnoDB Cluster環境でMySQL Shellを使ってAutomatic Node Provisioningするデモ動画

    • Automatic provisioning in Group Replication

      • Group replication, Clone pluginを使う際に新しく入ったgroup_replication_clone_threshold、Purged Data, Credentialについての紹介
    • A Breakthrough in Usability – Automatic Node Provisioning
      • 2つ前のblogで公開されたdemo動画 (MySQL InnoDB Cluster – Automatic Node Provisioning)のより詳細な解説
      • ここでDistributed recoveryとClone Pluginの違いや挙動の説明が読める
      • この記事を読んでClone pluginがlogical backupではなくphysical backupをとっていることがわかった
      • group replicationにおいて、MySQL Shellを使って<Cluster>.addInstance()を実行してからの挙動のフローチャートもあり、このあたりの操作の整理がされている
    • mysqlbinlog: support for protocol compression
      • mysqlbinlogでリモートサーバからbinlogを取得する際に--compress or -Cで圧縮することが可能
    • Binary Log Encryption: Encryption of Temporary Capture Files
      • binlogを吐く際にbufferから溢れたbinlogをTemporary fileに吐くときにこれまではそれを暗号化することができるようになった
    • Improved handling of different member versions in Group Replication
      • Group Replication内では基本的に8.0.17からパッチバージョンが同じもののみしかサポートされない、しかしローリングアップデートの際などは複数のバージョンが混在する場合がある。その際のPrimary member selectionやcompatibility, Upgrade作業に関する情報
      • 筆者がGroup Replicationに詳しくないので、詳細はリンクへ。

Personal blogs

このブログ記事はGitHub上で管理されていますMySQL-weekly repository。Issue, pull-request歓迎です。(完全に同期できているわけではありません)

Update for last week (2019-07-15 ~ 2019-07-21)

月曜日に先週一週間のMySQL関連の更新を再確認するのにご活用ください。

Release note

(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)

  • Nothing

Bugs

serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分を見る

条件を適用した検索結果

  • nothing

Organization blogs

  • MySQL server blog: https://mysqlserverteam.com/

    • Nothing

  • Percona blog (MySQL): https://www.percona.com/blog/

    • MySQL: The Impact of Transactions on Query Throughput
      • selectだけをするクエリをトランザクションとして実行する(begin, commit等で挟む)とどの程度Throughputが落ちるのかという検証。
      • Percona Server for MySQLを含む5.6~8.0の比較もある。
      • 明示的にトランザクションとして実行した場合、begin, commitでもserver,client間でクエリのやり取りが発生するからThroughputが落ちるよねという結論。
      • 同時に3threadだけの単純なselectで実験したため、versionが上がるごとにThroughputが低下しているが、より新しいバージョンでは並列度を上げた時にパフォーマンスを出せるようにしているからとしている。
    • Assessing MySQL Performance Amongst AWS Options – Part One
      • Cloudの環境選択も含めMySQLインスタンスをどうやって利用するかを選択することはchallengingな課題になってきているよね？ということで、パフォーマンス比較の記事。
      • 以下のMySQLを比較
      • ストレージはio1, gp2でも比較
      • 比較にはsysbench-tpccを500 warehouses/10 tables, 128 threadsで30分間回している
      • この結果だけを見ると RDS InnoDB < ec2 Percona InnoDB < amazon aurora < ec2 Percona RocksDB ということになるけど、configについては全く触れていないので、どんな設定で実験して、どこがボトルネックになったのかは不明(それを書くのは大変なのはわかる)
      • 2部作で次回はcostについても触れるそう
    • MySQL: Disk Space Exhaustion for Implicit Temporary Tables
      • Tmp tableが使われるようなクエリで、そのtmp tableがon memoryで解決できずにtmpファイルに落ちる場合にdisk sizeが問題になるケースの説明と対策
      • まずtmp tableを作る主なクエリに以下のものがある
        • GROUP BY, ORDER BY, DISTINCTをつかう
        • UNION statementの評価がある
        • マージできないVIEWを使う(サブクエリを使うderived tableのため)
        • 複数テーブルにUPDATEをかける
      • 5.6まではtmp_tableのストレージエンジンはMyISAMだったが、5.7以降はInnoDB
        • 大抵の場合InnoDBでよいが、general tableスペースを使っていることで、disk spaceがOPTIMIZE TABLEを実行するかMySQLが再起動されるまでshrinkされない
        • よってdisk fullになるケースがある
      • 解決策(詳細は元記事へ)
        • disk sizeを充分に増やす
        • ibtmp1のサイズに上限のリミットをつける(要再起動)
        • internal_tmp_disk_storage_engine = MYISAMを設定する
          • onlineで変更可能SET GLOBAL internal_tmp_disk_storage_engine = MYISAM;
        • クエリをoptimizeする(slow_logにどれくらいのtmp table sizeが使われたかでるらしい)
    • Assessing MySQL Performance Amongst AWS Options – Part Two
      • 前回の続き。今回はコスト面にフォーカスした内容
      • IOPSやストレージサイズで課金する場合の状況が整理されていそう
  • MySQL道普請: https://gihyo.jp/dev/serial/01/mysql-road-construction-news

  • gihyo.jp MySQL-tag

    • Nothing

  • Yakst MySQL-tag: https://yakst.com/ja/tags/mysql

    • Nothing

Personal blogs

このブログ記事はGitHub上で管理されていますMySQL-weekly repository。Issue, pull-request歓迎です。(完全に同期できているわけではありません)

Update for last week (2019-07-08 ~ 2019-07-14)

月曜日に先週一週間のMySQL関連の更新を再確認するのにご活用ください。

Release note

(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)

  • Nothing

Bugs

serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分を見る 条件を適用した検索結果

Bug #94610

Server stalls because ALTER TABLE on partitioned table holds dict mutex

  • Severity: S5(Performance), status: Verified
  • PrtitionされたテーブルでのDDLが遅い
  • パーティションが大量にあり、テーブルサイズも大きいテーブルでALTER操作を行うと、dictionary mutexが取られて、他のテーブルへの操作までもブロックされるという報告
  • 報告者や同じ状況にあたった人はこれはS1(critical)か少なくともS3(Non-critical)以上に値するとコメントしていたりするが、回答者によるとこの問題は以下の2つが原因になっている
    • Partitioned tableに対するALTERが非常に遅いという Bug #83435 の現象
    • DROP TABLEなどでも同じmutex ロックを取るがそれらは一瞬で開放されるので、問題にならないだけ
  • 回答者としては後者は仕様なので、バグではない、なので、前者が解決されればこの報告も解決されるだろうとのこと
  • ドキュメントのONLINE DDLに関する説明が正しいかどうかは別にして、5.7ではこれらの挙動は変わらず、8.xではblockingな処理ではなくなるだろうとのこと
  • 詳細はリンク先へ

この問題も気になるけど、Bug #83435も知らなかった。両方とも行方が気になる。

BUG #83435は 2016年10月に報告されてS1でVerifyされているけど、まだ解決していない。 報告者の説明が分かりづらくて何が問題なのか分かりづらい；；

Organization blogs

Personal blogs

通知がいってしまうブログもあるので、個人のブログのURLを列挙するのはやめました

この記事はGitHub上で管理されています(MySQL-weekly repository)。Issue, pull-request歓迎です。 (完全に同期できているわけではありません)

Update for last week (2019-07-01 ~ 2019-07-07)

日曜日にこの記事を書くことが多いので、日曜更新をやめて、今回以降月曜日10時ごろ更新にしました。
月曜日に先週一週間のMySQL関連の更新を再確認するのにご活用ください。

Release note

(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)

  • Nothing

Bugs

serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分を見る

条件を適用した検索結果

Bug #96112

"SELECT x WHERE y ORDER BY x LIMIT 1" faster than "SELECT MIN(x) WHERE y"

  • Severity: S5(Performance), status: Open
  • SELECT x WHERE y ORDER BY x LIMIT 1がSELECT MIN(x) WHERE yよりも簡単に早くなるという報告。
    • 例ではxをPKにしてもそうなるといっていて、確かにPKが昇順に並んでいるので、どちらのクエリもPKの先頭からたどってyを満たすレコードを返せば良い。
    • 報告者のサンプルでのExplainの結果にはMIN(x)を使った方ではPKアクセスができていないことがわかる。
    • さらにshow status like '%handler%'でHander_read_rnd_nextがレコード数分アクセスしたことも確認している。
    • Explainからテーブルアクセスになっていることは十分わかるけど、Hander_hogeの有効な使い方の例として面白い

Organization blogs

Personal blogs

通知がいってしまうこともあるので、個人のブログのURLを列挙するのはやめました
更新があったものだけとリストアップします

  • tom__bo:
    • MySQL Weekly 始めました
      • このブログを開始したという告知です
      • Personal blogsはここのリストにあるものを毎週確認する予定です。
        • 個人のブログのURLを乗せると通知を毎週送ることになってしまうので、更新があったものだけを貼るようにしたため

Update for this week (2019-06-30)

Release note

(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)

  • Nothing
    • 次回は8.0.16の内容まとめ。
    • 今後はGAになったバージョンが出たらそれについてまとめ

Bugs

serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分を見る

条件を適用した検索結果

Bug #94283

MySQL 8.0.15 is slower than MySQL 5.7.25

  • 5.7.25よりも8.0.15のパフォーマンスが悪い.
    • Sysbench oltp_read_writeの実験において、特にtrx_commit=0 and sync_binlog=1000の場合22%の性能悪化
    • group replication環境でのパフォーマンス悪化を検証していたが、単体のMySQLですでのパフォーマンスが悪いことに気づいたとのこと
  • 報告自体は4ヶ月ほど前のもの今回はコメントで、
    • innodb_max_dirty_pages_pct=75 innodb_max_dirty_pages_pct_lwm=0 使ってみてくれってコメントついたことによる更新
  • my.cnfの設定、HWやsysbenchのoptionについては下記URLを参照のこと

報告者の実験結果 (参考: https://bugs.mysql.com/bug.php?id=94283)

+-------------------------------------------+--------------+--------------+-------+
| case                                      | MySQL 5.7.25 | MySQL 8.0.15 | ratio |
+-------------------------------------------+--------------+--------------+-------+
| trx_commit=0, binlog=off                  | 11402 tps    | 9840(*)      | 1.16  |
+-------------------------------------------+--------------+--------------+-------+
| trx_commit=1, binlog=off                  | 8375         | 7974         | 1.05  |
+-------------------------------------------+--------------+--------------+-------+
| trx_commit=0, binlog=on, sync_binlog=1000 | 10862        | 8871         | 1.22  |
+-------------------------------------------+--------------+--------------+-------+
| trx_commit=0, binlog=on, sync_binlog=1    | 7238         | 6459         | 1.12  |
+-------------------------------------------+--------------+--------------+-------+
| trx_commit=1, binlog=on, sync_binlog=1    | 5970         | 5043         | 1.18  |
+-------------------------------------------+--------------+--------------+-------+
  • 感想
    • sync_binlog=1000ってそういえば0/1以外もあった(binlogを指定された数ためてからsyncする、OSにsyncを任せない)
    • sync_binlog=1000はともかく、その下のtrx_commit=1, binlog=on, sync_binlog=1 だと5.7.25が18%良いのは覚えておく
    • 報告者はHow to reportと言いつつ Make MySQL 8 Great Again MySQL 8.0 does not have to be slower than MySQL 5.7 とか言ってて面白い。
    • こういう内容でもreportできて、receiveされるんだな...このあとの対応気になる(どうなったらcloseされるのか)

MySQL server blog

https://mysqlserverteam.com/

  • Nothing

Organization blogs

  • Percona blog (MySQL): https://www.percona.com/blog/

    • pt-kill: How it Works
      • pt-killで問い合わせ多いけど使い方間違ってること多いから解説するよって記事。
      • オプションで以下の条件をつけたときにこれらの条件はOR条件でマッチするクエリを検索するからAND条件と思ってるとほかも巻き込んで殺すよって話。怖い --busy-time 2s --match-info "(select|SELECT)" この場合selectで2秒以上のクエリがkillされるんじゃなくて、どっちかに当てはまったものが殺される。。。 ん？write系も? (要確認...使わないほうが良いのでは？)
    • Adaptive Hash Index on AWS Aurora
      • Auroraのreader nodeではwriter nodeに比べてクエリが2,3倍遅いことがある
      • InnoDB_Adaptive_Hash_Indexesがreader nodeではoffになっているっぽい。
      • Auroraの都合っぽいのでパス
    • Percona Live Europe 2019 Call for Papers is Now Open!
      • タイトル通りPercona Live Europe 2019のTalk sessionの募集開始！！！
      • 前回LTの応募出したんだけど、そもそもLT枠なくなってた...
    • Stored Functions and Temporary Tables are Not a Good Fit
      • MySQLがTemporary Tableを作成してクエリを処理する場合にSELECT LIST内の関数は結果行ごとの実行されるから処理が非常に遅くなるという現象の指摘。
      • SQLの実行順序と実行方式を整理する必要がるので、別途調査予定。
    • Percona XtraDB Cluster 5.7.26-31.37 Is Now Available
      • タイトル通り
      • 10個のbugsがfixされたようだけど、PXCなのでパス
    • InnoDB ALTER TABLE ADD INDEX and INSERT performance
      • 5.6移行でonline DDLができるようになったけど、online DDL中のinsert性能が悪い、さらに大きいテーブルに対してonline DDLを実行し、その実行中にinsertが600秒以上待つとserver crashになる問題がどうなったかという話。
      • Percona serverの5.7.26-29, 8.0.15-6では直ったらしい。
      • MySQLでは次の5.7のリリースでpatchを取り込んでほしいと思っているそう
      • 8.0では直っている？(要確認)
      • 対策としてはpt-osc使えとのこと
    • Percona Live 2019’s Top 10 Most Attended Talks
      • Percona Live 2019のセッションの人気トップ10が発表！！
      • No1のØysteinの発表をばっちり聞いていたのと、それ以外のコア開発チームの発表は後日動画が公開されそうという予想がバッチリ的中して最高。
      • そして動画を公開できないことが理由かもしれないけど、僕はFacebookの発表が1つも上位に入っていないのが不思議。
      • FBの発表は聞いてきたから良いけどね！

  • Oracle-MySQL blog: https://blogs.oracle.com/mysql/

    • Nothing
  • MySQL道普請: https://gihyo.jp/dev/serial/01/mysql-road-construction-news
    • Nothing
  • Yakst MySQL-tag: https://yakst.com/ja/tags/mysql
    • Nothing

Personal blogs

(リストは不完全です。この人のが抜けてるじゃん！？ってあったら教えてくださいm( )m)
(ただし内容はMySQL関連に限ります)