Upload
yoku0825
View
3.795
Download
4
Embed Size (px)
Citation preview
MySQL 5.7 + MySQL Fabric + MySQL Routerでぼっこぼこに され
た はなしシュレーディンガーの猫は観測された
2016/07/02
yoku0825YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa
\こんにちは/
yoku0825@とある企業のDBAオラクれない-ポスグれない-マイエスキューエる-
家に帰ると妻の夫-せがれの⽗-ムスメの⽗-
⽣息域Twitter: @yoku0825-Blog: ⽇々の覚書-MyNA ML: ⽇本MySQLユーザ会-MySQL Casualʼs Slack: MySQL Casual-
1/84
結果、MySQL Fabricにはボコられました(悲)
2/84
これはMySQL Fabricに 悪 夢を描いたDBAが屍になるまでの物語である
3/84
このスライドに書かれた内容は個⼈の感想であり、所属する組織および所属しない組織の意⾒を代表するわ
けがありません4/84
ボコられるまでの軌跡(1)
マルチサイトなサービス各サービス⽤のDBは独⽴していなければならないa. 各サービス⽤のDBをまとめて集計するバッチがあるb.
5/84
あっ、これ 進研ゼミ MySQL
Casualで⾒たやつだ︕
6/84
各DB独⽴&まとめて集計
APAPAPAP APAP
MySQL MySQL MySQL
MySQL
Multi-Source Replication
7/84
Multi-Source Replication
MySQL :: MySQL 5.7 Reference Manual :: 18.1.4 MySQL Multi-Source Replication各マスターごとにI/Oスレッドとリレーログ⽣やせば良いんじゃね︖ という 雑な シンプルな考え⽅で実装されている
8/84
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
Multi-Source Replication
[mysqld]master_info_repository= TABLErelay_log_info_repository = TABLE
10/84
Multi-Source Replication
mysql> CHANGE MASTER TO master_host = 'xxx', master_port = xxx, master_user = 'xxx', master_password = 'xxx', master_auto_position = 1 FOR CHANNEL 'site_1';mysql> SHOW SLAVE STATUS\G*************************** 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
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 TablesOh..
-
12/84
ボコられるまでの軌跡(2)
どうせ5.7使うならJSON型使いたいよねログテーブル的なやつで、ブラウザの情報とか結構残したりするらしいし
-
SQL的にはPKで引いて、アプリケーション側でJSONデコードして表⽰したり
-
集計に使わず、画⾯表⽰⽤のところだけ-
13/84
⽴ちはだかるConnector/Jの壁
MySQL Bugs: #80631: ResultSet.getString return garbled result with json type data
Connector/Jだとマルチバイト⽂字が化ける-まだ直ってない-マルチバイトもテストしてくれよおおおお-
14/84
というかJSONデータ型のメリットを間違って解釈
MySQL 5.7 + JSON
“効率の良い、バイナリーフォーマット” の⼀⽂を誤読
空間効率も良いのかと思ったら別にそういう訳ではなかった“JSON関数を通すなら効率が良い” ってことだった
-
PKで引くだけならTEXT型の⽅が速いというね。。-
15/84
こうしてJSON型の夏は終わった
もともとgenerated columnで関数インデックスにする気は微塵もなかったそれならちゃんとカラムに詰める-午前中の正規化の話に近い-
MySQL側のJSON validatorったって、どうせライブラリー側でJSONエンコードしたりデコードしたりするわけで、それで救われる場⾯少ないはずTEXT型より空間効率が良いと思ってて、それで使いたかった幻想がぶち殺されたので正直JSON型にこだわる理由がどこにもなくなった
-
16/84
ボコられるまでの軌跡(3)
どうせ5.7使うならInnoDB FTSやっとくかVMでスタートすることが決まってるので、メモリーを際限なく⾷らう Mroonga(Groonga) さんとはちょっと相性が悪い
-
そんなヘビーに使う訳じゃないので、Mroongaほどスピード要らないはず
-
トランザクションガリガリな感じなので…。-そこに地雷があるから-
17/84
InnoDB FTS + mecab-ipadic-neologd
吊るしのIPA辞書は⼼許ないので、 neologd/mecab-ipadic-neologd を辞書に利⽤
Ngramは最初からあきらめてる-MySQLの全⽂検索に関するあれやこれや-辞書まで含めてApache License 2.0で利⽤できるらしい-
18/84
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
(∩´∀`)∩ 踏んでおいてよかった(︖)
20/84
ボコられるまでの軌跡(4)
⽉間だか週間だかの単位で、アクションの回数にハードリミットをかける仕様があった折角だからgenerated columnで似非CHECK制約してみようず︕︕
21/84
generated column de CHECK制約
mysql> SHOW CREATE TABLE amount_limit\G*************************** 1. row *************************** Table: amount_limitCreate 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_amount` <= `limit_amount`),1,NULL)) VIRTUAL NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb41 row in set (0.00 sec)
22/84
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
< (すいませんハードリミットだけじゃなくてソフトリミットも追加することになったんでやっぱりアプリ側でやります)
24/84
orz25/84
ボコられるまでの軌跡(5)
冗⻑化も必要だよねシンプルにレプリケーション使うか
MHA || mysqlfailover + LVS, MySQL Fabric + MySQL Router-
PXC(Percona XtraDB Cluster .. GaleraのPercona Server実装)使うか
-
MySQL Clusterはいくら何でもユースケースじゃないな-スレーブは読み込み分散⽤途じゃなくてホットスワップ遅延させたくない&VMスタートだからスケールアップ戦略でいく-
26/84
ボコられ案(5-1)
APAPAPAP APAP
MySQL MySQL MySQL
MySQL
マルチソースレプリケーション
Slave Slave Slave
27/84
ボコられ案(5-1-1)
APAP
Master Slave
LVSLVS
VIP
MHA/mysqlfailover
Monitor/Demote
Monitor/Promote
Notification
28/84
MHAを選ばなかった理由
5.6以降のクラッシュセーフスレーブと相性が悪いマスターの mysql.slave_relay_log_info をSELECTして結果が返ってこないので転ける
-
クラッシュセーフスレーブを切りたくはないので、MHAは使ってない-
5.7のMSRに絶対対応していないそもそも↑の問題があるので、パッチしてまで使う情熱はないというかエコシステムはゆっくり後ろに乗りたい。。
-
29/84
mysqlfailoverを選ばなかった理由
read_only を全くいじってくれないあたりで諦めたレプリケーションのつなぎ替えはしてくれるけど、それしかしてくれない調⼦がおかしくなると mysql.failover_console をいじってやらないといけない。割と引っかかる。。--exec-before と --exec-after があるのは良かったんだけど…
正直劣化MHA-
30/84
ボコられ案(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
MySQL Fabricのもともとの形
Fabric対応コネクター(Connector/J, Connector/.NET, Connector/Python)が mysqlfabricデーモンへの問い合わせとルーティングをやるコネクターからの接続先は mysqlfabric デーモンを指定する-アカウント情報だけ、MySQL Fabric⽤のとリアルサーバー⽤のを両⽅渡す
-
Connector/Jなんてただでさえ⼿に負えてないのに更にブラックボックス追加は⾟い
Connector/Cは割と素直だったんだけど、Labsから消えましたね…-
32/84
ボコられ案(5-1-3)
Master Slave
mysqlfabric
Monitor/Demote
Monitor/Promote
AP
AP
mysqlrouter127.0.0.1:3306
AP
AP
mysqlrouter127.0.0.1:3306
Lookup Group QueryRouting(NAT)
Routing(NAT)
33/84
MySQL Fabric + MySQL Router
Fabric対応コネクターの代わりに mysqlrouter が問い合わせとルーティングを司る
MySQL Fabric⽤のアカウントとパスワードは mysqlrouter に設定-アプリケーションからはMySQL Routerのポートに対してリアルサーバーのアカウント情報を渡す
-
MySQL Routerがブラックボックスっぽくなるけど、Pure JavaなConnector/Jに⽐べてC++なMySQL Routerの⽅が気が楽
34/84
ボコられ案(5-2)
MySQL
マルチソースレプリケーション
APAP
MySQL
APAP
MySQL
APAP
MySQL
35/84
いつものレプリケーションに
SlaveMaster
COMMIT
InnoDB log
InnoDB Tablespace
client
Binary Log
Binlog Dump I/O Thread Relay Log
SQL Thread
COMMIT
36/84
wsrepをプラス
SlaveMaster
COMMIT
InnoDB log
InnoDB Tablespace
client
wsrep
Galera Cache wsrep
InnoDB log
InnoDB Tablespace
ACK
Galera Cache
37/84
ボコられ案(5-2-1)
APAP
PXC
PXC PXC
38/84
PXC + Connector/J
jdbc:mysql://server1,server2,server3 で書ける
server1が倒れてたらserver2, server3と試すスタイル-コネクションプールとの相性はどうなんだろう-偏りは制御できなさそう-
追加コンポーネントなしでいい感じ
39/84
ボコられ案(5-2-2)
APAP
PXC
PXC PXC
LVSLVS
VIP
40/84
PXC + LVS(HAProxyでもいい)
コネクションプールとの相性が悪いのは良く知ってる⼀度偏っちゃうとtomcat再起動しないといけないとか-
鉄板っぽい構成だけども
41/84
ボコられ案(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
PXCのAPサーバー相乗り
割とやりたかったんだけど全⼒で⽌められたPXCは台数増えるほど更新性能が落ちるので、APに引きずられてスケールアウトしていくと死が⾒える更新量がすごく⼩さく、参照局所性が⾼いトラフィックなら相性が良いはず
-
43/84
ボコられ案(5-3)
MySQL Clusterなので省略
44/84
ボコられ案⽐較
ド新規なので gtid_mode= ON は特に問題にしていないマネージャーノードまたはMySQL Fabricを動かすノードでもともと1台取るつもりなのでそこの台数は変わらない
45/84
ボコられ案⽐較(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
ボコられ案⽐較(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
で48/84
PXCを選ばなかった理由
マルチマスターでまである必要はないだいぶ前に計ったやつではあるけど、Semisyncから更に3割増しくらいのレイテンシー
-
結局レイテンシーを嫌って、Asyncベースの 茨の道 地雷原を進むことに
-
最⼩構成が3台(3プロセス)スプリットブレイン体制を捨てるか-1つを garbd (投票専⽤のプロセス)にするか-
49/84
PXCを選ばなかった理由
log_slave_updates でも、更新を分散させた時のbinlogの順番が厳密には保証されない
wsrep内でコミットが制御されるから順番が異なることはないんだけど特定のトランザクションを切断⾯にはできない
5.7のLogical Clockといっしょの結果整合性モデル
-
トランザクションガリガリなので、PITRはトランザクションを切断⾯にしたい
-
50/84
MySQL Fabric + MySQL Routerを選んじゃった理由
なんか名前がかっこよかった 今は後悔している
マイエスキューエルファブリックって発⾳するとなんかかっこいい気がしたんですよ。。
-
2年間、ちょっとずつ検証してみたけど、そろそろ使ってもいいかなと 錯覚 した
MySQL Fabricつらい Advent Calendar 2014-MySQL Fabric&Routerつらくない Advent Calendar 2015-
MHA, mysqlfailoverに⽐べてAPIの⼝を開いているので、外部からの監視が楽楽というよりは、作っておきたかったというかなんというか-
51/84
MySQL Fabricの理想
このサービス(︖)の複数のサイトは1つのMySQL Fabric(mysqlfabricデーモンとバッキングストアのmysqld)で管理スクリプトをフックするところがないので、MySQL FabricのXMLRPCかMySQLプロトコルの⼝を叩いて監視&通知MySQL Fabric対応コネクターはブラックボックスっぽいので使わず、MySQL Routerで切り替えなんだかんだ⾔って mysqlfabric コマンドは慣れれば⾒やすい
52/84
MySQL Fabricの理想
mysqlrouter と mysqlfabric は非同期でキャッシュを更新1. APから mysqlrouter がESTAB2. mysqlrouter はキャッシュを⾒てMySQL ServerとESTAB3. AP => mysqlrouter => MySQL Server とNATされる。遅延は10usくらい。
4.
53/84
MySQL Fabricの現実
MySQL FabricはMSR非対応結果、まさかの場所にもう⼀個MySQL Router追加コイツが、Fabric Cacheが更新されても切り替わらなくて頭を抱えているところ確かにハートビート⾃体は通るから、 slave_net_timeout ⼩さくしてもしょうがないんだよなあ。。
-
GTIDベースなんだからマスターもスレーブもフルメッシュにしちゃう⼿もあるなと思っている
-
54/84
MySQL Fabricの現実
MySQL
APAP
MySQL
APAP
MySQL
APAP
MySQL
mysqlrouter
マルチソースレプリケーション
55/84
MySQL Fabricの現実
バッキングストアが落ちると mysqlfabric デーモンがハングする
落ちずに刺さったりDisk Fullで書き込みができなくても mysqlfabric デーモンがハングする
mysqld が落ちたらすぐに mysqlfabric デーモンを落とすような仕組み⼊れたmysqlfabric デーモンが落ちてさえいれば、mysqlrouterはキャッシュで動いてくれる
-
56/84
MySQL Fabricの現実
mysqlrouter と mysqlfabric は非同期でキャッシュを更新 <= ここが詰まる
1.
APから mysqlrouter がESTAB2. mysqlrouter はキャッシュ更新が詰まってるのでMySQL ServerとESTAB しにいかない
3.
57/84
orz58/84
MySQL Fabricの現実
なぜかログを fabric.log テーブル(スキーマ名は可変)に吐く。ファイルにも書く。
ファイルに書くより情報量が圧倒的に多い。ジェネラルログっぽい感じ。
-
挙句、パラメーターで制御不可能-テーブルあふれる => mysqlfabric デーモンがハングする => mysqlrouter が応答しなくなる のコンボ
-
59/84
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
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
MySQL Fabricの現実
MySQL Bugs: #73206: MySQL Fabric should report a warning when MySQL Event Scheduler is disabledMySQL 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 EventMySQL Bugs: #81558: prune̲log event doesnʼt use any indexMySQL Bugs: #81559: Incorrect WHERE clause in dump̲servers fanction
62/84
MySQL Routerの理想
全NATで遅延の影響を受ける代わりに、アプリ側もインフラ側も何も考えなくてもMySQL Fabricだけでフェイルオーバーが完結する
Javaでコネクションプールとはいえ、全NATされてるから上⼿くルーティングされてくれると信じていた時期が俺にもありました
-
63/84
MySQL Routerの現実
コネクションプールとの相性が超絶悪かったMySQL Fabricから構成変更の通知が来て、キャッシュを更新するところまではいいんだけど
-
キャッシュを更新したタイミングで、今張ってるコネクションはgraceful stopとか
-
gracefulとか贅沢なこと⾔わないんでコネクション全部⼀度切ってくれてもいいんですよ
-
何のためにパケットを全部NATしてるんですかあんた-
64/84
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
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
MySQL Routerの現実
現在のコンフィグや、バックエンドをどう認識しているかなんかを⾒るコマンドがない監視はMySQLプロトコルで話しかけて、正しくルーティングされるかどうかを SELECT @@hostname とかで⾒るしかない。
-
正直諦めてアプリケーションログが唸ったら…とかそんな感じ-
graceful restartの仕組みがないことが些細な問題に思えてきた
67/84
MySQL Routerの現実
ルーティングの単位がポート“site̲1のマスター” に対して1ポート、 “site̲1のスレーブ” に対して1ポート、とか割り当てる
-
ポートがカブっても起動に失敗せず、カジュアルに起動するもちろんポートはLISTENできないので動作が失われる-:(;゙゚ʼω゚ʼ):-
68/84
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
我々⼀般⼈にはMySQL Fabricはまだもう少し早いのかも知れない
とはいえ、黙って待ってても技術は勝⼿には枯れない枯らしに⾏く⼈間はどこかに必要できれば⾃分じゃない⼈がいい-
地雷を踏んでも⾜が壊れない⼈柱er募集できれば⾃分じゃない⼈で-
70/84
ところでMySQL 5.7.13がリリースされて噴出してきたぁゃιぃバグ
MySQL Bugs: #81769 (アクセス権なし)MySQL Bugs: #81772 (アクセス権なし)
71/84
:(;゙゚ʼω゚ʼ): MSR、おまえ
もか72/84
DBAの 悪 夢は終わらない
73/84
新しいことをやろうとするとボコられるところまでは覚悟の上だけど
⼀緒に…とまでは⾔わなくとも「それは困ったねえ」って⾔ってくれる友達がほしい⼼が⿊くなっちゃう (c) Yappo
74/84
みなさまに送る575
地雷原⼀緒に⾏けばこわくない踏みに⾏くならお供しますよ
75/84
なお、MySQL 5.7(の、新規じゃない機能)に関しては既に導⼊済みのこともあり特に⽂句はない
です76/84
(別の環境含め) 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
(別の環境含め) 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
(別の環境含め) 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
(別の環境含め) MySQL 5.7でやったこと
innodb_default_row_format= Dynamic
まだ悪い⽅の洗礼は受けていないADD KEY, DROP KEY は影響なし、 ADD COLUMN で⾷らう
-
むしろDynamicになって innodb_large_prefix の恩恵を受けているっぽい
-
mysql p ump
MyDumperでええやん-
80/84
地雷を踏みに⾏くなら
⽇本MySQLユーザ会http://mysql.gr.jp/frame/myna/index.php-
現在の主な活動は ML での意⾒交換です。時々オフ会も
あるかもしれませ ん :-)
MySQL に興味がある⽅はどなたでも⼊会できます。会
費はありませんし、 退会も⾃由です。
81/84
地雷を踏みに⾏くなら
MySQL Casualhttp://mysql-casual.org/-
perl-casualのコンセプトに触発され、もっと深く浅
く、広く狭くMySQLを使っていこうと思っている趣旨
の⼈とのつながりを作っていくための緩めのコミュニテ
ィです。
82/84
きみはひとりじゃない
83/84
Questions and/or
Suggestions?84/84