GA

2015/09/15

MySQL Fabricつらい(リモートのmysqlfabricサーバーにmysqlfabricコマンドで接続するのにやっと成功)

MySQL Fabric、そのまま全てを(Fabric対応コネクターに全てを任せて)使うのはつらすぎるとして、せめてお手軽にMySQLを監視したりSwitchoverさせたりする器として使えないかな、というのを前からずっと考えていて(mysqlrpladmin 使えって? 知らない子ですね。。)

MySQL Fabricつらい Advent Calendar 2014 - Qiita


去年の12月に、「mysqlfabricをそのままクライアントとして使おうとするとlocalhostのmysqlfabricサーバーに接続しようとして転ける、リモートアドレス向けに接続しようとするとfabric.cfgの書き換えが必要でつらい」とか思ってばぐれぽしたのがこちら。
MySQL Bugs: #75308: mysqlfabric's --param option's syntax is not documented

実は4月くらいに返事が返ってきていたので、書いておこうかなと思います。

気が付いたらドキュメントにも上がってた。
MySQL :: MySQL Utilities :: 8.2.3.4 The Configuration Parameter (--param)



想定しているのは↓のような状態。
* 172.17.0.45なサーバーでバッキングストアのmysqldとmysqlfabricが起動している
* 172.17.0.46, 172.17.0.47なサーバーではmysqlfabricに管理されているmysqldが動いている。mysqlfabricコマンド(MySQL Utilities)はインストールされている。
* 172.17.0.47から172.17.0.45のmysqlfabricサーバーを叩いて情報を見たい

172.17.0.45$ mysqlfabric group lookup_servers myfabric1
Password for admin:
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

                         server_uuid          address    status      mode weight
------------------------------------ ---------------- --------- --------- ------
03a5981a-5ac9-11e5-9d85-0242ac11002f 172.17.0.47:3306 SECONDARY READ_ONLY    1.0
740fd00e-5ac8-11e5-9d81-0242ac11002e 172.17.0.46:3306 SECONDARY READ_ONLY    1.0

172.17.0.45からフツーに`mysqlfabric`をクライアントとして実行すると、この通り結果が返ってくる。


172.17.0.47$ mysqlfabric group lookup_servers myfabric1
Password for admin:
<urlopen error [Errno 111] Connection refused>

172.17.0.47$ strace -e connect mysqlfabric group lookup_servers myfabric1
--- SIGCHLD (Child exited) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
Password for admin:
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_INET, sin_port=htons(32274), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(32274), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(32274), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ECONNREFUSED (Connection refused)
connect(3, {sa_family=AF_INET, sin_port=htons(32274), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
<urlopen error [Errno 111] Connection refused>

172.17.0.47で同じことをやろうとすると、当然ながらlocalhost向けに接続しに行こうとして転ける。
ここまではいい。ここまではいいんだけど、

(少なくとも当時)どうやってリモートのmysqlfabricに接続するのかが全くドキュメントに書いてない。。:(;゙゚'ω゚'):


取り敢えず正解は、[protocol.xmlrpc]セクションのaddressを書き換えること。ただしこのパラメーターはmysqlfabricをサーバーとして起動した時はbind-address的な意味を持つので、サーバーとしても動かしてるホストでこれをホイホイ書き換えるのは結構危険。
日々の覚書: MySQL Fabricつらい(クライアントとしてのmysqlfabricとサーバーとしてのmysqlfabricのオプションの扱いが一緒)

で、mysqlfabricには--paramがあるからそれでfabric.cfgいじらなくてもパラメーター上書きできるんじゃね? => --paramの説明が全くドキュメントになくて記法が全然わからない

までが前回のあらすじ。


で、--paramの書き方は"--param=セクション.パラメータ=値"だそうだ。fabric.cfgに手を入れてない172.17.0.46からやってみる。

172.17.0.46$ mysqlfabric --param=protocol.xmlrpc.address=172.17.0.45:32274 group lookup_servers myfabric1
Password for admin:
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

                         server_uuid          address    status      mode weight
------------------------------------ ---------------- --------- --------- ------
03a5981a-5ac9-11e5-9d85-0242ac11002f 172.17.0.47:3306 SECONDARY READ_ONLY    1.0
740fd00e-5ac8-11e5-9d81-0242ac11002e 172.17.0.46:3306 SECONDARY READ_ONLY    1.0

( ゚д゚) ポカーン。。
今までの苦労が何だったんだくらいの勢いで簡単。


172.17.0.46$ mysqlfabric --param=protocol.xmlrpc.address=172.17.0.45:32274 --param=protocol.xmlrpc.password=xxxx group lookup_servers myfabric1
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

                         server_uuid          address    status      mode weight
------------------------------------ ---------------- --------- --------- ------
03a5981a-5ac9-11e5-9d85-0242ac11002f 172.17.0.47:3306 SECONDARY READ_ONLY    1.0
740fd00e-5ac8-11e5-9d81-0242ac11002e 172.17.0.46:3306 SECONDARY READ_ONLY    1.0

passwordを渡してやるとプロンプトも出なくなる。


172.17.0.46$ mysqlfabric --param=protocol.xmlrpc.address=172.17.0.45:32274 --param=protocol.xmlrpc.password=xxxx group promote myfabric1
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

                                uuid finished success result
------------------------------------ -------- ------- ------
1d048c45-bd68-4e79-b77d-0c9bb22a7431        1       1      1

state success          when                                                   description
----- ------- ------------- -------------------------------------------------------------
    3       2   1.44228e+09 Triggered by .
    4       2   1.44228e+09                      Executing action (_define_ha_operation).
    5       2   1.44228e+09                       Executed action (_define_ha_operation).
    3       2   1.44228e+09 Triggered by .
    4       2   1.44228e+09                      Executing action (_find_candidate_fail).
    5       2   1.44228e+09                       Executed action (_find_candidate_fail).
    3       2   1.44228e+09 Triggered by .
    4       2   1.44228e+09                     Executing action (_check_candidate_fail).
    5       2   1.44228e+09                      Executed action (_check_candidate_fail).
    3       2   1.44228e+09 Triggered by .
    4       2   1.44228e+09                          Executing action (_wait_slave_fail).
    5       2   1.44228e+09                           Executed action (_wait_slave_fail).
    3       2   1.44228e+09 Triggered by .
    4       2   1.44228e+09                      Executing action (_change_to_candidate).
    5       2   1.44228e+09                       Executed action (_change_to_candidate).


172.17.0.46$ mysqlfabric --param=protocol.xmlrpc.address=172.17.0.45:32274 --param=protocol.xmlrpc.password=xxxx group lookup_servers myfabric1
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

                         server_uuid          address    status       mode weight
------------------------------------ ---------------- --------- ---------- ------
03a5981a-5ac9-11e5-9d85-0242ac11002f 172.17.0.47:3306   PRIMARY READ_WRITE    1.0
740fd00e-5ac8-11e5-9d81-0242ac11002e 172.17.0.46:3306 SECONDARY  READ_ONLY    1.0

この通り、promoteもできる。
XML-RPCでつつけばいいんだけど、それだと何故か認証を無効にしないと通せなかったので、これを食ってシェル芸でiptablesで向き先変えるのとかやってみるかな。。

日々の覚書: MySQL Fabricつらい(XML-RPCでつついてみる編)

2015/09/08

MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです

MySQL 5.7.9では innodb_default_row_format というサーバー変数が追加される(らしい。5.7.9はリリース前なので試せない)
オンライン変更可能なグローバル変数なので、`SET GLOBAL innodb_default_row_format= ..'で変更も可能。暗黙のデフォルトは"Dynamic"。

名前と値から察せられる通り、kamipoさん の悲願をかなえる類のもの…なんだけれども、

MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる


これ、


The innodb_file_format configuration option is ignored if a table is created or altered to use ROW_FORMAT=DYNAMIC. For example, innodb_file_format=Antelope is ignored if you create a table with a DYNAMIC row format. The Barracuda file format is used instead.

http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_default_row_format



CREATE TABLEの時は良い。kamipo時代の到来という感じで、基本的にはメリットになる(や、ページが強制的に分割されるから、innodb_fill_factor とかいじってる人にはそうじゃないだろうけど)

ただしALTER TABLE、テメーはダメだ。勝手にROW_FORMAT= Dynamicとか押し込むな。頼む。

Change ROW_FORMAT property
Although ALGORITHM=INPLACE is allowed, the data is reorganized substantially, so it is still an expensive operation.
MySQL :: MySQL 5.7 Reference Manual :: 14.10.1 Overview of Online DDL

オンラインでALTER TABLEできるけど、テーブルの再構築が走るので重くなる。
ROW_FORMAT= Compactなテーブルは、ALTER TABLEする時にROW_FORMAT= Compactを明示的に指定しないといけない。

何故ALTER TABLEにも適用するようにしたんだこのオプション。。



ばぐれぽ読む限りは、割と希望が見える。

I have analyzed your bug and the reasoning for the deprecation of the variable and I do agree with your findings.

I am now handing over your request to developers for the decision-making.

Hopefully, we shall hear from them soon.

MySQL Bugs: #78347: innodb_default_row_format: Undesireable new behaviour

さあみんなであふぇくつみー。


【2015/09/08 13:53】





2015/09/01

論理削除Casual Talks #ronsakucasual でMySQLで論理削除する話をしてきた

論理削除 Casual Talks #1 : ATND に行ってきました。

アプリケーション方面では色々あるし、DBAから見ても良いことはないはず…と思ってましたが、 *ちゃんとMySQLの都合に沿ってやれば* 意外と忌避する理由もないことにふと気付きました。途中で3回くらいテーマ変更して最終的にこの形に落ち着いたカタチです。はふん。


ごめんなさい、当日流していたスライドに致命的な誤り(5.5以降ではなく、5.5以降 *ではない*)がありました。。まとめてくれた方ごめんなさい…><






DBAっぽく、という背景があったので、「論理削除? それUPDATEじゃん」というのが割と前提にあります。「DELETEじゃなくてUPDATEなんだから、削除とか言わずにスーパー非表示フラグでいいじゃん、システム的に *ちゃんとMySQLの都合に沿ってやれば* はそこまで変わらないし」というのが個人の見解です。

しゃらっと *ちゃんとMySQLの都合に沿ってやれば* という感じで流してますが、要はつまり









こういう話で、bool(MySQLだとboolがないのでENUMかTINYINTかな)だと必ず"="演算子の等価比較に持ち込める(そして持ち込めないクエリーはユーザートラフィックが吐いてはいけない)ので好きとか、カーディナリティーがどうこうというより必ず全てのセカンダリーインデックスの先頭につけろでないとインデックスだけで完結できないぞとかそんな話です。

( ´-`).oO(や、別に先頭じゃなくてもいいんですが、万人が正しいセカンダリーインデックスを考えてくれるかというとそうではないわけで、打ち漏らされるくらいなら全部先頭につけろって感じです。自信のある人は正しいところにつけてください。。

@t_wadaさん と色々お話できて、「こんなすごい人でも闇に対しては少しずつ立ち向かうしかないのだなぁ」とか「あー、SQLアンチパターンの本持ってくるの忘れた…(サインほしかった)」とか「エンタープライズ 闇 Casual」とか楽しかったです。

もし次があるなら、Oracle(DBの方)の重課金してる人たちがスーパー非表示についてどう思ってるのかとか聞きたいですね。「スーパー非表示? え、Flashbackじゃだめなの?」みたいな。

@kenchanくんさん お疲れ様でした!



ちなみにスライド冒頭のInnoDBさんの「よくやるよくやる」はチェンジバッファのことですのでご安心ください(?)
論理削除(ライフサイクルを終えるまでスーパー非表示)と非同期削除(一時的にスーパー非表示&非同期パージ)の間には少し溝があるような気がしました。