MySQL 8.0.0のmysqlコマンドラインクライアントでは `--ssl` オプションの名前が変わった

実は（？） GA後の MySQL 5.7.11でdeprecatedになっていたヤーツ。

The client-side --ssl option is deprecated as of MySQL 5.7.11 and is removed in MySQL 8.0. For client programs, it is preferable to use --ssl-mode instead:
Use --ssl-mode=REQUIRED instead of --ssl=1 or --enable-ssl.
Use --ssl-mode=DISABLED instead of --ssl=0, --skip-ssl, or --disable-ssl.
No explicit --ssl-mode option is equivalent to no explicit --ssl option.
The server-side --ssl option is not deprecated.

MySQL :: MySQL 5.7 Reference Manual :: 7.4.5 Command Options for Secure Connections

結構盛大に変わる。。

$ mysql80 --ssl
mysql: [ERROR] unknown option '--ssl'

$ mysql80 --help | grep ssl
  --ssl-mode=name     SSL connection mode.
  --ssl-ca=name       CA file in PEM format.
  --ssl-capath=name   CA directory.
  --ssl-cert=name     X509 cert in PEM format.
  --ssl-cipher=name   SSL cipher to use.
  --ssl-key=name      X509 key in PEM format.
  --ssl-crl=name      Certificate revocation list.
  --ssl-crlpath=name  Certificate revocation list path.
ssl-ca                            (No default value)
ssl-capath                        (No default value)
ssl-cert                          (No default value)
ssl-cipher                        (No default value)
ssl-key                           (No default value)
ssl-crl                           (No default value)
ssl-crlpath                       (No default value)

`--help` が不完全な気がする（デフォルトを出す方に載ってない）
あと、取り得る値とかも出してくれないのでちょっと不親切。。
引用の通り、今までの `--ssl` と同じように使うには `--ssl-mode=REQUIRED` で良いみたい。

ついでに気づいちゃったんだけど、

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=required -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"
Ssl_cipher      DHE-RSA-AES256-SHA

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=req -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"
Ssl_cipher      DHE-RSA-AES256-SHA

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=r -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"
Ssl_cipher      DHE-RSA-AES256-SHA

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=v -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"         ### vだけだとverify_caとverify_identityの両方があり得るのでエラー
Unknown option to ssl-mode: v
Alternatives are: 'DISABLED','PREFERRED','REQUIRED','VERIFY_CA','VERIFY_IDENTITY'

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=verify_i -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"  ### verify_iでverify_identity相当
ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

$ mysql80 -h127.0.0.1 -P64057 --ssl-mode=verify_c -sse "SHOW SESSION STATUS LIKE 'Ssl_cipher'"  ### verify_cでverify_ca相当
Ssl_cipher      DHE-RSA-AES256-SHA

あ、あー、これ前方一致で補完するやつだ！
5.7.14の時点でそうだった。

MySQL 8.0.0で追加されたROLEの仕組み

正直なんの情報もなくてすごく困ったんだけど、何故か自分のブログ記事に助けられた。

日々の覚書: MariaDB 10.0.5で実装されたROLEを試す


ほぼこの時と同じ。MariaDB 10.0の時はロールを割り当てるユーザーが存在しなくても割り当てられたけど、MySQL 8.0は先にCREATE USERしておかないと割り当てられなかったことくらい。

mysql80> CREATE ROLE sys_select;
Query OK, 0 rows affected (0.00 sec)

mysql80> GRANT SELECT ON mysql.* TO sys_select;
Query OK, 0 rows affected (0.00 sec)

mysql80> SELECT * FROM mysql.user WHERE user = 'sys_select'\G
*************************** 1. row ***************************
                  Host: %
                  User: sys_select
           Select_priv: N
           Insert_priv: N
           Update_priv: N
           Delete_priv: N
           Create_priv: N
             Drop_priv: N
           Reload_priv: N
         Shutdown_priv: N
          Process_priv: N
             File_priv: N
            Grant_priv: N
       References_priv: N
            Index_priv: N
            Alter_priv: N
          Show_db_priv: N
            Super_priv: N
 Create_tmp_table_priv: N
      Lock_tables_priv: N
          Execute_priv: N
       Repl_slave_priv: N
      Repl_client_priv: N
      Create_view_priv: N
        Show_view_priv: N
   Create_routine_priv: N
    Alter_routine_priv: N
      Create_user_priv: N
            Event_priv: N
          Trigger_priv: N
Create_tablespace_priv: N
              ssl_type:
            ssl_cipher:
           x509_issuer:
          x509_subject:
         max_questions: 0
           max_updates: 0
       max_connections: 0
  max_user_connections: 0
                plugin: mysql_native_password
 authentication_string:
      password_expired: Y
 password_last_changed: 2016-09-05 11:55:04
     password_lifetime: NULL
        account_locked: Y
      Create_role_priv: N
        Drop_role_priv: N
1 row in set (0.00 sec)

MariaDB 10.0では is_role なるカラムでロールかどうかを識別していたけど、MySQL 8.0にはそれっぽいカラムはなさげ。account_lockedで代用している気配。

mysql80> GRANT sys_select TO yoku0825;
Query OK, 0 rows affected (0.00 sec)

mysql80> SELECT * FROM default_roles;
Empty set (0.00 sec)

mysql80> SELECT * FROM role_edges;
+-----------+------------+---------+----------+-------------------+
| FROM_HOST | FROM_USER  | TO_HOST | TO_USER  | WITH_ADMIN_OPTION |
+-----------+------------+---------+----------+-------------------+
| %         | sys_select | %       | yoku0825 | N                 |
+-----------+------------+---------+----------+-------------------+
1 row in set (0.00 sec)

ロールのマッピングはmysql.role_edgesテーブルに記録される。

$ mysql80 -uyoku0825

mysql80> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| yoku0825@%     |
+----------------+
1 row in set (0.00 sec)

mysql80> SELECT current_role();
+----------------+
| current_role() |
+----------------+
| NONE           |
+----------------+
1 row in set (0.00 sec)

mysql80> SHOW GRANTS;
+------------------------------------------+
| Grants for yoku0825@%                    |
+------------------------------------------+
| GRANT USAGE ON *.* TO `yoku0825`@`%`     |
| GRANT `sys_select`@`%` TO `yoku0825`@`%` |
+------------------------------------------+
2 rows in set (0.00 sec)

mysql80> SELECT user, host FROM mysql.user;
ERROR 1142 (42000): SELECT command denied to user 'yoku0825'@'localhost' for table 'user'

mysql80> SET ROLE sys_select;
Query OK, 0 rows affected (0.00 sec)

mysql80> SELECT current_role();
+------------------+
| current_role()   |
+------------------+
| `sys_select`@`%` |
+------------------+
1 row in set (0.00 sec)

mysql80> SELECT user, host FROM mysql.user;
+------------+-----------+
| user       | host      |
+------------+-----------+
| sys_select | %         |
| yoku0825   | %         |
| mysql.sys  | localhost |
| root       | localhost |
+------------+-----------+
4 rows in set (0.00 sec)

まるっきり MariaDBのとき と同じで助かるというか捗るというか。

MariaDBは10.1からとされていた（10.1使ってないから本当にされたのか知らない。。）デフォルトロールも実装されている。
勘に任せてALTER USERしてみた。

mysql80> ALTER USER yoku0825 DEFAULT ROLE sys_select;
Query OK, 0 rows affected (0.01 sec)

mysql80> SELECT * FROM default_roles;
+------+----------+-------------------+-------------------+
| HOST | USER     | DEFAULT_ROLE_HOST | DEFAULT_ROLE_USER |
+------+----------+-------------------+-------------------+
| %    | yoku0825 | %                 | sys_select        |
+------+----------+-------------------+-------------------+
1 row in set (0.00 sec)

$ mysql80 -uyoku0825
mysql80> SELECT current_role();
+------------------+
| current_role()   |
+------------------+
| `sys_select`@`%` |
+------------------+
1 row in set (0.00 sec)

なるほど大正解。しかしこれ、ユーザーアカウントとROLEを区別してないってことは、もしかして逆もできるのかしら。

mysql80> GRANT yoku0825 TO sys_select;
Query OK, 0 rows affected (0.01 sec)

mysql80> SELECT * FROM role_edges;
+-----------+------------+---------+------------+-------------------+
| FROM_HOST | FROM_USER  | TO_HOST | TO_USER    | WITH_ADMIN_OPTION |
+-----------+------------+---------+------------+-------------------+
| %         | sys_select | %       | yoku0825   | N                 |
| %         | yoku0825   | %       | sys_select | N                 |
+-----------+------------+---------+------------+-------------------+
2 rows in set (0.00 sec)

( д ) ﾟ ﾟ やっぱりできた
アカウント同士でも試してみたけど

mysql80> GRANT root@localhost TO yoku0825;
Query OK, 0 rows affected (0.00 sec)

$ mysql80 -uyoku0825
mysql80> SET ROLE root@localhost;
Query OK, 0 rows affected (0.00 sec)

mysql80> SET GLOBAL innodb_buffer_pool_dump_now= 1;
Query OK, 0 rows affected (0.00 sec)

おおおおおお…ユーザーとロールは区別した方がいいと思うんだけど、設定次第でこうも出来ると…。
ロール機能自体はウェルカムですねべんり。

MySQL 8.0.0でSET PERSIST構文が出来て、my.cnfへの反映忘れが防げそう

MySQL 8.0.0時代のmy.cnfの探り方 の続き。

ここに /etc/my.cnf から読み込まれた innodb_buffer_pool_size = 128MB があるじゃろ？ （AA略）

mysql80> SELECT variable_name, variable_source, variable_path, variable_value FROM performance_schema.variables_info JOIN performance_schema.global_variables USING(variable_name) WHERE variable_name = 'innodb_buffer_pool_size';
+-------------------------+-----------------+---------------+----------------+
| variable_name           | variable_source | variable_path | variable_value |
+-------------------------+-----------------+---------------+----------------+
| innodb_buffer_pool_size | GLOBAL          | /etc/my.cnf   | 134217728      |
+-------------------------+-----------------+---------------+----------------+
1 row in set (0.01 sec)

これを

mysql80> SET PERSIST innodb_buffer_pool_size = 256 * 1024 * 1024;
Query OK, 0 rows affected (0.00 sec)

mysql80> SELECT variable_name, variable_source, variable_path, variable_value FROM performance_schema.variables_info JOIN performance_schema.global_variables USING(variable_name) WHERE variable_name = 'innodb_buffer_pool_size';
+-------------------------+-----------------+---------------+----------------+
| variable_name           | variable_source | variable_path | variable_value |
+-------------------------+-----------------+---------------+----------------+
| innodb_buffer_pool_size | DYNAMIC         |               | 268435456      |
+-------------------------+-----------------+---------------+----------------+
1 row in set (0.00 sec)

こうじゃ。

(　ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ） …！？


＿人人人人人人人＿
＞　SET PERSIST　＜
￣Y^Y^Y^Y^Y^Y^Y^￣


ではmysqldを再起動して、

mysql80> SELECT variable_name, variable_source, variable_path, variable_value FROM performance_schema.variables_info JOIN performance_schema.global_variables USING(variable_name) WHERE variable_name = 'innodb_buffer_pool_size';
+-------------------------+-----------------+---------------------------------------+----------------+
| variable_name           | variable_source | variable_path                         | variable_value |
+-------------------------+-----------------+---------------------------------------+----------------+
| innodb_buffer_pool_size | PERSISTED       | /usr/mysql/8.0.0/data/mysqld-auto.cnf | 134217728      |
+-------------------------+-----------------+---------------------------------------+----------------+
1 row in set (0.00 sec)

$ cat /usr/mysql/8.0.0/data/mysqld-auto.cnf
{ "mysql_server": {"innodb_buffer_pool_size": "134217728" } }

え…書き換わってないじゃんダメじゃん。。

バグ（だと思う）で、innodb_buffer_pool_sizeだけはSET PERSISTで指定した値じゃなくて、SET PERSISTで指定する **前の** 値が保存されちゃってるぽい。
他のサーバー変数はイケた。

MySQL Bugs: #82905: SET PERSIST stores previous value of innodb_buffer_pool_size to mysqld-auto.cnf


innodb_io_capacity_maxとかならこの通り。

mysql80> SET PERSIST innodb_io_capacity_max = 8000;
Query OK, 0 rows affected (0.00 sec)

$ cat /usr/mysql/8.0.0/data/mysqld-auto.cnf
{ "mysql_server": {"innodb_io_capacity_max": "8000" } }

なお、SET PERSISTできるのは当然ながら SET GLOBAL 可能なオプションだけ。

mysql80> SET PERSIST last_insert_id = 2;
ERROR 1228 (HY000): Variable 'last_insert_id' is a SESSION variable and can't be used with SET GLOBAL

ところで、セッションスコープしかない変数をを手でmysqld-auto.cnfに書いたら、mysqldが異常終了じゃなくてクラッシュなさるようになった。。
（存在しない変数ならワーニングで無視してくれるんだけど、存在してかつセッションスコープしかないやつだと落ちる。。）

MySQL 8.0.0時代のmy.cnfの探り方

以前、straceで開いてるmy.cnfを調べて…とかやってたけど、それももう過去の話。

日々の覚書: ラッパーも含めて mysqldが起動するときにどのmy.cnfを舐めてるのか知りたいとき


MySQL 8.0.0では performance_schema.variables_info という便利なテーブルができた。

mysql80> SELECT * FROM performance_schema.variables_info LIMIT 10;
+--------------------------+-----------------+---------------+-----------+----------------------+
| VARIABLE_NAME            | VARIABLE_SOURCE | VARIABLE_PATH | MIN_VALUE | MAX_VALUE            |
+--------------------------+-----------------+---------------+-----------+----------------------+
| auto_increment_increment | COMPILED        |               | 1         | 65535                |
| auto_increment_offset    | COMPILED        |               | 1         | 65535                |
| autocommit               | COMPILED        |               | 0         | 0                    |
| automatic_sp_privileges  | COMPILED        |               | 0         | 0                    |
| avoid_temporal_upgrade   | COMPILED        |               | 0         | 0                    |
| back_log                 | COMPILED        |               | 0         | 65535                |
| basedir                  | COMMAND_LINE    |               | 0         | 0                    |
| big_tables               | COMPILED        |               | 0         | 0                    |
| bind_address             | COMPILED        |               | 0         | 0                    |
| binlog_cache_size        | COMPILED        |               | 4096      | 18446744073709551615 |
+--------------------------+-----------------+---------------+-----------+----------------------+
10 rows in set (0.00 sec)

パラメーターの名前と最小値、最大値を表示してくれるのはいいんだけど、それなら現在の値も一緒に出してほしいところ。
performance_schema.global_variablesあたりとJOINすればいいだけだから、sysに入ってくるかしら。

まあ、そんなことよりこれの凄そうなところは（取り敢えず、このクエリーはJOINしてある）

mysql> SELECT variable_name, variable_source, variable_path, variable_value FROM performance_schema.variables_info JOIN performance_schema.global_variables USING(variable_name) WHERE variable_path <> '';
+-------------------------+-----------------+---------------+----------------+
| variable_name           | variable_source | variable_path | variable_value |
+-------------------------+-----------------+---------------+----------------+
| innodb_buffer_pool_size | GLOBAL          | /etc/my.cnf   | 1073741824     |
+-------------------------+-----------------+---------------+----------------+
1 row in set (0.01 sec)

variable_pathにどのmy.cnfから読んできたか書いてくれるところ…なんだけど、残念ながらこれ、 "!include" に対応していないぽい。

$ cat /etc/my.cnf
[mysqld]
innodb_buffer_pool_size= 1G

!include /usr/mysql/8.0.0/test.cnf


$ cat /usr/mysql/8.0.0/test.cnf
[mysqld]
innodb_buffer_pool_size= 256M

こう設定した場合、設定が後勝ちするため innodb_buffer_pool_sizeは256MBで起動してくる。（ 日々の覚書: my.cnfのパラメータ優先順位 ）
しかしこう、

mysql> SELECT variable_name, variable_source, variable_path, variable_value FROM performance_schema.variables_info JOIN performance_schema.global_variables USING(variable_name) WHERE variable_path <> '';
+-------------------------+-----------------+---------------+----------------+
| variable_name           | variable_source | variable_path | variable_value |
+-------------------------+-----------------+---------------+----------------+
| innodb_buffer_pool_size | GLOBAL          | /etc/my.cnf   | 268435456      |
+-------------------------+-----------------+---------------+----------------+
1 row in set (0.01 sec)

/etc/my.cnfが見えちゃうという(´･ω･｀)
（どうやら仕様らしい。 MySQL Bugs: #82861: performance_schema.variable_info.variable_path doesn't reflect config-including でFeature Requestとして出し直す、みたいな話になった）

variable_sourceの値はこのあたりをとることまでは確かめた。

パラメーターを設定した場所	variable_source
/etc/my.cnf	GLOBAL
$basedir/my.cnf	SERVER
—defaults-file=/etc/my.cnf	EXPLICIT
—defaults-extra-file=/etc/my.cnf	EXTRA
—innodb-buffer-pool-size=256M	COMMAND_LINE
SET GLOBAL innodb_buffer_pool_size= 256M	DYNAMIC

​

mysql> SHOW CREATE TABLE performance_schema.variables_info\G
*************************** 1. row ***************************
       Table: variables_info
Create Table: CREATE TABLE `variables_info` (
  `VARIABLE_NAME` varchar(64) NOT NULL,
  `VARIABLE_SOURCE` enum('COMPILED','GLOBAL','SERVER','EXPLICIT','EXTRA','USER','LOGIN','COMMAND_LINE','PERSISTED','DYNAMIC') DEFAULT NULL,
  `VARIABLE_PATH` varchar(1024) DEFAULT NULL,
  `MIN_VALUE` varchar(64) DEFAULT NULL,
  `MAX_VALUE` varchar(64) DEFAULT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
1 row in set (0.01 sec)

ほとんどのパラメーターがCOMPILEDになってるから、COMPILEDはコンパイル時に設定したデフォルトで、あと謎いのは USER, LOGIN くらいですかね。PERSISTED はまたあとで。

MySQL 8.0.0からmysql_install_dbがなくなってる、ついでにbinディレクトリ探求

日々の覚書: MySQL 5.7.6でデータベースの初期化が変わる mysql_install_dbからmysqld --initialize

1年半の時を経て、ついに消えた様子。
（MySQL 5.7の時点で、mysql_install_dbはscriptディレクトリーからbinディレクトリーに移動になってた）

$ ll bin/mysql_install_db
ls: cannot access bin/mysql_install_db: No such file or directory

あと、SDIファイル関連ぽい ibd2sdi とかいうファイルがあるけど使い方はいまいち謎。

$ bin/ibd2sdi -d >(cat -) data/ibdata1
[INFO] ibd2sdi: SDI from both copies is empty.

それ以外は特になさげ

$ diff <(ls -1 /usr/mysql/5.7.14/bin) <(ls -1 /usr/mysql/8.0.0/bin)
1c1,2
< innochecksum
---
> ibd2sdi
> innochecksum
12c13
< mysql_client_test
---
> mysql_client_test_embedded
15a17
> mysqld-debug
19a22
> mysql_embedded
21,22d23
< mysql_install_db
< mysql_plugin
28c29
< mysqltest
---
> mysqltest_embedded

ついでにplugindirも漁ってみるけど、これはコンパイルオプションとかに依存してそうな気もするので何とも言えない。
component_example*が気になる。mysql.componentテーブルと関連があるのかな。

$ diff <(ls -1 /usr/mysql/5.7.14/lib/plugin) <(ls -1 /usr/mysql/8.0.0/lib/plugin)
2d1
< auth.so
4,5c3,5
< auth_test_plugin.so
< daemon_example.ini
---
> component_example_component1.so
> component_example_component2.so
> component_example_component3.so
11d10
< libdaemon_example.so
39,42d37
< qa_auth_client.so
< qa_auth_interface.so
< qa_auth_server.so
< replication_observers_example_plugin.so

MySQL 8.0.0でmysqlスキーマの中身がほぼ全部InnoDBになった

MySQL 8.0でmysqlスキーマの中身が全部InnoDBになった。


5.7だと↓だったのが、

mysql57> SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' ORDER BY table_name;
+---------------------------+--------+
| table_name                | engine |
+---------------------------+--------+
| columns_priv              | MyISAM |
| db                        | MyISAM |
| engine_cost               | InnoDB |
| event                     | MyISAM |
| func                      | MyISAM |
| general_log               | CSV    |
| gtid_executed             | InnoDB |
| help_category             | InnoDB |
| help_keyword              | InnoDB |
| help_relation             | InnoDB |
| help_topic                | InnoDB |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| ndb_binlog_index          | MyISAM |
| plugin                    | InnoDB |
| proc                      | MyISAM |
| procs_priv                | MyISAM |
| proxies_priv              | MyISAM |
| servers                   | InnoDB |
| server_cost               | InnoDB |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | MyISAM |
| time_zone                 | InnoDB |
| time_zone_leap_second     | InnoDB |
| time_zone_name            | InnoDB |
| time_zone_transition      | InnoDB |
| time_zone_transition_type | InnoDB |
| user                      | MyISAM |
+---------------------------+--------+
31 rows in set (0.01 sec)

↓が8.0.0

mysql80> SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' ORDER BY table_name;
+---------------------------+--------+
| TABLE_NAME                | ENGINE |
+---------------------------+--------+
| column_stats              | InnoDB |
| columns_priv              | InnoDB |
| component                 | InnoDB |
| db                        | InnoDB |
| default_roles             | InnoDB |
| engine_cost               | InnoDB |
| func                      | InnoDB |
| general_log               | CSV    |
| gtid_executed             | InnoDB |
| help_category             | InnoDB |
| help_keyword              | InnoDB |
| help_relation             | InnoDB |
| help_topic                | InnoDB |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| plugin                    | InnoDB |
| procs_priv                | InnoDB |
| proxies_priv              | InnoDB |
| role_edges                | InnoDB |
| server_cost               | InnoDB |
| servers                   | InnoDB |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | InnoDB |
| time_zone                 | InnoDB |
| time_zone_leap_second     | InnoDB |
| time_zone_name            | InnoDB |
| time_zone_transition      | InnoDB |
| time_zone_transition_type | InnoDB |
| user                      | InnoDB |
+---------------------------+--------+
32 rows in set (0.02 sec)

general_log, slow_logは相変わらずとして、それ以外はInnoDBになった。
column_stats, component, default_roles, role_edgesが新設テーブル、ndb_binlog_index, event, procがなくなってる。ndb_binlog_indexはコンパイル方法が違うのかとも思うけど取り敢えず置いておく。


あと、mysqld --initializeした中でも、 **InnoDB: Creating foreign key constraint system tables.** って書いてあるので、おおおって感じがした。

$ bin/mysqld --no-defaults --initialize-insecure --basedir=./ --datadir=./data
2016-09-05T01:17:12.549926Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2016-09-05T01:17:12.550002Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
2016-09-05T01:17:12.550282Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-09-05T01:17:12.842536Z 1 [Warning] InnoDB: New log files created, LSN=49311
2016-09-05T01:17:12.890633Z 1 [Warning] InnoDB: Creating foreign key constraint system tables.
2016-09-05T01:17:14.176756Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 7a644122-7306-11e6-bba7-02018582356a.
2016-09-05T01:17:14.185156Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2016-09-05T01:17:14.185650Z 3 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.

FLUSH PRIVILEGESやFLUSH TABLESはバイナリーログに書かれるのでgtid_executedに記録されるよ

や、まあ、バイナリーログに吐かれるのはマニュアルに書いてあってそうなんだけれども、GTID振られるのは失念してた。

一つだけマニュアルが誤解を招く表現。

デフォルトでは、サーバーは FLUSH ステートメントをバイナリログに書き込み、それらがレプリケーションスレーブにレプリケートされるようにします。ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG キーワード、またはそのエイリアス LOCAL を指定します。

注記
FLUSH LOGS、FLUSH TABLES WITH READ LOCK (テーブルリスト付き、またはなし)、および FLUSH TABLES tbl_name ... FOR EXPORT は、スレーブにレプリケートされると問題が発生するため、どのような場合でもバイナリログに書き込まれません。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.6.3 FLUSH 構文


FLUSH LOGSのうちロギングされないのは「バイナリーログをフラッシュする」時だけで、追加引数なしのFLUSH LOGSとFLUSH BINARY LOGSだけがバイナリーロギングされない。

https://github.com/mysql/mysql-server/blob/mysql-5.6.32/sql/sql_reload.cc#L156-L170

それ以外のFLUSH SLOW LOGSやFLUSH ENGINE LOGS, FLUSH PRIVILEGES, WITH READ LOCKなしのFLUSH TABLESはしっかりバイナリーロギングされてスレーブでも実行される。迂闊にFLUSH TABLESとかマスターでやると、スレーブでも実行されてクエリーキャッシュが吹っ飛ばされるとか、マスターとスレーブの mysql.user がズレてる状態でFLUSH PRIVILEGESがレプリカされると地獄が見えるなとか思いますたん。

FLUSH TABLES WITH READ LOCK とFLUSH TABLES .. FOR EXPORT はそれぞれ違う関数を通り、それらの関数の後に write_bin_log は呼ばれない（ので、コイツらはロギングされることはない）


簡単なところなので、コードを読むにはなかなか面白かった。