2016/07/02 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa

1. MySQL 5.7 + MySQL Fabric +
MySQL Routerでぼっこぼこに され
た はなし
シュレーディンガーの猫は観測された
2016/07/02
yoku0825
YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa

2. ＼こんにちは／
yoku0825＠とある企業のDBA
オラクれない-
ポスグれない-
マイエスキューエる-
家に帰ると
妻の夫-
せがれの⽗-
ムスメの⽗-
⽣息域
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
MySQL Casualʼs Slack: MySQL Casual-
1/84

3. 結果、MySQL
Fabricにはボコら
れました（悲）
2/84

4. これはMySQL
Fabricに 悪 夢を描
いたDBAが屍になる
までの物語である
3/84

5. このスライドに書かれた内
容は個⼈の感想であり、所
属する組織および所属しな
い組織の意⾒を代表するわ
けがありません
4/84

6. ボコられるまでの軌跡(1)
マルチサイトなサービス
各サービス⽤のDBは独⽴していなければならないa.
各サービス⽤のDBをまとめて集計するバッチがあるb.
5/84

7. あっ、これ 進研ゼ
ミ MySQL
Casualで⾒たやつ
だ︕
6/84

8. 各DB独⽴＆まとめて集計
APAPAPAP APAP
MySQL MySQL MySQL
MySQL
Multi-Source Replication
7/84

9. Multi-Source Replication
MySQL :: MySQL 5.7 Reference Manual :: 18.1.4
MySQL Multi-Source Replication
各マスターごとにI/Oスレッドとリレーログ⽣やせば良いん
じゃね︖ という 雑な シンプルな考え⽅で実装されている
8/84

10. Multi-Source Replication
binlog_dump
binlog
site_1's master
binlog_dump
binlog
site_2's master
binlog_dump
binlog
site_3's master
I/O Thread
Relay Log
SQL Thread
I/O Thread
Relay Log
SQL Thread
I/O Thread
Relay Log
SQL Thread
Slave's Storage Engine
Administration Slave
9/84

11. Multi-Source Replication
[mysqld]
master_info_repository= TABLE
relay_log_info_repository = TABLE
10/84

12. Multi-Source Replication
mysql> CHANGE MASTER TO master_host = 'xxx', master_port = xxx, m
aster_user = 'xxx', master_password = 'xxx', master_auto_positio
n = 1 FOR CHANNEL 'site_1';
mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: xxx
Master_User: xxx
Master_Port: xxx
..
Channel_Name: site_1
11/84

13. Multi-Source Replicationの監視
SHOW SLAVE STATUS だと全チャンネル出⼒されるので、今ま
でのがそのまま使えない
SHOW SLAVE STATUS FOR CHANNNEL 'site_1', SHOW SLAVE STATUS
FOR CHANNEL 'site_2', .. と分割するか
-
そういえば5.7からperformance̲schemaにレプリケーション関連の
テーブル追加されたよねって思ったけど
SELECT iothread.channel_name, iothread.service_state AS io_thread,
sqlthread.service_state AS sql_thread FROM
performance_schema.replication_connection_status AS iothread JOIN
performance_schema.replication_applier_status_by_worker AS sqlthread で
*_Running: Yes 的なところは取れるんだけど、 Seconds_Behind_Master が取れな
い。。
“SHOW SLAVE STATUS Information Not In the Replication Tables”
MySQL :: MySQL 5.7 Reference Manual :: 23.9.11 Performance Schema
Replication Tables
Oh..
-
12/84

14. ボコられるまでの軌跡(2)
どうせ5.7使うならJSON型使いたいよね
ログテーブル的なやつで、ブラウザの情報とか結構残したりするらし
いし
-
SQL的にはPKで引いて、アプリケーション側でJSONデコードして表
⽰したり
-
集計に使わず、画⾯表⽰⽤のところだけ-
13/84

15. ⽴ちはだかるConnector/Jの壁
MySQL Bugs: #80631: ResultSet.getString return
garbled result with json type data
Connector/Jだとマルチバイト⽂字が化ける-
まだ直ってない-
マルチバイトもテストしてくれよおおおお-
14/84

16. というかJSONデータ型のメリットを間違って解釈
MySQL 5.7 + JSON
“効率の良い、バイナリーフォーマット” の⼀⽂を誤読
空間効率も良いのかと思ったら別にそういう訳ではなかった
“JSON関数を通すなら効率が良い” ってことだった
-
PKで引くだけならTEXT型の⽅が速いというね。。-
15/84

17. こうしてJSON型の夏は終わった
もともとgenerated columnで関数インデックスにする気は
微塵もなかった
それならちゃんとカラムに詰める-
午前中の正規化の話に近い-
MySQL側のJSON validatorったって、どうせライブラリー
側でJSONエンコードしたりデコードしたりするわけで、そ
れで救われる場⾯少ないはず
TEXT型より空間効率が良いと思ってて、それで使いたかっ
た
幻想がぶち殺されたので正直JSON型にこだわる理由がどこにもなく
なった
-
16/84

18. ボコられるまでの軌跡(3)
どうせ5.7使うならInnoDB FTSやっとくか
VMでスタートすることが決まってるので、メモリーを際限なく⾷ら
う Mroonga(Groonga) さんとはちょっと相性が悪い
-
そんなヘビーに使う訳じゃないので、Mroongaほどスピード要らない
はず
-
トランザクションガリガリな感じなので…。-
そこに地雷があるから-
17/84

19. InnoDB FTS + mecab-ipadic-neologd
吊るしのIPA辞書は⼼許ないので、 neologd/mecab-
ipadic-neologd を辞書に利⽤
Ngramは最初からあきらめてる-
MySQLの全⽂検索に関するあれやこれや-
辞書まで含めてApache License 2.0で利⽤できるらしい-
18/84

20. InnoDB FTS + mecab-ipadic-neologd
InnoDB FTSは 既に⾊々踏み抜いておいたので 今のところ
問題なし
MySQL Bugs: #76120 (アクセス権なし)-
MySQL Bugs: #76121: Warning 1235, “FTS auxiliary tables
will not be flushed” is printed twice.
-
MySQL Bugs: #76139 (アクセス権なし)-
MySQL Bugs: #76164: InnoDB FTS with MeCab parser prints
empty error message
-
MySQL Bugs: #80755 (アクセス権なし)-
MySQL Bugs: #80760: Reverse Engineer fails to load table
which has “WITH PARSER” clause
-
19/84

21. (∩´∀｀)∩ 踏
んでおいてよ
かった（︖）
20/84

22. ボコられるまでの軌跡(4)
⽉間だか週間だかの単位で、アクションの回数にハードリミ
ットをかける仕様があった
折角だからgenerated columnで似非CHECK制約してみよう
ず︕︕
21/84

23. generated column de CHECK制約
mysql> SHOW CREATE TABLE amount_limitG
*************************** 1. row ***************************
Table: amount_limit
Create Table: CREATE TABLE `amount_limit` (
`current_amount` int(11) NOT NULL,
`limit_amount` int(11) NOT NULL,
`virtual_check` int(11) GENERATED ALWAYS AS (if((`current_amoun
t` <= `limit_amount`),1,NULL)) VIRTUAL NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)
22/84

24. generated column de CHECK制約
mysql> SELECT * FROM amount_limit;
+----------------+--------------+---------------+
| current_amount | limit_amount | virtual_check |
+----------------+--------------+---------------+
| 0 | 100 | 1 |
+----------------+--------------+---------------+
1 row in set (0.00 sec)
mysql57> UPDATE amount_limit SET current_amount = current_amount + 100;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> SELECT * FROM amount_limit;
+----------------+--------------+---------------+
| current_amount | limit_amount | virtual_check |
+----------------+--------------+---------------+
| 100 | 100 | 1 |
+----------------+--------------+---------------+
1 row in set (0.00 sec)
mysql> UPDATE amount_limit SET current_amount = current_amount + 100;
ERROR 1048 (23000): Column 'virtual_check' cannot be null
23/84

25. ＜ （すいませんハードリ
ミットだけじゃなくてソ
フトリミットも追加する
ことになったんでやっぱ
りアプリ側でやります）
24/84

26. orz
25/84

27. ボコられるまでの軌跡(5)
冗⻑化も必要だよね
シンプルにレプリケーション使うか
MHA || mysqlfailover + LVS, MySQL Fabric + MySQL Router
-
PXC(Percona XtraDB Cluster .. GaleraのPercona Server実装)使
うか
-
MySQL Clusterはいくら何でもユースケースじゃないな-
スレーブは読み込み分散⽤途じゃなくてホットスワップ
遅延させたくない＆VMスタートだからスケールアップ戦略でいく-
26/84

28. ボコられ案(5-1)
APAPAPAP APAP
MySQL MySQL MySQL
MySQL
マ ル チ ソ ー ス レ プ リ ケ ー シ ョ ン
Slave Slave Slave
27/84

29. ボコられ案(5-1-1)
APAP
Master Slave
LVSLVS
VIP
MHA/mysqlfailover
Monitor/Demote
Monitor/Promote
Notification
28/84

30. MHAを選ばなかった理由
5.6以降のクラッシュセーフスレーブと相性が悪い
マスターの mysql.slave_relay_log_info をSELECTして結果が返っ
てこないので転ける
-
クラッシュセーフスレーブを切りたくはないので、MHAは使ってない-
5.7のMSRに絶対対応していない
そもそも↑の問題があるので、パッチしてまで使う情熱はない
というかエコシステムはゆっくり後ろに乗りたい。。
-
29/84

31. mysqlfailoverを選ばなかった理由
read_only を全くいじってくれないあたりで諦めた
レプリケーションのつなぎ替えはしてくれるけど、それしか
してくれない
調⼦がおかしくなると mysql.failover_console をいじって
やらないといけない。割と引っかかる。。
--exec-before と --exec-after があるのは良かったんだけ
ど…
正直劣化MHA-
30/84

32. ボコられ案(5-1-2)
AP
[Not supported by viewer] Connector/J
Master Slave
mysqlfabric
Monitor/Demote
Monitor/Promote
Lookup Group Query
Routing
Routing
AP
AP Connector/J
31/84

33. MySQL Fabricのもともとの形
Fabric対応コネクター(Connector/J, Connector/.NET,
Connector/Python)が mysqlfabricデーモンへの問い合わせ
とルーティングをやる
コネクターからの接続先は mysqlfabric デーモンを指定する-
アカウント情報だけ、MySQL Fabric⽤のとリアルサーバー⽤のを両
⽅渡す
-
Connector/Jなんてただでさえ⼿に負えてないのに更にブラ
ックボックス追加は⾟い
Connector/Cは割と素直だったんだけど、Labsから消えましたね…-
32/84

34. ボコられ案(5-1-3)
Master Slave
mysqlfabric
Monitor/Demote
Monitor/Promote
AP
AP
mysqlrouter
127.0.0.1:3306
AP
AP
mysqlrouter
127.0.0.1:3306
Lookup Group QueryRouting(NAT)
Routing(NAT)
33/84

35. MySQL Fabric + MySQL Router
Fabric対応コネクターの代わりに mysqlrouter が問い合わせ
とルーティングを司る
MySQL Fabric⽤のアカウントとパスワードは mysqlrouter に設定-
アプリケーションからはMySQL Routerのポートに対してリアルサー
バーのアカウント情報を渡す
-
MySQL Routerがブラックボックスっぽくなるけど、Pure
JavaなConnector/Jに⽐べてC++なMySQL Routerの⽅が
気が楽
34/84

36. ボコられ案(5-2)
MySQL
マ ル チ ソ ー ス レ プ リ ケ ー シ ョ ン
APAP
MySQL
APAP
MySQL
APAP
MySQL
35/84

37. いつものレプリケーションに
SlaveMaster
COMMIT
InnoDB log
InnoDB Tablespace
client
Binary Log
Binlog Dump I/O Thread Relay Log
SQL Thread
COMMIT
36/84

38. wsrepをプラス
SlaveMaster
COMMIT
InnoDB log
InnoDB Tablespace
client
wsrep
Galera Cache wsrep
InnoDB log
InnoDB Tablespace
ACK
Galera Cache
37/84

39. ボコられ案(5-2-1)
APAP
PXC
PXC PXC
38/84

40. PXC + Connector/J
jdbc:mysql://server1,server2,server3 で書ける
server1が倒れてたらserver2, server3と試すスタイル-
コネクションプールとの相性はどうなんだろう-
偏りは制御できなさそう-
追加コンポーネントなしでいい感じ
39/84

41. ボコられ案(5-2-2)
APAP
PXC
PXC PXC
LVSLVS
VIP
40/84

42. PXC + LVS(HAProxyでもいい)
コネクションプールとの相性が悪いのは良く知ってる
⼀度偏っちゃうとtomcat再起動しないといけないとか-
鉄板っぽい構成だけども
41/84

43. ボコられ案(5-2-3)
AP
PXC
127.0.0.1
AP
PXC
127.0.0.1
AP
PXC
127.0.0.1
Write Set Replication
42/84

44. PXCのAPサーバー相乗り
割とやりたかったんだけど全⼒で⽌められた
PXCは台数増えるほど更新性能が落ちるので、APに引きず
られてスケールアウトしていくと死が⾒える
更新量がすごく⼩さく、参照局所性が⾼いトラフィックなら相性が良
いはず
-
43/84

45. ボコられ案(5-3)
MySQL Clusterなので省略
44/84

46. ボコられ案⽐較
ド新規なので gtid_mode= ON は特に問題にしていない
マネージャーノードまたはMySQL Fabricを動かすノードで
もともと1台取るつもりなのでそこの台数は変わらない
45/84

47. ボコられ案⽐較(Async系)
⽅法 ステータス確認 フェイルオーバーフ
ック
同期⽅法 その他
MHA + LVS ログ ある Async /
Semisync
クラッシュセー
フスレーブ非対
応
mysqlfailover
+ LVS
ログ ある Async /
Semisync
レプリケーショ
ンのつなぎ替え
だけで、マスタ
ー昇格とまでは
⾔えない
mysqlfabric
+ Connector/
J
XMLRPCか
MySQLプロト
コルのAPI
ない Async /
Semisync
Connector/Jが
ブラックボック
ス
mysqlfabric
+
mysqlrouter
XMLRPCか
MySQLプロト
コルのAPI
ない Async /
Semisync
46/84

48. ボコられ案⽐較(Sync系)
⽅法 ステータス確認 フェイルオーバーフ
ック
同期⽅法 その他
PXC +
Connector/J
SHOW
GLOBAL
STATUS
必要ない Virtual Sync
PXC + LVS SHOW
GLOBAL
STATUS,
ipvsadm
必要ない Virtual Sync コネクションプ
ールと相性が悪
いのが難点
PXC APサーバ
ー相乗り
SHOW
GLOBAL
STATUS
必要ない Virtual Sync スケールアウト
戦略で死ぬ
MySQL
Cluster
ndb̲mgm 必要ない NDB 俺が悪かった
47/84

49. で
48/84

50. PXCを選ばなかった理由
マルチマスターでまである必要はない
だいぶ前に計ったやつではあるけど、Semisyncから更に3割増しくら
いのレイテンシー
-
結局レイテンシーを嫌って、Asyncベースの 茨の道 地雷原を進むこ
とに
-
最⼩構成が3台(3プロセス)
スプリットブレイン体制を捨てるか-
1つを garbd (投票専⽤のプロセス)にするか-
49/84

51. PXCを選ばなかった理由
log_slave_updates でも、更新を分散させた時のbinlogの順
番が厳密には保証されない
wsrep内でコミットが制御されるから順番が異なることはないんだけ
ど特定のトランザクションを切断⾯にはできない
5.7のLogical Clockといっしょの結果整合性モデル
-
トランザクションガリガリなので、PITRはトランザクションを切断⾯
にしたい
-
50/84

52. MySQL Fabric + MySQL Routerを選んじゃった理由
なんか名前がかっこよかった 今は後悔している
マイエスキューエルファブリックって発⾳するとなんかかっこいい気
がしたんですよ。。
-
2年間、ちょっとずつ検証してみたけど、そろそろ使っても
いいかなと 錯覚 した
MySQL Fabricつらい Advent Calendar 2014-
MySQL Fabric＆Routerつらくない Advent Calendar 2015-
MHA, mysqlfailoverに⽐べてAPIの⼝を開いているので、外
部からの監視が楽
楽というよりは、作っておきたかったというかなんというか-
51/84

53. MySQL Fabricの理想
このサービス（︖）の複数のサイトは1つのMySQL Fabric
(mysqlfabricデーモンとバッキングストアのmysqld)で管理
スクリプトをフックするところがないので、MySQL Fabric
のXMLRPCかMySQLプロトコルの⼝を叩いて監視＆通知
MySQL Fabric対応コネクターはブラックボックスっぽいの
で使わず、MySQL Routerで切り替え
なんだかんだ⾔って mysqlfabric コマンドは慣れれば⾒やす
い
52/84

54. MySQL Fabricの理想
mysqlrouter と mysqlfabric は非同期でキャッシュを更新1.
APから mysqlrouter がESTAB2.
mysqlrouter はキャッシュを⾒てMySQL ServerとESTAB3.
AP => mysqlrouter => MySQL Server とNATされる。遅
延は10usくらい。
4.
53/84

55. MySQL Fabricの現実
MySQL FabricはMSR非対応
結果、まさかの場所にもう⼀個MySQL Router追加
コイツが、Fabric Cacheが更新されても切り替わらなくて頭を抱えているところ
確かにハートビート⾃体は通るから、 slave_net_timeout ⼩さくしてもしょうがない
んだよなあ。。
-
GTIDベースなんだからマスターもスレーブもフルメッシュにしちゃ
う⼿もあるなと思っている
-
54/84

56. MySQL Fabricの現実
MySQL
APAP
MySQL
APAP
MySQL
APAP
MySQL
mysqlrouter
マ ル チ ソ ー ス レ プ リ ケ ー シ ョ ン
55/84

57. MySQL Fabricの現実
バッキングストアが落ちると mysqlfabric デーモンがハング
する
落ちずに刺さったりDisk Fullで書き込みができなくても mysqlfabric
デーモンがハングする
mysqld が落ちたらすぐに mysqlfabric デーモンを落とすような仕組み⼊れた
mysqlfabric デーモンが落ちてさえいれば、mysqlrouterはキャッシュで動いてくれ
る
-
56/84

58. MySQL Fabricの現実
mysqlrouter と mysqlfabric は非同期でキャッシュを更新
<= ここが詰まる
1.
APから mysqlrouter がESTAB2.
mysqlrouter はキャッシュ更新が詰まってるのでMySQL
ServerとESTAB しにいかない
3.
57/84

59. orz
58/84

60. MySQL Fabricの現実
なぜかログを fabric.log テーブル（スキーマ名は可変）に
吐く。ファイルにも書く。
ファイルに書くより情報量が圧倒的に多い。ジェネラルログっぽい感
じ。
-
挙句、パラメーターで制御不可能-
テーブルあふれる => mysqlfabric デーモンがハングする =>
mysqlrouter が応答しなくなる のコンボ
-
59/84

61. MySQL Fabricの現実
fabric.log テーブルのパージはバッキングストアの
event_schedular にイベントで DELETEステートメントが登
録されてる
バッキングストアの event_schedular をONにしないとテーブルがあ
ふれる
-
event_schedular をONにしても、DELETEステートメントのWHERE
で使ってる関数の引数の順番間違ってて消えない
-
更に binlog_format= ROW で mysqlrouter が増えれば増えるほど
DELETEするだけで地獄が⾒える
-
event_schedular に設定されるパージ期間は mysqlfabric manage
setup した時のprune̲timeで固定という罠
-
結局テーブルにロギングしてるところをまるっと削除するパッチした-
60/84

62. MySQL Fabricの現実
もうずっと⻑いことMySQL WorkbenchからMySQL Fabric
に接続できない
⼀時期セミナーで「MySQL WorkbenchからMySQL Fabricが管理で
きます︕」と謳っていた時期があったのに…
-
MySQL Bugs: #74894: Failure to connect to MySQL Fabric
from a windows installed workbench.
-
とはいえ慣れれば mysqlfabric コマンドでも何とかなる
けど、監視⽤途にはパースが超めんどくさいので、昔みたいにJSONで返してくれるオ
プションも欲しかった。。
-
61/84

63. MySQL Fabricの現実
MySQL Bugs: #73206: MySQL Fabric should report a
warning when MySQL Event Scheduler is disabled
MySQL Bugs: #74894: Failure to connect to MySQL
Fabric from a windows installed workbench.
MySQL Bugs: #81557: MySQL Fabric uses wrong
argument of MAKETIME in prune̲log Event
MySQL Bugs: #81558: prune̲log event doesnʼt use
any index
MySQL Bugs: #81559: Incorrect WHERE clause in
dump̲servers fanction
62/84

64. MySQL Routerの理想
全NATで遅延の影響を受ける代わりに、アプリ側もインフラ
側も何も考えなくてもMySQL Fabricだけでフェイルオーバ
ーが完結する
Javaでコネクションプールとはいえ、全NATされてるから上⼿くルー
ティングされてくれると信じていた時期が俺にもありました
-
63/84

65. MySQL Routerの現実
コネクションプールとの相性が超絶悪かった
MySQL Fabricから構成変更の通知が来て、キャッシュを更新すると
ころまではいいんだけど
-
キャッシュを更新したタイミングで、今張ってるコネクションは
graceful stopとか
-
gracefulとか贅沢なこと⾔わないんでコネクション全部⼀度切ってく
れてもいいんですよ
-
何のためにパケットを全部NATしてるんですかあんた-
64/84

66. MySQL Routerの現実
APから mysqlrouter がESTAB1.
mysqlrouter と mysqlfabric は非同期通信でキャッシュを更
新
2.
mysqlrouter はキャッシュを⾒てMySQL ServerとESTAB3.
AP => mysqlrouter => MySQL Server とNATされる。遅
延は10usくらい。
4.
何故か mysqlfabric からキャッシュの更新通知が⾏って
も、 mysqlrouter => MySQL ServerのESTABが 切れない
5.
65/84

67. MySQL Routerの現実
シングルスレッドで、パケットを全てルーティングする
（NATな動き）ので、1万QPSとか叩くと mysqlrouter がボ
トルネックになって詰まる
それくらいの規模になったら複数の mysqlrouter プロセスを上げるし
かないけど
-
そんなトラフィックが来る予定はない
-
mysqlrouter の max_connections を1000以上にするとクラッシュす
るらしい
MySQL Bugs: #80260: MySQL Router is down with more than 1000
concurrent connections
-
66/84

68. MySQL Routerの現実
現在のコンフィグや、バックエンドをどう認識しているかな
んかを⾒るコマンドがない
監視はMySQLプロトコルで話しかけて、正しくルーティングされるか
どうかを SELECT @@hostname とかで⾒るしかない。
-
正直諦めてアプリケーションログが唸ったら…とかそんな感じ-
graceful restartの仕組みがないことが些細な問題に思えて
きた
67/84

69. MySQL Routerの現実
ルーティングの単位がポート
“site̲1のマスター” に対して1ポート、 “site̲1のスレーブ” に対して
1ポート、とか割り当てる
-
ポートがカブっても起動に失敗せず、カジュアルに起動する
もちろんポートはLISTENできないので動作が失われる-
:(;ﾞﾟʼωﾟʼ):-
68/84

70. MySQL Routerの現実
MySQL Routerには “MySQL Fabricに接続するためのアカ
ウント情報” を指定する。MySQL Router越しに接続するク
ライアントは “MySQL Serverに接続するためのアカウント
情報” を指定する
router.ini に password オプションがあるんだけれど、何か書くと
Configuration error: 'password' option is not allowed in the
configuration file. Router will prompt for password instead.
って怒られる
-
かといって指定しないと、プロンプトでパスワードを聞いてくる-
どうやってデーモン化しろと⾔うのか
仕⽅ないからMySQL Fabric側で protocol.mysql.disable_authentication= yes し
てる
systemd の設定ファイルに --password を渡せってことなのかしら
-
69/84

71. 我々⼀般⼈にはMySQL Fabricはまだもう少し早いのかも
知れない
とはいえ、黙って待ってても技術は勝⼿には枯れない
枯らしに⾏く⼈間はどこかに必要
できれば⾃分じゃない⼈がいい-
地雷を踏んでも⾜が壊れない⼈柱er募集
できれば⾃分じゃない⼈で-
70/84

72. ところでMySQL 5.7.13がリリースされて噴出してきた
ぁゃιぃバグ
MySQL Bugs: #81769 (アクセス権なし)
MySQL Bugs: #81772 (アクセス権なし)
71/84

73. :(;ﾞﾟʼωﾟʼ):
MSR、おまえ
もか
72/84

74. DBAの 悪 夢
は終わらない
73/84

75. 新しいことをやろうとするとボコられるところまでは覚悟
の上だけど
⼀緒に…とまでは⾔わなくとも
「それは困ったねえ」って⾔ってくれる友達がほしい
⼼が⿊くなっちゃう (c) Yappo
74/84

76. みなさまに送る575
地雷原
⼀緒に⾏けば
こわくない
踏みに⾏くなら
お供しますよ
75/84

77. なお、MySQL 5.7（の、
新規じゃない機能）に関
しては既に導⼊済みのこ
ともあり特に⽂句はない
です
76/84

78. (別の環境含め) MySQL 5.7でやったこと
SET GLOBAL innodb_buffer_pool_size = .. 経験済み
そこまで悪いものでもなかった (⼼臓には悪かった)-
MySQL Bugs: #77564: SIGABRT during resizing the InnoDB
Buffer Pool Online with memory full condition
-
sync_binlog= 1 でも5.6ほどひどくない (気がする)
sys スキーマ美味しいです
5.6にもガリガリインストールしてるから余計ありがたみはない-
77/84

79. (別の環境含め) MySQL 5.7でやったこと
むしろ既存の5.6をアップグレードした5.7でオンライン
gtid_mode= ON に移⾏できた。うれしい。
暗黙のテンポラリーテーブル
MyISAMにしてる( internal_tmp_disk_storage_engine= MyISAM )-
performance_schema_*_size とか
performance_schema_*_instances のデフォルトがautosize
になってるので、テキトーな値を秘伝のタレに追加
でないと運⽤中に思った以上にメモリー使⽤量が増えていく
で、 SET GLOBAL innodb_buffer_pool_size = .. でちょっと減らした。。
SHOW ENGINE performance_schema STATUS で⾒られるよ
-
78/84

80. (別の環境含め) MySQL 5.7でやったこと
slave_parallel_type= LOGICAL_CLOCK は指定してあるけ
ど、スレーブ側が slave_parallel_workers= 0 だからMTS
にはなってない
innodb_numa_interleave がLinux Genericバイナリーでは使
えない問題
新しいInnoDBのパンチホール圧縮も同様-
Linux Genericの.tar.gzをダウンロードして展開するスクリプトにし
てるけど、ソース取ってきてmakeする形式に書き換えるかも
-
79/84

81. (別の環境含め) MySQL 5.7でやったこと
innodb_default_row_format= Dynamic
まだ悪い⽅の洗礼は受けていない
ADD KEY, DROP KEY は影響なし、 ADD COLUMN で⾷らう
-
むしろDynamicになって innodb_large_prefix の恩恵を受けている
っぽい
-
mysql p ump
MyDumperでええやん-
80/84

82. 地雷を踏みに⾏くなら
⽇本MySQLユーザ会
http://mysql.gr.jp/frame/myna/index.php-
現在の主な活動は ML での意⾒交換です。時々オフ会も
あるかもしれませ ん :-)
MySQL に興味がある⽅はどなたでも⼊会できます。会
費はありませんし、 退会も⾃由です。
81/84

83. 地雷を踏みに⾏くなら
MySQL Casual
http://mysql-casual.org/-
perl-casualのコンセプトに触発され、もっと深く浅
く、広く狭くMySQLを使っていこうと思っている趣旨
の⼈とのつながりを作っていくための緩めのコミュニテ
ィです。
82/84

84. きみはひと
りじゃない
83/84

85. Questions
and/or
Suggestions?
84/84