MySQL clients

MySQL Clients! at MySQL Nippon Association 2013/03/15 yoku0825 modified version 2.

I’m yoku0825, working as DBA for the company’s web-service. Nice to meet you. I only play with MySQL. I can’t even log in to PostgreSQL and Oracle! :) Living in MyNA ML about 1 year, MySQL Bugs about half year. Tweeting what thinking, Blogging what studied.

平塚さん Oracle ACE認定おめでとうございます m(_”_)m

あとついでに MySQL5.6 GAおめでとうございます m(_”_)m

MySQL 5.6 General Available at 2013/02/05 I started to try 5.6 series at 5.6.6 to play InnoDB memcached Plugin :)

There are many kind of functional improvements. Online ALTER TABLE, Buffer Pool Dump InnoDB Fulltext,FLUSH TABLES for export, InnoDB memcached Plugin, Read Only Transaction, Multi Thread Slave, Binlog Checksum Materialization Derived Table, Batched Key Access, And many so on..

But! Do you know how function has been added to clients?

mysqld以外にも (意外と)面白いことありますよ！ …というお話をしますが、そんな大それたものではないです。

MySQL Client & Utility Programs • mysql • mysqladmin • mysqldump • mysql_install_db • (My Favorite!) mysql_config_editor • (cool!) mysqlbinlog And on..

mysql The MySQL Command-Line Tool • --histignore 5.5までは$HOME/.mysql_historyになんでもかんでも記録されていたが、特定のキーワードを含むエントリを記録しない様に設定可能。デフォルトでは“*IDENTIFIED*:*PASSWORD*“が記録から弾かれる (セミコロンはORとして解釈されます) ⇒特に構文解析しているわけではないので、 SELECT PASSWORD(‘hoge’); も記録から弾かれるようになります。

mysql The MySQL Command-Line Tool • --default-character-set おなじみのこのパラメータにujis, sjis, cp932など (UTF-8以外のマルチバイト、という感じ。big5とかも)を渡すと Segmentation faultするバグが！ｗ ⇒.mysql_historyに触るあたりのマルチバイト判定に問題がありそう。 ⇒なのでmysqlクライアントだけです。 http://bugs.mysql.com/bug.php?id=68107 それまでは”SET NAMES ujis;”でしのぎましょう。。 ⇒UTF-8使えという神託的なものでもある気がしますが。

mysqldump A Database Backup Program • 5.6のmysqldに向けて5.5未満のmysqldumpを使うとError: 1064(ER_PARSE_ERROR)で怒られます。 ⇒5.5までのmysqldumpは内部的に ”SET OPTION SQL_QUOTE_SHOW_CREATE=1”を呼んでいるそうな。 ⇒5.6で古い”SET OPTION ..”構文は完全に廃止されたので、そこがエラーになってしまう。 ⇒5.0で既に”SET ..”構文に置き換えられていて、 5.5のmysqldumpに残っていたのはご愛嬌という感じ…？ http://bugs.mysql.com/bug.php?id=67507 特に気に入った新機能はないです。 --add-drop-triggerと--set-gtid-purgedくらいですかね。

mysql_install_db Initialize MySQL Data Directory • Shell script -> Perl Script • --random-passwords rootのパスワードをランダムに設定し、password_expiredを’Y’に設定します。ランダムパスワードは$HOME/.mysql_secretに記録。暗黙のデフォルトではないですが、rpm(やdpkg)でインストールする時はこのオプションつきで叩かれます。 mysql_secure_installation的なことも一緒にやってくれます。 • Create $MYSQL_HOME/my.cnf from support-files/my- default.cnf $MYSQL_HOME/my.cnfにファイルを作成します。 2013/03/15現在、このmy.cnfは sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 以外全てがコメントアウトされています。

contents of $MYSQL_HOME/my.cnf

mysql_install_db Initialize MySQL Data Directory • $MYSQL_HOME/my.cnfファイルは/etc/my.cnfの内容をオーバーライドします。 (優先度低) /etc/my.cnf -> /etc/mysql/my.cnf -> /usr/local/mysql/etc/my.cnf -> $MYSQL_HOME/my.cnf -> --defaults-extra-file -> $HOME/.my.cnf -> $HOME/.mylogin.cnf (優先度高) /etc/my.cnfにsql_modeを設定している場合、$MYSQL_HOME/my.cnfを消すかコメントアウトするかする必要があります。 • オーバーライドされる仕組み http://dev.mysql.com/doc/refman/5.6/en/option-files.html • 確かにmysql_install_dbの説明のところに、sql_modeは上書きするって書いてありますが。。 http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html ⇒不親切だからファイル作るかどうかオプションにしようよって Feature Requestしてみたり。 http://bugs.mysql.com/bug.php?id=68643

mysql_config_editor MySQL Configuration Utility • $HOME/.mylogin.cnf $HOME/.my.cnfに [mysql] user=tpcc password=.. [mysqldump] user=root password=.. と書いておくとコマンドライン引数で渡す必要がありませんでしたが、平文で書くのはどうも嫌でした。

.mylogin.cnfを使ってみる

mysqldumpだけ別のユーザーで

任意のlogin-pathを指定可能

mysql_config_editor MySQL Configuration Utility • .mylogin.cnfのファイル名は環境変数で制御します。指定するコマンドラインパラメータはなし。 $MYSQL_TEST_LOGIN_FILEで制御する(ファイル名まで設定する) なんかWindowsのデフォルトが%APPDATA%だったり %APPDATA%MySQLだったりマニュアルの表記が揺れてる。 http://dev.mysql.com/doc/refman/5.6/en/option-files.html http://dev.mysql.com/doc/refman/5.6/en/environment-variables.html 気付いちゃったからBugsに上げてみたり（誰も気にしないだろうけど）

mysqlbinlog Utility for Processing Binary Log Files • --read-from-remote-master 5.5までにあった--read-from-remote-serverは --read-from-remote-master=BINLOG-DUMP-NON-GTIDSにマップされました。 BINLOG-DUMP-GTIDSとBINLOG-DUMP-NON-GTIDSの違いがよく判らない。。 • --stop-never --read-from-remote-masterとあわせて使うことで、mysqlbinlogがtail -f的な動きになります。 --rawと組み合わせると黙って動き続けます。 • --raw いつものSQLステートメントな出力ではなく、デコードせずに黙ってファイルに出力するようになります。 • --result-file --rawを使っていない時は単に標準出力を指定したファイルにリダイレクトするだけですが、 --rawとあわせて使う場合は<result-fileの指定><マスターのバイナリログファイル名>が mysqlbinlogによって作成されるファイル名になります。

tail -f的にマスターの更新を待機

FLUSH LOGSしても追従する

--rawを組み合わせてバックアップ開始更新 FLUSH LOGS

mysqlbinlog Utility for Processing Binary Log Files • tail -f的にバイナリログを追尾するとき $ mysqlbinlog --read-from-remote-master=BINLOG-DUMP-GTIDS --host=192.168.xxx.xxx --port=64056 --user=replicator --password --stop-never bin.001725 ⇒指定したバイナリログファイル名以降を追従します。内部的に”SHOW MASTER EVENTS in ‘bin.001725’”のように置き換えるので、ファイル名だけでパスは要りません。 ⇒5.5のマスターに繋ぐときは--read-from-remote-master=BINLOG-DUMP-NON- GTID(--read-from-remote-serverでも可)にする必要あり。 • バックアップ的に使うとき $ mysqlbinlog --read-from-remote-master=BINLOG-DUMP-GTIDS --host=192.168.xxx.xxx --port=64056 --user=replicator --password=xxxx --stop-never --raw --result- file=my_name_is. bin.001725 & ⇒バックグラウンドに回す時はパスワードプロンプトが来るとそこで止まってしまうので、 $HOME/.mylogin.cnfを使うのが良いです！

mysqlbinlog Utility for Processing Binary Log Files • MySQL-Client*.rpmに入っています。 ⇒Serverは5.5据え置きで、今までrsyncで取っていたバイナリログだけ mysqlbinlog方式に変えるとかできます。 • binlog-checksumとか色々追加されている関係で、デフォルトのままではMySQL5.5の mysqlbinlogは(mysqldも) 5.6のバイナリログを解釈できません。 ⇒サーバー側に--binlog-checksum=noneと --log-bin-use-v1-row-eventsをつけると、 5.5と互換性のある形でバイナリログを吐きます。 ⇒先にマスターをバージョンアップするとかしてはいけませんよ！

mysqlbinlog Utility for Processing Binary Log Files • Ctrl+Cでmysqlbinlogを切ってもコネクションが残留し続ける。 ⇒Bugs上げました。上げたばかりなのでVerifyされるかどうかも謎です。 http://bugs.mysql.com/bug.php?id=68681 --- ここからadded at 2013/03/18 --- 残念なことになっていたのyoku0825の脳髄であったことが判明したので、ここから検証過程の追記です。

mysqlbinlog接続、切断前 mysql56> show processlist; +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ | 95 | replicator | dev-personal-04.lo.gmo-pass.jp:49762 | NULL | Binlog Dump GTID | 1281 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | | 96 | root | localhost | NULL | Query | 0 | init | show processlist | +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ 2 rows in set (0.00 sec) # lsof -p 6382 .. mysqld 6382 mysql 18u IPv4 7355566 0t0 TCP *:64056 (LISTEN) mysqld 6382 mysql 19u IPv4 7622665 0t0 TCP dev-personal-04.lo.gmo-pass.jp:64056->dev-personal- 04.lo.gmo-pass.jp:49762 (ESTABLISHED) .. # netstat -antp | grep "6382/mysqld" tcp 0 0 0.0.0.0:64056 0.0.0.0:* LISTEN 6382/mysqld tcp 0 0 192.168.198.214:64056 192.168.198.214:49762 ESTABLISHED 6382/mysqld

mysqlbinlog切断 mysql56> show processlist; +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ | 95 | replicator | dev-personal-04.lo.gmo-pass.jp:49762 | NULL | Binlog Dump GTID | 1415 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | | 97 | root | localhost | NULL | Query | 0 | init | show processlist | +----+------------+--------------------------------------+------+------------------+------+----------------------------------- ------------------------------------+------------------+ 2 rows in set (0.01 sec) # lsof -p 6382 .. mysqld 6382 mysql 18u IPv4 7355566 0t0 TCP *:64056 (LISTEN) mysqld 6382 mysql 19u IPv4 7625437 0t0 TCP dev-personal-04.lo.gmo-pass.jp:64056->dev-personal- 04.lo.gmo-pass.jp:49781 (CLOSE_WAIT) .. # netstat -antp | grep "6382/mysqld" tcp 0 0 0.0.0.0:64056 0.0.0.0:* LISTEN 6382/mysqld tcp 0 0 192.168.198.214:64056 192.168.198.214:49762 CLOSE_WAIT 6382/mysqld * straceでmysqldを追いかけていても、 mysqlbinlogを止めたところでは当然何の出力もなし。

1つ更新してみたときのstrace [pid 6598] fsync(9) = 0 [pid 6598] write(43, "TwFQ! 400,0005200001d2P20p521342227377032"..., 240) = 240 [pid 6593] read(40, "TwFQ! 400,0005200001d2P20p521342227377032"..., 7719) = 240 [pid 6593] read(40, "", 7479) = 0 [pid 6593] sendto(19, "-002060TwFQ! 400,0005200001d2P20p521"..., 260, MSG_DONTWAIT, NULL, 0) = 260 [pid 6398] fsync(9) = 0 [pid 6400] fsync(4) = 0 [pid 6390] pwrite(49, "34516e,00033773773773773773773773770000$K=27E277000000"..., 16384, 49152 <unfinished ...> [pid 6390] <... pwrite resumed> ) = 16384 [pid 6390] fsync(4 <unfinished ...> [pid 6390] <... fsync resumed> ) = 0 [pid 6390] fsync(49) = 0 [pid 6385] pwrite(9, "0000003250000$K=3444KC344020000377377377377377377377377"..., 512, 1536) = 512 [pid 6385] fsync(9) = 0 * ちょっと端折りながらですが、9番がib_logfile0, 43番と40番が bin.001759, 19番がmysqlbinlogが掴んでいたTCPソケット, 4番が ibdata1, 49番がt1.ibd(更新したテーブル)です。

1つ更新してみたときのstrace [pid 6598] fsync(9) = 0 [pid 6598] write(43, "TwFQ! 400,0005200001d2P20p521342227377032"..., 240) = 240 [pid 6593] read(40, "TwFQ! 400,0005200001d2P20p521342227377032"..., 7719) = 240 [pid 6593] read(40, "", 7479) = 0 [pid 6593] sendto(19, "-002060TwFQ! 400,0005200001d2P20p521"..., 260, MSG_DONTWAIT, NULL, 0) = 260 [pid 6398] fsync(9) = 0 [pid 6400] fsync(4) = 0 [pid 6390] pwrite(49, "34516e,00033773773773773773773773770000$K=27E277000000"..., 16384, 49152 <unfinished ...> [pid 6390] <... pwrite resumed> ) = 16384 [pid 6390] fsync(4 <unfinished ...> [pid 6390] <... fsync resumed> ) = 0 [pid 6390] fsync(49) = 0 [pid 6385] pwrite(9, "0000003250000$K=3444KC344020000377377377377377377377377"..., 512, 1536) = 512 [pid 6385] fsync(9) = 0 * pid 6598のスレッド(操作用のmysqlクライアントと接続してるやつ) がInnoDBログファイルをfsync, バイナリログにwrite。pid 6593のスレッド(mysqlbinlogと接続していたやつ)が更新されたバイナリログからread、fd19(=mysqlbinlogが接続していたTCPソケット)にsendto。 sendtoはなぜか成功している(失敗なら戻り値は-1)

1つ更新してみたときのstrace（おまけ） [pid 6598] fsync(9) = 0 [pid 6598] write(43, "TwFQ! 400,0005200001d2P20p521342227377032"..., 240) = 240 [pid 6593] read(40, "TwFQ! 400,0005200001d2P20p521342227377032"..., 7719) = 240 [pid 6593] read(40, "", 7479) = 0 [pid 6593] sendto(19, "-002060TwFQ! 400,0005200001d2P20p521"..., 260, MSG_DONTWAIT, NULL, 0) = 260 [pid 6398] fsync(9) = 0 [pid 6400] fsync(4) = 0 [pid 6390] pwrite(49, "34516e,00033773773773773773773773770000$K=27E277000000"..., 16384, 49152 <unfinished ...> [pid 6390] <... pwrite resumed> ) = 16384 [pid 6390] fsync(4 <unfinished ...> [pid 6390] <... fsync resumed> ) = 0 [pid 6390] fsync(49) = 0 [pid 6385] pwrite(9, "0000003250000$K=3444KC344020000377377377377377377377377"..., 512, 1536) = 512 [pid 6385] fsync(9) = 0 * 後続の処理を見てみると、どうやらバイナリログにwriteが成功した後にもう一度InnoDBログをfsyncして、あとはバックグラウンドな別のスレッドがibdata1とかt1.ibdファイルによしなにwriteとfsyncをかけているっぽい（よく出来てるな。。）

もう1つ更新してみたときのstrace [pid 6593] read(40, "o{FQ! 400,000365200001d2P20p521342227377032"..., 7479) = 240 [pid 6593] read(40, "", 7239) = 0 [pid 6593] sendto(19, "-002120o{FQ! 400,000365200001d2P20p521"..., 260, MSG_DONTWAIT, NULL, 0) = -1 EPIPE (Broken pipe) [pid 6593] close(40) = 0 [pid 6593] clock_gettime(CLOCK_REALTIME, {1363573615, 192886816}) = 0 [pid 6593] shutdown(19, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) [pid 6593] close(19) = 0 * 該当のスレッドだけ抜き出してみました。更新されたバイナリログをreadして、fd19番にsendtoするところまでは同じで、ただし今度はBroken Pipeでエラー。それを受けて(だと思う)TCPソケットをshutdownしてfdをクローズ。ここでプロセスリストからも消えて破棄されてるのかスレッドキャッシュに行ったか。。

つまりもともとと全然変わらない動作なんですね。。orz お騒がせしました。。。orz ( ´-｀).oO（でも色々調べられて楽しかった） --- ここまでadded at 2013/03/18 ---

How are they? Do you feel something WAK-WAK? I introduced only I have known, but there are more functional addition in the world.

Do you come with us? Let’s research and pain and claim and laugh and enjoy with MySQL.

Thank you! ご清聴ありがとうございました！

MySQL clients

More Related Content

What's hot

Similar to MySQL clients

More from yoku0825

MySQL clients