MySQL clients

MySQL Clients!at MySQL Nippon Association

2013/03/15yoku0825

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 Availableat 2013/02/05

I started to try 5.6 series at 5.6.6to play InnoDB memcached Plugin :)

There are many kind of functional improvements.

Online ALTER TABLE, Buffer Pool DumpInnoDB 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 knowhow 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..

mysqlThe MySQL Command-Line Tool

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

MySQL 5.5.30

MySQL 5.6.10

mysqlThe 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 使えという神託的なものでもある気がしますが。

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


mysqldumpA 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_dbInitialize 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以外全てがコメントアウトされています。

--random-passwords

$HOME/.mysql_secret

condition of mysql.user

contents of $MYSQL_HOME/my.cnf

mysql_install_dbInitialize 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

http://dev.mysql.com/doc/refman/5.6/en/option-files.html


http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html

http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html



mysql_config_editorMySQL Configuration Utility

• $HOME/.mylogin.cnf　 $HOME/.my.cnf に

　　 [mysql]　　 user=tpcc　　 password=..　　 [mysqldump]　　 user=root　　 password=..

　と書いておくとコマンドライン引数で渡す必要がありませんでしたが、平文で書くのはどうも嫌でした。

.mylogin.cnf を使ってみる

mysqldump だけ別のユーザーで

任意の login-path を指定可能

mysql_config_editorMySQL 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 に上げてみたり（誰も気にしないだろうけど）



http://dev.mysql.com/doc/refman/5.6/en/environment-variables.html

http://dev.mysql.com/doc/refman/5.6/en/environment-variables.html

mysqlbinlogUtility 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


• 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 を使うのが良いです！


• 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 と互換性のある形でバイナリログを吐きます。　⇒先にマスターをバージョンアップするとかしてはいけませんよ！

しかし。。


• 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 |+----+------------+--------------------------------------+------+------------------+--------+-----------------------------------------------------------------------+------------------+| 66 | replicator | dev-personal-04.lo.gmo-pass.jp:48357 | NULL | Binlog Dump GTID | 198460 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 67 | replicator | dev-personal-04.lo.gmo-pass.jp:48358 | NULL | Binlog Dump GTID | 198459 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 69 | root | localhost | NULL | Query | 0 | init | show processlist || 70 | replicator | dev-personal-04.lo.gmo-pass.jp:49725 | NULL | Binlog Dump GTID | 9 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 71 | replicator | dev-personal-04.lo.gmo-pass.jp:49726 | NULL | Binlog Dump GTID | 7 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 72 | replicator | dev-personal-04.lo.gmo-pass.jp:49727 | NULL | Binlog Dump GTID | 5 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |+----+------------+--------------------------------------+------+------------------+--------+-----------------------------------------------------------------------+------------------+6 rows in set (0.00 sec)

プロセスはがっつり残ってらっしゃる。66, 67が当日から残っていたやつ、70～72は今日起動＆停止したやつ。

何か更新してみるmysql56> dedrop table t12,;Query OK, 0 rows affected (0.09 sec)

mysql56> show processlist;+----+------------+--------------------------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------------+--------------------------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+| 69 | root | localhost | d1 | Query | 0 | init | show processlist || 70 | replicator | dev-personal-04.lo.gmo-pass.jp:49725 | NULL | Binlog Dump GTID | 40 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 71 | replicator | dev-personal-04.lo.gmo-pass.jp:49726 | NULL | Binlog Dump GTID | 38 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 72 | replicator | dev-personal-04.lo.gmo-pass.jp:49727 | NULL | Binlog Dump GTID | 36 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |+----+------------+--------------------------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+4 rows in set (0.00 sec)

…古いの(MyNA会当日に試してたやつ)が消えた。ついさっき接続＆切断した70～72のクライアントは残っている。

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/mysqldtcp 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/mysqldtcp 0 0 192.168.198.214:64056 192.168.198.214:49762 CLOSE_WAIT 6382/mysqld

* straceで mysqldを追いかけていても、mysqlbinlogを止めたところでは当然何の出力もなし。

1 つ更新してみたmysql56> INSERT INTO t1 VALUES(1, md5(1));Query OK, 0 rows affected (0.01 sec)

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 | 1613 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 97 | root | localhost | d1 | 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 sock 0,6 0t0 7625437 can't identify protocol..


1 つ更新してみたときの strace

[pid 6598] fsync(9) = 0[pid 6598] write(43, "TwFQ! \4\0\0,\0\0\0\5\2\0\0\0\0\1d2P\20p\5\21\342\227\377\0\32"..., 240) = 240[pid 6593] read(40, "TwFQ! \4\0\0,\0\0\0\5\2\0\0\0\0\1d2P\20p\5\21\342\227\377\0\32"..., 7719) = 240[pid 6593] read(40, "", 7479) = 0[pid 6593] sendto(19, "-\0\0\206\0TwFQ! \4\0\0,\0\0\0\5\2\0\0\0\0\1d2P\20p\5\21"..., 260, MSG_DONTWAIT, NULL, 0) = 260[pid 6398] fsync(9) = 0[pid 6400] fsync(4) = 0[pid 6390] pwrite(49, "\345\16e,\0\0\0\3\377\377\377\377\377\377\377\377\0\0\0\0$K=\27E\277\0\0\0\0\0\0"..., 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, "\0\0\0\0\0\0\3\25\0\0\0\0$K=\344\4KC\344\0\200\0\0\377\377\377\377\377\377\377\377"..., 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のスレッド (操作用の mysqlクライアントと接続してるやつ )が InnoDBログファイルを fsync, バイナリログに write。 pid 6593のスレッド (mysqlbinlogと接続していたやつ )が更新されたバイナリログから read、 fd19(=mysqlbinlogが接続していた TCPソケット )に sendto。sendtoはなぜか成功している (失敗なら戻り値は -1)

1 つ更新してみたときの strace （おまけ）


* 後続の処理を見てみると、どうやらバイナリログに writeが成功した後にもう一度 InnoDBログを fsyncして、あとはバックグラウンドな別のスレッドが ibdata1とか t1.ibdファイルによしなにwriteと fsyncをかけているっぽい（よく出来てるな。。）

もう 1 つ更新してみたときの strace

[pid 6593] read(40, "o{FQ! \4\0\0,\0\0\0\365\2\0\0\0\0\1d2P\20p\5\21\342\227\377\0\32"..., 7479) = 240[pid 6593] read(40, "", 7239) = 0[pid 6593] sendto(19, "-\0\0\212\0o{FQ! \4\0\0,\0\0\0\365\2\0\0\0\0\1d2P\20p\5\21"..., 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をクローズ。ここでプロセスリストからも消えて破棄されてるのかスレッドキャッシュに行ったか。。

あと気になることホンモノのスレーブサーバーの時も同じ動き？　⇒　同じでした。mysql56> show processlist;+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+| Id | User | Host | db | Command | Time | State | Info |+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+| 97 | root | localhost | d1 | Query | 0 | init | show processlist || 100 | replicator | localhost:34060 | NULL | Binlog Dump | 34 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 101 | replicator | localhost:34061 | NULL | Binlog Dump | 8 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL || 102 | replicator | localhost:34062 | NULL | Binlog Dump | 1 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+4 rows in set (0.00 sec)

mysql56> flush logs;Query OK, 0 rows affected (0.03 sec)

mysql56> flush logs;Query OK, 0 rows affected (0.03 sec)

mysql56> show processlist;+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+| Id | User | Host | db | Command | Time | State | Info |+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+| 97 | root | localhost | d1 | Query | 0 | init | show processlist || 102 | replicator | localhost:34062 | NULL | Binlog Dump | 107 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+2 rows in set (0.00 sec)

2回バイナリログが更新されると綺麗になります(INSERT, UPDATE, DELETE, FLUSHでもバイナリログが更新されればなんでもOK）

つまりもともとと全然変わらない動作なんですね。。 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

Documents

Transcript of MySQL clients