日々の覚書: MySQL 5.7.6からSSL周りのセットアップが扱いやすくなった のmysql_ssl_rsa_setup がそのまま/etc/init.d/mysqld の中で呼ばれるようになった…というだけの話なんですが、理屈を知らないとエラーログが矛盾してそうに思えることになっていたので解説がてら。

# rpm -i mysql-community-server-5.7.8-0.3.rc.el5.x86_64.rpm mysql-community-common-5.7.8-0.3.rc.el5.x86_64.rpm mysql-community-client-5.7.8-0.3.rc.el5.x86_64.rpm mysql-5.7.8-0.3.rc.el5.x86_64.rpm mysql-community-libs-5.7.8-0.3.rc.el5.x86_64.rpm mysql-community-libs-compat-5.7.8-0.3.rc.el5.x86_64.rpm
..

# less /var/log/mysqld.log
2015-07-15T07:44:47.363530Z 0 [Warning] InnoDB: New log files created, LSN=45790
2015-07-15T07:44:47.504281Z 0 [Warning] InnoDB: Creating foreign key …

my.cnfの[mysqld]セクションに require_secure_transport と書いておくと、SSL接続を強要できるらしい。

MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables

# service mysqld restart --require_secure_transport
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]

$ mysql -uroot

mysql> SELECT @@require_secure_transport;
+----------------------------+
| @@require_secure_transport |
+----------------------------+
|                          1 |
+----------------------------+
1 row in …

MySQL 5.7.6から入ったgenerated column、STOREDで作るとデータ領域に計算後の結果が格納されてインデックスも貼れるようになるというシロモノだったのが、5.7.8ではVIRTUALで作るとデータ領域には計算後の結果が格納されないけど *インデックスは計算後の値を使って貼れるようになった* 

日々の覚書: MySQL 5.7.6のgenerated columnは関数インデックスの夢を見るか

InnoDB: InnoDB now supports secondary indexes on virtual generated columns. A secondary index on a virtual generated column stores the column's generated values within the records of the index. Such indexes can be scanned and searched more efficiently than virtual generated columns, which are computed “on the fly” when rows are read.
…

TL;DR

MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。

ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は  …

TL;DR

MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。

ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は  …

STRICT_TRANS_TABLESが暗黙のデフォルトになったことが俺の中で有名なMySQL 5.7ですが、MySQL 5.7.8でまたちょっと変更になるらしい。

MySQL :: MySQL 5.7 Reference Manual :: 5.1.7 Server SQL Modes


5.7.4から5.7.7の間までは、STRICT_{TRANS|ALL}_TABLESは "5.6までのSTRICT_{TRANS|ALL}_TABLES" + "ERROR_FOR_DIVISION_BY_ZERO" + "NO_ZERO_DATE" + "NO_ZERO_IN_DATE" でした。
これが5.7.8からもとに戻ります。STRICT_TRANS_TABLESは5.6までのSTRICT_TRANS_TABLESと同じ効果を持つようになり、同時に暗黙のデフォルトにERROR_FOR_DIVISION_BY_ZERO
, NO_ZERO_DATE, NO_ZERO_IN_DATEが追加されて、動作としては5.7.7までと同じです。


…

昨日の 日々の覚書: MySQL 5.7では迂闊にperformance_schemaをOFFするとSHOW STATUSが使えない の派生バージョン。

MySQL 5.7.8以降、show_compatibility_56= 0が暗黙のデフォルトになり、SHOW VARIABLESとかはinformation_schemaではなくperformance_schemaを見に行くようになる。performance_schema.*_variablesテーブルにSELECT権限がないとSHOW VARIABLESは転ける。

さて…レプリケーションスレーブを作ろうと思った時、どんな権限を持ったユーザーを作るか。
俺ならこうだ。

mysql> CREATE USER replicator;
Query OK, 0 rows affected (0.07 …

オンラインで色々なDDL処理が出来るのは、サービス提供側も、利用者も、DBAとしても
非常に便利な機能かと思います。MySQLは4.1からUnicode対応していたので、
10年弱程利用してますが、Online DDLが利用可能になるまでは、
夜中のユーザーが少ない時間にテーブル定義を変更していたりする事も多々ありました。
MySQL5.6以降のオンラインDDLはそういったメンテナンス対応の方には、非常に便利で有難い機能かと思います。

オンライン処理可能かどうかは、14.11.1. オンライン DDL の概要で確認する事が出来ます。
手元で簡単に確認したい場合は、以下のオプションで処理を指定して確認する事が可能です。

…

動作は5.7.7で確認していて、 5.7.8で暗黙のデフォルトがOFFになるって書いてある のでやってみた。

MySQL 5.7.6から show_compatibility_56 というサーバー変数が追加されている。

SHOW {GLOBAL|SESSION} STATUS, SHOW {GLOBAL|SESSION} VARIABLES は今まで内部的にinformation_schemaのテーブルを叩いていた。これをperformance_schemaのテーブルを叩くように変えるのがこのパラメーター。

ONだとinformation_schemaから、OFFだとperformance_schemaから情報を取ってくる。

mysql57> SELECT @@version;
+--------------+
| …

MySQLのmysqlbinlogコマンドでは、MySQL5.6からリモートにあるバイナリーログを読み取る事が可能になりましたが、SSLを利用した通信の暗号化はサポートされておりませんでした。

次期メジャーバージョンのMySQL5.7では、ここら辺も機能拡張されておりmysqlbinlogコマンドを利用して、リモートのバイナリーログを読み込み場合にもSSLを利用した通信の暗号化を行う事が出来るようになりました。
Firewall、セキュリティ機器、セグメント分割された環境で、何処まで必要になるかは状況次第ですが、
リモートサーバーが自然災害対策の為に、自分でインフラを準備する必要が無いPublicクラウド上にある場合などに通信の暗号化が出来ると安心ですね。
…