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に残っていたのはご愛嬌という感じ…？

特に気に入った新機能はないです。
--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してみたり。

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
• 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
• 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
• Ctrl+Cでmysqlbinlogを切ってもコネクショ
ンが残留し続ける。
⇒Bugs上げました。上げたばかりなのでVerifyされるかどうかも謎
です。

--- ここからadded at 2013/03/18 ---

残念なことになっていたのyoku0825の脳髄
であったことが判明したので、ここから検
証過程の追記です。

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

+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| Info |
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| 69 | root | localhost | d1 | Query | 0 | init
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+

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

まっさらな状態
+----+------+-----------+------+---------+------+-------+------------------+
+----+------+-----------+------+---------+------+-------+------------------+
+----+------+-----------+------+---------+------+-------+------------------+

# lsof -p 6382
..
mysqld 6382 mysql 18u IPv4 7355566 0t0 TCP *:64056 (LISTEN)
..

# netstat -antp | grep "6382/mysqld"
tcp 0 0 0.0.0.0:64056 0.0.0.0:* LISTEN 6382/mysqld

mysqlbinlog接続、切断前
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| Info |
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+

# lsof -p 6382
..
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)
..

tcp 0 0 192.168.198.214:64056 192.168.198.214:49762 ESTABLISHED 6382/mysqld

mysqlbinlog切断
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| Info |
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+

# lsof -p 6382
..
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)
..

tcp 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));

+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| Info |
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+
| 97 | root | localhost | d1 | Query | 0 | init
+----+------------+--------------------------------------+------+------------------+------+-----------------------------------
------------------------------------+------------------+

# lsof -p 6382
..
mysqld 6382 mysql 19u sock 0,6 0t0 7625437 can't identify protocol
..


ときの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(更新したテーブル)です。

ときのstrace
[pid 6598] fsync(9) = 0
[pid 6593] read(40, "TwFQ! 400,0005200001d2P20p521342227377032"..., 7719) = 240
[pid 6593] read(40, "", 7479) = 0
[pid 6398] fsync(9) = 0
[pid 6400] fsync(4) = 0
[pid 6390] pwrite(49, "34516e,00033773773773773773773773770000$K=27E277000000"..., 16384, 49152
<unfinished ...>
[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)

ときのstrace（おまけ）
[pid 6598] fsync(9) = 0
[pid 6593] read(40, "TwFQ! 400,0005200001d2P20p521342227377032"..., 7719) = 240
[pid 6593] read(40, "", 7479) = 0
[pid 6398] fsync(9) = 0
[pid 6400] fsync(4) = 0
[pid 6390] pwrite(49, "34516e,00033773773773773773773773770000$K=27E277000000"..., 16384, 49152
<unfinished ...>
[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つ更新してみた
mysql56> INSERT INTO t1 VALUES (2, md5(2));

+----+------+-----------+------+---------+------+-------+------------------+
+----+------+-----------+------+---------+------+-------+------------------+
+----+------+-----------+------+---------+------+-------+------------------+

# lsof -p 6382
..
..


もう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をクローズ。
ここでプロセスリストからも消えて破棄されてるのかスレッドキャッ
シュに行ったか。。

あと気になること
ホンモノのスレーブサーバーの時も同じ動き？ ⇒ 同じでした。
+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
| 100 | replicator | localhost:34060 | NULL | Binlog Dump | 34 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+

mysql56> flush logs;

mysql56> flush logs;

+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
+-----+------------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie MySQL clients

Ähnlich wie MySQL clients (20)

Mehr von yoku0825

Mehr von yoku0825 (20)

MySQL clients