mysql fabricでぼっこぼこにされたはなし

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


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

8/84

https://dev.mysql.com/doc/refman/5.7/en/replication-multi-source.html


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


[mysqld]master_info_repository= TABLErelay_log_info_repository = TABLE

10/84


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

https://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html


どうせ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

https://bugs.mysql.com/bug.php?id=80631

というかJSONデータ型のメリットを間違って解釈

MySQL 5.7 + JSON

“効率の良い、バイナリーフォーマット” の⼀⽂を誤読

空間効率も良いのかと思ったら別にそういう訳ではなかった“JSON関数を通すなら効率が良い” ってことだった

-

PKで引くだけならTEXT型の⽅が速いというね。。-

15/84

こうしてJSON型の夏は終わった

もともとgenerated columnで関数インデックスにする気は微塵もなかったそれならちゃんとカラムに詰める-午前中の正規化の話に近い-

MySQL側のJSON validatorったって、どうせライブラリー側でJSONエンコードしたりデコードしたりするわけで、それで救われる場⾯少ないはずTEXT型より空間効率が良いと思ってて、それで使いたかった幻想がぶち殺されたので正直JSON型にこだわる理由がどこにもなくなった

-

16/84


どうせ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

http://bugs.mysql.com/bug.php?id=76120






(∩´∀｀)∩ 踏んでおいてよかった（︖）

20/84


⽉間だか週間だかの単位で、アクションの回数にハードリミットをかける仕様があった折角だから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


冗⻑化も必要だよねシンプルにレプリケーション使うか

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


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


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


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


APAP

PXC

PXC PXC

38/84

PXC + Connector/J

jdbc:mysql://server1,server2,server3 で書ける

server1が倒れてたらserver2, server3と試すスタイル-コネクションプールとの相性はどうなんだろう-偏りは制御できなさそう-

追加コンポーネントなしでいい感じ

39/84


APAP

PXC

PXC PXC

LVSLVS

VIP

40/84

PXC + LVS(HAProxyでもいい)

コネクションプールとの相性が悪いのは良く知ってる⼀度偏っちゃうとtomcat再起動しないといけないとか-

鉄板っぽい構成だけども

41/84


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


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

APAP

MySQL

APAP

MySQL

APAP

MySQL

mysqlrouter


55/84


バッキングストアが落ちると mysqlfabric デーモンがハングする

落ちずに刺さったりDisk Fullで書き込みができなくても mysqlfabric デーモンがハングする

mysqld が落ちたらすぐに mysqlfabric デーモンを落とすような仕組み⼊れたmysqlfabric デーモンが落ちてさえいれば、mysqlrouterはキャッシュで動いてくれる

-

56/84


mysqlrouter と mysqlfabric は非同期でキャッシュを更新 <= ここが詰まる

1.

APから mysqlrouter がESTAB2. mysqlrouter はキャッシュ更新が詰まってるのでMySQL ServerとESTAB しにいかない

3.

57/84

orz58/84


なぜかログを fabric.log テーブル（スキーマ名は可変）に吐く。ファイルにも書く。

ファイルに書くより情報量が圧倒的に多い。ジェネラルログっぽい感じ。

-

挙句、パラメーターで制御不可能-テーブルあふれる => mysqlfabric デーモンがハングする => mysqlrouter が応答しなくなるのコンボ

-

59/84


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 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 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


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


シングルスレッドで、パケットを全てルーティングする（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プロトコルで話しかけて、正しくルーティングされるかどうかを SELECT @@hostname とかで⾒るしかない。

-

正直諦めてアプリケーションログが唸ったら…とかそんな感じ-

graceful restartの仕組みがないことが些細な問題に思えてきた

67/84


ルーティングの単位がポート“site̲1のマスター” に対して1ポート、 “site̲1のスレーブ” に対して1ポート、とか割り当てる

-

ポートがカブっても起動に失敗せず、カジュアルに起動するもちろんポートはLISTENできないので動作が失われる-:(;ﾞﾟʼωﾟʼ):-

68/84


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



むしろ既存の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


slave_parallel_type= LOGICAL_CLOCK は指定してあるけど、スレーブ側が slave_parallel_workers= 0 だからMTSにはなってないinnodb_numa_interleave がLinux Genericバイナリーでは使えない問題

新しいInnoDBのパンチホール圧縮も同様-Linux Genericの.tar.gzをダウンロードして展開するスクリプトにしてるけど、ソース取ってきてmakeする形式に書き換えるかも

-

79/84


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

mysql fabricでぼっこぼこにされたはなし

Technology