実は（？） 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 …

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 …

以前、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                |
| …

日々の覚書: 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 …

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 |
| …

MySQL5.7.14のGroup Replication DMR版が先月リリースされていたので、基本的な動作確認をしました。
まだ、DMR版なので前回の5.7.10とまた微妙に異なっていて、
group_replication_peer_addressesがgroup_replication_group_seedsに代わっていたり、
group_replication_recovery_userやgroup_replication_recovery_passwordが無くなっていたりします。

MySQL Group Replication: A Quick Start Guide
http://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/

MySQL5.7.10版での検証：　MYSQL GROUP REPLICATION
http://variable.jp/2016/07/18/mysql-group-replication/

…

MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。

MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。

UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。

utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。

登録

接続が utf8mb4 でカラムが utf8mb4

あたりまえですが、そのまま登録されます。

mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺');
mysql> select * from utf8mb4;
+-------------------------+
| c                       |
+-------------------------+
| 美味しい🍣と🍺 …

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

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

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

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

mikasafabric for MySQL が何なのかについては こちら

取り敢えずビルド方法のメモ。雑に。

#!/bin/bash

version="0.1.1"
dirname="mikasafabric-${version}"

rm -rf ~/rpmbuild
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

if [ -d ~/$dirname ] ; then
  rm -rf ~/$dirname
fi
git clone https://github.com/gmo-media/mikasafabric.git ~/$dirname
cd ~/$dirname
git checkout ${version}
cd $OLDPWD

tar czf ~/rpmbuild/SOURCES/${dirname}.tar.gz $dirname
rpmbuild -bb ~/$dirname/mikasafabric.spec

ビルドにはpython-develとrpm-buildが必要。実際にmikasafabricを動かすにはmysql-connector-pythonが必要。CentOS …

ログポジションベースのレプリケーションの場合は、レプリケーション障害発生時にスレーブでSKIP処理を容易に行う事ができましたが、GTIDモードの場合は以下のように空のトランザクションを実行して、エラー対応をする必要がありました。

mysqlslavetrxを利用しない場合の例

root@localhost [sakila]> stop slave;
Query OK, 0 rows affected (0.03 sec)

root@localhost [sakila]> SET GTID_NEXT = "3edaa0b8-3e39-11e4-9df1-080027f5bf08:54";
Query OK, 0 rows affected (0.00 sec)

root@localhost [sakila]> begin; commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

root@localhost [sakila]> SET GTID_NEXT = "3edaa0b8-3e39-11e4-9df1-080027f5bf08:55";
Query OK, 0 rows affected (0.00 sec)

root@localhost [sakila]> begin; commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

root@localhost [sakila]> SET …