Your SlideShare is downloading. ×
MySQL clients
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

MySQL clients

3,949
views

Published on

mysqlbinlogが残る問題、バグっていたのはyoku0825の脳髄でした。 …

mysqlbinlogが残る問題、バグっていたのはyoku0825の脳髄でした。
"modified version 2"で追記してあります。


0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,949
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
8
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MySQL Clients!at MySQL Nippon Association 2013/03/15 yoku0825 modified version 2.
  • 2. I’m yoku0825, working as DBAfor 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.
  • 3. 平塚さんOracle ACE認定おめでとうございます m(_”_)m
  • 4. あと ついでにMySQL5.6 GAおめでとうございま す m(_”_)m
  • 5. 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 :)
  • 6. There are many kind offunctional 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..
  • 7. But! Do you knowhow function has been added to clients?
  • 8. mysqld以外にも(意外と)面白いことありますよ! …というお話をしますが、 そんな大それたものではないです。
  • 9. MySQL Client & Utility Programs• mysql• mysqladmin• mysqldump• mysql_install_db• (My Favorite!) mysql_config_editor• (cool!) mysqlbinlog And on..
  • 10. mysql The MySQL Command-Line Tool• --histignore 5.5までは$HOME/.mysql_historyになんでもかんでも記録されていたが、特定のキーワードを含むエントリを記録しない様に設定可能。 デフォルトでは“*IDENTIFIED*:*PASSWORD*“が記録から弾かれる(セミコロンはORとして解釈されます) ⇒特に構文解析しているわけではないので、 SELECT PASSWORD(‘hoge’); も記録から弾かれるようになります。
  • 11. MySQL 5.5.30
  • 12. MySQL 5.6.10
  • 13. mysql The MySQL Command-Line Tool• --default-character-set おなじみのこのパラメータにujis, sjis, cp932など(UTF-8以外のマルチバイト、という感じ。big5とかも)を渡すとSegmentation faultするバグが!w ⇒.mysql_historyに触るあたりのマルチバイト判定に問題がありそう。 ⇒なのでmysqlクライアントだけです。 http://bugs.mysql.com/bug.php?id=68107 それまでは”SET NAMES ujis;”でしのぎましょう。。 ⇒UTF-8使えという神託的なものでもある気がしますが。
  • 14. 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くらいですかね。
  • 15. 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以外全てがコメントアウトされています。
  • 16. --random-passwords
  • 17. $HOME/.mysql_secret
  • 18. condition of mysql.user
  • 19. contents of $MYSQL_HOME/my.cnf
  • 20. 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
  • 21. mysql_config_editor MySQL Configuration Utility• $HOME/.mylogin.cnf $HOME/.my.cnfに [mysql] user=tpcc password=.. [mysqldump] user=root password=.. と書いておくとコマンドライン引数で渡す必要がありませんでしたが、平文で書くのはどうも嫌でした。
  • 22. .mylogin.cnfを使ってみる
  • 23. mysqldumpだけ別のユーザーで
  • 24. 任意のlogin-pathを指定可能
  • 25. 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に上げてみたり(誰も気にしないだろうけど)
  • 26. 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によって作成されるファイル名になります。
  • 27. tail -f的にマスターの更新を待機
  • 28. 更新してみる
  • 29. FLUSH LOGSしても追従する
  • 30. --rawを組み合わせてバックアップ 開始 更新 FLUSH LOGS
  • 31. 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を使うのが良いです!
  • 32. 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と互換性のある形でバイナリログを吐きます。 ⇒先にマスターをバージョンアップするとかしてはいけませんよ!
  • 33. しかし。。
  • 34. 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の脳髄であったことが判明したので、ここから検証過程の追記です。
  • 35. 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 toslave; 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 toslave; 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 toslave; 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 toslave; 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 toslave; waiting for binlog to be updated | NULL |+----+------------+--------------------------------------+------+------------------+--------+-----------------------------------------------------------------------+------------------+6 rows in set (0.00 sec)プロセスはがっつり残ってらっしゃる。66, 67が当日から残っていたやつ、70~72は今日起動&停止したやつ。
  • 36. 何か更新してみる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 toslave; 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 toslave; 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 toslave; waiting for binlog to be updated | NULL |+----+------------+--------------------------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+4 rows in set (0.00 sec)…古いの(MyNA会当日に試してたやつ)が消えた。ついさっき接続&切断した70~72のクライアントは残っている。
  • 37. もうひとつ更新してみるmysql56> drop table t22;Query OK, 0 rows affected (0.02 sec)mysql56> show processlist;+----+------+-----------+------+---------+------+-------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+-----------+------+---------+------+-------+------------------+| 69 | root | localhost | d1 | Query | 0 | init | show processlist |+----+------+-----------+------+---------+------+-------+------------------+1 row in set (0.00 sec)ついさっき接続したヤツも消えた。この時点でだいーぶアタリがついたので、この後はエビデンスです。
  • 38. まっさらな状態mysql56> show processlist;+----+------+-----------+------+---------+------+-------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+-----------+------+---------+------+-------+------------------+| 69 | root | localhost | d1 | Query | 0 | init | show processlist |+----+------+-----------+------+---------+------+-------+------------------+1 row in set (0.00 sec)# 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
  • 39. 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 toslave; 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
  • 40. 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 toslave; 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を止めたところでは当然何の出力もなし。
  • 41. 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 toslave; 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 cant identify protocol..# netstat -antp | grep "6382/mysqld"tcp 0 0 0.0.0.0:64056 0.0.0.0:* LISTEN 6382/mysqld
  • 42. 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(更新したテーブル)です。
  • 43. 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)
  • 44. 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をかけているっぽい(よく出来てるな。。)
  • 45. もう1つ更新してみたmysql56> INSERT INTO t1 VALUES (2, md5(2));Query OK, 0 rows affected (0.01 sec)mysql56> show processlist;+----+------+-----------+------+---------+------+-------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+-----------+------+---------+------+-------+------------------+| 97 | root | localhost | d1 | Query | 0 | init | show processlist |+----+------+-----------+------+---------+------+-------+------------------+1 row in set (0.00 sec)# 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
  • 46. もう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をクローズ。ここでプロセスリストからも消えて破棄されてるのかスレッドキャッシュに行ったか。。
  • 47. あと気になることホンモノのスレーブサーバーの時も同じ動き? ⇒ 同じでした。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)
  • 48. つまりもともとと全然変わらない動作なんですね。。orzお騒がせしました。。。orz( ´-`).oO(でも色々調べられて楽しかった)--- ここまでadded at 2013/03/18 ---
  • 49. How are they?Do you feel something WAK-WAK? I introduced only I have known, but there are more functional addition in the world.
  • 50. Do you come with us?Let’s research and pain and claim and laugh and enjoy with MySQL.
  • 51. Thank you!ご清聴ありがとうございました!