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のみまとめます
Nothing
Organization blogs
-
- Nothing
-
- Nothing
-
- Centralization Vs. Decentralization of DBA Teams
- 中央集約型のチーム(Centralized)と非中央集約型(Centralized)のDBAチームの違いについての考察記事
- 中央集約型(Centralized)
- 1つのチームとして大体DBMS製品ごとにグループにされている
- ドキュメント、開発、マネジメントにおいて会社で共通の手法を取りやすい
- 運用に関して一貫性がある一方で、そのためにカスタマイズがしづらくvanilla状態で運用することになりやすい
- 一貫性を保てると新しいメンバーの適応速度や知見の横展開においてはメリットがある
- 大手企業でサービスやアプリケーションを複数持っている会社に見られがちで、こういうチームは往々にして新しい技術や挑戦に対して受け身になりやすい
- 非中央集約型(Centralized)
- 中央集約型の対策として、開発チームごとにDBAがつく非中央集約型でチームを構成することがある
- プロダクトにあったカスタマイズが進むことで社内では一貫性がなくなり、一度起きた問題が他のチームでも起きるようになり、車輪の再開発も起きるようになる
- 中央集約型(Centralized)
- どちらの方針が正解ということはないが重要なのは一貫性とコミュニケーションであり、もし非中央集約型にするのであれば、誰かが一貫性やコミュニケーションを担保する役割を担う必要があると結論づけている
- まあ当たり前の事しか言っていない気がするけど、一貫性やコミュニケーションの度合いをどう評価するか、どういう手段でこれらを担保するかを考えてみると面白いと思う
- 中央集約型のチーム(Centralized)と非中央集約型(Centralized)のDBAチームの違いについての考察記事
- Achieving Disaster Recovery with Percona XtraDB Cluster
- Percona Monitoring and Management (PMM) 2.0.1 Is Now Available
- PMM(Percona Monitoring and Managementの2.0.1がリリース)
- セキュリティやUIの改善があった
- Impromements, Fixed bugsの項目の列挙
- Centralization Vs. Decentralization of DBA Teams
-
- 第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への出力の違い
- 第107回 CREATE TEMPORARY TABLEによる一時テーブルの利用
SmartStyle TECH BLOG (category MySQL and Percona)
- MySQL の mysql_config_editor における制約について
- mysql_config_editorを使った際に気をつけるべきポイント、明示的な制約という意味ではなく未修正のバグについての説明
- https://bugs.mysql.com/bug.php?id=74691
- かなり前から直ってないから運用上は制約と考えても良さそう。。。
- MySQL の mysql_config_editor における制約について
-
- Nothing
-
- Nothing
-
- https://www.mysql.com/jp/news-and-events/seminar/downloads.html
- db tech show case Tokyo 2019の発表資料がある(発表者名のみ紹介)
- yoku0825-san
- inagaki-san
- ichirin2501-san
- ito-san
- 【ゲーム業界向けセミナー】ゲーム業界におけるMySQLの発表資料(発表者名のみ紹介)
- inagaki-san
- ikoma-san
- kajiyama-san
- nojima-san
- sejima-san
- matuno-san
- tom__bo
Personal blogs
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
- タイトル通りの現象についての調査記事
- この状態が起こる原因は以下(元記事引用)
- binlog_format= ROW である
- ii. 式インデックスを使っている
- iii. 式インデックスを作って以降、そのテーブルにカラムを追加した
- iv. 論理バックアップからリストアしてスレーブを作成
- ということでだいぶ影響範囲が大きいように思える。とりあえず式インデックス今から入れるのはやめたほうが良さそう
- 調査の様子をibd2sdi, mysqlbinlogを使って説明してくれていて、とてもためになる
- affects meは押しましたね? (https://bugs.mysql.com/bug.php?id=96986 )
-
- sakaik-san
- 緯度経度の表現方法として"度"と"度分秒"で表す方法がある、この内"度分秒"から"度"の単位に変換してくれるstored functionの紹介
- そもそも緯度経度の表現方法が複数あることを知らなかった。。。
このブログ記事はGitHub上で管理されていますMySQL-weekly repository。Issue, pull-request歓迎です。(完全に同期できているわけではありません)