MySQL Weekly

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

Update for last week (2019-10-07 ~ 2019-10-13)

MySQL Weeklyでは1週間ごとにMySQLのrelease-note, bug, official blog, organizationによるblog, 個人のblogをまとめ紹介しています。
更新は月曜 10時(AM)です。先週一週間のMySQL関連の更新を再確認するのにご活用ください。

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

Release note

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

  • Nothing

Bugs

基本的にMySQL Server, 5.7以上のbug fixのみまとめます

  1. serverity >= S5(Performance)でupdatedでdesc sort、結果の今週分
  2. Status == ClosedID#でdesc sort、結果の今週分を見る

Nothing

Organization blogs

  • MySQL server blog

    • Nothing
  • MySQL High Availability blog

    • Nothing
  • Percona blog (MySQL)

    • Centralization Vs. Decentralization of DBA Teams
      • 中央集約型のチーム(Centralized)と非中央集約型(Centralized)のDBAチームの違いについての考察記事
        • 中央集約型(Centralized)
          • 1つのチームとして大体DBMS製品ごとにグループにされている
          • ドキュメント、開発、マネジメントにおいて会社で共通の手法を取りやすい
          • 運用に関して一貫性がある一方で、そのためにカスタマイズがしづらくvanilla状態で運用することになりやすい
          • 一貫性を保てると新しいメンバーの適応速度や知見の横展開においてはメリットがある
          • 大手企業でサービスやアプリケーションを複数持っている会社に見られがちで、こういうチームは往々にして新しい技術や挑戦に対して受け身になりやすい
        • 非中央集約型(Centralized)
          • 中央集約型の対策として、開発チームごとにDBAがつく非中央集約型でチームを構成することがある
          • プロダクトにあったカスタマイズが進むことで社内では一貫性がなくなり、一度起きた問題が他のチームでも起きるようになり、車輪の再開発も起きるようになる
      • どちらの方針が正解ということはないが重要なのは一貫性とコミュニケーションであり、もし非中央集約型にするのであれば、誰かが一貫性やコミュニケーションを担保する役割を担う必要があると結論づけている
      • まあ当たり前の事しか言っていない気がするけど、一貫性やコミュニケーションの度合いをどう評価するか、どういう手段でこれらを担保するかを考えてみると面白いと思う
    • Achieving Disaster Recovery with Percona XtraDB Cluster
      • 地理的に分散したインスタンスPXCを構成するとパフォーマンスが非常に悪くなってしまうが、DRのためには必須な場合async slaveをDR先に置くのが1つの解決策
      • この場合、asyncなので、大幅にdelayが発生している可能性もあるからpt-table-checksumやpt-table-syncを使うと良いよ
    • Percona Monitoring and Management (PMM) 2.0.1 Is Now Available
      • PMM(Percona Monitoring and Managementの2.0.1がリリース)
      • セキュリティやUIの改善があった
      • Impromements, Fixed bugsの項目の列挙
  • MySQL道普請

    • 第107回 CREATE TEMPORARY TABLEによる一時テーブルの利用
      • TEMPORARY TABLEに関する詳細なまとめ
      • innodb_strict_modeがONで,ROW_FORMATがCOMPRESSEDだとtemporary tableは作れない
      • temporary tableはshow tablesに表示されない SELECT * FROM INNODB_TEMP_TABLE_INFO;で確認
      • binlog_formatごとのbinlogへの出力の違い
  • SmartStyle TECH BLOG (category MySQL and Percona)

  • Severalnines Database Blog

    • Nothing
  • Yakst MySQL-tag

    • Nothing
  • MySQL関連イベントの資料ダウンロード先

Personal blogs

  • How to integrate ProxySQL in MySQL InnoDB Cluster

    • MySQL RouterだとTCPのL4レイヤのルーティングしかしてくれないので、write/readを分けてクエリを投げたい場合にはProxy SQLをかませるのが一つの方法
    • InnoDB ClusterとProxy SQLを使ってMySQLにアクセスする設定の構築例を使って紹介
  • MySQL Parallel Index Range Scans: One is Sometimes Better Than Two

    • Index Range Scan(not covering index)の効率が悪いという指摘
    • TABLE ScanとIndex Range Scanを実行するthread数をスケールさせてその際のQPSを比較
    • resource groupでCPU socketを1,2で変えてみると1 socketしか使わないほうがパフォーマンスが良かった
    • 要約する必要がないくらいまとまっているので、読んでみることをおすすめします。
  • The dark side of super_read_only

    • J,F, Gagne-san
    • super_read_onlyをONにすると勝手にread_onlyもONになり、read_onlyをOFFにするとsuper_read_onlyもOFFになるという挙動の紹介
    • なんとドキュメントにも書かれているらしい。まじか。。。
    • IMHO clearly part of the ugly (or dark) side of MySQLと言いたくなるのもわかる
  • MySQL 8.0.17現在、PRIMARY KEYやUNIQUE KEYのCOLLATEを変更しても何故か再起動まで反映されない

    • yoku0825-san
    • タイトル通りの現象についての調査記事
    • ハハパパ問題を復習しつつcollationの変更がうまく効かない地獄を垣間見れる
    • 正直、文字列型でPK, UKにしていてかつ英数字以外を入れるケースは僕の周囲では少ない、ただ発生したら結構厳しい
  • binlog_format= ROW + 式インデックス + mysqldumpでレプリケーションに失敗する可能性がある

    • yoku0825-san
    • タイトル通りの現象についての調査記事
    • この状態が起こる原因は以下(元記事引用)
        1. binlog_format= ROW である
      • ii. 式インデックスを使っている
      • iii. 式インデックスを作って以降、そのテーブルにカラムを追加した
      • iv. 論理バックアップからリストアしてスレーブを作成
    • ということでだいぶ影響範囲が大きいように思える。とりあえず式インデックス今から入れるのはやめたほうが良さそう
    • 調査の様子をibd2sdi, mysqlbinlogを使って説明してくれていて、とてもためになる
    • affects meは押しましたね? (https://bugs.mysql.com/bug.php?id=96986 )
  • MySQL: ストアドで度分秒変換

    • sakaik-san
    • 緯度経度の表現方法として"度"と"度分秒"で表す方法がある、この内"度分秒"から"度"の単位に変換してくれるstored functionの紹介
    • そもそも緯度経度の表現方法が複数あることを知らなかった。。。

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